Hey all,
This is a paper verification I would like to understand before I go ahead and test. I am working with an atmeag328.
So I would like to perform serial communication between multiple ports, two of which are hardware, and one being Altsoftwareserial. From the information page at http://www.pjrc.com/teensy/td_libs_AltSoftSerial.html#speed, the maximum baud rate for the altsoftwareserial library is 31250. From this, assuming a 16mhz clock source of the target MCU and a 16x multiplier for receiver/sender clock requirements to communicate via UART, I get 32 clock cycles per interrupt from the altsoftwareserial library.
https://www.maximintegrated.com/en/app-notes/index.mvp/id/2141
Adding that I now will incur separate ISR's from the Hardware serial and Hardware i2c, I must add the potential delay in the altsoftwareserial to both the start and ending edges of a bit to be sent from the software controlled altsoftwareserial pin. Since hardware serial only needs processor time to transfer a byte into/out of the UART register, and the UART handles everything else (transmission, clock requirement, etc), the serial will hog up just a few cycles to perform this task. I assume it will take upwards of 32 clock cycles for the processor to transfer three bytes into the UART register based upon the packet length I need to transfer. Most likely a high limit, but I was unable to attain the number of cycles a UART isr takes to transfer in a byte. Similarly, I use the same justification for the processor to interact with the TWI hardware since I couldn't find those numbers either. So, the estimated start and ending bit delay to satisfy UART clocking requirements through altsoftwareserial will give me a possible extra 64 clock cycles on start of the bit, and 64 cycles on the end of the bit. From the altsoftwareserial 32 clocks per interrupt * 16 + 64 + 64 = 640 clock cycles. 16000000/640 = 25000.
From this analysis, I can assume a maximum reliable baud rate of 25000 for altsoftwareserial, assuming I have no other significant code in the interrupts. Is this sound research and reasoning? Or do I need to go back and read the reference manual again?
For those curious. I need an atmega328 to pass continuous dmx uart data (only 3 dmx channels) to altsoftwareserial port (9600baud), and for the atmega328 to receive occasional TWI data from a teensy 3.2 and pass it through to the altsoftwareserial port. There are obviously some nuances to the dmx library that I will have to contend with in order to make this work, but I just wanted to make sure my reasoning was correct above so I can resolve conflicts that I may see once I test.
This is a paper verification I would like to understand before I go ahead and test. I am working with an atmeag328.
So I would like to perform serial communication between multiple ports, two of which are hardware, and one being Altsoftwareserial. From the information page at http://www.pjrc.com/teensy/td_libs_AltSoftSerial.html#speed, the maximum baud rate for the altsoftwareserial library is 31250. From this, assuming a 16mhz clock source of the target MCU and a 16x multiplier for receiver/sender clock requirements to communicate via UART, I get 32 clock cycles per interrupt from the altsoftwareserial library.
https://www.maximintegrated.com/en/app-notes/index.mvp/id/2141
Adding that I now will incur separate ISR's from the Hardware serial and Hardware i2c, I must add the potential delay in the altsoftwareserial to both the start and ending edges of a bit to be sent from the software controlled altsoftwareserial pin. Since hardware serial only needs processor time to transfer a byte into/out of the UART register, and the UART handles everything else (transmission, clock requirement, etc), the serial will hog up just a few cycles to perform this task. I assume it will take upwards of 32 clock cycles for the processor to transfer three bytes into the UART register based upon the packet length I need to transfer. Most likely a high limit, but I was unable to attain the number of cycles a UART isr takes to transfer in a byte. Similarly, I use the same justification for the processor to interact with the TWI hardware since I couldn't find those numbers either. So, the estimated start and ending bit delay to satisfy UART clocking requirements through altsoftwareserial will give me a possible extra 64 clock cycles on start of the bit, and 64 cycles on the end of the bit. From the altsoftwareserial 32 clocks per interrupt * 16 + 64 + 64 = 640 clock cycles. 16000000/640 = 25000.
From this analysis, I can assume a maximum reliable baud rate of 25000 for altsoftwareserial, assuming I have no other significant code in the interrupts. Is this sound research and reasoning? Or do I need to go back and read the reference manual again?
For those curious. I need an atmega328 to pass continuous dmx uart data (only 3 dmx channels) to altsoftwareserial port (9600baud), and for the atmega328 to receive occasional TWI data from a teensy 3.2 and pass it through to the altsoftwareserial port. There are obviously some nuances to the dmx library that I will have to contend with in order to make this work, but I just wanted to make sure my reasoning was correct above so I can resolve conflicts that I may see once I test.
