Il 27/04/2023 02:10, Rick C ha scritto:> 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.pdf > > You point me to a data sheet. I am not reading the data sheet to do your work for you.And I don't want you do it if you don't want. The datasheet link is there if someone WANTS to look at it with a single click of the mouse.> 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?Because internal oscillator has an accuracy of 10% and I read that UART receivers are usually able to decode the input signal with an error of 2-5% order. However I tested one sample at high temperature, but the MCUs continued communicating well.> 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.Ok, thanks for suggestion.> 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?No, this isn't an option.
UART connection between ATSAMD20 and ATtiny4313
Started by ●April 26, 2023
Reply by ●April 27, 20232023-04-27
Reply by ●April 27, 20232023-04-27
On 2023-04-27, pozz <pozzugno@gmail.com> wrote:> Il 27/04/2023 02:10, Rick C ha scritto: > >> 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? > > No, this isn't an option.The other option would be to adopt a Manchester-encoded (self clocking) signal. Wouldn't be true RS485 but would pass through transceivers and cabling at sensible baud rates. Manchester coding is fine provided the clocks are within 2:1 of each other. You will need to bit-bang the interface though, the UART won't handle it. -- Andrew Smallshaw andrews@sdf.org
Reply by ●April 27, 20232023-04-27
On Thursday, April 27, 2023 at 4:28:29 AM UTC-4, pozz wrote:> Il 27/04/2023 02:10, Rick C ha scritto: > > 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.pdf > > > > You point me to a data sheet. I am not reading the data sheet to do your work for you. > And I don't want you do it if you don't want.I'm glad we are in agreement. My point is you could have pointed us to any useful info in the document, or better quoted it, if there was anything you had not already quoted. I find CPU data sheets to be rather onerous to read, as they have so much data in them these days, and they don't always put timing data in the timing section, for example.> The datasheet link is > there if someone WANTS to look at it with a single click of the mouse. > > 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? > Because internal oscillator has an accuracy of 10% and I read that UART > receivers are usually able to decode the input signal with an error of > 2-5% order.The 10% was for a fixed voltage and temperature without calibration. I don't recall if you are adverse to calibration. But you do have a wide temperature range which is an issue.> However I tested one sample at high temperature, but the MCUs continued > communicating well.That means pretty much nothing. While testing can prove that something doesn't work, it can't prove that it does. Instead of simply testing pass/fail, it would have been more useful to measure the clock rate, by measuring the bit rate over temperature. Get some numbers for multiple units to see what sort of spread you get.> > 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. > Ok, thanks for suggestion. > > 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? > No, this isn't an option.You can't add a crystal? Then the two workable choices would appear to be calibration of each unit over temperature, or a real time calibration from the data rate of the incoming data. I can't think of any other solutions. Adding the crystal seems the simple route. -- Rick C. -+ Get 1,000 miles of free Supercharging -+ Tesla referral code - https://ts.la/richard11209
Reply by ●April 27, 20232023-04-27
On Thursday, April 27, 2023 at 9:28:33 AM UTC-4, Andrew Smallshaw wrote:> On 2023-04-27, pozz <pozz...@gmail.com> wrote: > > Il 27/04/2023 02:10, Rick C ha scritto: > > > >> 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? > > > > No, this isn't an option. > The other option would be to adopt a Manchester-encoded (self > clocking) signal. Wouldn't be true RS485 but would pass through > transceivers and cabling at sensible baud rates. Manchester coding > is fine provided the clocks are within 2:1 of each other. You will > need to bit-bang the interface though, the UART won't handle it.What about Manchester encoding is not RS-485? That's just an electrical interface standard, no? But that is a great idea... if the hardware will accommodate it. Or this can be done in the UART using a faster clock and synchronous mode. Send characters with one data bit per character, the Manchester encoded bit, x0F or xF0. It would not be terribly hard to decode the data in software.. possibly. I believe you align to the transition that is always present mid-cell, then look for the presence/absence of the other transition. The OP talked about the "small" processor being program space constrained, but again, this is not a lot of code... maybe. So maybe this will be too much. But it would solve the clocking issue. Then again, so would a crystal. -- 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.4.2023 16.28, Andrew Smallshaw wrote:> On 2023-04-27, pozz <pozzugno@gmail.com> wrote: >> Il 27/04/2023 02:10, Rick C ha scritto: >> >>> 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? >> >> No, this isn't an option. > > The other option would be to adopt a Manchester-encoded (self > clocking) signal. Wouldn't be true RS485 but would pass through > transceivers and cabling at sensible baud rates. Manchester coding > is fine provided the clocks are within 2:1 of each other. You will > need to bit-bang the interface though, the UART won't handle it.I doubt that the ATTiny can handle Manchester coding at the requested bit rate, and it may be difficult for the SAM. In 2016, I made a processor unit using AT91SAM4E for IEC H1 Manchester coded bus at 31.25 kbit/s. The trick was to innovatively use the timer counter units of the chip. A timer used to measure the times between pulse edges could be used to receive and decode the incoming data, and a timer running at half of the bit rate (15.625 kbit/s) could be used to send the data. The receiver needed to respond to interrupts at the incoming edge rate, and the transmitter needed to respond at the outgoing bit rate. -- -TV
Reply by ●April 27, 20232023-04-27
Den 2023-04-27 kl. 19:18, skrev Tauno Voipio:> On 27.4.2023 16.28, Andrew Smallshaw wrote: >> On 2023-04-27, pozz <pozzugno@gmail.com> wrote: >>> Il 27/04/2023 02:10, Rick C ha scritto: >>> >>>> 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? >>> >>> No, this isn't an option. >> >> The other option would be to adopt a Manchester-encoded (self >> clocking) signal. Wouldn't be true RS485 but would pass through >> transceivers and cabling at sensible baud rates. Manchester coding >> is fine provided the clocks are within 2:1 of each other. You will >> need to bit-bang the interface though, the UART won't handle it. > > > I doubt that the ATTiny can handle Manchester coding at the requested > bit rate, and it may be difficult for the SAM.Atmel implemented Manchester Coding in the SAM7 USART (My proposal) but the SAMD20 has a "SERCOM" module without Manchester Coding. I would look into the event system. The tiny will have to do it in S/W. /Ulf> > In 2016, I made a processor unit using AT91SAM4E for IEC H1 Manchester > coded bus at 31.25 kbit/s. The trick was to innovatively use the timer > counter units of the chip. A timer used to measure the times between > pulse edges could be used to receive and decode the incoming data, and > a timer running at half of the bit rate (15.625 kbit/s) could be used > to send the data. The receiver needed to respond to interrupts at the > incoming edge rate, and the transmitter needed to respond at the > outgoing bit rate. >The SAM4E USART supports Manchester Coding in H/W. The SAM4E UART does not. /Ulf
Reply by ●April 27, 20232023-04-27
On Thursday, April 27, 2023 at 1:19:01 PM UTC-4, Tauno Voipio wrote:> On 27.4.2023 16.28, Andrew Smallshaw wrote: > > On 2023-04-27, pozz <pozz...@gmail.com> wrote: > >> Il 27/04/2023 02:10, Rick C ha scritto: > >> > >>> 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? > >> > >> No, this isn't an option. > > > > The other option would be to adopt a Manchester-encoded (self > > clocking) signal. Wouldn't be true RS485 but would pass through > > transceivers and cabling at sensible baud rates. Manchester coding > > is fine provided the clocks are within 2:1 of each other. You will > > need to bit-bang the interface though, the UART won't handle it. > I doubt that the ATTiny can handle Manchester coding at the requested > bit rate, and it may be difficult for the SAM. > > In 2016, I made a processor unit using AT91SAM4E for IEC H1 Manchester > coded bus at 31.25 kbit/s. The trick was to innovatively use the timer > counter units of the chip. A timer used to measure the times between > pulse edges could be used to receive and decode the incoming data, and > a timer running at half of the bit rate (15.625 kbit/s) could be used > to send the data. The receiver needed to respond to interrupts at the > incoming edge rate, and the transmitter needed to respond at the > outgoing bit rate.That's if the entire job is handled in software, perhaps. The USART can be used to send the bits as characters at the transmitter. A USART can be used to handle the reception with software seeking edges. I don't think that would be a huge burden at 38.4 kbps. But then, I'm more used to FPGA work. -- Rick C. ++ Get 1,000 miles of free Supercharging ++ Tesla referral code - https://ts.la/richard11209
Reply by ●April 28, 20232023-04-28
On 28.4.2023 0.03, Ulf Samuelsson wrote:> Den 2023-04-27 kl. 19:18, skrev Tauno Voipio: >> On 27.4.2023 16.28, Andrew Smallshaw wrote: >>> On 2023-04-27, pozz <pozzugno@gmail.com> wrote: >>>> Il 27/04/2023 02:10, Rick C ha scritto: >>>> >>>>> 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? >>>> >>>> No, this isn't an option. >>> >>> The other option would be to adopt a Manchester-encoded (self >>> clocking) signal. Wouldn't be true RS485 but would pass through >>> transceivers and cabling at sensible baud rates. Manchester coding >>> is fine provided the clocks are within 2:1 of each other. You will >>> need to bit-bang the interface though, the UART won't handle it. >> >> >> I doubt that the ATTiny can handle Manchester coding at the requested >> bit rate, and it may be difficult for the SAM. > > Atmel implemented Manchester Coding in the SAM7 USART (My proposal) > but the SAMD20 has a "SERCOM" module without Manchester Coding. > I would look into the event system. > > > The tiny will have to do it in S/W. > /Ulf > >> >> In 2016, I made a processor unit using AT91SAM4E for IEC H1 Manchester >> coded bus at 31.25 kbit/s. The trick was to innovatively use the timer >> counter units of the chip. A timer used to measure the times between >> pulse edges could be used to receive and decode the incoming data, and >> a timer running at half of the bit rate (15.625 kbit/s) could be used >> to send the data. The receiver needed to respond to interrupts at the >> incoming edge rate, and the transmitter needed to respond at the >> outgoing bit rate. >> > > The SAM4E USART supports Manchester Coding in H/W. > The SAM4E UART does not. > > /UlfThe problem with the USART Manchester coder was in address markers (intentional mis-codings). It was not possible to conform with the markers in the IEC coding. -- -TV
Reply by ●April 28, 20232023-04-28
On 28.4.2023 3.45, Rick C wrote:> On Thursday, April 27, 2023 at 1:19:01 PM UTC-4, Tauno Voipio wrote: >> On 27.4.2023 16.28, Andrew Smallshaw wrote: >>> On 2023-04-27, pozz <pozz...@gmail.com> wrote: >>>> Il 27/04/2023 02:10, Rick C ha scritto: >>>> >>>>> 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? >>>> >>>> No, this isn't an option. >>> >>> The other option would be to adopt a Manchester-encoded (self >>> clocking) signal. Wouldn't be true RS485 but would pass through >>> transceivers and cabling at sensible baud rates. Manchester coding >>> is fine provided the clocks are within 2:1 of each other. You will >>> need to bit-bang the interface though, the UART won't handle it. >> I doubt that the ATTiny can handle Manchester coding at the requested >> bit rate, and it may be difficult for the SAM. >> >> In 2016, I made a processor unit using AT91SAM4E for IEC H1 Manchester >> coded bus at 31.25 kbit/s. The trick was to innovatively use the timer >> counter units of the chip. A timer used to measure the times between >> pulse edges could be used to receive and decode the incoming data, and >> a timer running at half of the bit rate (15.625 kbit/s) could be used >> to send the data. The receiver needed to respond to interrupts at the >> incoming edge rate, and the transmitter needed to respond at the >> outgoing bit rate. > > That's if the entire job is handled in software, perhaps. The USART can be used to send the bits as characters at the transmitter. A USART can be used to handle the reception with software seeking edges. I don't think that would be a huge burden at 38.4 kbps. But then, I'm more used to FPGA work.Had to bit-bang. The USART cannot create or detect IEC H1 standard address marker octets. -- -TV
Reply by ●April 28, 20232023-04-28
On Friday, April 28, 2023 at 3:00:45 AM UTC-4, Tauno Voipio wrote:> On 28.4.2023 3.45, Rick C wrote: > > On Thursday, April 27, 2023 at 1:19:01 PM UTC-4, Tauno Voipio wrote: > >> On 27.4.2023 16.28, Andrew Smallshaw wrote: > >>> On 2023-04-27, pozz <pozz...@gmail.com> wrote: > >>>> Il 27/04/2023 02:10, Rick C ha scritto: > >>>> > >>>>> 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? > >>>> > >>>> No, this isn't an option. > >>> > >>> The other option would be to adopt a Manchester-encoded (self > >>> clocking) signal. Wouldn't be true RS485 but would pass through > >>> transceivers and cabling at sensible baud rates. Manchester coding > >>> is fine provided the clocks are within 2:1 of each other. You will > >>> need to bit-bang the interface though, the UART won't handle it. > >> I doubt that the ATTiny can handle Manchester coding at the requested > >> bit rate, and it may be difficult for the SAM. > >> > >> In 2016, I made a processor unit using AT91SAM4E for IEC H1 Manchester > >> coded bus at 31.25 kbit/s. The trick was to innovatively use the timer > >> counter units of the chip. A timer used to measure the times between > >> pulse edges could be used to receive and decode the incoming data, and > >> a timer running at half of the bit rate (15.625 kbit/s) could be used > >> to send the data. The receiver needed to respond to interrupts at the > >> incoming edge rate, and the transmitter needed to respond at the > >> outgoing bit rate. > > > > That's if the entire job is handled in software, perhaps. The USART can be used to send the bits as characters at the transmitter. A USART can be used to handle the reception with software seeking edges. I don't think that would be a huge burden at 38.4 kbps. But then, I'm more used to FPGA work. > Had to bit-bang. The USART cannot create or detect IEC H1 standard > address marker octets.I did a Google search and this didn't return anything useful. So I don't know for certain what an IEC H1 standard address marker octet is, but if I'm specifying the waveform, rather than relying on the hardware to do the Manchester encoding, I can't see a reason why I could not transmit any given waveform. Can you point me to something that describes these marker octets? -- Rick C. --- Get 1,000 miles of free Supercharging --- Tesla referral code - https://ts.la/richard11209
