No one even mentioned the new Raspberry Pi Pico?

[mrburnette]

i'd guess soon there'd be a dual core or even quad core pico
what i read about 'multi core' is that the 'os' literally run concurrently on each one of the cores, this is very different from the systick interrupt driven multi-tasking

Neither approach requires an 'OS' prese, there is lots of traditional microprocessor thinking in online articles. With a microprocessor or a microcontroller, a single cpu can be multithreaded; one only needs a threading paradigm to manage the cpu resources and provide semaphores and mutexes.

A good write-up for ARM can be read here: http://www.atakansarioglu.com/simple-se ... mentation/

Also, Adam Dunkels explains a simple implementation of Protothreads.

[dannyf]

proto threads is really a state machine, not an os, much less an os dealing with multiple concurrent threads.

[mrburnette]

proto threads is really a state machine, not an os, much less an os dealing with multiple concurrent threads.

Well, yea. I do not think I misrepresented that point. In fact, I stated just the opposite:

Neither approach requires an 'OS' prese, there is lots of traditional microprocessor thinking in online articles. With a microprocessor or a microcontroller, a single cpu can be multithreaded

But the Pico is dual-core and Adam's ProtoThreads [s]can[/s] could be utilized to pass function pointers to either core. Certainly not an OS and way to lean for RTOS, but if the programmer were handling resource contention (or avoiding same), both cores could easily be made to work at the same time... say one for the bulk of the program and one for interrupts.

Example below:
Set up the second core to accept, and run, any function pointer pushed into its mailbox FIFO. Push in a few pieces of code and get answers back.

Code: Select all

/**
 * Copyright (c) 2020 Raspberry Pi (Trading) Ltd.
 *
 * SPDX-License-Identifier: BSD-3-Clause
 */

#include <stdio.h>
#include "pico/stdlib.h"
#include "pico/multicore.h"

/// \tag::multicore_dispatch[]

#define FLAG_VALUE 123

void core1_entry() {
    while (1) {
        // Function pointer is passed to us via the FIFO
        // We have one incoming int32_t as a parameter, and will provide an
        // int32_t return value by simply pushing it back on the FIFO
        // which also indicates the result is ready.
        int32_t (*func)() = (int32_t(*)()) multicore_fifo_pop_blocking();
        int32_t p = multicore_fifo_pop_blocking();
        int32_t result = (*func)(p);
        multicore_fifo_push_blocking(result);
    }
}

int32_t factorial(int32_t n) {
    int32_t f = 1;
    for (int i = 2; i <= n; i++) {
        f *= i;
    }
    return f;
}

int32_t fibonacci(int32_t n) {
    if (n == 0) return 0;
    if (n == 1) return 1;

    int n1 = 0, n2 = 1, n3;

    for (int i = 2; i <= n; i++) {
        n3 = n1 + n2;
        n1 = n2;
        n2 = n3;
    }
    return n3;
}

#define TEST_NUM 10

int main() {
    int res;

    stdio_init_all();
    printf("Hello, multicore_runner!\n");

    // This example dispatches arbitrary functions to run on the second core
    // To do this we run a dispatcher on the second core that accepts a function
    // pointer and runs it
    multicore_launch_core1(core1_entry);

    multicore_fifo_push_blocking((uintptr_t) &factorial);
    multicore_fifo_push_blocking(TEST_NUM);

    // We could now do a load of stuff on core 0 and get our result later

    res = multicore_fifo_pop_blocking();

    printf("Factorial %d is %d\n", TEST_NUM, res);

    // Now try a different function
    multicore_fifo_push_blocking((uintptr_t) &fibonacci);
    multicore_fifo_push_blocking(TEST_NUM);

    res = multicore_fifo_pop_blocking();

    printf("Fibonacci %d is %d\n", TEST_NUM, res);


}

/// \end::multicore_dispatch[]

Source: https://github.com/raspberrypi/pico-examples#multicore

[ag123]

in a true multicore and if both threads are running

Code: Select all

static int x;
while(1) {
	x = x + 1;
	Serial.print(x);
}

it should simply clobber the x value of the other thread. the pico mail boxes i'd guess makes the 2 threads independent of each other or does locking

