Unfortunately, hyperkit, the hypervisor that Docker-For-Mac uses doesn't support USB forwarding. In order to expose the port to the container, you first have to expose it to the virtual machine where Docker is running. For other operating systems it's run in a hypervisor or virtual machine. That's because the docker daemon only runs natively on Linux. Needless to say, it's not that simple on OSX or Windows. If you're running Linux, this is as simple as adding -device /dev/ttyUSBx to the docker run command. Also, in order to standardize embedded toolchains for a team or client at work, I really need to know how to get USB working on Mac. For that, I really need to be able to hand folks an environment I know works, so we're not spending more time working kinks out of dev setups than learning. Secondly, I'm now beginning to build on that workshop to turn it into an "Intro to Bare Metal Programming" course. Having these toolchains containerized means I can easily keep both readily available. First, I've been playing with ARM development, but there's a bug in AVR and ARM's compiler packaging that means you can't have both toolchains installed at the same time. Recently though, I've taken a renewed interest in getting this to work properly.
I just stopped fighting with it and went with a regular install of the tools on my machine. For that session we mobbed, so I only had to setup one machine. Exposing a USB port to a docker container on Mac isn't exactly a trivial task (until you know how at least!). I had started to create a Docker image for AVR development, but ran into problems when it came time to flash the program to the board. Last year I put on a TDD for Arduino workshop. Leaving a build tools image behind means I can just pick it up and work on it without spending a day getting back up and running. Without fail, when I come back to some old project, I've since updated my tools for something newer, and I can't build that old project without either upgrading the project or degrading my tools. Not only is this great for teams, but it's also fantastic when you have side projects that you only periodically revisit. Then everyone, including your build server, uses that single pre-packaged image. Instead of everyone on the team needing to setup their development environments identically, and then keep them in sync, you define the build tools in a single place, a docker image. I won't fault you for it.ĭocker is a great tool for deploying web services, but one of my favorite uses for it is standardizing toolchains. If you've been struggling with this issue and just want an answer, skip to the bottom for the TL DR.
0 kommentar(er)
