I currently have SPI working and I can run that fine. But I also want to do gpio and both CAN ports for my container. It seems CAN is something special.
I have a Verdin iMX8M plus and I have a Verdin Development board v1.1a, using Torizon with Visual Studio Code and the Toradex extension.
When I look at the CAN example, it has you build a container with the command
“docker build -t can-torizon-sample .”
Which I was able to do and put it over on the dev board. However, I also want my SPI there as well.
However, I don’t get to see what the docker file looks like. They have possibly an example of that previously:
"ARG IMAGE_ARCH=arm64v8
FROM torizon/$IMAGE_ARCH-debian-shell:1.0
WORKDIR /home/torizon
So, I tried adding just the run commands from this to my SPI Dockerfile.template, which adds things to the container, but it doesn’t seem to work correctly. If I run my code, it doesn’t know anything about CAN. Apparently, CAN is not a device, so it can’t be added in the device setting. Eventually, I’ll want to add RS232 and gpio as well.
I think I might need some clarification on what you are trying to do. Are you trying to add your SPI program into the CAN Docker container?
One of the benefits of using containers is to ‘containerize’ your program. So you have multiple containers that are focused on different aspects of the overall application. Is this the route you want to go? Then you can set up the multiple containers via the Docker Compose file. Which might include having a separate container for SPI and CAN.
Were you following this guide? It has some examples of CAN and some testing as well as the Dockerfile Code you shared.
Here is the datasheet for the IMX8M plus, section 5.17 will show give a more generic info on CAN IMX8M_Plus_datasheet.
Are you able to share some more specific details on what you are trying to do and what the error is?
HI @eric.tx ,
This is a program that will talk to several inputs and outputs and will provide overall control. It would seem to me to need to be all in one container, not separate pieces which would be another layer to slow down processing. Information needs to be processed and dispersed quickly to all.
Yes, I was following the guide. But what I was expecting to do was to be able to add access to both CAN controllers as well as RS232 (will be RS485) and network. Timing is critical.
In that case it would involve building a monolith docker container that has all of the dependence.
Regarding the two dockerfiles: Are they using the same parent image? (FROM)? This could cause issues if they have different dependence. If the are the same, are there any other major difference? And what type of error/issue are you seeing as you test your program?
What you linked was the basis for the CAN docker file from the examples:
`ARG IMAGE_ARCH=arm64v8
# Use the parameter below for Arm 32 bits (like iMX6 and iMX7)
# ARG IMAGE_ARCH=arm32v7
FROM torizon/$IMAGE_ARCH-debian-shell:1.0
WORKDIR /home/torizon
RUN apt-get -y update && apt-get install -y \
nano \
python3 \
python3-pip \
python3-setuptools \
git \
iproute2 \
can-utils \
python3-can \
&& apt-get clean && apt-get autoremove && rm -rf /var/lib/apt/lists/* `
Hi @eric.tx
I thought that might be an issue, so I just added/appended the RUN statements from the above lines. But after the container is made via VSC, when I run my program, I test out whether I can access CAN, just using the “ip link show can0” command. But it returns “ip not found”. So obviously, my additions didn’t work. The RUN commands from that didn’t seem all that specific since it was just installing new things. So in the Dockerfile.template from is:
FROM %{torzon.sdkimage}
I know that can exists on the device because I can ssh in and run the ip link command successfully.
Hi @eric.tx ,
According to documentation, CAN is already enabled in the device tree. And I have run the docker can build and the CAN all works according to the commands. I just am not sure how to add this via VSC.
Hi @eric.tx ,
Sorry, I don’t think I’m explaining myself correctly.
If I work through the CAN example, I get the expected results. But just adding the RUN code from the CAN example into my current SPI Dockerfile.template (which I do see the added commands also in the actual Dockerfile when I rebuild the SDK), shows that the install of iproute2 doesn’t get installed, or I don’t have access to it in my code, because it comes back and says “ip not found” when I run “ip link show can0” from my program.
And just to be clear, I am running the Verdin iMX8m Plus board and Verdin Dev board. This setup should have 2 CAN controllers that are always there.
The container is from:
arm64v8-debian-no-ssh_bullseye_debug_de147197-93ba-4469-b5e3-3694bde5967a_latest_instance
I also get a Docker exception when I try to run because if I change the buildcommands in the torizon extension from:
RUN usermod -a -G spidev torizon
To:
RUN usermod -a -G spidev can-dev gpio torizon
By using a different base image for the dockerfile(i.e deviating from the example FROM torizon/$IMAGE_ARCH-debian-shell:1.0 ), you may be missing some requirements that adding the RUN command alone will not capture. Here is a guide on how our containers are related/nested.
You can see from the Hierarchy picture. torizon/arm64v8-debian-shell, has its requirements, and is also dependent on torizon/arm64v8-debian-base which is then based on docker.io/debian:bullseye. So these requirements would need accounting for with your different container image base.
Here is the github with our Dockerfiles, you can see what their requirements are.
-Eric
Another important piece of information. When using the VS version 1 extension (if you are), the docker file is auto generated. In order to affect the Dockerfile, you need to use the side-panel to add your dependence and modifications. I’m not sure if this is what you are doing already. The V2/ApolloX version you can modify the dockerfile directly.
Hi @eric.tx,
Yes, I am currently using the V2 apolloX version and modifying the docker.template file. Modifying the dockerfile directly seems to be overwritten.
It would seem that based on what you said, and what I’ve been using, the Bullseye would be the one container that you could modify to add the things you need, as it seems like it has all the support. Is this not the case?
Also, one of my co-workers is trying to use the acontis Ethercat demo, but it doesn’t seem to be available for the verdin 8m Plus, only for the mini. Is there an 8m plus version we can build?
Yes the Debian Base could start as a foundation if you need to ‘combine’ different container image requirements into one container. You’ll have to back track all the requirements if you are ‘combining’ two different containers that follow different paths.
For your coworker- would you mind asking them to start a new ticket, with some details on his setup so we can keep topics separate? It makes it easier for when people search for solutions via the forums w/ similar problems.