[mrburnette]

...
it should simply clobber the x value of the other thread. the pico mail boxes i'd guess makes the 2 threads independent of each other or does locking

The cache is partitioned.

Functions for inter-core FIFO.
The RP2040 contains two FIFOs for passing data, messages or ordered events between the two cores. Each FIFO is 32 bits wide, and 8 entries deep. One of the FIFOs can only be written by core 0, and read by core 1. The other can only be written by core 1, and read by core 0.

https://raspberrypi.github.io/pico-sdk- ... ml#details
https://raspberrypi.github.io/pico-sdk- ... re_example

In other news...

https://www.hackster.io/news/iot-focuse ... f8046cc68b
IoT-Focused Real-Time Operating System RT-Thread Announces Raspberry Pi RP2040 and Pico Support
The Raspberry Pi Pico is now an official target in the RT-Thread Studio IDE, and third-party RP2040 boards are likely to follow shortly.

https://www.cnx-software.com/2021/02/05 ... -freertos/
Raspberry Pi Pico Gets supports for Rust, RT-Thread OS and FreeRTOS
There are not many resources available online about the support of FreeRTOS for Raspberry Pi Pico. However, Reddit thread draws our attention to a FreeRTOS Example for Raspberry Pi Pico that is hosted on GitHub. The operating system can be used in a conventional way for raspberry pico projects with CMake.

[ag123]

interesting, i'd guess it makes for a simplier smp, but i still doubt it really is smp/ well mp in a sense but may not be necessary smp

[mrburnette]

interesting, i'd guess it makes for a simplier smp, but i still doubt it really is smp/ well mp in a sense but may not be necessary smp

[ag123]

either way smp may be 'slower' as the cores would need to take turns to access memory, it depends on the cache to do all that magic. and it is real complicated to write a smp arduino

edit:
on the other hand few has ventured that far as well
"The STM32H7x7 lines combine the performance of the Cortex-M7 (with double-precision floating point unit) running up to 480 MHz and the Cortex-M4 core (with single-precision floating point unit)."
https://www.st.com/en/microcontrollers- ... 7-757.html

the board is here, this is probably a most powerful arduino (yet)
https://store.arduino.cc/usa/portenta-h7

[DiTBho]

what's the "remote function calling" mechanism mentioned on the Arduino presentation ?

[mrburnette]

what's the "remote function calling" mechanism mentioned on the Arduino presentation ?

Did you mean Remote Procedure Call (RPC)? I was unable to find any hits on your phrasing.

At a high level, what RPC means will generally depend upon your point-of-view: PC OS vs an environment such as (micro(Python.) I'm going to leave the 2-machine PC OS to Wikipedia and simply make a generalized statement in regard to a micro-controller - it is general and not entirely accurate, but should bring the RP2040 into focus.

In traditional Arduino boards with one (1) cpu, calls to functions are made by use of the program stack: the stack gets pushed, the address counter is adjusted to the function called, the function runs and may optionally return a value, the stack is popped, the address counter is adjusted, things continue. The address space being used in "flat" space and C/C++ allocate this global memory space... (and butchers it often.)

With a dual-core architecture, each core can receive a totally private memory space and optionally a chunk of memory for inter-process communications. As each core must share other resources such as I/O, ADC, USARTs, SPI, I2C, etc... software must control access to these such that both cores do not attempt simultaneous use. Within the context of a single chunk of silicon, RPC is a mechanism by which one CPU causes the "remote" processing of code on the other CPU. Once the RPC is made, the calling CPU can continue processing, handle housekeeping, or just sit and wait for a return answer. RPC can be more efficient (and maybe faster) than stack-based computing. But, if done correctly, it is certainly more secure as the memory is partitioned.

It is my (personal guess) that with the RP2040, using one CPU to handle encryption/decryption and the other CPU for application code would be efficient in some scenarios. One only need to envision program needs where a few routines causes the CPU to become cycle-starved. Moving these functions (procedures) to their own CPU with a dedicated chunk of RAM may be prudent. Consideration needs to be given to the scope of variable sharing between the two CPU - ideally, the amount of sharing should be minimal so that only the inter-process communications are quick/efficient. Another dedicated use could be hash calculations.