Howie Goodell

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 

I am trying to use a Netduino Plus board to replace the legacy controller for an industrial machine that uses a 9-bit serial protocol (the remote process controllers only read bytes with the 9th bit set until they see a packet addressed to them). Life is good if I specify 8 data bits, but if I set 9 it throws an unhandled System.ArgumentException at Microsoft.SPOT.Hardware.SerialPort.dll!System.IO.Port.InternalOpen() (call made at Line 156 of the 4.1 source file SerialPort.cs) Here's my code: mSerial = new SerialPort(SerialPorts.COM1, 375000, Parity.Even, 9); mSerial.DataReceived += new SerialDataReceivedEventHandler(mSerial_DataReceived); mSerial.Open(); I assume the DLL is complaining about a parameter it can't fully handle (9th bit needs a special register bit write; obviously not included in the data byte). Not sure if this is a SecretLabs or MS issue. Would changing to 4.2 firmware fix it? (I tried, but I gave up fighting the driver incompatibility of the Atmel tiny booter.) How do I fix this myself? First time trying managed code for low-level; reminds me of the old days when Windows worked great at the GUI high level before a low-level crash ;-) Howie Goodell