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: >>> >>>> 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? >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.
UART connection between ATSAMD20 and ATtiny4313
Started by ●April 26, 2023
Reply by ●April 28, 20232023-04-28
Reply by ●April 28, 20232023-04-28
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 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?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. -- -TV
Reply by ●April 28, 20232023-04-28
On Friday, April 28, 2023 at 3:48:32 AM UTC-4, David Brown wrote:> 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: > >>> > >>>> 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? > > > 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.Not technically, actually. "Wouldn't be true RS485" is a very clear statement, which happens to also be wrong, no matter how hands are waved.> > 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.I never said anything different.> 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.It is simply not practical to send Manchester encoding with a UART... but Manchester is not the only encoding scheme that embeds a clock. Or you can roll your own. The point is, clock encoding with the data is a viable method of overcoming the lack of precision in the clock rate, which does not require bit banging an I/O pin. The encoding scheme of IRIG is a real possibility. The data bits are PWM encoded, with three values; 0.2, 0.5 and 0.8 widths for 0, 1 and a sync marker. This would fit a UART very nicely. With a distinction of symbols of 0.3 bit times, it can tolerate a lot more clock error than a typical async data stream with a start and stop bit on each character. It would also be pretty easy to decode. Align to the rising edge, and count the bits in the received data to find the falling edge. 0.1, 0.2 and 0.3 are all a zero bit. 0.4, 0.5 and 0.6 are all one bits. 0.7, 0.8 and 0.9 are all sync markers. To prevent the UART from missing anything important, set it for 7 data bits and no parity on receive. Then it always stops one bit early. Then if the timing is off by 10%, you still don't lose any data. This can be better than using a USART, actually. It does the alignment in the hardware, making the decoding simpler. It also includes a sync marker. Yeah, I think this is a much better scheme than Manchester encoding. -- Rick C. --+ Get 1,000 miles of free Supercharging --+ Tesla referral code - https://ts.la/richard11209
Reply by ●April 28, 20232023-04-28
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: >>>>>> 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? > > 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.
Reply by ●April 28, 20232023-04-28
On Friday, April 28, 2023 at 4:43:13 AM UTC-4, Tauno Voipio wrote:> 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 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? > 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.Yes, 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. 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 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. -- Rick C. -+- Get 1,000 miles of free Supercharging -+- Tesla referral code - https://ts.la/richard11209
Reply by ●April 28, 20232023-04-28
On Friday, April 28, 2023 at 5:14:48 AM UTC-4, Rick C wrote:> On Friday, April 28, 2023 at 4:43:13 AM UTC-4, Tauno Voipio wrote: > > 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 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? > > 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. > Yes, 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. > > 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 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.Sorry, two points to distinguish the three values encoded in the eight possible received bit patterns using a 7 bit character. -- 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/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.
Reply by ●April 28, 20232023-04-28
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 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. >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.
Reply by ●April 28, 20232023-04-28
On 28.4.2023 12.10, Ulf Samuelsson wrote:> 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: >>>>>>> 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? >> >> 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. > >The packet structure and coding is set in the standard. An USART cannot create the bit patterns, even with fictive data, as there are fixed start and stop bit patterns. -- -TV
Reply by ●April 28, 20232023-04-28
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 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.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. -- Rick C. +-- Get 1,000 miles of free Supercharging +-- Tesla referral code - https://ts.la/richard11209
