Raspberry Pi port

[Giovanni]

In you port you need to make msg_t have the same size of a pointer, see chtypes.h. Other types could require changes too, 64bits architectures have not been explored yet (8, 16 and 32 work as-is).

Giovanni

You have a couple of warnings being thrown from code as well ... I will pragma them out for now

./os/common/oslib/include/chfifo.h: In function 'chFifoSendObjectI':
./os/common/oslib/include/chfifo.h:238:30: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
msg = chMBPostI(&ofp->mbx, (msg_t)objp);
^
./os/common/oslib/include/chfifo.h: In function 'chFifoSendObjectS':
./os/common/oslib/include/chfifo.h:255:37: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
msg = chMBPostTimeoutS(&ofp->mbx, (msg_t)objp, TIME_IMMEDIATE);
^
./os/common/oslib/include/chfifo.h: In function 'chFifoSendObject':
./os/common/oslib/include/chfifo.h:272:36: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
msg = chMBPostTimeout(&ofp->mbx, (msg_t)objp, TIME_IMMEDIATE);

[LdB]

Hmm that makes things very difficult .. it's a little too micro-controller centric.
I haven't even got to the fun bit yet of working out how to extend your scheduler to deal with 4 cores

I suspect I am going to have to tear it apart I am not sure I can work with it like this ... let me do some digging.

[Giovanni]

It is micro-controllers centric, the project is very focused on its niche, making a generic kernel has never been a requirement. I believe there are no real constraints for a 64bits port, you need to understand how it is organized, some things are very unlike other common RTOSes.

SMP is a planned extension, required changes are well understood. The complexity depends on if you want threads statically assigned to cores at creation or dynamically assigned, the latter is much more complex and does not work well with NUMA (very common on multicore MPUs).

Giovanni

[LdB]

The 64 bit itself is not the issue, it is the fact a 64bit system can host 64 and 32 bit apps


So if ChibiOS is going to be our OS we sort of need that ability otherwise you are restricted to only being able
to run all 64 bit or all 32 bit apps.

Just as a sidenote SMP is rather dog on an RTOS on the Pi you might as well just use the RTLinux kernel as they have sorted out the balancing (I get that RTlinux is probably to big for microcontrollers so there is probably a space for you).
You are better using a BSP implementation or mini MPI setup they are much easier to balance on the Pi2 & 3.
So your plans in that area really are of no interest to me at least on the Pi.

[Polux]

Hi

Just my 2 cents.

RTOS on a quad core 1+GHz. What realtime application will be targeted by this?
Something complex, which will probably need lots of serial ports, SPI, I2C, Timer modules "STM32-like", PWM, CAN, encoders counters.

Am I wrong if I say RPi processor is not the best choice in term of peripherals ?
If I am not wrong, the processor on BananaPi, BeagleBone and others have such peripherals.

We need something like STM32-on-steroids

Angelo

[LdB]

You lost me angelo the Pi has just as many peripherals and GPIO as any of the other boards you mention.

So a Pi3 is 1.4Ghz quad core with I2C, SPI, UART2, PWM, SD CARD, ETHERNET, WIFI, USB and around 30 GPIO pins.
Each core has it's own timer and you have 4 peripheral timers, so you have 8 timers in all.
It also has a 12 core 850Mhz GPU with full HDMI output something a micro-controller can only dream of.
It also carries 512K or 1GB of memory

A beagleboard black is actually very similar just with a mali GPU rather than a VC4 and slightly more memory 4GB.

It is like an STM32 on steroids.