Re^3: 6502 Perl

Darn Arduinos with their ming-boggling constraints....

I really like the SAMD21, an ARM Cortex M0+ found on the Arduino Zero and many clones, e.g. Sparkfun DEV-13664 and Sparkfun DEV-13672. At work, we use the latter as prototype board for embedded systems based on the SAMD21. Chip45 sells various SAMD21 boards with a DIL32 form factor.

One great feature are the six SERCOM modules, that can be used as USART, I涎 master and slave, and SPI master and slave, in any combination. DMA is a weak point, it generally works for sending out data, but receiving unknown amounts of data is simply not possible via DMA. This limits USART receive and I涎 receive. Also, I涎 read-after-write can not be controlled by DMA.

At chip45, I found the SAML21, which I really want to test out. You loose one GPIO pin compared to the SAMD21, and one SERCOM is restricted for better power saving, but get a lot more: A tiny block of configurable logic (think of it as a really tiny embedded CPLD), a second DAC, three OP-Amps, a random number generator, AES accelerator, switchable power domains, and a switching mode power supply in addition to the LDO also found in the SAMD21. The switching mode power supply is also the reason for the lost pin, it is needed for the supply.

A generic difference is that the ARM processors use 3.3V (or less) as I/O voltage, compared with up to 5 V for the AVRs found on the old Arduinos. Also, the ARM I/O pins can't sink/source as much current as the AVR I/O pins (ARM 2..10 mA vs. AVR 20 mA). Both is rarely a problem when driving LEDs or transistors, or when reading switch contacts. Many digital peripherals can also work at 3.3V instead of 5V. For the few remaining ones, you may need a level converter.

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

Comment on Re^3: 6502 Perl

Replies are listed 'Best First'.
Re^4: 6502 Perl by afoken (Chancellor) on Aug 07, 2020 at 07:37 UTC
Another "future me" reply: I found the SAML21, which I really want to test out. We have done a first project using the SAML21 at work. We choose it instead of the SAMD21 mainly because of the second DAC channel, that significantly reduced the number of components required for a very basic port-expander like project. That board will very likely be used as a component in several following projects. We don't use many of the new features (compared to the SAMD21), but our hardware design does not prevent us from doing so. We still use the LDO for supply, it is good enough. Our experiences: The DAC is not just doubled, it is a completely different peripheral, closer to the SAMD5x/E5x DAC peripheral. So we reworked the SAMD5x/E5x driver. The ADC was also replaced, and again it looks more like the SAMD5x/E5x peripheral than the SAMD21 ADC. Again, reworked the ADC driver from the SAMD5x/E5x. The clock system is similar to that of the SAMD21, but sufficiently different to require some drivers changes. The SERCOM5 does not support DMA, so we had to rewrite our SERCOM USART driver to support interrupt-driven transfers in addition to DMA, and to use IRQ-driven transfers for SERCOM5. You should not think of SERCOM5 as a usual SERCOM, as it has too many restrictions. It is probably most useful as a debug console output, because it is available even in low-power modes. If you don't need all six SERCOMs, and power saving is not a big issue, avoid SERCOM5 and use its pins for other peripherals or for GPIO. No experience with CCL, Op-Amps, RNG, AES No experience with power saving To explain the last point: Most of our hardware either runs from mains power or from high-capacity batteries. When running from batteries, the power required by the microcontroller is typically in the noise floor compared to the remaining hardware (touch screen backlight, solenoid valves, pumps, sensors with heating elements, radios, ...), so its power consumption simply does not matter. Power saving becomes interesting if your hardware has to run from low-capacity cells (something like a CR2032), and is always powered. Maybe waking up for a few hundred clock cycles every minute or hour, then going back to sleep as quick as possible. In such scenarios, every 渙 counts. But, as explained, our peripherals easily need three-digit mA at 12V or 24V, i.e. several Watts, compared to one-digit mA at 3.3V (Milliwatts) for the microcontroller. Switching off a single power-hungry peripheral easily saves two or three orders of magnitude more power than fiddling with the microcontroller's power management. Alexander -- Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)	[reply]

Replies are listed 'Best First'.

Re^4: 6502 Perl
by afoken (Chancellor) on Aug 07, 2020 at 07:37 UTC

Another "future me" reply:

I found the SAML21, which I really want to test out.

We have done a first project using the SAML21 at work. We choose it instead of the SAMD21 mainly because of the second DAC channel, that significantly reduced the number of components required for a very basic port-expander like project. That board will very likely be used as a component in several following projects. We don't use many of the new features (compared to the SAMD21), but our hardware design does not prevent us from doing so. We still use the LDO for supply, it is good enough. Our experiences:

The DAC is not just doubled, it is a completely different peripheral, closer to the SAMD5x/E5x DAC peripheral. So we reworked the SAMD5x/E5x driver.
The ADC was also replaced, and again it looks more like the SAMD5x/E5x peripheral than the SAMD21 ADC. Again, reworked the ADC driver from the SAMD5x/E5x.
The clock system is similar to that of the SAMD21, but sufficiently different to require some drivers changes.
The SERCOM5 does not support DMA, so we had to rewrite our SERCOM USART driver to support interrupt-driven transfers in addition to DMA, and to use IRQ-driven transfers for SERCOM5. You should not think of SERCOM5 as a usual SERCOM, as it has too many restrictions. It is probably most useful as a debug console output, because it is available even in low-power modes. If you don't need all six SERCOMs, and power saving is not a big issue, avoid SERCOM5 and use its pins for other peripherals or for GPIO.
No experience with CCL, Op-Amps, RNG, AES
No experience with power saving

To explain the last point: Most of our hardware either runs from mains power or from high-capacity batteries. When running from batteries, the power required by the microcontroller is typically in the noise floor compared to the remaining hardware (touch screen backlight, solenoid valves, pumps, sensors with heating elements, radios, ...), so its power consumption simply does not matter.

Power saving becomes interesting if your hardware has to run from low-capacity cells (something like a CR2032), and is always powered. Maybe waking up for a few hundred clock cycles every minute or hour, then going back to sleep as quick as possible. In such scenarios, every 渙 counts.

But, as explained, our peripherals easily need three-digit mA at 12V or 24V, i.e. several Watts, compared to one-digit mA at 3.3V (Milliwatts) for the microcontroller. Switching off a single power-hungry peripheral easily saves two or three orders of magnitude more power than fiddling with the microcontroller's power management.

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

[reply]