Adafruit Feather M4 Express BSP and examples

[ghost]

I have pushed BSP files for the Feather M4 and three examples to go with them to my fork of modm (https://github.com/tarush53/modm; branch feature/board_feather_m4).

Nothing too ground breaking here, you all have done the hard stuff. These are pretty minor variations on previous work. The 'neopixel' example includes a WS2812 driver that utilizes modm:delay_ns(), but as mentioned in the comments, it's not intended to be the ultimate solution for the purpose.

This may be easily adaptable to the Feather M4 CAN Express board as the pinouts seem identical and the processor is a SAME51 rather than the SAMD51. I do not have the CAN version so cannot test it.

Just wanted to float the idea before submitting a PR.

Tom Rush

[salkinium]

Yes, go for it! Can never have too much board support, we can always deduplicate code later with lbuild templates if it becomes a pattern. I could also use a pure software driver for WS2812 LEDs for some RP2040 boards I have lying around.

[ghost]

Thanks, PR submitted.

The WS2812 'driver' I wrote is rather simplistic; it's only for a single LED, not a chain, so there's no outer loop. And I have no idea how much time is spent in the setup for the delay_ns() portions; although when I check the listing, most of the overhead winds up occurring during the low part of the signal, so it doesn't hurt anything. The whole thing could be placed in modm_fastcode if needed.

[salkinium]

I actually wrote a blog post about nanosecond delay in modm ;-)
https://blog.salkinium.com/modm-delay/

I'll test it on the RP2040 too.

[ghost]

Yes, I read that post. You did an amazing job figuring that one out :-)

The issue for me was not a problem with delay_ns() but the code that calls it. I had an earlier version that would not work unless it was in modm_fastcode. Sometimes I have to keep looking at the listing and trying different things to get the compiler to produce the code I want. I eventually found the combination that worked and got that loop down to a compact size.

Hope it works on the rp2040.

[malachib]

I'm sorta new to modm - been eyeing it for a while. I have a couple of M4 CAN Feathers and modm is looking like a WAY better option than MPLAB X or Arduino, so maybe with someone holding my hand I can get the basic device online.

I wonder how hard it would be to adapt the SAME7x CAN support to the SAME5x?

[ghost]

I'm pretty new to it myself. I've had a FeatherM4 for a while, was impressed with the modm project but disappointed that they didn't have support for the SAMD51-E5x chips. I tried writing some of that core code myself, but I'm just a hobbyist and not in the same league as most of these guys. What I wrote worked, but didn't look like or integrate with modm. Fortunately, Chris Durand accomplished what I could only attempt.
After a cursory look at the datasheets for the SAMDE5x and the SAME70/S70/V7x, the CAN modules look very similar. Almost all the registers have the same names (with MCAN_ prepended on the 70 series) and bit fields, with the exception of MCAN_CUST and MRCFG.
(MCAN_DBTP and DBTP have some subtle differences in the fields and decriptions; there may be other registers with slight differences as well.)
Here's one way to start:
Assuming you have followed the instructions for installing modm on the home page, next go to the section called 'Your Project'. After creating your project directory as described, copy the files board.hpp and board.xml from modm/src/modm/board/feather_m4 to your project directory. Rename board.xml to project.xml and make the following changes:

<library>
  <repositories>
    <repository><path>../../ext/modm/repo.lb</path></repository>
  </repositories>
  <options>
    <option name="modm:target">same51j19a-au</option>
    <option name="modm:platform:cortex-m:linkerscript.flash_offset">0x4000</option>
    <option name="modm:architecture:can:message.buffer">64</option>
  </options>
  <modules>
    <module>modm:debug</module>
    <module>modm:platform:gclk</module>
    <module>modm:platform:core</module>
    <module>modm:platform:gpio</module>
    <module>modm:platform:uart:5</module>
    <module>modm:build:scons</module>
  </modules>
</library>

Note that the repository path is based on the instructions from 'Your Project' as mentioned above. If you put it in a different place, that path will need to be corrected.
Next, cd to modm/examples/samv71_xplained_ultra/fdcan and copy main.cpp to your project directory. Type 'lbuild build', and (from the current directory) cd to modm/src/platform/can and copy all the files there into your project directory. Go back to your project directory and type 'lbuild build'.
You will need to add a clock in board.hpp SystemClock::enable(); if you want 80MHz like the example, you'll have to add something like GenericClockController::enableDpll<GclkSource, 80_MHz>(DpllInstance::Dpll1); (or make it 160_MHz and divide it when you connect to a generator with GenericClockController::enableGenerator<>();). Whichever generator you use must be connected to the Can1 peripheral, similar to the others in board.hpp. Also somewhere the AHB bus connection must be enabled, e.g. PeripheralClock<Peripherals::Can<1>>::enable(); which is normally done in the peripheral initialization() function (in can.hpp, but the SAMx7 chips do it differently).
The rest of it would involve changing the register struct pointer names, register names, and searching for any other implementation differences that you can find in those six files that you copied over from the example. That's a pretty tall order!
BTW, I use a FTDI USB to 3.3V TTL UART adapter cable to connect to the Feather's Rx and Tx pins to view the debug output from the programs (I don't have a debug probe). And one more thing: the Can peripheral apparently has it's own DMA function, so the CMCC cache controller would need to have at least the data cache disabled, if not the whole thing.

Good luck!

[salkinium]

the CAN modules look very similar.

I mean, just™ hack it until it works!1!!

In all seriousness though: take small steps, use the logger or GDB to validate your assumptions and configurations, and if you get stuck, open a PR and we'll help.

[malachib]

What awesome insight! Thank you! Nice tip with the serial pins. I was planning on leaning heavily on USB for all logging, but those are a convenient option really~ when I reach a settled stage with my current Arduino code gonna give your suggestions a try. Since this is a discussion area, I'll put my progress here too and we can compare notes!