V1 reference hardware

Development & Maintenance
1

I want to propose that we designate a set of dev kits as the official reference hardware maintainers should use when developing embedded versions of UAVCAN. The reasons for standardizing are:

  1. To avoid getting distracted by supporting a wide range of MCUs – The reference implementations should be device agnostic but the limited amount of time the maintainers have should be spent on the core implementation and not ports to various targets.

  2. Make it possible to automate on-target testing – If we have too many supported targets it will become onerous to support a full test automation matrix build.

  3. Simplify development – Too many targets supported by a given reference implementation will make testing changes difficult.

Remember that the community is free to contribute any port that is of adequate quality and for which the contributer makes some effort to provide ongoing support.

And onto my proposals:

Requirements

  1. The MCU shall contain a single Cortex M0+, M4, M7, M23, M33, or M35P core.
  2. The MCU shall have at least two ISO compliant CAN-FD peripherals.
  3. The development kit shall have two CAN transceivers connected to the MCU.

Candidates

The ST micro STM32H743 Nucleo-144 (~$25 USD – https://www.digikey.com/product-detail/en/stmicroelectronics/NUCLEO-H743ZI/497-17786-ND/7809236). We like this board’s peripherals but the devkit does not have CAN transceivers. If we standardize on this board we’ll have to develop a CAN shield for it (not sure if Zubax can provide this?)

@iain.galloway , does NXP have an inexpensive devkit that has an M0+ or M4 core with 2 CAN-FD peripherals and transceivers? If the part was also automotive rated this would be ideal.

The Atmel V71 xplained (https://www.digikey.com/products/en/development-boards-kits-programmers/evaluation-boards-embedded-mcu-dsp/786?k=v71%20ultra) is very expensive (~$200USD) but does come with a single CAN transceiver. This is also a crazy powerful MCU being a 300MHz M7 core. I’m concerned that we would not catch performance problems if we used something this beefy as a reference. That said, it leaves a lot of room for sophisticated, on-target testing.

The Atmel C21 xplained (https://www.digikey.com/product-detail/en/microchip-technology/ATSAMC21-XPRO/ATSAMC21-XPRO-ND/5256707) is much cheaper and does come with a CAN transceiver. This is an M0+ core so it would keep us honest (I wonder how much money Atmel saves by removing the e from explained?).

2

We used NXP S32K for a few things at my previous workplace. It seems like NXP have evaluation kits for the whole series (M0+ @ 48MHz to M4F @ 112MHz) but we only used the upper mid level unit (S32K144 and S32K144EVB).

These kits are relatively inexpensive (~50USD for the one we used, I can’t find a price yet but perhaps the S32K116EVB is even cheaper?). They have at least 1 CAN-FD controller+transceiver. And the top level product (S32K148) has 3 CAN-FD controllers (but the EVB kit only has 1 transceiver). They also feature headers compatible with Arduino shields allowing easy and inexpensive extension (as the other alternatives).

The only disadvantage I remember is that an external DC power supply is needed for a few things, and this might include the CAN-FD transceiver? (@iain.galloway please confirm/refute this if you know). Other than that, I enjoyed working with this dev kit. (And I’ve had uavcan.rs run on it for a few things as well).

Since the peripherals are quite identical it would perhaps be viable to choose the most inexpensive one and the most expensive one for evaluation boards. You could get the inexpensive one for testing one CAN-FD interface without extra transceivers on the shield, and the most expensive one (~150USD) for up to 3 CAN-FD transceivers (with two of them on a shield).

Can I get a job in the NXP sales department now?

I do like the STM32 stuff, and see advantages of using this as the standard dev kit for an open source project. But I don’t like to choose a dev kit without built-in CAN-FD support for a project that uses CAN(-FD) as it’s most relevant transport layer.

A lot of people will probably want to use the dev kit with a shield of their choice. Already requiring the CAN-FD shield for any sort of operation might make this harder as conflicts may happen when stacking shields.

I’m currently using this board with libcanard, and found out that this board is using the silicon revision A of the V71 chip. The main difference between the rev A and rev B is that the MCAN peripheral differs in register names, functions and bit positions and Microchip/Atmel has only documented the way rev B works in the data sheet (not on the xplained pro board) and documented the discrepancies as errdata (I wish I was joking).

Since I’m familiar with this MCU I wouldn’t mind using it as the default dev platform, but on the other hand, I would be reluctant to do so without getting xplained pros with the rev B silicon.

I also don’t appreciate Atmels decision of only providing development tools on windows. And also expecting everyone to use their ASF system without providing it in any reasonable way outside Atmel Studio (which is only available on Windows). If we can get equivalent hardware for an equivalent price from a manufacturer that is a bit more open to things as cross-platform development it would probably be beneficial to do so.

3

What we’re building here is not an operating system.

One of the main reasons why I wanted to separate the libuavcan platform drivers from the libuavcan repo is to prevent the misunderstanding that libuavcan can only be used with platforms it has been “ported” to; that is not true, and I would avoid using the word “porting” in public because of the risk of misunderstanding. What we describe as “porting” here in this thread (assuming we’re talking about libuavcan in the first order) amounts to writing implementations of three C++ interfaces: uavcan::ICanDriver, uavcan::ICanIface, uavcan::ISystemClock. I suppose that when a regular developer (like myself) who is not familiar with UAVCAN hears the word “porting” they imagine something like this instead: https://docs.rtems.org/releases/rtemsdoc-4.7.3/share/rtems/pdf/porting.pdf.

In the case of libcanard there is no place where the concept of porting can be applied to, since the library doesn’t even have a dedicated driver layer (the hardware-specific parts should be moved into dedicated repositories as well, too).

As what we are building is quite agnostic of the hardware it is running on, we can cover the entirety of the logic with automatic tests where the actual driver is replaced with mocks. What should be relegated to testing on-hardware is probably just the hardware-specific logic: in the case of libuavcan that would be the implementation of the three interfaces mentioned above, in the case of libcanard that would be just a collection of functions for working with the CAN hardware.

So, in the view of the above, we should apply the Scott’s proposal not to the reference implementations of the specification, but to their small hardware-specific parts only. Here is a summary of the current situation:

For libuavcan:

Platform OS Quality Testing target
STM32 bxCAN ChibiOS okay none
STM32 bxCAN FreeRTOS okay none
STM32 bxCAN NuttX poor none
STM32 bxCAN none very poor none
Kinetis FlexCAN NuttX ? none
NXP LPC11C24 C_CAN none okay Olimex LPC P11C24 dev board
SocketCAN GNU/Linux okay GNU/Linux

Nice to have:

For libcanard:

Platform OS Quality Testing target
STM32 bxCAN any okay none
any NuttX okay none
AVR none ? none
SocketCAN GNU/Linux okay GNU/Linux

Nice to have:

  • STM32 FDCAN (available on STM32H7 only AFAIK)
  • NXP LPC11C24
  • FlexCAN FD

I am not sure how valuable Atmel platforms are. By the way, I should correct a minor unfairness here towards STM32H7: it is more computationally powerful than V71 being a Cortex M7-based MCU with double-precision FPU clocked at 400 MHz. To my knowledge, this seems to be the most powerful M7-based MCU as of today. Can I get a job in the ST Microelectronics sales department now?

So, considering the above, I don’t think it is that important to have a testing platform that everybody agrees upon, unless several geographically distributed developers collaborate on the same driver. I personally have a Nucleo here in the lab with separate CAN FD transceivers which should work well for testing. If automated on-hardware testing is desired (it’s certainly nice to have), it should be discussed on a per-driver level.

4

For my part, I’ll look early next week to see what the options are for NXP S32K automotive MCU. If it made sense, we might even be in a position to make a small lowest cost “application specific” board, with preferred connectors and breakout.

1 Like
5

The V71 is an M7 with dp fp but it does max out at 300Mhz so is pretty close to the the ST micro but it is also automotive rated.
I guess I’ll work for Microchip sales?

Sure. Technically there is “porting” but 98% of this effort is done by the compiler and the C++ standard library. This does raise an interesting naming problem I’ve run into recently: libuavcan has a “driver” which turns out to be very confusing when using socketCan. I ported this library to an RTOS recently (crap, I mean I made libuavcan work on an RTOS?) and was working with an engineer building the CAN drivers for the operating system. There were some conversations that became confused when I said I was working on the libuavcan “driver” (“Wait, didn’t Bob just finish the CAN driver? What are you building again?”). Perhaps we should change the name of the “driver” layer in libuavcan to be something else?

I mildly disagree with this statement. I think having a common, on-target test platform encourages developers to actually test on-target and gives us a “gold standard” driver we can use to compare new drivers against.

It’s worse than that: the rev A is not ISO compliant so you cannot use rev A on an ISO compliant CAN-FD bus. The good news is you can repopulate the LQFP 144 with a rev B part to save your $200 dev kit from obsolescence.

This’d be huge @iain.galloway as there does not appear to be any dev kits with dual CAN-FD transceivers available and it’d be awesome to have a dev-kit that was focused on CAN-FD without all the other bits and bobs getting in the way.

If NXP can’t spin a low-cost board then I guess the best solutions would be either the Microchip v71 xplained, which only has a single transceiver so we couldn’t test redundant busses, or Pavel’s ad-hoc solution using the STM32H7 and two CAN transceiver breakouts of your choosing.

6

Indeed, I didn’t see that it’s automotive grade. Shame it doesn’t have a decent ADC, it’s a deal breaker for us here.

I think you just wrote implementations for uavcan::ICanDriver, uavcan::ICanIface, and uavcan::ISystemClock; presumably you didn’t have to change the library itself to make it work? If you did, the library is broken and should be fixed.

I agree, “driver” is probably a poor choice of word, we can do better than that. How about Platform API?

Okay, can we keep this common on-target test platform away from user’s eyes? Because otherwise, someone will certainly read it as “libuavcan is designed to work with V71/STM32/Kinetis, I guess I can’t use with my hardware”.

7

Opened https://github.com/UAVCAN/libuavcan/issues/187 to handle this.

Fine but I guess it’s a bit moot since we don’t actually have an adequate dev kit given that you don’t like the only one that comes with a transceiver. I guess we’re left with the STM32H7 and two transceiver dev kits (I have a pair of TCAN1042 dev kits laying around I can use).

I am a little unhappy to choose an M7 core since this will make us lazy. I’d love to have an m0+ or perhaps an m4. With all the floating-point we’re planning on using we shouldn’t get too lazy with having a full dp fp processor available.

@iain.galloway is there an nxp m4 dev kit that brings at least two CAN-FD peripheral outputs to external headers? Perhaps we could use that with the ad-hoc transceivers instead of the ST-Micro M7?

Really? What’s wrong with the ADCs on the V71?

8

Sorry, it was just a side comment, I should have provided more context. There is nothing wrong with V71 in general, and its ADC in particular. The ADC just happens to be significantly inferior to that of STM32H7, and my remark of it being a “deal breaker for us here” meant that as much as I like this MCU, our company Zubax can’t easily switch to those, but this remark has no direct relation to the current discussion. I am actually quite indifferent to which hardware will be chosen as a main dev board for us, whatever you find appropriate. As I said above, I don’t think this is particularly important.

9

“S32K is a scalable family of AEC-Q100 qualified 32-bit Arm® Cortex®-M4F and Cortex-M0+ based MCUs targeted for general purpose automotive and high-reliability industrial applications.”

For Automotive grade MCU with M4 core, 1M Flash, and Dual CAN-FD (plus a single “regular CAN”), the first part would be S32K146.

One step up is S32K148 which has 3 CAN-FD 2M Flash and ethernet as well. That is likely overkill.

M0+ core parts S32K116/118 currently only have one CAN-FD. (but are also the lowest cost parts)

The EVK for the S32K146 is https://www.nxp.com/products/processors-and-microcontrollers/arm-based-processors-and-mcus/s32-automotive-platform/s32k146-evaluation-board:S32K146EVB

It includes a single CAN-FD transceiver which is part of the System Basis Chip (also an Automotive part). I checked the schematics and the second CAN-FD is on the “arduino” headers. So it would just need a PHY on a small carrier board. There is also an on board debugger and console, so you just need to connect via USB cable.
I will check with the business line about sponsoring the project with this board if it look suitable. It is what is ready now. We can look to doing a custom cost optimized board as well.
I’m also checking internally as a few application specific boards have been built in the past that maybe fit the purpose.

Note that public pricing is generally representative of sample pricing not production price on these automotive parts.

10

If the The EVK for the S32K146 or 148 looks good i’ll work to get you some boards.

1 Like
11

I think the S32K146 is a good mid-range target for libuavcan. I’d propose selecting this as a collaboration point between NXP and the libuavcan project. For libcanard we should probably choose an m0+ target but I’m not involved with that implementation.

1 Like
12

Gentlemen, let me introduce you OPENCOPCHO, the stm32H743 nucleo shield for UAVCAN development. It has a whole bunch of connectors, couple FDCAN transcievers and it is radically red.
Here you can check it. White thing under the shiled is A SIMPLIFIED nucleo model.

image
image1317×729 56.2 KB

2 Likes
13
  1. Will Zubax be producing this shield?
  2. Can we make it compatible with the S32K146 dev kit as well, perhaps using jumpers to change where the CAN signals come in?
14
  1. Yes, we have already ordered a small batch. We’ll post here when it’s available.
  2. Perhaps. Unfortunately we don’t have the dev kit on hand; we can just open source the schematic and PCB (as you can imagine, it’s quite trivial) and let whoever cares update it to match their hardware.
15

Cool. Will you release Eagle CAD files?

16

@scottdixon Send pull requests this way: https://github.com/Zubax/opencopcho

17

Pavel - did the s32K146 dev kit i sent not make it to you yet?

18

did the s32K146 dev kit i sent not make it to you yet?

It has been delivered successfully, thank you.