Programming PIC32 Microcontroller with Rust(gill.net.in)
gill.net.in
Programming PIC32 Microcontroller with Rust
https://gill.net.in/posts/pic32-blink-led-rust/
33 comments
One detail of note: PIC32 is a modern microcontroller built up around a MIPS core instead of one of the older (oddball) 8- or 16-bit PIC cores. MIPS is much easier to support in a compiler than the legacy PIC instruction set.
It is certainly possible to make an 8-bit core based on RISC principles (ex: AVR), but the PIC wasn't. Classic PIC has a hard-earned reputation for awful compiler support.
It is certainly possible to make an 8-bit core based on RISC principles (ex: AVR), but the PIC wasn't. Classic PIC has a hard-earned reputation for awful compiler support.
> Classic PIC has a hard-earned reputation for awful compiler support
Luckily the assembly language is one of the nicest in existence.
Luckily the assembly language is one of the nicest in existence.
Agree. My 4th year robotics course was 8-bit PIC assembly. They wouldn't let us use AVRs because they were too powerful.
Turns out that PIC assembly is super fun.
Turns out that PIC assembly is super fun.
> Luckily the assembly language is one of the nicest in existence.
Ah, this I totally agree with. Brought back memories from my undergrad days, programming with PIC was a joy compared to AVR in assembly.
Ah, this I totally agree with. Brought back memories from my undergrad days, programming with PIC was a joy compared to AVR in assembly.
> Classic PIC has a hard-earned reputation for awful compiler support.
Did it? I didn't realize.
Though I did find at least one bug in the code generation for the compiler we were using ~15 years ago... Something funny was happening with the generation of an if statement, don't remember the rest of the details.
Did it? I didn't realize.
Though I did find at least one bug in the code generation for the compiler we were using ~15 years ago... Something funny was happening with the generation of an if statement, don't remember the rest of the details.
It’s true.
They struggled with C8 or something, then they purchased HiTech C and renamed it XC8 (and 16). Then I think expanded it to the DSP33s and PIC32 which for some reason are drastically different. Then at some point they forced everything into MPLABX (netbeans) and Harmony code generation… it’s never been good.
I hate that I’ve never found anything I completely love.
They have niches though.
They struggled with C8 or something, then they purchased HiTech C and renamed it XC8 (and 16). Then I think expanded it to the DSP33s and PIC32 which for some reason are drastically different. Then at some point they forced everything into MPLABX (netbeans) and Harmony code generation… it’s never been good.
I hate that I’ve never found anything I completely love.
They have niches though.
When I was coding for 16C71 all the C compilers were buggy. It's one reason never call them the good old days. We are so luck to have the tools we have today!
May I ask, what language you were using back then?
No OP, but I used C and asm. Hi-Tech c compiler. I had no issues with it. Very simple and straightforward to code the PIC chips. I forget how much I paid for it.
Good old C. I am moderately sure it was the MPLAB software, I remember we had several of their ICD JTAG units (the round ones). But it might have been Hitech.
The Hi-Tec (sp?) Compiler was excellent on those parts. Microchip even recommended it over their own.
Those parts didnt support stack variables, so that compiler would analyze the call tree and essentially use global (fixed address) variables for locals, but it could reuse them in different functions.
Yes a pain for the compiler, but at least one did it really well.
Those parts didnt support stack variables, so that compiler would analyze the call tree and essentially use global (fixed address) variables for locals, but it could reuse them in different functions.
Yes a pain for the compiler, but at least one did it really well.
Microchip bought HI-TECH a few years ago and rebranded the 8-bit PIC compiler as XC8 (and discontinued their own compiler).
It’s the only one of Microchip’s compilers that’s not GCC-based, which can be a pain. Also I remember at -O0, the generated code is just huge and inefficient.
It’s the only one of Microchip’s compilers that’s not GCC-based, which can be a pain. Also I remember at -O0, the generated code is just huge and inefficient.
A few personal takes on the microcontroller/embedded rust side: I've been fiddling a lot with the stm32 and rust over the past several months. The fact of the matter is that having rust at your disposal feels like you are given a set of high quality scalpels compared to the otherwise good old C. I mean having a package manager and easy access to third party libraries is an absolute heaven and it's a very enjoyable experience. BUT... It is enjoyable once you have everything up and running of course, which on the other hand is a huge pain in the ass. I feel like there is a gap to be filled between plugging in an embedded board and running a simple "blink the led" program. Unlike say an arduino(or even a raspberry pi pico which I genuinely dislike after fiddling with it as well), where you simply plug it in, open the arduino IDE and click "Upload". If someone dumbs the process down to something like that for Rust, I feel like it would completely take over this niche.
> BUT... It is enjoyable once you have everything up and running of course, which on the other hand is a huge pain in the ass.
Yes. I’ve been waiting for this for a few years.
For someone to dumb down and actually support this process.
I can’t leave C and my IDEs behind. I can’t jump into a new product with RUST if there is no official support anywhere. I’m not payed to tinker with a setup, I’m paid to make embedded products that solve customer problems.
Give me an IDE. Or someone make a serious effort at Rust with VS Code or whatever IDE and some real package support. I’ll be there with dollars in hand.
I look at how much money and effort things like Zephyr or MicroPython get and it’s so strange that things with a ton of competition already or niche toys draw bigly - but something like Rust for embedded gets a couple of people making crates here or there.
Yes. I’ve been waiting for this for a few years.
For someone to dumb down and actually support this process.
I can’t leave C and my IDEs behind. I can’t jump into a new product with RUST if there is no official support anywhere. I’m not payed to tinker with a setup, I’m paid to make embedded products that solve customer problems.
Give me an IDE. Or someone make a serious effort at Rust with VS Code or whatever IDE and some real package support. I’ll be there with dollars in hand.
I look at how much money and effort things like Zephyr or MicroPython get and it’s so strange that things with a ton of competition already or niche toys draw bigly - but something like Rust for embedded gets a couple of people making crates here or there.
My attempts on this:
https://github.com/vlisivka/rust-arduino-blink - just minimal blink
https://github.com/vlisivka/rust-arduino-hello-world - just print "Hello, world" to serial port.
https://github.com/vlisivka/rapt - little shell for pin testing (turning them on/off via serial port).
https://github.com/vlisivka/rust-arduino-blink - just minimal blink
https://github.com/vlisivka/rust-arduino-hello-world - just print "Hello, world" to serial port.
https://github.com/vlisivka/rapt - little shell for pin testing (turning them on/off via serial port).
Have you tried Ferrous Systems' probe-run? It's basically that.
Very glad to see Rust on PIC32! This microcontroller is one of the very few that is still made in DIP package making it ideal for breadboardind and easy through-hole soldering, and by far most powerful, making it ideal choice for interesting projects.
I spent many years with PIC chips, starting with PIC16C84 and a homemade EEPROM programmer on my DOS machine. One thing I like to this day is that the PIC chips were extremely well documented, and the documentation style was consistent across their product line. This in turn made bare-iron programming relatively easy.
I still have my UV EPROM eraser from those days. My friend used an old chip of mine with the brass frame around the quartz window as a base for jewelry design. They do look cool on their own!
I kept a few of those chips to show my kids. They're really works of art.
The PIC16C84 was one of the (if not the) first MCU chips to use EEPROM (precursor to flash memory), so I didn't need an eraser. It became a favorite of hobbyists. Programs were so simple, that assembly language wasn't really much of a barrier. I only started using C later, in fact, to teach myself C programming.
Before that, I made a board that combined an 8031 (8051 without built-in ROM) and a 28 pin EEPROM. My programmers hung on the parallel printer port of a MS-DOS machine, and were controlled by code I wrote in Turbo Pascal. Ah, the days. ;-)
The PIC16C84 was one of the (if not the) first MCU chips to use EEPROM (precursor to flash memory), so I didn't need an eraser. It became a favorite of hobbyists. Programs were so simple, that assembly language wasn't really much of a barrier. I only started using C later, in fact, to teach myself C programming.
Before that, I made a board that combined an 8031 (8051 without built-in ROM) and a 28 pin EEPROM. My programmers hung on the parallel printer port of a MS-DOS machine, and were controlled by code I wrote in Turbo Pascal. Ah, the days. ;-)
I missed the UV boat, but instead of getting a high voltage programmer like I should have, wasted a ton of time saving $100 by making an low voltage programmer that sometimes worked. Embedded was rough for a long time.
The MX32 series PICs, as well as most "modern" 16F and 18F PICs can be programmed with a low-voltage programming (LVP) mode using the GPIO pins of a Raspberry Pi or 32-bit ARM single-board computer (e.g. Orange Pi Zero) and the free open-source in-circuit serial program Pickle[0].
I mostly use Great Cow BASIC[1] with 16F and 18F series PICs on my projects. My workflow[2] is to connect the PIC to a breadboard as in the article, then connect the Pi to the pins on the breadboard using dupont cables. I then ssh into the Pi, write my program in vim on the Pi, compile the program using the command-line version of GCB, and flash it to the PIC using Pickle. (Not sure if this workflow would work in this case, however--will the pic32-rs compiler work on ARM?)
As a bonus, most PICs can be configured so the program pins also are serial UART pins, making it possible to use the same connection for serial I/O between the PIC and the Pi.
[0]-https://wiki.kewl.org/dokuwiki/projects:pickle
[1]-http://gcbasic.sourceforge.net/
[2]-https://www.pedalpc.com/blog/program-pic-raspberry-pi/
I mostly use Great Cow BASIC[1] with 16F and 18F series PICs on my projects. My workflow[2] is to connect the PIC to a breadboard as in the article, then connect the Pi to the pins on the breadboard using dupont cables. I then ssh into the Pi, write my program in vim on the Pi, compile the program using the command-line version of GCB, and flash it to the PIC using Pickle. (Not sure if this workflow would work in this case, however--will the pic32-rs compiler work on ARM?)
As a bonus, most PICs can be configured so the program pins also are serial UART pins, making it possible to use the same connection for serial I/O between the PIC and the Pi.
[0]-https://wiki.kewl.org/dokuwiki/projects:pickle
[1]-http://gcbasic.sourceforge.net/
[2]-https://www.pedalpc.com/blog/program-pic-raspberry-pi/
Serious question: Is there any real difference between the title and just "Programming PIC32 Microcontroller"? Would almost any language you can compile to LLVM IR serve about as well, modulo trivia? Is the focus on the PIC32, or on Rust?
The site likes to strip off leading "Why ...", "How ... ", and "9 ways to ...", as clickbait. Isn't "...in Rust" often just a peculiarly HNish variety?
The site likes to strip off leading "Why ...", "How ... ", and "9 ways to ...", as clickbait. Isn't "...in Rust" often just a peculiarly HNish variety?
Yes there is, up to this article most people would be fooled to think PIC32 programming was only possible in either C or Assembly, most likely they wouldn't be even aware that MikroElektronika has been selling Basic, Pascal and C compilers targeting the PIC32 for years.
So "...in Rust" makes those people aware that Rust now is also an option, alongside Assembly, Basic, Pascal and C.
So "...in Rust" makes those people aware that Rust now is also an option, alongside Assembly, Basic, Pascal and C.
And C++, D, Nim, Zig, and several others.
Does it really mean "... with LLVM"? Maybe say that.
Does it really mean "... with LLVM"? Maybe say that.
As you certainly are aware, just with LLVM doesn't mean the language actually works even if LLVM can emit PIC32 machine code, but you have to make your point.
There are lots of LLVM-targeting languages that need a runtime environment hard to provide in a PIC32. So, maybe Swift, or Kotlin, or Julia is not a good candidate. (I don't know.) Still, plenty of languages you can compile to LLVM IR do work exactly as well as C, or as Rust. We all know that anything with Rust in the title gets a huge signal boost on HN, far beyond its objective relevance, which defines clickbait.
So the question is really, what should be done to these titles to make them not clickbait? My proposal was "with LLVM", for programming microcontrollers. If you have a better idea, say.
So the question is really, what should be done to these titles to make them not clickbait? My proposal was "with LLVM", for programming microcontrollers. If you have a better idea, say.
My idea is simple, don't get upset with fashion titles that get changed every couple of years.
It has been Ruby, Elixir, Erlang, Clojure, Go, and now Rust, probably it will be Zig after it gets 1.0, or something else even more fancy.
Besides,
> Otherwise please use the original title, unless it is misleading or linkbait; don't editorialize.
It has been Ruby, Elixir, Erlang, Clojure, Go, and now Rust, probably it will be Zig after it gets 1.0, or something else even more fancy.
Besides,
> Otherwise please use the original title, unless it is misleading or linkbait; don't editorialize.
And around we go again. The "in Rust" part of the title is what is identified as linkbait.
[1] https://blog.adacore.com/how-to-prevent-drone-crashes-using-...