Posts by andyinfsnet

    I have a NdcuA5 on one and a Picocom4 on the other side.

    Only one application per device, but also other threads (see example attach). We transmit about say 2000 bytes/ sec in my test, in reality it is less but may increase to such. A Telegram is about 50-60 bytes long, 4 byte overhead the other is data, variable lentgh.

    Baudrate 115200, Data 8, Stop 1, parity none.

    Both sides may transmit a Telegram any time, but it´s defined that there is a Master and a Slave, so one of both needs to wait in case of collision.

    It´s the so called 3964R Protokoll, I think invented from Siemens but am not sure.

    The PicoCom side hasn´t these Problems, and the NDCU8 that I used some years long also didn´t do this trouble to me.

    Edit: I completely forgot to say, there is also a 2. Application, (in fact the main application...), that also runs on netcdua5, see picture.

    I did another trial. I use event based communication instead of the above polling.

    I set the receiver thread priority to 100, and there is a difference now. It takes much longer until the problem occurs, about 3 Mb I could transmit. The error happens then again, but with the difference that when communication stops, and I send an additional byte, there are now 2 events, the missing byte and the additional byte. In former trials there was only 1 event.

    Any ideas now ?


    Beim pollen der serielle Schnittstelle habe ich das Problem, das nach einiger Zeit ein empfangenes byte im Puffer zurückgehalten wird und nicht ausgelesen werden kann.

    Erst nachdem ich ein weiteres byte nachschicke, reagiert ReadFile() wieder und ich kann dann 2 bytes sehen, also auch das erwartete welches fehlt. Ich habe das auch schon als event basierende

    Lösung programmiert, dort tritt das Problem eher auf.

    Hier die Polling Routine, das geht ne Stunde gut, und dann tritt der Fehler auf. Es ist also nicht so dass irgendwas verloren geht, sonder es ist im Puffer drin, nur kann ich es nicht lesen.

    Rx und Tx DMA habe ich in der registry eingeschaltet.

    public void Poll_Read(ref Queue myQueue)


    byte[] readbuffer = new Byte[rxBufferSize];

    int bytesread = 0;



    // make sure the port handle is valid

    if (hPort == (IntPtr)CommAPI.INVALID_HANDLE_VALUE)


    bytesread = 0;



    if (!m_CommAPI.ReadFile(hPort, readbuffer, rxBufferSize, ref bytesread, IntPtr.Zero))


    throw new CommPortException("Serial port -> " + Marshal.GetLastWin32Error());


    if (bytesread >= 1)


    lock (myQueue.SyncRoot)


    for (int b = 0; b < bytesread; b++)




    // Re-specify the set of events to be monitored for the port.

    if (CommAPI.FullFramework)


    m_CommAPI.SetCommMask(hPort, CommEventFlags.ALLPC);




    m_CommAPI.SetCommMask(hPort, CommEventFlags.ALLCE);



    } while (bytesread > 0);



    Wie bekommt man unter C# für eine importierte CeSetThreadPriority Methode an den benötigten IntPtr für den Thread Handle ?

    [DllImport("coredll.dll", EntryPoint = "CeSetThreadPriority", SetLastError = true)]

    public static extern bool CeSetThreadPriority(IntPtr hThread, int nPriority);

    Möchte für einen Thread die Priorität auf 150 erhöhen.


    For better explanation what I mean, under .net CLR, I try to send a bunch of bytes from NETDCU8 (serially / COM3 / 115200bd), when the bytes are transmitted I see this output on the serial debug interface:
    WAIT- for 0x417a5722, mask 0x00000004
    WAIT+ for 0x417a5722, mask 0x00000004

    The bytes are transmitted correctly(port sniffed), only I think this debug output is unusual, may be it is even decreasing performance of the Netdcu8.
    Probably it has to do with IOCTL_SERIAL_WAIT_ON_MASK, from the native API, but how to understand and avoid it?

    I use from OpenNETCF.IO.Serial the property : public byte[] Output { set; } to deliver the bytes to the serial interface.
    Please have a look.


    I use serial communication in netdcu8, does anyone know what this output means(from debug serial interface):

    WAIT+ for 0x61489266, mask 0x00000003
    WAIT- for 0x61489266, mask 0x00000003
    WAIT+ for 0x61489266, mask 0x00000083
    WAIT- for 0x61489266, mask 0x00000002
    WAIT+ for 0x61489266, mask 0x00000004
    WAIT- for 0x61489266, mask 0x00000004


    I have PicoCOM4 Hardware revision 1.2 and want to use CAN Bus from PicoCOM4.
    Usually I initalize like this
    When doing so GetLastError() returns 55
    Looks, thed driver is not available, can you help here?

    The serial debug output looks like this:

    Hello, just a short question
    Is it possible to have / enable RS485 interface on the NETDCU8 ?
    What would I need to do? Are there drivers availabe?