Main Site Documentation

Project - RS232 Gadgeteer <=> PC Round-n-Round (1)


#1

I just posted RS232 Gadgeteer <=> PC Round-n-Round (1) on Codeshare. Feel free to discuss and make suggestions here.


#2

I am using MF version 4.2 and Visual Studio 2010. Could you post a version compiled for this version of MF?


#3

This was copied from the thread:

https://www.ghielectronics.com/community/forum/topic?id=16336&page=4


#4

Just tried with a longer string with a length of around 200 Byte at a Baudrate of 38400.
I stopped it at 17592 rounds (~ 3,5 MByte) with no data corruption.


#5

[/quote]

With good cable you can get a reasonable distance with RS232. About 25 years ago (hell, it don’t feel like that long ago) we used to send survey data for a video overlay one way and ROV data the other and this was over a 100m cable from our control shack to the survey shack. We ran this at 9600 bps and never had any failures.

Mind you, in those days the driver IC’s had some clout and where powered from +12 and -12V real supplies and not the current, charge pump drivers of today’s devices.


#6

So you have demonstrated that a program dedicated to receiving serial port data, with nothing else to do, and a low enough baud rate, will not drop characters. My program has many other real time functions to perform, it has other devices to monitor on other serial ports, a KP16 keypad to scan, a touch screen, a temp/humidity sensor to monitor. Please answer me, what is wrong with having the CPU perform other tasks while waiting for serial port received data? Is there a hardware generated interrupt for received characters in the MF 4.2? If so, why does it matter if my program is performing many tasks? The interrupt service routine should buffer all received characters and not lose any.


#7

@ Dave McLaughlin -
Hi,
Yes, times are changing, my first serial interface (36 years ago) was to a teletype. 60 Volts, 75 bps I think. As these machines had no buffer the carriage return had to be performed as fast as the usual characters (need to cover the ears when nearby).
This little app is only intended to show that the firmware handles transmission without data corruption (at least in a program environment with no potentially interfering other threads). It was not intended to test the maximal possible datarate.


#8

Yes, you put your finger on my problem exactly - I have other threads. Why do they interfere with the serial port firmware? I have to have other threads, and they should not be a problem for the firmware causing it to lose data from the serial port hardware. It is not the data rate that is causing me problems. I can go at a lower baud rate, I tried. Even at 9600 baud, the serial port hands me messages with bytes missing. The problem is worse at lower buad rates. Is this acceptable to you? That a program for the serial port can do only one function, no other threads can run, and use only one serial port?


#9

@ dspacek - Does your application use Gadgeteer? And if so, maybe you can refactor it to use plain NETMF? I use serial heavily in tandem with monitoring/control functions. I have not encountered the issues that you are seeing, but maybe because I’ve always stuck with vanilla NETMF. I’ve heard Gadgeteer can be a resource hog, and that the Gadgeteer core simplifies/automates certain tasks in the background, possibly yielding unexpected results elsewhere.

[EDIT]
Also – what is expected data throughput (not just baud) of each of your 4 ports?


#10

Please, if you have any suggestions for me, any rules or guidelines to solve the dropped character problem, and yet have other threads doing things, and other serial ports in use ( I have four) please help.


#11

I see, I’m late with my answer.

We are agreed, there is nothing wrong. The CPU and firmware must satisfy these demands.
But there are still two possible reasons for the malfunction of your program (I mean: combination of your application, firmware and hardware).

  1. faulty CPU-firmware-system,
  2. not yet recognized bug in your application.
    My way to find the reason would be to start with a working serial port solution and add step by step the possibly interfering factors of your special application. I would not blame the CPU-firmware-system before a have set up a simple application in which there is no reasonable doubt that it should work and I find that it does not.

I do not know so much about this. As far as I know these demands are handled in native code behind the scenes of NETMF. Each incoming character induces an interrupt and in the interrupt routine the byte is transferred into a FiFo-buffer from where the bytes can be read by the NETMF serialPort.Read() function. These functions must be so fast that no byte is missed. The scenario when the buffer is full, must be handled by “hardware” handshake but I’m quite sure that this does not play a role when a low datarate of 38400 baud is used and only short command and data messages are sent.

Yes.