Homepage GitHub

Virtual plugfest -- looking for testers

(Pavel Kirienko) #1

Let’s have a virtual plug-fest.

As UAVCAN v1.0 is approaching, the question of testing is slowly becoming more relevant. Please let us know in this thread if you will be able to lend a hand with testing against our standard implementations (libuavcan, libcanard, pyuavcan, uavcan.rs); and, most importantly, if you need hardware, please also let us know which kind.

The standard hardware set would likely include some kind of a demo board for a CAN FD capable MCU, a CAN transceiver for it (or several if there are redundant interfaces), and a USB CAN adapter for PC. Such as:

  • MIKROE-2299 (MCP2542 transceiver breakout board)
  • PCAN-USB FD (other options welcome)

(cybermerln) #2

Hi Pavel

I already on hand are 2 MCP2542 CLICK breakout boards. I have already on order 2 NUCLEO DEV BOARD STM32H743ZI boards but they are on backorder from Digikey. Also looking at using the Arduino IDE for STM32 - it will cut down on my development effort. You can see the issue here: https://github.com/stm32duino/Arduino_Core_STM32/issues/227,

(Antoine Albertelli) #3

What do you think of setting up a virtual lab to which core devs could SSH into and that Travis could use for validation ? The second step is probably a lot of work, but just having a UAVCAN “cluster” to SSH into could be nice.


(Pavel Kirienko) #4

@antoine.albertelli I’m not sure I understand the advantages of that approach compared to just compiling and running test nodes locally? Except perhaps not having to compile stuff locally, but if you’re a dev you will have to deal with that sooner or later anyway. I am definitely not against that, I just suspect that I’m missing something.

@cybermerln I have replied to your DM regarding the adapter, not sure if you got the message (we had a brief problem with this website recently). I need your shipping address to order one for you. Thanks!

(cybermerln) #5

This might be a cheaper alternative to the PCAN-USB FD: Virtual plugfest -- looking for testers


(Pavel Kirienko) #6

You seem to have posted a wrong link by mistake.

(cybermerln) #7

Oh shoot my apologies: http://skpang.co.uk/catalog/mcp2517fd-can-fd-breakout-with-teensy-include-teensy-32-p-1549.html.

(Antoine Albertelli) #8

For me the most interesting part would be if you want to have access to other hardware. For example CAN-FD hardware is not readily available, so it might be a way to share it. Or also if you want to test on other platforms, with maybe different RTOS?

It could also serve as a first step to introduce hardware testing in the CI environment.

(Pavel Kirienko) #9

Would you or someone else from your team be up to set that up if we provided you with the hardware?

(Roger Smith) #10

What about SocketCan testing? our board, has a MicroChip mcp251x connected over SPI. However support is configured to use socketCAN and not traditional UART/Serial. We have a couple myxa’s and an orel 20. We may end up using a babel and socket can simultaneously during our testing.

Socketcan seems to becoming more prevalent because of tools like wire shark. However I do not have a sense for what all this layering does (for latency). We are interested in running a test suite and contributing results based on our hardware configuration.


(Antoine Albertelli) #11

I think I can give a hand yeah. I borrowed some hardware from the team to do a proof of concept, I will try to implement it this weekend to see if it is useful to somebody. I borrowed one F4 development platform with CAN transceiver and one SocketCAN-compatible adapter.

On a longer time scale, I am not sure of where I can host it though. We don’t have reliable internet in our team space and I don’t really have enough space at my place. Let’s see if it is useful first.

(cybermerln) #12

I just received two of the MCP2517FD click boards that I am planning to try out with my Teensies and SKPrang’s firmware for the teensy. Just waiting for a few extra parts I need to give it a test. I did order the board but they are closed until Monday. The api he uses is from Microchip so it should be adaptable for any SPI.

(Scott Dixon) #13

I wonder if something like https://buildkite.com/ might be useful here. We could provide some standard test environments that could be brought up as needed and as people had free resources. It’s more of a test marketplace then a fixed environment so there may be some need to pester people to setup an attach a given test environment for certain things.

(Pavel Kirienko) #14

If hosting is a problem and the demand is there, we can theoretically host it in our lab in Tallinn. We have a regular office-grade fiber optics connection, so its availability is so-so, but should be acceptable (I think there were like two transient service disruptions over the last 12 months or so). Let’s see.

(Scott Dixon) #15

@pavel.kirienko : let’s talk about using build kite. I’ve used this service in the past and they have a free-for-open-source plan. It allows us to setup build/test pipelines that anyone can contribute resources to. If Zubax can host resources then great! But if I have a dev kit you want to run tests on then I’d be able to connect a buildkite agent to one of our pipelines.

I just setup a quick UAVCAN organization and it still works as well as when I used it a few years ago.

(They are Australian but I wouldn’t hold that against them)

(Pavel Kirienko) #16

Let’s discuss that on the Monday dev call. Anyone interested is also welcome to join.

(cybermerln) #17

Just as a quick update I hooked up the Click boards to a Teensy 3.2 and a Teensy 3.5. Did not have any issue in transferring CAN-FD packets between the boards. For SPI there is a 20Mhz limit and it appears will only support up to 5Mbits on the CAN-FD bus.