Bootloading a barebones arduino
-
@Larson Thinking about it now, I suspect maybe what you're describing is why I previously couldn't get lesser UART chips "to work" and instead took refuge in, generally, a CP2102, which could maybe handle such inconsistency better at nominal baud rates. So, if that's the case, good on ya for sticking with it and figuring out how to make cheaper UART chips work. Evidently they do work after all if you dial-in the actual rather than the nominal baud rate.
As a side note, I just now looked at the CP2102 datasheet, and it finally explains why I seemingly couldn't get the nominal 1mbps baudrate out of the nRF52805, even though the nRF52805 datasheet offers that as a possible setting. It's because the CP2102 is maxed out supporting a nominal 921600. :face_palm:
With that mystery now solved, the remaining mystery is why I can't seem to get a USB virtual com port on a PC to do hardware flow control. Do I literally need a physical serial port rather than a USB to get hardware flow control working? It's breaking somewhere in the chain; I'm just not sure where. For now I've worked around the lack of proper hardware flow control at high speeds by just padding in some extra time between transmissions, which does allow communication to happen, but obviously slower than what it could be with proper RTS/CTS protocol working. Who knows? Maybe it's a factor in your situation as well, depending on what assumptions you're making or how you're configuring things. As it turns out, without HWFC, at higher baud rates you actually need less of a catch-up delay between transmissions than at lower baud rates, so running at max baudrate is a double win of sorts.
@NeverDie Talking about virtual ports, HWFC, and chain breakage is way out of my experience. But I'm impressed that you are thinking at that level.
On Baud Rate missmatch: Lacking an OScope, I suppose I could hook the PPKII to the TX of the barebones and transfere values of (2^8)-1, or 255, to see what the exact timing looks like. Serial.print(255, BIN) should do it, right? The datasheet tells me the max sampling speed of the PPKII is 100,000 S/s, so 9600 baud should show pretty clearly and enable me to fine tune what baud the MCU is generating. In a forum post I asked you what the trade-off is for using the internal crystal; you answered "accuracy". That is what got me thinking and looping on different baud rates. Serial Monitor was giving me 12#$, or the like, when I was expecting 1234 via Serial.print, so I knew it was close.
How tight are the radios to baud support they get from the 328P? I would imagine the internal crystal baud rate is dependent on voltage. Maybe some formula exists in the 328P datasheet that allows for adapting this on the fly.
-
@NeverDie Talking about virtual ports, HWFC, and chain breakage is way out of my experience. But I'm impressed that you are thinking at that level.
On Baud Rate missmatch: Lacking an OScope, I suppose I could hook the PPKII to the TX of the barebones and transfere values of (2^8)-1, or 255, to see what the exact timing looks like. Serial.print(255, BIN) should do it, right? The datasheet tells me the max sampling speed of the PPKII is 100,000 S/s, so 9600 baud should show pretty clearly and enable me to fine tune what baud the MCU is generating. In a forum post I asked you what the trade-off is for using the internal crystal; you answered "accuracy". That is what got me thinking and looping on different baud rates. Serial Monitor was giving me 12#$, or the like, when I was expecting 1234 via Serial.print, so I knew it was close.
How tight are the radios to baud support they get from the 328P? I would imagine the internal crystal baud rate is dependent on voltage. Maybe some formula exists in the 328P datasheet that allows for adapting this on the fly.
@Larson said in Bootloading a barebones arduino:
How tight are the radios to baud support they get from the 328P? I would imagine the internal crystal baud rate is dependent on voltage. Maybe some formula exists in the 328P datasheet that allows for adapting this on the fly.
The radios are connected over SPI, with the radio as slave and the atmega328p as master. The master sends out the clock signal, and the slave is literally "slave" to that clock signal, even if it isn't steady. Therefore, within normal parameters, it's not something you need to worry about, because the shared clock signal synchronizes their communication. Naturally there's some limit on how fast you could theoretically run a master's clock before it becomes too fast for the slave to follow, but AFAIK there is no limit on how slow you can run the clock. You could probably even toggle the clock pulses manually by hand if you wanted to. The slave isn't allowed to get bored and time out no matter how long it takes. The protocol simply says that whenever there is a clock transition, the next bit of data has to be ready for reading on the datalines (both MOSI and MISO). i.e. the protocol is agnostic as to the clock speed and even its consistency. You and a group of friends could sit around a table and pass bits and bytes to each other using an SPI communication protocol. Better than telephone!
-
@Larson said in Bootloading a barebones arduino:
How tight are the radios to baud support they get from the 328P? I would imagine the internal crystal baud rate is dependent on voltage. Maybe some formula exists in the 328P datasheet that allows for adapting this on the fly.
The radios are connected over SPI, with the radio as slave and the atmega328p as master. The master sends out the clock signal, and the slave is literally "slave" to that clock signal, even if it isn't steady. Therefore, within normal parameters, it's not something you need to worry about, because the shared clock signal synchronizes their communication. Naturally there's some limit on how fast you could theoretically run a master's clock before it becomes too fast for the slave to follow, but AFAIK there is no limit on how slow you can run the clock. You could probably even toggle the clock pulses manually by hand if you wanted to. The slave isn't allowed to get bored and time out no matter how long it takes. The protocol simply says that whenever there is a clock transition, the next bit of data has to be ready for reading on the datalines (both MOSI and MISO). i.e. the protocol is agnostic as to the clock speed and even its consistency. You and a group of friends could sit around a table and pass bits and bytes to each other using an SPI communication protocol. Better than telephone!
@NeverDie said in Bootloading a barebones arduino:
You and a group of friends could sit around a table and pass bits and bytes to each other using an SPI communication protocol.
Passing bits and bytes is probably more fun that sitting around a table and passing digs and barbs! I don't know: maybe my friends ARE binary!:angel:
[Edit: I forgot to say anything about the content of your SPI protocol story. That was a great story; I feel badly for not thinking about the SPI connection at all. Now it is ingrained. ]
