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: > >> 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.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. -- Rick C. +-+ Get 1,000 miles of free Supercharging +-+ Tesla referral code - https://ts.la/richard11209
UART connection between ATSAMD20 and ATtiny4313
Started by ●April 26, 2023
Reply by ●April 28, 20232023-04-28
Reply by ●April 29, 20232023-04-29
On 29/04/2023 01:44, Rick C wrote:> 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: >>>> 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. > > Yes, trial and error. I believe that's the design process recommended by NASA. >Feel free to try /reading/ posts before making comments about them that show you up your ignorance.> 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. >
Reply by ●April 29, 20232023-04-29
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 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. >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?
Reply by ●April 30, 20232023-04-30
On Saturday, April 29, 2023 at 12:01:52 PM UTC-4, David Brown wrote:> 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 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. > > > 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?David, that wasn't a reply to the OP, that was to your silly speculation. -- Rick C. ++- Get 1,000 miles of free Supercharging ++- Tesla referral code - https://ts.la/richard11209
Reply by ●May 3, 20232023-05-03
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.
Reply by ●May 3, 20232023-05-03
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. > > 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.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 the solution? -- Rick C. +++ Get 1,000 miles of free Supercharging +++ Tesla referral code - https://ts.la/richard11209
Reply by ●May 4, 20232023-05-04
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. >>> 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. > > 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.
Reply by ●May 4, 20232023-05-04
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. >>>> 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. >> >> 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?
Reply by ●May 4, 20232023-05-04
On Thursday, May 4, 2023 at 4:34:25 AM UTC-4, 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. > >>> 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. > > > > 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.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 specify that nothing be within some distance of your board. That is not an unusual thing for sensitive circuits. 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 parasitic values. 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. -- Rick C. ---- Get 1,000 miles of free Supercharging ---- Tesla referral code - https://ts.la/richard11209
Reply by ●May 5, 20232023-05-05
Il 04/05/2023 12:31, David Brown ha scritto:> 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. >>>>> 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. >>> >>> 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.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.
