missing packets on RDA

[Linuxbuilders]

Hi all,
Quick question:

18F4520 CCS PCH 4.107

I have structured comms into packets of 20 hex signs which I stream at once, another device is receiving it. I make a flooder which is sending 20x packet at once. My INT_RDA routines are correct and buffering. In parallel with a bus I have monitoring software. Now my bus setup between devices is RS232 -> MAX485 <...bus RS485...> MAX485 <- RS232. What is happening? My RX device is missing on occasions single packets. I see it being sent from TX device. This is my C setup:

[bkamen]

so these are just translaters from RS232-> RS485 -> RS232 ??

In your TX code, you aren't looking for kbhit(). You're looking to have data in the receive buffer. What you have isn't correct.

In your INT_RDA, take out the loop do {} while();

You never want to get stuck in the loop for the whole packet. Just the chars received.

What you should have is a bigger circular buffer (like maybe 10packets worth which is 200bytes which is a single byte sized pointer.)

look at the EX_SISR.c example for those circular buffers.

Then while there is data in the buffer -- send it.

But don't hang up in your INT_RDA routine looking for more chars than the receiver register can hold.

-Ben
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D

[Linuxbuilders]

thnx,

[bkamen]

[Linuxbuilders]

Thnx Ben, with all respect I can understand a difference between RS485 and RS232 and I can see that RS485 works differently because it is one way communication, but for some "special" reason I do not use native protocol for it. So lets see what kbhit does? It is saying that there is CHAR ready in a buffer or? It is saying that:

[bkamen]

[Linuxbuilders]

Hi, sorry for delay, didn't have much time to write back.

As native I understand examples from CCS.

How does your program cope with 2 way comms from 200 devices on the bus?

My problem is not sitting inside of INT - it is still relatively short time. Problem is TX hit in the middle of another packet flying around on the bus because PIC detects a window between collecting two CHARS.

That is how it looks inside of packet being sent by one device to the server:

<start of packet from device 1>....<detected free window by device 2 - TRY to TX to device 3>....<end of packet from device 1> - it is microseconds but still detectable by device 2.

It breaks my packet in half and that is why I lose it. So there is two ways to fix it. One is look for <start><end> and when it is present then put delay on TX. So when kbhit is valid and <end> wasn't present then put delay on TX until <end> and then TX. Second solution is hardware. I am 100% positive that I can get it right in the software. So far I have changed TX and RX buffers to be processed once in a cycle of main{}. This is eliminating problem with constant messages and puts bus in nice order. I send 10 max at once from one device if required. This way I have stable bus and less collisions. I agree that my int is long but because I do have 200+ devices in the network I need it to be long. I have no way to do buffering, error checking, etc outside of INT. If you look at my program you will see what I do there. I have circular buffer, I check if it is empty and then fill it up. If I do not have free spot then I put it in spare and send error that buffer is full. I am still thinking how to get out of INT with most of it and do this outside but because my program is at 70% and I put any extra buffering then I may find zero space for anything extra. On another hand I do the job at once inside of INT what from the point of my program makes no difference in operation of the device. If I will try to do it outside I may find that I will have lost more data because before I process one packet I will have another 10 written in.

Makes sense?

I will be happy to get help to redesign my INT to the point of collecting a data and doing rest of job outside but I am somehow not able to imagine it differently than you see it in example above.

Thank you.
_________________
Help "d" others and then you shell receive some help from "d" others.

[Linuxbuilders]

and it looks like this:

[bkamen]

[icefield]

For reliable comms, you need to first decide to use polling or interrupts. Your code is trying to mix the two and that is asking for problems.

If you use polling (kbhit/getc), then do not implement an interrupt routine.

If you use interrupts (faster than polling), the interrupt routine must be extremely short. All it should do is execute getc (or a direct register read - even faster) to get the character and put it into a ring buffer. Don't do anything else. It should be just a few lines of code. Don't check kbhit (of course there is a character - you got an interrupt!!!). Don't do any protocol/collision analysis. Just get the character and store it away.

Now, in your main application, you can have all manner of loops that get characters (and check for available characters) from the ring buffer, NOT the serial port. Of course, you need to initialize the ring buffer to be empty in your startup code. Never use kbhit in an interrupt-driven serial scheme - there is no point!

It also sounds like you need to implement some sort of collision detection and resend request of you are going to have multiple transmitters on your RS485.

Hope this helps!

[Linuxbuilders]

thnx

[bkamen]