Proton BASIC Community

Hello all,

I have a project requiring data reception from as many as 8 devices using USART protocol every 200ms with baud rates of 57600. There is enough time for all data from the 8 devices to be received and processed, however because the data can come at any time (with respect to the rest of the devices) and there is no option for flow control, there is possibility for collision and data loss.

So I am thinking of using 8 small (8-pin) PICs to buffer the data from the USART devices and then re-transmit it to the main MCU via I2C line with some flow control protocol, i.e. using a pin to notify the main MCU when new data is available.

However this option requires 8 additional MCUs on the board and I was wondering if you would have some ideas how to deal differently with the problem - if possible using the main MCU only.

Thanks   

If you have control of the transmitter source code, you could implement a "busy" state, where each transmitter looks at the data line and if it is busy, it waits a random amount of time, then looks again. It then transmits when the line is clear for x amount of Bit times, and each tranmsitter has a predefined address that it tranmits first, before the data being sent, and a terminator sequence of bytes. i.e. A protocol with master address, amount of data, data, CRC and terminator. The random wait time must be a good random value, otherwise, each transmitter will use the same pseudo random sequence and wait exactly the same amount of time as each other. The address of the transmitter can be used as a simple seed value, and the data being sent can be xored or added etc to use as further random seeds, to keep them different to each other.

The receiver then only ever sees data from a single transmitter at any given time and stores the received data in a buffer. It then reads the buffer protocols and can see what transmitter sent what. This can be done within an interrupt, so the main program can ask for data from a particular transmitter, if it has sent any.

For this to work, their must be no idle times in the transmitted data because another transmitter will see the idle time as "no transmission taking place" and start to transmit itself, so the transmitted data must be a single block.

I2C uses a similar mechanism and is named "Collision Detection", when multiple masters share the I2C bus. Ethernet also uses a similar mechanism of the busy mode, with random wait/try again times.

Quote from: top204 on Jun 06, 2021, 04:19 PMIf you have control of the transmitter source code, you could implement a "busy" state, where each transmitter looks at the data line and if it is busy, it waits a random amount of time, then looks again.

Thank you for the suggestion top204, unfortunately the USART devices are external and I have no control over the transmitter's code nor any way to hold or control when the transmission starts. I have been thinking for a while but for the moment I can only think of buffering the data in 8 small (8-pin) PICs.

How about a device that has PPS. However, each transmitter must be connected to seperate input pins.

The USART's PPS pins can be dynamically moved around to scan each transmitter's data. It will miss some transmissions when scanning other transmitter pins, but it will catch them second time around if it is made fast enough or with random timing sequences for the scanning, or with priorities or something like... I received something from transmitters 1, 2, 3, 4, 6, 7, 8, but not from 5, so the next scanning sequence will start at 5.

The same principle can be used with devices that contain more than one USART, so the scanning sequence can be much shorter.

Quote from: top204 on Jun 06, 2021, 04:38 PMHow about a device that has PPS. However, each transmitter must be connected to seperate input pins....

Thank you for the idea top204, I haven't decided yet for the MCU, thus I can choose one with enough pins. Your idea is definitely worth exploring - now I am thinking in addition to your suggestion I can tie in parallel the USART signals to PORTB in order to generate an interrupt with the start bit.

Then I have to figure it out how to organize the program for the hardware USART interrupt when scanning the PPS pins while receiving data, and if it will be fast enough not to miss bits during simultaneous reception in the worst case scenario - 8 at the same time.     

in 8 bit pic mcu, K40 and Q43 series has 5 uart and with pps and Les method is looks possible for 8 usart support

but ;

exactly the mcu you are looking for

UART 8
SPI 8
I2C 8

ATSAMC20N17A ...ARM Cortex-M0+ CPU running at up to 48MHz

Pricing: (USD)
100-999    2.33 - 2.33
1000-4999  2.13 - 2.13*
5000+      2.04 - 2.04*

https://www.microchip.com/wwwproducts/en/ATSAMC20N17A

I wish we could use the positron for these as well. We wouldn't fight to learn crazy "c"....

actually there is a multi drop ttl uart communication scheme, but you don't have the control of sending the devices..

UART/TTL-Serial network with single master and multiple slaves
http://cool-emerald.blogspot.com/2009/10/multidrop-network-for-rs232.html

but, if you can put 8 smallest pic mcu in between and sort it with rs-485..
copying both device becomes a little more difficult.

Many many years back a client had the same 8 input 1 output request. The way I solved it was like you proposed. I used the 8 of the cheapest Usart enabled pic's I could find. They listened to the data coming in and then the main device polled the 8 to see if they had any data. I used a simple bit shifting system to get the data and if they had any. Then packeted them all up an sent them on.

Unless you can use a multi input Arm I found no other way.

It worked for the client although made for a bigger board.

Personally I would look at something like the PIC16F15213T #
1   £0.336   £0.34
25   £0.312   £7.80
100   £0.282   £28.20

Comes with a USART can run on internal OSC at 32mhz. In my original design I used a single clock generator to drive all pics as in the days I did the work it would not run on internal osc.

