I'd like to use async UART to let these MCUs communicate. The protocol will be request-response with the request generated by the SAM MCU. The baudrate will be 38400bps. I'd like to use internal oscillator of ATtiny4313, while the SAM will use an external 32.768kHz crystal (that is multiplied by internal PLL to reach 48MHz). I'm not sure if this scenario can work well. My concerns are related to the internal oscillator of ATtiny4313 that hasn't a good accuracy over temperature and life. The tiny MCU will be supplied by 3.3V and its temperature will be in the range 0-80°C.
UART connection between ATSAMD20 and ATtiny4313
Started by ●April 26, 2023
Reply by ●April 26, 20232023-04-26
On 26/04/2023 16:56, pozz wrote:> I'd like to use async UART to let these MCUs communicate. > The protocol will be request-response with the request generated by the > SAM MCU. The baudrate will be 38400bps. > > I'd like to use internal oscillator of ATtiny4313, while the SAM will > use an external 32.768kHz crystal (that is multiplied by internal PLL to > reach 48MHz). > > I'm not sure if this scenario can work well. My concerns are related to > the internal oscillator of ATtiny4313 that hasn't a good accuracy over > temperature and life. > > The tiny MCU will be supplied by 3.3V and its temperature will be in the > range 0-80°C.The rule of thumb is a maximum of 5% total mismatch in baud rates between the two sides. One side has a crystal and PLL, so it will be quite close - that means you can have most of the error margin on the other side. If the internal oscillator is within 2%, you should be fine. If it is 5% or more, you will want to do some automatic measurement of the rate.
Reply by ●April 26, 20232023-04-26
On Wednesday, April 26, 2023 at 10:57:01 AM UTC-4, pozz wrote:> I'd like to use async UART to let these MCUs communicate. > The protocol will be request-response with the request generated by the > SAM MCU. The baudrate will be 38400bps. > > I'd like to use internal oscillator of ATtiny4313, while the SAM will > use an external 32.768kHz crystal (that is multiplied by internal PLL to > reach 48MHz). > > I'm not sure if this scenario can work well. My concerns are related to > the internal oscillator of ATtiny4313 that hasn't a good accuracy over > temperature and life. > > The tiny MCU will be supplied by 3.3V and its temperature will be in the > range 0-80°C.I don't get what your question is. You seem to understand the concepts. You don't tell us the relevant data however. What does the data sheet say about the frequency variability of the internal clock over PVT (process, voltage and temperature)? I assume you are aware that the 3.3V supply will have an accuracy and an RC clock rate can be voltage dependent. It depends on how they designed the circuit. There are techniques for removing most of the voltage dependency, if they used them. You can always use the bit times of the SAM to adjust the bit rate on the ATtiny. That used to be part of the protocol for low data rate modems. The first characters sent were AT if I recall, which give good edges to time to measure the bit rate. At 38400 bps this might be a bit tricker, it depends on your instruction rate. A bit time is just 26 us. Will this be a software UART, or a hardware unit? -- Rick C. - Get 1,000 miles of free Supercharging - Tesla referral code - https://ts.la/richard11209
Reply by ●April 26, 20232023-04-26
Il 26/04/2023 17:57, David Brown ha scritto:> On 26/04/2023 16:56, pozz wrote: >> I'd like to use async UART to let these MCUs communicate. >> The protocol will be request-response with the request generated by >> the SAM MCU. The baudrate will be 38400bps. >> >> I'd like to use internal oscillator of ATtiny4313, while the SAM will >> use an external 32.768kHz crystal (that is multiplied by internal PLL >> to reach 48MHz). >> >> I'm not sure if this scenario can work well. My concerns are related >> to the internal oscillator of ATtiny4313 that hasn't a good accuracy >> over temperature and life. >> >> The tiny MCU will be supplied by 3.3V and its temperature will be in >> the range 0-80°C. > > The rule of thumb is a maximum of 5% total mismatch in baud rates > between the two sides. One side has a crystal and PLL, so it will be > quite close - that means you can have most of the error margin on the > other side. If the internal oscillator is within 2%, you should be > fine. If it is 5% or more, you will want to do some automatic > measurement of the rate. >ATtiny4313 datasheet[1] says the internal oscillator is factory calibrated with an accuracy of +/-10% at Vcc=3V and 25°C temperature. This accuracy can be reduced to +/-2% at a fixed voltage and a fixed temperature with a user calibration. I could calibrate for a fixed voltage (3.3V), but I can't fix a temperature, because it can vary in the real application. I tried to heat the ATtiny4313 with a heat gun and the communication between SAM and tiny didn't stopped, but I know this isn't an exaustive test. [1] https://ww1.microchip.com/downloads/en/DeviceDoc/doc8246.pdf
Reply by ●April 26, 20232023-04-26
Il 26/04/2023 18:26, Rick C ha scritto:> On Wednesday, April 26, 2023 at 10:57:01 AM UTC-4, pozz wrote: >> I'd like to use async UART to let these MCUs communicate. >> The protocol will be request-response with the request generated by the >> SAM MCU. The baudrate will be 38400bps. >> >> I'd like to use internal oscillator of ATtiny4313, while the SAM will >> use an external 32.768kHz crystal (that is multiplied by internal PLL to >> reach 48MHz). >> >> I'm not sure if this scenario can work well. My concerns are related to >> the internal oscillator of ATtiny4313 that hasn't a good accuracy over >> temperature and life. >> >> The tiny MCU will be supplied by 3.3V and its temperature will be in the >> range 0-80°C. > > I don't get what your question is. You seem to understand the concepts. You don't tell us the relevant data however. What does the data sheet say about the frequency variability of the internal clock over PVT (process, voltage and temperature)? I assume you are aware that the 3.3V supply will have an accuracy and an RC clock rate can be voltage dependent. It depends on how they designed the circuit. There are techniques for removing most of the voltage dependency, if they used them.ATtiny4313 datasheet[1] says the internal oscillator is factory calibrated with an accuracy of ±10% at Vcc=3V and 25°C temperature. This accuracy can be reduced to ±2% at a fixed voltage and a fixed temperature with a user calibration.> > You can always use the bit times of the SAM to adjust the bit rate on the ATtiny. That used to be part of the protocol for low data rate modems. The first characters sent were AT if I recall, which give good edges to time to measure the bit rate. At 38400 bps this might be a bit tricker, it depends on your instruction rate. A bit time is just 26 us. Will this be a software UART, or a hardware unit? >I will use the interal UART peripheral of ATtiny4313. I can't add too much code, the Flash memory is almost full. I wanted to know if the figures shown on the datasheet guarantee good communication between the the MCUs. It seems this isn't the case. [1] https://ww1.microchip.com/downloads/en/DeviceDoc/doc8246.pdf
Reply by ●April 26, 20232023-04-26
On 2023-04-26, pozz <pozzugno@gmail.com> wrote:> ATtiny4313 datasheet[1] says the internal oscillator is factory > calibrated with an accuracy of +/-10% at Vcc=3V and 25°C temperature.10% total error (combination of both ends) is pretty much right at the limit according to the usual rule of thumb for UART receivers that sync only on the start bit. IIRC, there used to be UART receivers that would sync on every edge within the data "word" as well, but I don't think that was ever very common -- and to take advantage of it, you had to make sure your data had edges. :) Can you spare a line for a clock and go synchronous? (Or are they really UARTs and not USARTs?).> This accuracy can be reduced to +/-2% at a fixed voltage and a fixed > temperature with a user calibration.2% is no problem at all. With a crystal on the other end, you should be able to easily tolerate +/-5%. The requirement for a fixed temperature, OTOH, is usually a problem.> I could calibrate for a fixed voltage (3.3V), but I can't fix a > temperature, because it can vary in the real application.Does the ATtiny have an on-die temp sensor? If yes, you could try characterizing the oscillator over temperature at 3.3V and adjusting the baud rate divisor as the temperature changes. That get's expensive if you have to do it on every unit during production, but if the T/F curve is consistent enough between units, then maybe...
Reply by ●April 26, 20232023-04-26
On Wednesday, April 26, 2023 at 4:44:20 PM UTC-4, pozz wrote:> Il 26/04/2023 18:26, Rick C ha scritto: > > On Wednesday, April 26, 2023 at 10:57:01 AM UTC-4, pozz wrote: > >> I'd like to use async UART to let these MCUs communicate. > >> The protocol will be request-response with the request generated by the > >> SAM MCU. The baudrate will be 38400bps. > >> > >> I'd like to use internal oscillator of ATtiny4313, while the SAM will > >> use an external 32.768kHz crystal (that is multiplied by internal PLL to > >> reach 48MHz). > >> > >> I'm not sure if this scenario can work well. My concerns are related to > >> the internal oscillator of ATtiny4313 that hasn't a good accuracy over > >> temperature and life. > >> > >> The tiny MCU will be supplied by 3.3V and its temperature will be in the > >> range 0-80°C. > > > > I don't get what your question is. You seem to understand the concepts. You don't tell us the relevant data however. What does the data sheet say about the frequency variability of the internal clock over PVT (process, voltage and temperature)? I assume you are aware that the 3.3V supply will have an accuracy and an RC clock rate can be voltage dependent. It depends on how they designed the circuit. There are techniques for removing most of the voltage dependency, if they used them. > ATtiny4313 datasheet[1] says the internal oscillator is factory > calibrated with an accuracy of ±10% at Vcc=3V and 25°C temperature. This > accuracy can be reduced to ±2% at a fixed voltage and a fixed > temperature with a user calibration.Ok, that is information. Do you have a question?> > You can always use the bit times of the SAM to adjust the bit rate on the ATtiny. That used to be part of the protocol for low data rate modems. The first characters sent were AT if I recall, which give good edges to time to measure the bit rate. At 38400 bps this might be a bit tricker, it depends on your instruction rate. A bit time is just 26 us. Will this be a software UART, or a hardware unit? > > > I will use the interal UART peripheral of ATtiny4313. I can't add too > much code, the Flash memory is almost full. I wanted to know if the > figures shown on the datasheet guarantee good communication between the > the MCUs. It seems this isn't the case. > > > [1] https://ww1.microchip.com/downloads/en/DeviceDoc/doc8246.pdfYou point me to a data sheet. I am not reading the data sheet to do your work for you. I'm happy to discuss the information and offer advice and opinion. The info you provide above with the 2% stability if temperature and voltage are maintained and the clock calibrated, is not enough to know if this will work. When you write, "It seems this isn't the case.", what do you base this on? What is your reasoning? I don't think the software UART is a lot of code, but you don't need that. You need to write a routine to measure a bit time on the input to calibrate your clock to the incoming bit times. That should not be a lot of code. Translating a loop count into a bit clock setting for the UART should be a simple linear relationship, although it may involve a divide. You only need to work over a small range, so a small table lookup should be pretty close to optimal solution. I don't see where you have a choice, unless you want to add a crystal to the ATtiny. Can the SAM chip send a clock? You can use an SPI port instead of a UART, or just send a clock to use for the bit rate clock in the UART? -- Rick C. + Get 1,000 miles of free Supercharging + Tesla referral code - https://ts.la/richard11209
Reply by ●April 26, 20232023-04-26
On Wednesday, April 26, 2023 at 5:00:22 PM UTC-4, Grant Edwards wrote:> On 2023-04-26, pozz <pozz...@gmail.com> wrote: > > > ATtiny4313 datasheet[1] says the internal oscillator is factory > > calibrated with an accuracy of +/-10% at Vcc=3V and 25°C temperature. > 10% total error (combination of both ends) is pretty much right at the > limit according to the usual rule of thumb for UART receivers that > sync only on the start bit.I think you are not doing the calculation right. The limit is based on the UART trying to sample in the middle of a bit. If it gets out by a half a bit time, either way, it will sample the wrong bit. With 10 bits in the character, including start and stop bits, that puts the total error limit at about 5%. This is actually closer to 5.5% (because while it is 10 bits, it's only 9 bit times between start and stop bits), but then you need to subtract a fraction of a bit for the internal Nx clock used to sample the bit stream. So round off to 5%. That's the total error allowed, including both ends. Then there's distortion in the pulse edges. With 26 us bit times, there may be issues with asymmetric edge distortion. There has been no mention of the electrical interface.> IIRC, there used to be UART receivers that > would sync on every edge within the data "word" as well, but I don't > think that was ever very common -- and to take advantage of it, you > had to make sure your data had edges. :) > > Can you spare a line for a clock and go synchronous? (Or are they > really UARTs and not USARTs?). > > This accuracy can be reduced to +/-2% at a fixed voltage and a fixed > > temperature with a user calibration. > 2% is no problem at all. With a crystal on the other end, you should > be able to easily tolerate +/-5%. The requirement for a fixed > temperature, OTOH, is usually a problem. > > I could calibrate for a fixed voltage (3.3V), but I can't fix a > > temperature, because it can vary in the real application. > Does the ATtiny have an on-die temp sensor? If yes, you could try > characterizing the oscillator over temperature at 3.3V and adjusting > the baud rate divisor as the temperature changes. That get's expensive > if you have to do it on every unit during production, but if the T/F > curve is consistent enough between units, then maybe...Calibration, in general is expensive. But yes, a calibration curve is worse, since you need to wait for temperature to adjust. -- Rick C. -- Get 1,000 miles of free Supercharging -- Tesla referral code - https://ts.la/richard11209
Reply by ●April 27, 20232023-04-27
On 27/04/2023 02:10, Rick C wrote:> I don't think the software UART is a lot of code, but you don't need > that. You need to write a routine to measure a bit time on the input > to calibrate your clock to the incoming bit times. That should not > be a lot of code. Translating a loop count into a bit clock setting > for the UART should be a simple linear relationship, although it may > involve a divide. You only need to work over a small range, so a > small table lookup should be pretty close to optimal solution. >That's definitely one way to do it, yes. Have the master side send a couple of 0x00 bytes before the data, and use an interrupt on the Rx pin falling edge - when that comes in, count the time until a rising edge is seen. If that time works out to within 10% of the nominal expected time, you are calibrated and can turn off the interrupt. Alternatively, send 0x55 bytes first and measure multiple short periods. There will be some details to work out, depending on the what you are sending, the type of noise you expect, how often you need to re-calibrate, etc. You are making a software equivalent to a PLL. There's no need for a lookup table here (unless I've got my calculations upside down!). The more cycles you count for the incoming trainer characters, the bigger the UART divider value you need. That means your divisions will be done with constant values, and the compiler will turn those into multiplies. An alternative is trial and error. If your clock source is ±10%, and you need to get within ±2%, start your UART at the nominally correct baud rate. If you don't receive error-free telegrams within a timeout, go 2% faster. Keep adding 2%, stepping from +10% to -10%, until you hit a baud rate that works. You can get even fancier here by figuring out the lowest and highest rates that work, then picking their average to get the best value.
Reply by ●April 27, 20232023-04-27
Il 26/04/2023 23:00, Grant Edwards ha scritto:> On 2023-04-26, pozz <pozzugno@gmail.com> wrote: > >> ATtiny4313 datasheet[1] says the internal oscillator is factory >> calibrated with an accuracy of +/-10% at Vcc=3V and 25°C temperature. > > 10% total error (combination of both ends) is pretty much right at the > limit according to the usual rule of thumb for UART receivers that > sync only on the start bit. IIRC, there used to be UART receivers that > would sync on every edge within the data "word" as well, but I don't > think that was ever very common -- and to take advantage of it, you > had to make sure your data had edges. :) > > Can you spare a line for a clock and go synchronous? (Or are they > really UARTs and not USARTs?).No, I can't. The MCUs are not on the same board and they are really connected through RS485 half-duplex transceivers.>> This accuracy can be reduced to +/-2% at a fixed voltage and a fixed >> temperature with a user calibration. > > 2% is no problem at all. With a crystal on the other end, you should > be able to easily tolerate +/-5%. The requirement for a fixed > temperature, OTOH, is usually a problem. > >> I could calibrate for a fixed voltage (3.3V), but I can't fix a >> temperature, because it can vary in the real application. > > Does the ATtiny have an on-die temp sensor? If yes, you could try > characterizing the oscillator over temperature at 3.3V and adjusting > the baud rate divisor as the temperature changes. That get's expensive > if you have to do it on every unit during production, but if the T/F > curve is consistent enough between units, then maybe...Thank you for this suggestion, but I can't use this trick.
