After getting MicroPython to run on Pico]OS in MSP432 Launchpad environment, there was a next step I absolutely had to take: See if the same system would work on Microchip PIC32.
I’m using the free version of XC32 compiler, which comes with it’s own runtime library. It is rather complete, ie. has stdio streams with similar idea for low-level device integration as newlib has on Arm environments. But to simplify things for now, I left file input/output out from the build.
After compiling with -O1 the resulting binary size is:
text rodata data bss dec hex filename 148960 28736 220 7324 185240 2d398 mp-test.elf
The free XC32 version doesn’t allow optimization with -O2, so the resulting binary is larger than it could be with a proper compiler.
Unfortunately I have currently only PIC32 chips with 128 Kb of flash available now, so this won’t fit into them. But MPLAB X has a simulator, which can be used to run the resulting binary. And here it is:
I’ll have to get some bigger PIC32MX chips to try this out with real hardware. I think that PIC32MX270F256B might be a nice choice, it has 256 Kb of flash and 64 Kb of ram and is available in DIP28 package!
Father of three 🙂
{ Electronics | Music | Computer | Motorbike } hobbyist.
Factory IT professional.
FreeBSD since day one.
Is Pico]OS necessary to run MicroPython? Perhaps it will fit in hardware with MicroPython alone?
Is the idea that you run .py scripts from an sd card or via an interactive (usb/serial) shell?
Also, any thoughts on which RTOS lends itself for use with a soft-core cpu? The ones I’ve found that don’t seem to target only ARM: FemtoOS, contiki, NuttX, Chibios, FreeRTOS, TnKernel, and now Pico]OS!
Any estimate what kind of features/resources Pico]OS uses and how easily buildable it would be for fpga based cpus?
Thanks!
Ben
Here is a link to document for porting Pico]OS to new architectures:
http://arizuu.github.io/picoos/html/group__port.html
MicroPython would be able to run without Pico]OS, but I’m not sure if it would help much with code size. Simple ‘blinky’ application with Pico]OS for pic32 seems to be about 11 Kb flash (that includes scheduler and serial port console I/O).
But I myself really like running things on Pico]OS, as it gives kind of solid ground for doing things. My interest with these scripting languages like MicroPython is to be able to provide a hybrid environment for projects. If you need hard realtime stuff, create a Pico]OS thread with C/C++. If not, you can be more productive with python.
About the RTOS systems in general & porting to new platforms: I think for those that have real threads (ie. not just co-operative multitasking) the first requirement is to be able to implement a context switch, which usually requires assembly stuff (for Pico]OS implementations, see portSaveContext/portRestoreContext macros in picoos/ports/*/port.h).
There are some (old) memory size statistics for Pico]OS on original authors site:
http://picoos.sourceforge.net/memory.html
But I have been able to run multiple threads on msp430 chip, which has only 512 bytes of ram and 8 Kb of flash!
One of the reasons why I have always liked Pico]OS is that it is very well documented. I was very easy to get it running on new platforms, once I had some understanding about the CPU.
Idea is to run .py scripts from sd card or embedded into flash. It is usable also from serial or telnet console, so you could use python as “shell” for an embedded system.
But I have still some work left to reach those goals (currently waiting for some hardware for sd card stuff).
Thanks, you have lots of great blog posts.. I look forward to reading more!
I tried commenting on the picoos-uip article, but it looks like time has expired for comments to that post.
I was wondering, is the general idea that you flash a modified version of openwrt onto the hlink so that it passes raw frames (via spi) using the RFC1662 format? The STM32 (or PIC32) then process these frames on it’s own tcp/ip (uip) stack?
Also, the low-cost esp8266 seems to be everywhere these days. Could that also be programmed with such a bridge?
Recently I was considering using a ENC424J600. The idea was to use it with an fpga, so unfortunately, the microchip tcp/ip stack license won’t allow it. I think ethercard is based on uip, so maybe that’s a good starting point to make a stack with a parallel interface :
http://www.mikroe.com/download/eng/documents/compilers/mikroc/pro/pic/help/spi_ethernet_24j600_library.htm
Yes, the idea with the hilink module was that it acts as low-cost wifi module that could be used in replacement for an ethernet chip if wifi is needed. The hilink just passes raw frames, using tap interface in linux. The link between hilink module and microcontroller is usart, not spi (it could have been spi, but I had more experience with usart programming on linux). The microcontroller (STM32 in my case) then runs UIP stack.
I haven’t used ENC424J600 myself, but if you can find driver functions that initialize it, send and receive packets it should be simple to get it working with picoos-net library. Interrupts are not strictly required (but recommended of course), the library can poll the interface if needed.
Picoos-net UIP stack has currently also simple BSD socket layer, so application programming should be quite simple with it once ethernet driver is running.
I think it should be possible to program a ‘hdlcbridge’ for esp8266 also, but it seems that most people are focused on single-chip solution, ie. putting the application also into esp8266. But using it as bridge would be nice, as it would allow using a microcontroller with more features as main application processor. I have a couple of those modules, but I haven’t done much with them yet.