1 Pin usart
2 pins for Data+CLock
1 pin poll

The PIC16F15213T is 8 pin

The Master needs to have more pins as it will need a line to poll each device in turn to see if it has data. Also I used the USART in the master as an SPI slave so the 115200 out was bit banged in asm and the OSC to that device was fine tuned to make the bit banging 100% correct.

If I can find the source code for it I will post. One thing was I used the Labcenter VSM to sim the whole thing. I had around 15 pics running at one time in the VSM. Was really impressed!

Tim

Quote from: top204 on Jun 06, 2021, 04:38 PMHow about a device that has PPS. However, each transmitter must be connected to seperate input pins.

The USART's PPS pins can be dynamically moved around to scan each transmitter's data. It will miss some transmissions when scanning other transmitter pins, but it will catch them second time around if it is made fast enough or with random timing sequences for the scanning, or with priorities or something like... I received something from transmitters 1, 2, 3, 4, 6, 7, 8, but not from 5, so the next scanning sequence will start at 5.

The same principle can be used with devices that contain more than one USART, so the scanning sequence can be much shorter.

I like Les' idea.
You could experiment with IOC negative edge interrupt enabled on each pin to see if the ISR can switch the UART (using PPS) to the interrupting pin fast enough to catch the start bit of the arriving byte. My gut feeling is it could. I like the

At 57600 baud, each bit time is 17.36us.

For a UART you usually want to stay within about 2-3% of the bit timing, so that's roughly 520ns, give or take.
That means you'd have about 8 asm instructions @64MHz (or 4 instructions @ 32MHz) from the beginning of the start bit to switch the input pin to the UART.

Even if you take the tolerance out to the max of 5% you still have < 1us to perform the switch.

Quote from: tumbleweed on Jun 07, 2021, 10:51 AMAt 57600 baud, each bit time is 17.36us.
...
Even if you take the tolerance out to the max of 5% you still have < 1us to perform the switch.

Indeed, I came to the same conclusion. In addition to that I have to place the data in the corresponding buffer in case multiple receptions occur at the same time, which would be problematic. There is simply not enough free processing time.

I think the better and simpler option would be using the buffer MCU's - as TimB pointed out they are inexpensive and require no external oscillators.

Thank you all for the input.

I found my code and I remember more now. There was 4 inputs and 4 outputs with 1 master handling the TX and 1 the RX side.
9600 baud in/out on the salves
115200 baud in/out on the masters

Your welcome to have a look although as its an old version of Proton it's not as clear as I can write now.
Nothing really to write home about in there

You have a TX buffer in each of the 8 input pics. I recommend you understand the packet sizes expected so you can collect a whole packet.

Then wait your turn being polled by the master. Basically the master pulls a line low on your device and and you need to be quick to respond by pulling the line high to let the master know you have data. Then you bit bang it out SPI style.
When done release the line. The Master also has to know how big a packet to expect. A timer or 2 can be used to check if the line is being released etc in time.
Not sure what you can do if its not!

Not really an hard job, only thing to watch out for it timing on the polling lines. Making sure you do not grab it just as the master is letting it go.

HTH

Tim
 

hi,
i dont how to setup DMA with uart,
but an idea came to my mind with dma using



I would like to ask with this schematic you if it is possible to do with this idea.

and some sample projects from microcihp github for using DMA

https://github.com/microchip-pic-avr-examples/pic18f57q43-dma-adc-to-uart-part1
https://github.com/microchip-pic-avr-examples/pic18f57q43-dma-uart-to-pwm-part2
https://github.com/microchip-pic-avr-examples/pic18f27k42-dma-ram-to-uart
https://github.com/microchip-pic-avr-examples/pic18f45k42-dma-based-led-dimming
https://github.com/microchip-pic-avr-examples/pic18f26k42-dma-pfm-to-ram
https://github.com/microchip-pic-avr-examples/pic18f57q84-2-axis-cnc
https://github.com/microchip-pic-avr-examples/pic18f57q43-automated-led-display-driver

DMA doesn't help the original problem, which is switching the RX input to monitor different slaves.

Quote from: trastikata on Jun 06, 2021, 04:10 PMI have a project requiring data reception from as many as 8 devices using USART protocol every 200ms with baud rates of 57600.

I cannot see anywhere in the previous posts mention of what the devices are. If there is nothing preventing you from mentioning them, if people knew what they were and take a look at the datasheet it might help them to determine a relevant solution.

Quote from: Stephen Moss on Jun 09, 2021, 08:16 AMI cannot see anywhere in the previous posts mention of what the devices are. If there is nothing preventing you from mentioning them, if people knew what they were and take a look at the datasheet it might help them to determine a relevant solution.

Thank you Stephen Moss, those are old modules sending sensor data as strings, so I need to collect that information, log it in a log file on a PC and display it.

Anyway, I decided the easiest and safest way is using 8 small PIC's as data buffers.

I have to give a big warning on the small 8 pin pics. After the post I went to see what the stock situations was like.

Basically nobody has stock.

Tim