Click here to Skip to main content
15,792,266 members

Comments by Romain TAILLANDIER (Top 14 by date)

Romain TAILLANDIER 16-Dec-11 3:30am View    
I am a quite new programmer (near 10 years of C#) comparing to you Jack 'Dinosaur' Dingler :)
I agree, switch is not necessary. as the else is. (if(a){...}if(!a){...}
There this many form of loop, for, while, doWhile, (and now foreach in C#), only one should be necessary
There is the linq language ..., not necessary
There is a swarm of unnecessary keywords, function concepts ...
But it is just a easy way to do, read and maintain the things.

Being a dinosaur, wouldn't you exclusivly use assembler ? or perfored card ? :)

I am aout of the question, it's happend ... but may i suggest you to take a look to brainfuck ? I am sure you would like it ! Nothing unnecessary !

Finally back to your question, I try to reply in C# with your permition (not good enough in C++).
I would have created a hashtable containning numbers (100, 201, 300, 305...) as keys, and type names ("Namespace.Circle", "System.String" ...) as string values.
Then getting the number i would retrieve the type name using this table and use the reflection.emit to instanciate the type. (not so far from Emilio Garavaglia solution)
Romain TAILLANDIER 16-Dec-11 2:38am View    
You have to start with some MSDN documentation ...
Romain TAILLANDIER 13-Dec-11 7:28am View    
Start by trying to set the baud rate to 115200*8. you will gain a little during the transmition. according to your 5ms, even one 0.5 ms is a good gain ...

You can try to set your reading and writing threads to higher priority.
the 15ms may contains the delay used by windows to give some processor time to your process.

I can't understand why you need timers of 5ms ?

The better way to get the better time reaction is to reply in the same function as you receive like
public void SerialPort_Receved(..)
byte[] reply = this.BuildMyReply(buffer);
if you use an additional timer, it should be less fast.

Romain TAILLANDIER 13-Dec-11 3:18am View    
It is not clear if your 5ms constraint is
- between start of frame and end of frame, OR
- between end of reception and start of emission ....

If i do not mistake, your have 2 delay :
- Time for react to a reception
- Time a write transmition

Time to write 64 bytes @115200 Baud (115200 bit/seconds)
should be 512/115200 = 0.0044 sec = 4.4ms, so you have less than one ms to create the reply ...

If your RF dongle is USB, you probably have a usb-serial converter inside. So your speed should be only limited by usb speed AND driver of the USB-COM converter. That way you (usually) should be able to set up the BaudRate to 115200*8 (and more for USB2), but i believe Framework is limited to 115200*8.

Now to speed up you time of react, it really depend on your implementation.
How do you measure the time of your reaction ?
I have notice that in debug, Console.WriteLine and Debug.WriteLine are really slow down all times i can measure.

Romain TAILLANDIER 12-Dec-11 7:54am View    
Thread.sleep is not recommanded on UI thread that's right. But if it sleep a very few time (less than 200-300), user can't observe the delay. You can add Application.DoEvents() in the sleep loop, to let the user have the control, and the UI refreshing good. You also can freeze the UI while the program communicate with the peripheral, simply by activate a wait cursor (this.Cursor = Cursors.Wait;)

According to my experience, i drove tens of rfid peripherals using C#, massively constructed on waiting for ByteToRead > 0, and i never experienced problems using this, since the SerialPort class exists on compact framework 2. (didn't exists in CF1).
Most of the peripheral i drive are self maid one based on microchip PIC microcontrollers. Do you now ASPYCOM[^]?
It allow you to spy a com port and see if your program and your peripheral communicate as waited