bricks/ev3: New arm none port. #241
Conversation
This boots all the way up to MicroPython and outputs stdout over UART on sensor port 1.
|
Super exciting developments! |
|
For context, we basically "just" need implementations for functions like the following. Likewise for I2C, PWM, and so on. void pbdrv_uart_set_baud_rate(pbdrv_uart_dev_t *uart, uint32_t baud);
pbio_error_t pbdrv_uart_read_begin(pbdrv_uart_dev_t *uart, uint8_t *msg, uint8_t length, uint32_t timeout);
pbio_error_t pbdrv_uart_read_end(pbdrv_uart_dev_t *uart);Most higher level protocols like LEGO LPF2, or motor control drivers are already done, because they are almost the same as on the platforms we already have. Of course, getting these peripherals to work is a bit more involved compared to your average STM32 (some UARTs even require the PRU), but things such as pin configs should be available from the projects linked above. Existing PRU code can probably be used as well. So hopefully it's quite not as bad as creating an entire new firmware 😄 |
|
super exciting! Thank you very much! |
|
This is very exciting. To the extent you need anyone to help beta test, or even if you have small-scoped programming tasks that could be done by someone with limited knowledge of the system, please feel welcome to reach out to me. |
|
I see the assets listed above. It's probably too soon to try. J is so right: exiting! |
|
@BertLindeman I believe the bin files for the PRU are here: https://github.com/mindboards/ev3sources/tree/master/extra/linux-03.20.00.13/pru-firmware-05-31-2011-1423-v3.0/pru/firmware/bin I'm trying to read and understand what the deal is with these things. As far as I can tell they are similar to the RP2040's programmable IO subsystem -- they're little coprocessors that can run a small instruction set and control IO pins. It looks like one of the purposes of this coprocessor is to implement UART functionality, which requires realtime scheduling, without involving the main CPU. |
Thanks, J. |
This adds a new bare arm Pybricks port for EV3 using the same
arm-none-eabimakefile used for the other ports.The goal is to get to a standalone firmware that works just like the Powered Up hubs with Pybricks. This means they can share almost all code except for low-level drivers. So without Linux underneath. And with drivers to make it compatible with WebUSB for compatibility with Pybricks Code for easy use.
If we get that far, it should be easier to maintain this brick just like the other hubs long term, and solve most of the Linux-related issues we currently have such as motor control loop time problems. It also wouldn't require low-capacity microSD cards which are increasingly hard to get.
It boots all the way to MicroPython with standard output over UART on sensor port 1. It has a dummy static program preloaded. The expected output is:
Which shows that MicroPython is running. Hardware peripherals are not implemented.
Unlike previous
nxtandev3rtports, this properly starts and runs viapbsys, which means that we could build gradually from here, adding one hardware driver at a time.To build:
Prepare a microSD card (16 GB or less) and format it as a single FAT32 partition. Then copy the
uImageto it.This should be modified to add a build target for a firmware that can be installed via the EV3 update mode so it can run without a microSD card and installed with a web USB driver via Pybricks Code.
The minimalist linker file and
startup.swas inspired by @pepijndevos ' devos.Inspiration for future hardware implementation: