I need to generate a 10 MBit RS485 (UART) data stream with an USB device. Until now, I thought that the FT2232H perfectly suit but as far as I understand, the FT2232H can only generate 12 MBit or 8 Mbit as the subdividers are limited for the main divider 0 and 1.
The USB device should enumerate at the PC as serial interface which supports a baudrate of 10 Mbit.
So any idea which chip is suited for the specific task?
Thanks.
Ok, I finally implemented a suitable solution.
Set the baud rate to 12 MBit and use 2 Stop and 1 parity bit.
Implement a 12 MBit RS422 receiver in a CPLD or FPGA and connect it directly with the FT2232H. The CPLD/FGPA removes one stop bit and the parity bit.
Output the received data in the CPLD/FPGA with an regular 8N1 10 MBit RS422 sender. In total, this must be done twice but with 12 and 10 MBit being switched.
Works like a charm and the CPLD can even be a QFN32 Lattice iCE40 CPLD.
Related
For a project I need to make communicate in a CANBus network, ethernet network and with RS-232. I want to use one single MCU that will act as the main unit of CANBus start topology, Ethernet start topology and that MCU also will be transfering the RS232 data that comes to it to another device. Now I want to use high speed CAN which can be up to 1 Mbits per second. However,RS-232 is max 20 k baud. I wonder if it is doable with 1 MCU to handle 3 different communications ( CANBus, ethernet and RS-232). I am afraid of to get overrun with data at some point. I can buffer data short term if data comes in bursts that can be averaged out. For continuous data where I'll never be able to keep up, I'll need to discard messages, perhaps in a managed way. But I do not want to discard any data. So my question is: Would using 1 MCU for this case work? And are there any software tricks that would help me with this case? (Like giving CANBus a higher priority etc.)
Yes, this can be done with a single MCU. Even a simple MCU should easily be able to handle data rates of 1 Mbps. Most likely you want to use DMA enabled transfer so the CPU core will only need to act when the transmission of a chunk of data has completed.
The problem of being overrun by data due to the mismatch in data rate is a separate topic:
If the mismatch persists, no system can handle it, no matter how capable.
If the mismatch is temporary, it's just a function of the available buffer size.
So if the worst case you want to handle is 10s of incoming data at 1 Mbps (with an outgoing rate of 20kbps), then you will need 10s x (1Mbps - 20kps) = 9.8 Mbit = 1.225 MByte of buffer memory.
I have an RDM6300 RFID writer/reader. It can read RFID Tags and it sends the data via UART to a microcontroller. So far I worked with multiple Microcontrollers from which ones the STM32F04 had the most UART "ports" (8 transmitters and receivers). The Arduino has got a few, but it is not enough.
I want to have 25 RFID readers (that are reading almost at the same time), but I can't find a way to send data from all the readers to one microcontroller.
Is there a way how can I connect 25 readers to ONE microcontroller?
You have 25 things transmitting at 9600 bps. You have an MCU running at 180 MHz with 8 UARTS and lots of timer capture channels (32 channels, 30 of them usable on the 100 pin STM32F427VITx). 8 of the 25 inputs are taken care of by the UARTS, 17 needs to be processed by other means. Connect them to timer capture channels.
The MCU runs at 180 MHz, the inputs change state at 9600 Hz, that means 18750 clock cycles between events. Should be way more than enough to process all of them, if you don't use HAL.
read the timer status register, check for capture events and clear them
check pin state, low means start of a frame
store the capture register value for that channel
keep checking for capture events
if there is one, clear it
read the capture timestamp, subtract the stored value from step 3 from it
calculate the number of bits received with identical state
keep doing it until you have 9 bits (start bit + 8 data bits) and high input on the pin
Do the above in parallel for all 17 channels. You need a suitable prescaler for the timers so they won't overflow while reading a full frame (9*18750=168750 cycles)
When I write 8 bit in hc595 shift register, with i2c last bit go to Q0 in second hc595.
Why?
Schematic:
My code:
i2c_write(0b10101010);
latch_led_sensors_out();
delay_ms(200);
It's because of the I2C protocol. Even though you want to send out 8 bits, you are really sending out 9. The way I2C works is the initial frame contains 7 (or 10) bits of address, plus one bit for read/write. After those initial 8 bits are clocked out, the master sends an additional clock pulse to read in the ACK/NACK bit from the slave device. Remember, the master controls the clock, even when the slave is driving the data pin.
I'm going to build a LED-Wall which i will control via 4 teensy micro controllers. Everywere I read the vertical number of my LEDs has to be a multiple of 8? Does it really have to be so?
Thank you
No.
The number 8 is the factor of number of output pins in a port of most digital electronics component (shifters, drivers etc) which assumes a output word to be 8 bits.
A port in a general purpose MCU or MPU will have 8 pins.
Thus the whole available pins can be utilised without wastage.
ATmega168P/328P in arduino, has 3 ports. PORTB, PORTC, and PORTD.
While running some tests with an FT232R USBtoRS232 Chip, which should be able to manage speeds up to 3 Mbaud, I have the problem that my actual speed is only around 38 kbaud or 3,8 KB/s.
I've searched the web, but I could not find any comparable data, to prove or disprove this limitation.
While I am looking further into this, I would like to know, if someone here has comparable data.
I tested with my own code and with this tool here:
http://www.aggsoft.com/com-port-stress-test.htm
Settings would be 115,200, 8N1, and 64 byte data-packet.
I would have expected results like these:
At 115200 baud -> effectively 11,520 byte/s or 11,52 KB/s
At 921600 baud -> 92,16 KB/s
I need to confirm a minimal speed of 11,2 KB/s, better speeds around 15-60 KB/s.
Based on the datasheet, this should be no problem - based on reality, I am stuck at 3,8 KB/s - for now at least.
Oh my, found a quite good hint - my transfer rate is highly dependent on the size of the packets. So, while using 64 byte packets, I end up with 3,8 KB/s, using 180 byte packets, it somewhat averages around 11,26 KB/s - and the main light went on, when I checked the speed for 1 byte packets -> around 64 byte/s!
Adding some math to it -> 11,52 KB/s divided by 180 equals to 64 byte/s. So basically the speed scales with the byte-size. Is this right? And why is that?
The results that you observe are because of the way serial over USB works. This is a USB 1.1 chip. The USB does transfers using packets and not a continuous stream as for example serial.
So your device will get a time sliced window and it is up to the driver to utilize this window effectively. When you set the packet size to 1 you can only transmit one byte per USB packet. To transmit the next byte you have to wait for your turn again.
Usually a USB device has a buffer on the device end where it can buffer the data between transfers and thus keep the output rate constant. You are under-flowing this buffer when you set packet size too low. The time slice on USB 1.1 is 10 ms which only gives you 100 transfers per second to be shared between all of the devices.
When you make a "send" call, all of your data will go out in one transfer to keep interactive applications working right. It is best to use the maximum transfer size to achieve best performance on USB devices. This is not always possible if you have interactive application, but mostly possible when you have a data transfer application.