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'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.
On Wednesday, April 26, 2023 at 10:57:01 AM UTC-4, pozz wrote: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.
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
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. At38400 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?
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.
Il 26/04/2023 18:26, Rick C ha scritto: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.
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
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.
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?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
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
On 2023-04-26, pozz <pozz...@gmail.com> wrote:
ATtiny4313 datasheet[1] says the internal oscillator is factory10% total error (combination of both ends) is pretty much right at the
calibrated with an accuracy of +/-10% at Vcc=3V and 25°C temperature.
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...
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.
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...
On Wednesday, April 26, 2023 at 4:44:20 PM UTC-4, pozz wrote: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.
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
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?
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?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
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.
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 countinto 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?
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.
Il 27/04/2023 02:10, Rick C ha scritto: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.
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
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?
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?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.
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.
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 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
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.
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.
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.
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.
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 (selfI doubt that the ATTiny can handle Manchester coding at the requested
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.
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.
On Thursday, April 27, 2023 at 1:19:01 PM UTC-4, Tauno Voipio wrote:38.4 kbps. But then, I'm more used to FPGA work.
On 27.4.2023 16.28, Andrew Smallshaw wrote:
On 2023-04-27, pozz <pozz...@gmail.com> wrote:I doubt that the ATTiny can handle Manchester coding at the requested
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.
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
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
On 28.4.2023 3.45, Rick C wrote:38.4 kbps. But then, I'm more used to FPGA work.
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:I doubt that the ATTiny can handle Manchester coding at the requested
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.
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
Had to bit-bang. The USART cannot create or detect IEC H1 standard
address marker octets.
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:The other option would be to adopt a Manchester-encoded (self
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.
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.
On Friday, April 28, 2023 at 3:00:45 AM UTC-4, Tauno Voipio wrote:38.4 kbps. But then, I'm more used to FPGA work.
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:I doubt that the ATTiny can handle Manchester coding at the requested
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.
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
see a reason why I could not transmit any given waveform. Can you point me to something that describes these marker octets?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
On 27/04/2023 18:22, Rick C wrote:
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:The other option would be to adopt a Manchester-encoded (self
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.
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?
Technically, you are correct. In reality, the term "RS-485" is usually
used to mean "UART signalling on an RS-485 bus" - any other kind of signalling (such as Manchester encoding) would be specified explicitly.
It's good to be technically accurate, but also good to consider less accurate common usage of terms.
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.
Not all microcontroller UARTs have synchronous modes.
Receiving or
sending Manchester encoded data with a UART is fiddly because of the
start and stop bits of UART, so it is often done by bit-banging.
Whether or not that suits the OP, only he can say.
On 28.4.2023 10.21, Rick C wrote:
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:Had to bit-bang. The USART cannot create or detect IEC H1 standard
On 2023-04-27, pozz <pozz...@gmail.com> wrote:I doubt that the ATTiny can handle Manchester coding at the requested >>>>> bit rate, and it may be difficult for the SAM.
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.
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.
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?
The H1 bus is an industrial fieldbus and technical information about
it has been notoriously difficult to access.
The Manchester coding in the H1 bus is sent as current variations,
which are converted into voltage variations for receiving.
I'll show the more positive voltage with a plus sign and the less
positive voltage with a minus sign.
A state pair takes one bit time (32 us) with the change at the middle.
A data bit of '1' is sent as +-
A data bit of '0' is sent as -+
There are two intentional miscodings for delimiters:
A coding N+ is sent as ++
A coding N- is sent as --
A frame starts with a preamble of alternating 0's and 1's:
1 0 1 0 1 0 1 0 1 0
After preamble a start delimiter is sent:
1 N+ N- 1 0 N- N+ 0
The packet content follows, with most significant bit first.
After last data octet an end delimiter is sent:
1 N+ N- N+ N- 1 0 1
After the packet the transmitter is switched off, so the line
will stay halfway between the + and - states.
The processor chip Manchester coders could not be twisted to
handle the start end end delimiters correctly.
On 28.4.2023 10.21, Rick C wrote:38.4 kbps. But then, I'm more used to FPGA work.
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:I doubt that the ATTiny can handle Manchester coding at the requested >>>> bit rate, and it may be difficult for the SAM.
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.
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
see a reason why I could not transmit any given waveform. Can you point me to something that describes these marker octets?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
The H1 bus is an industrial fieldbus and technical information about
it has been notoriously difficult to access.
The Manchester coding in the H1 bus is sent as current variations,
which are converted into voltage variations for receiving.
I'll show the more positive voltage with a plus sign and the less
positive voltage with a minus sign.
A state pair takes one bit time (32 us) with the change at the middle.
A data bit of '1' is sent as +-
A data bit of '0' is sent as -+
There are two intentional miscodings for delimiters:
A coding N+ is sent as ++
A coding N- is sent as --
A frame starts with a preamble of alternating 0's and 1's:
1 0 1 0 1 0 1 0 1 0
After preamble a start delimiter is sent:
1 N+ N- 1 0 N- N+ 0
The packet content follows, with most significant bit first.
After last data octet an end delimiter is sent:
1 N+ N- N+ N- 1 0 1
After the packet the transmitter is switched off, so the line
will stay halfway between the + and - states.
The processor chip Manchester coders could not be twisted to
handle the start end end delimiters correctly.
On Friday, April 28, 2023 at 4:43:13 AM UTC-4, Tauno Voipio wrote:at 38.4 kbps. But then, I'm more used to FPGA work.
On 28.4.2023 10.21, Rick C wrote:
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
t see a reason why I could not transmit any given waveform. Can you point me to something that describes these marker octets?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'
required. The UART aligns to the start of the bit frame, so less work in the software. It becomes a matter of recognizing which of the 7 bit patterns are received. You really only need to look at two bit positions to distinguish the three values.The H1 bus is an industrial fieldbus and technical information about
it has been notoriously difficult to access.
The Manchester coding in the H1 bus is sent as current variations,
which are converted into voltage variations for receiving.
I'll show the more positive voltage with a plus sign and the less
positive voltage with a minus sign.
A state pair takes one bit time (32 us) with the change at the middle.
A data bit of '1' is sent as +-
A data bit of '0' is sent as -+
There are two intentional miscodings for delimiters:
A coding N+ is sent as ++
A coding N- is sent as --
A frame starts with a preamble of alternating 0's and 1's:
1 0 1 0 1 0 1 0 1 0
After preamble a start delimiter is sent:
1 N+ N- 1 0 N- N+ 0
The packet content follows, with most significant bit first.
After last data octet an end delimiter is sent:
1 N+ N- N+ N- 1 0 1
After the packet the transmitter is switched off, so the line
will stay halfway between the + and - states.
The processor chip Manchester coders could not be twisted toYes, my point is you can run the USART at a higher rate and send data as x0F, xF0, x00 or xFF. You can use the hardware without a hardware Manchester encoder.
handle the start end end delimiters correctly.
Actually, I think Manchester encoding is inferior to the scheme they use in the IRIG signal (also the WWVB time broadcast). I don't know if that PWM scheme has a particular name, but it is very robust and can be implemented with a UART, so no USART
On Thursday, April 27, 2023 at 4:28:29 AM UTC-4, pozz 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 aNo, this isn't an option.
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?
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.
On Thursday, April 27, 2023 at 1:19:01 PM UTC-4, Tauno Voipio wrote:
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.
Den 2023-04-28 kl. 10:43, skrev Tauno Voipio:
On 28.4.2023 10.21, Rick C wrote:
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:Had to bit-bang. The USART cannot create or detect IEC H1 standard
On 2023-04-27, pozz <pozz...@gmail.com> wrote:I doubt that the ATTiny can handle Manchester coding at the requested >>>>>> bit rate, and it may be difficult for the SAM.
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.
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.
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?
The H1 bus is an industrial fieldbus and technical information about
it has been notoriously difficult to access.
The Manchester coding in the H1 bus is sent as current variations,
which are converted into voltage variations for receiving.
I'll show the more positive voltage with a plus sign and the less
positive voltage with a minus sign.
A state pair takes one bit time (32 us) with the change at the middle.
A data bit of '1' is sent as +-
A data bit of '0' is sent as -+
There are two intentional miscodings for delimiters:
A coding N+ is sent as ++
A coding N- is sent as --
A frame starts with a preamble of alternating 0's and 1's:
1 0 1 0 1 0 1 0 1 0
After preamble a start delimiter is sent:
1 N+ N- 1 0 N- N+ 0
The packet content follows, with most significant bit first.
After last data octet an end delimiter is sent:
1 N+ N- N+ N- 1 0 1
After the packet the transmitter is switched off, so the line
will stay halfway between the + and - states.
The processor chip Manchester coders could not be twisted to
handle the start end end delimiters correctly.
If the bus speed is known, this packet seems overkill.
It can be used to detect the BAUD rate.
The Atmel USART is designed to use a 9-bit mode for packet data, with
the 9th bit set for addresses.
/Ulf.
On 27/04/2023 18:02, Rick C wrote:
On Thursday, April 27, 2023 at 4:28:29 AM UTC-4, pozz 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 aNo, this isn't an option.
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?
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.
Perhaps he already has the boards produced - adding a crystal is then a rather difficult task! Even if the design is not completed, the Tiny is
a very small, cheap and low power family. Adding a crystal makes the
design bigger, more expensive and uses more power - assuming there are suitable pins free for connecting a crystal. Now, a small, cheap
crystal might be $0.50 and just a few square millimetres, but so is a
small AVR Tiny. I don't know why the OP is using a a Tiny, but if it is
for good technical or economic reasons, adding a crystal would work
against it.
Trial-and-error, as I suggested earlier, is another workable choice.
On 28/04/2023 02:45, Rick C wrote:
On Thursday, April 27, 2023 at 1:19:01 PM UTC-4, Tauno Voipio wrote:
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.
You certainly /can/ do this kind of thing in software on a Tiny.
However, it might be a challenge depending on other factors. If the
device already has high-precision timing requirements for another task, doing two of them can get complicated. If you need to deal with a lot
of noise on the lines, that too is messy.
On Friday, April 28, 2023 at 9:01:09 AM UTC-4, David Brown wrote:
On 27/04/2023 18:02, Rick C wrote:
On Thursday, April 27, 2023 at 4:28:29 AM UTC-4, pozz wrote:Perhaps he already has the boards produced - adding a crystal is then a
Il 27/04/2023 02:10, Rick C ha scritto:
I don't see where you have a choice, unless you want to add aNo, this isn't an option.
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?
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.
rather difficult task! Even if the design is not completed, the Tiny is
a very small, cheap and low power family. Adding a crystal makes the
design bigger, more expensive and uses more power - assuming there are
suitable pins free for connecting a crystal. Now, a small, cheap
crystal might be $0.50 and just a few square millimetres, but so is a
small AVR Tiny. I don't know why the OP is using a a Tiny, but if it is
for good technical or economic reasons, adding a crystal would work
against it.
Trial-and-error, as I suggested earlier, is another workable choice.
Yes, trial and error. I believe that's the design process recommended by NASA.
WTF are you talking about? If he's designed the board without considering the requirements, that's a failure of the first order. If someone imposed new requirements on the design, that's a perfect justification to respin the board.
Once again, not rocket science.
On Friday, April 28, 2023 at 8:51:33 AM UTC-4, David Brown wrote:
On 28/04/2023 02:45, Rick C wrote:
On Thursday, April 27, 2023 at 1:19:01 PM UTC-4, Tauno VoipioYou certainly /can/ do this kind of thing in software on a Tiny.
wrote:
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.
However, it might be a challenge depending on other factors. If
the device already has high-precision timing requirements for
another task, doing two of them can get complicated. If you need to
deal with a lot of noise on the lines, that too is messy.
I don't think you understand the issues. If there is a lot of noise,
the project is dead in the water regardless. Fix your noise
problems.
This does not impose "high-precision timing requirements" on the CPU.
The only requirements are to handle the data without dropping. It's
NOT bit banging, so there is lots of time to handle the data.
If the CPU is overloaded, then you picked the wrong CPU. Get a
faster one.
Why are you bringing in all this silliness? It's almost as if you've
never done design work.
On 29/04/2023 01:41, Rick C wrote:
On Friday, April 28, 2023 at 8:51:33 AM UTC-4, David Brown wrote:
On 28/04/2023 02:45, Rick C wrote:
On Thursday, April 27, 2023 at 1:19:01 PM UTC-4, Tauno VoipioYou certainly /can/ do this kind of thing in software on a Tiny.
wrote:
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.
However, it might be a challenge depending on other factors. If
the device already has high-precision timing requirements for
another task, doing two of them can get complicated. If you need to
deal with a lot of noise on the lines, that too is messy.
I don't think you understand the issues. If there is a lot of noise,
the project is dead in the water regardless. Fix your noise
problems.
This does not impose "high-precision timing requirements" on the CPU.
The only requirements are to handle the data without dropping. It's
NOT bit banging, so there is lots of time to handle the data.
If the CPU is overloaded, then you picked the wrong CPU. Get a
faster one.
Why are you bringing in all this silliness? It's almost as if you've
never done design work.
Have you heard the saying that it is better to keep quite and be thought
a fool, rather than opening your mouth and proving it? Do you think the
OP would have started this discussion if "just use a better
microcontroller" were a viable option?
Il 26/04/2023 16:56, pozz ha scritto:
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 want to thank all the ones that spent some time to reply and give suggestions. As usual, they are valuable for me.
I'm working on a board that is already in production. It was chosen a
tiny for its low cost.
The possibility to mount and use an external ceramic resonator is
available. Moreover it has been really mounted on around 1k boards that
are working now.
However a few customers reported a problem in a few installations: the
tiny blocks and only a power cycle is able to restart.
After some tests, we found that the problem is radiated noise on the
pins of the tiny oscillator. When power cables are near the board and
some specific load are connected to these cables, the noise generated is capable to block the tiny.
We tried to replace the ceramic resonator with a quartz crystal without success. We tried to strenghten the GND connection between the resonator/quartz and the single GND pin of the SOIC20, without success.
The only change that seems effective in avoiding blocks is using the internal oscillator.
This is the story.
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.
On Wednesday, May 3, 2023 at 12:16:49 PM UTC-4, pozz wrote:
Il 26/04/2023 16:56, pozz ha scritto:
I'd like to use async UART to let these MCUs communicate.I want to thank all the ones that spent some time to reply and give
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.
suggestions. As usual, they are valuable for me.
I'm working on a board that is already in production. It was chosen a
tiny for its low cost.
The possibility to mount and use an external ceramic resonator is
available. Moreover it has been really mounted on around 1k boards that
are working now.
However a few customers reported a problem in a few installations: the
tiny blocks and only a power cycle is able to restart.
After some tests, we found that the problem is radiated noise on the
pins of the tiny oscillator. When power cables are near the board and
some specific load are connected to these cables, the noise generated is
capable to block the tiny.
We tried to replace the ceramic resonator with a quartz crystal without
success. We tried to strenghten the GND connection between the
resonator/quartz and the single GND pin of the SOIC20, without success.
The only change that seems effective in avoiding blocks is using the
internal oscillator.
This is the story.
So I assume there is a reason why you can't route the power wires away from the ATtiny board?
I think you have been provided with all the possibilities for how to use the internal oscillator. It rather comes down to "pick one". Are any more appealing than the others? If you tell us what you don't like about it, maybe we can help refine thesolution?
Il 03/05/2023 18:40, Rick C ha scritto:
On Wednesday, May 3, 2023 at 12:16:49 PM UTC-4, pozz wrote:
Il 26/04/2023 16:56, pozz ha scritto:
I'd like to use async UART to let these MCUs communicate.I want to thank all the ones that spent some time to reply and give
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.
suggestions. As usual, they are valuable for me.
I'm working on a board that is already in production. It was chosen a
tiny for its low cost.
The possibility to mount and use an external ceramic resonator is
available. Moreover it has been really mounted on around 1k boards that
are working now.
However a few customers reported a problem in a few installations: the
tiny blocks and only a power cycle is able to restart.
After some tests, we found that the problem is radiated noise on the
pins of the tiny oscillator. When power cables are near the board and
some specific load are connected to these cables, the noise generated is >>> capable to block the tiny.
We tried to replace the ceramic resonator with a quartz crystal without
success. We tried to strenghten the GND connection between the
resonator/quartz and the single GND pin of the SOIC20, without success.
The only change that seems effective in avoiding blocks is using the
internal oscillator.
This is the story.
So I assume there is a reason why you can't route the power wires away
from the ATtiny board?
It depends. In some cases it is possible, in other cases it isn't. The installer isn't usually competent, so it routes cables as he wants. In
some cases, too near my board. After some weeks or months, he complains
the board has blocked. And he is my customer...
I think you have been provided with all the possibilities for how to
use the internal oscillator. It rather comes down to "pick one". Are
any more appealing than the others? If you tell us what you don't
like about it, maybe we can help refine the solution?
At the moment we are deciding what could be the best solution.
Il 03/05/2023 18:40, Rick C ha scritto:solution?
On Wednesday, May 3, 2023 at 12:16:49 PM UTC-4, pozz wrote:
Il 26/04/2023 16:56, pozz ha scritto:
I'd like to use async UART to let these MCUs communicate.I want to thank all the ones that spent some time to reply and give
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.
suggestions. As usual, they are valuable for me.
I'm working on a board that is already in production. It was chosen a
tiny for its low cost.
The possibility to mount and use an external ceramic resonator is
available. Moreover it has been really mounted on around 1k boards that >> are working now.
However a few customers reported a problem in a few installations: the
tiny blocks and only a power cycle is able to restart.
After some tests, we found that the problem is radiated noise on the
pins of the tiny oscillator. When power cables are near the board and
some specific load are connected to these cables, the noise generated is >> capable to block the tiny.
We tried to replace the ceramic resonator with a quartz crystal without >> success. We tried to strenghten the GND connection between the
resonator/quartz and the single GND pin of the SOIC20, without success. >>
The only change that seems effective in avoiding blocks is using the
internal oscillator.
This is the story.
So I assume there is a reason why you can't route the power wires away from the ATtiny board?It depends. In some cases it is possible, in other cases it isn't. The installer isn't usually competent, so it routes cables as he wants. In
some cases, too near my board. After some weeks or months, he complains
the board has blocked. And he is my customer...
I think you have been provided with all the possibilities for how to use the internal oscillator. It rather comes down to "pick one". Are any more appealing than the others? If you tell us what you don't like about it, maybe we can help refine the
At the moment we are deciding what could be the best solution.
On 04/05/2023 10:34, pozz wrote:
Il 03/05/2023 18:40, Rick C ha scritto:
On Wednesday, May 3, 2023 at 12:16:49 PM UTC-4, pozz wrote:
Il 26/04/2023 16:56, pozz ha scritto:
I'd like to use async UART to let these MCUs communicate.I want to thank all the ones that spent some time to reply and give
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.
suggestions. As usual, they are valuable for me.
I'm working on a board that is already in production. It was chosen a
tiny for its low cost.
The possibility to mount and use an external ceramic resonator is
available. Moreover it has been really mounted on around 1k boards that >>>> are working now.
However a few customers reported a problem in a few installations: the >>>> tiny blocks and only a power cycle is able to restart.
After some tests, we found that the problem is radiated noise on the
pins of the tiny oscillator. When power cables are near the board and
some specific load are connected to these cables, the noise
generated is
capable to block the tiny.
We tried to replace the ceramic resonator with a quartz crystal without >>>> success. We tried to strenghten the GND connection between the
resonator/quartz and the single GND pin of the SOIC20, without success. >>>>
The only change that seems effective in avoiding blocks is using the
internal oscillator.
This is the story.
So I assume there is a reason why you can't route the power wires
away from the ATtiny board?
It depends. In some cases it is possible, in other cases it isn't. The
installer isn't usually competent, so it routes cables as he wants. In
some cases, too near my board. After some weeks or months, he
complains the board has blocked. And he is my customer...
I think you have been provided with all the possibilities for how to
use the internal oscillator. It rather comes down to "pick one".
Are any more appealing than the others? If you tell us what you
don't like about it, maybe we can help refine the solution?
At the moment we are deciding what could be the best solution.
Do you do EMC testing for radiation emission and susceptibility? I
don't know what the rules and regulations are like where you are, but
any finished product (as distinct from prototype or test systems) made
here in Europe should be EMC certified. If radiated noise from "normal" power cables killed a card, that would be a failure in the certification.
Or is it the surrounding system that is bad? Maybe there is something
truly terrible connected to these power cables?
On Thursday, May 4, 2023 at 4:34:25 AM UTC-4, pozz wrote:solution?
Il 03/05/2023 18:40, Rick C ha scritto:
On Wednesday, May 3, 2023 at 12:16:49 PM UTC-4, pozz wrote:It depends. In some cases it is possible, in other cases it isn't. The
Il 26/04/2023 16:56, pozz ha scritto:
I'd like to use async UART to let these MCUs communicate.I want to thank all the ones that spent some time to reply and give
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.
suggestions. As usual, they are valuable for me.
I'm working on a board that is already in production. It was chosen a
tiny for its low cost.
The possibility to mount and use an external ceramic resonator is
available. Moreover it has been really mounted on around 1k boards that >>>> are working now.
However a few customers reported a problem in a few installations: the >>>> tiny blocks and only a power cycle is able to restart.
After some tests, we found that the problem is radiated noise on the
pins of the tiny oscillator. When power cables are near the board and
some specific load are connected to these cables, the noise generated is >>>> capable to block the tiny.
We tried to replace the ceramic resonator with a quartz crystal without >>>> success. We tried to strenghten the GND connection between the
resonator/quartz and the single GND pin of the SOIC20, without success. >>>>
The only change that seems effective in avoiding blocks is using the
internal oscillator.
This is the story.
So I assume there is a reason why you can't route the power wires away from the ATtiny board?
installer isn't usually competent, so it routes cables as he wants. In
some cases, too near my board. After some weeks or months, he complains
the board has blocked. And he is my customer...
I think you have been provided with all the possibilities for how to use the internal oscillator. It rather comes down to "pick one". Are any more appealing than the others? If you tell us what you don't like about it, maybe we can help refine the
specify that nothing be within some distance of your board. That is not an unusual thing for sensitive circuits.At the moment we are deciding what could be the best solution.
Perhaps you can add an enclosure to your board so cables can not be so near? You could make it look like an EMI shield. Heck, a simple piece of plexiglass mounted a half inch from your board should do the job. Also, it is perfectly acceptable to
BTW, do you get the same sort of hang condition if you bring other metal near the oscillators? It may not be an EMI issue at all, but rather a capacitive effect on the oscillator circuit. They often are sensitive to the details of the parasiticvalues. If you have a resistor in series with the crystal, this might need to be reduced in value, or increased.
What circuit does the manufacturer recommend for the oscillator?
Can you provide more detail on the nature of the hang? Does the oscillator stop working? Does the frequency shift? Can you measure any of this? Just saying "without success" isn't much to go on.
Il 04/05/2023 12:31, David Brown ha scritto:
Do you do EMC testing for radiation emission and susceptibility? I
don't know what the rules and regulations are like where you are, but
any finished product (as distinct from prototype or test systems) made
here in Europe should be EMC certified. If radiated noise from
"normal" power cables killed a card, that would be a failure in the
certification.
Yes, of course. This problem happens only on the field in a few
installations where cables are routed near my product, that is small and
in a plastic enclosure.
Or is it the surrounding system that is bad? Maybe there is something
truly terrible connected to these power cables?
The critical installations often have cables that gives mains power
(230Vac) to coils, for example relays or door ring bell.
The critical installations often have cables that gives mains power
(230Vac) to coils, for example relays or door ring bell.
The current used for door bells - even modern monstrosities with cameras
- is tiny.
I really think something must be wrong with the card if it
is susceptible to interference from such cables. Oscillators - crystal
or ceramic - usually need load capacitors and a damping resistor. These
are small loads (perhaps 15-20 pF and 10 MΩ), and are sometimes built
into the microcontroller. But if these are missing, your oscillator
could be unstable and easily affected by outside influence.
Il 05/05/2023 12:59, David Brown ha scritto:
[...]
The critical installations often have cables that gives mains power
(230Vac) to coils, for example relays or door ring bell.
The current used for door bells - even modern monstrosities with
cameras - is tiny.
In my installations they don't use that kind of door bells that are
digital circuits with digital audio output. I don't know what's their
exact name, similar to high power buzzers.
Il 05/05/2023 12:59, David Brown ha scritto:
[...]
The critical installations often have cables that gives mains power
(230Vac) to coils, for example relays or door ring bell.
The current used for door bells - even modern monstrosities with camerasIn my installations they don't use that kind of door bells that are
- is tiny.
digital circuits with digital audio output. I don't know what's their
exact name, similar to high power buzzers.
I really think something must be wrong with the card if it
is susceptible to interference from such cables. Oscillators - crystal
or ceramic - usually need load capacitors and a damping resistor. These are small loads (perhaps 15-20 pF and 10 MΩ), and are sometimes built into the microcontroller. But if these are missing, your oscillator
could be unstable and easily affected by outside influence.
The critical installations often have cables that gives mains power
(230Vac) to coils, for example relays or door ring bell.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 307 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 132:27:17 |
| Calls: | 6,856 |
| Calls today: | 2 |
| Files: | 12,360 |
| Messages: | 5,418,146 |