Hi --
Job
Use Netduino Plus2 to make an Ethernet-to-specialized-serial interface for industrial control.
Killer problem
Each round trip takes over 20 milliseconds; it needs to be 1-2.
Analysis
I think the delay comes because my control program is a simple loop running in one thread waiting for Ethernet data. It sends and receives to the industrial HW on serial in ca. 1 MS; then sends results back on Ethernet. Tracing shows the TCP/IP stack in a different thread, and I've read that each thread transition waits for a 10-millisecond clock tick. Hence, the killer problem.
Possible solutions?
- I don't think e.g. making my control code "event-driven" would make a difference, but I'm not an experienced C# programmer. Any way to get either C# (or all-C++ interop code) into the same thread as the Ethernet I/O?
- I am recompiling the whole software just to include my tiny interop changes. Is there some build option or high-level code switch to disable the multitasker and just have Ethernet and user code wait for each other?
- If I ping the Netduino Plus2 before the C# program is downloaded, my laptop says it responds in less than a millisecond. It's that performance I need: 500-1000 packets/second. I'll happily make a little tweak, but I'll also dump the whole .Net infrastructure (now that I can use JTAG debug); if that gets the job done quickest. (For example, just hook the ping code -- the message size is perfect -- directly to my interop control code, and never load a C# program.
- Or I'll put completely different software on the board,
- Go to different hardware.
- ...
Argument for a tweak (if one is possible) is that bare-metal programming is perishable; in these few months I already had to rewrite my direct hardware control of the Atmel ARM UART in Netduino Plus to the the ST UART in Plus2. The dotNetMF might be a way to future-proof the application. However, it first has to work in the present ;-)
Suggestions anyone?
Howie
