Skip to content

Commit 5c29551

Browse files
committed
Update the Giga RPC/dual-core tutorial.
- Fix typos, code formatting and minor code issues. - Update the API to include the new RPC.cpu_id() function. - Add a section on using the RPC library with MicroPython. Signed-off-by: iabdalkader <[email protected]>
1 parent 68af80a commit 5c29551

File tree

1 file changed

+186
-16
lines changed
  • content/hardware/10.mega/boards/giga-r1-wifi/tutorials/giga-dual-core

1 file changed

+186
-16
lines changed

content/hardware/10.mega/boards/giga-r1-wifi/tutorials/giga-dual-core/giga-dual-core.md

+186-16
Original file line numberDiff line numberDiff line change
@@ -24,7 +24,8 @@ The M4 and M7 cores are programmed with separate sketches, using the same serial
2424
In this guide you will discover:
2525
- How to configure and program the M4/M7 cores and conventional approaches to do so.
2626
- How to boot the M4 core.
27-
- How to communicate between the cores via Remote Call Procedures (RPC).
27+
- How to communicate between the cores via Remote Procedure Call (RPC).
28+
- Using the RPC Library with MicroPython.
2829
- Useful examples based on the dual core & RPC features.
2930
- The `RPC` library API.
3031

@@ -144,9 +145,9 @@ Once the M4 is booted from the M7, both cores will run in parallel, much like tw
144145

145146
Uploading new sketches works the same as a typical upload procedure. The new sketch will overwrite the current sketch running on the core you upload to.
146147

147-
## Identify Core Used
148+
## Identifying the Current CPU Core
148149

149-
To identify which core is being used, use the `HAL_GetCurrentCPUID()` method. Below is a function that returns which core is currently being used. This can be useful to identify that your program is running on the right core.
150+
The `RPC.cpu_id()` method can be used to identify current CPU core running the sketch. This can be used to run different code paths based on the CPU core ID. For example, the following sketch blinks the blue LED if the current core is the Cortex-M7, and the Green LED if the current core is the Cortex-M4:
150151

151152
```arduino
152153
/*
@@ -169,7 +170,7 @@ void setup() {
169170
pinMode(LEDB, OUTPUT);
170171
pinMode(LEDG, OUTPUT);
171172
172-
if (HAL_GetCurrentCPUID() == CM7_CPUID) {
173+
if (RPC.cpu_id() == CM7_CPUID) {
173174
blink(LEDB, 100); //blink blue LED (M7 core)
174175
} else {
175176
blink(LEDG, 100); //blink green LED (M4 core)
@@ -190,11 +191,7 @@ void blink(int led, int delaySeconds) {
190191
}
191192
```
192193

193-
- The `HAL_GetCurrentCPUID()` is a method that checks the CPU ID, and returns the value in a `uint32_t` format.
194-
- The `CM7_CPUID` flag that we compare with holds the value `0x00000003` (hexadecimal), or `3` (decimal).
195-
- It is also possible to use `CM4_CPUID` flag which holds the value `0x00000003`, or `1` (decimal).
196-
197-
## Remote Call Procedures (RPC)
194+
## Remote Procedure Call (RPC)
198195

199196
RPC is a method that allows programs to make requests to programs located elsewhere. It is based on the client-server model (also referred to as caller/callee), where the client makes a request to the server.
200197

@@ -226,7 +223,8 @@ RPC.bind("addFunction", addFunction);
226223
On the client side, it could look like this:
227224

228225
```arduino
229-
int x,y = 10;
226+
int x = 10;
227+
int y = 10;
230228
231229
RPC.call("addFunction", x, y);
232230
```
@@ -235,6 +233,111 @@ When `call()` is used, a request is sent, it is processed on the server side, an
235233

236234
![Communication between M7 and M4 core.](assets/rpc-m7-m4.png)
237235

236+
### Using the RPC Library with MicroPython
237+
238+
The `msgpackrpc` library provides the same functionality as the Arduino RPC library for MicroPython, i.e., it allows the binding of local functions or objects, starting the M4 core, and invoking remote calls from Python scripts. This library and its supporting features are enabled by default on all compatible Arduino boards, starting with **MicroPython release v1.23**, and require no external dependencies to use. However, there are a few restrictions to using the RPC library with MicroPython:
239+
240+
- Arduino sketches can only run on the M4 core.
241+
- SDRAM-based firmware is **not** supported<sup>[1]</sup>.
242+
- Flash-based firmware must use a **1.5MB M7 + 0.5MB M4** flash partitioning scheme.
243+
244+
The following sections introduce the `msgpackrpc` library API and some use cases in detail.
245+
246+
*1. Although the `msgpackrpc` library does support loading firmware images to SDRAM, the firmware currently generated for the M4 core with an SDRAM target does not work. This issue may be fixed in future releases.*
247+
248+
#### The `msgpackrpc` Library
249+
250+
The `msgpackrpc` library is the RPC library's counterpart for MicroPython, and it provides the same functionality as the Arduino RPC library. The first steps to using the `msgpackrpc` library, are importing the module and creating a `MsgPackRPC` object:
251+
252+
```python
253+
import msgpackrpc
254+
255+
# Create a MsgPackRPC object.
256+
rpc = msgpackrpc.MsgPackRPC()
257+
```
258+
259+
The RPC object created above can then be used to bind Python callables, start the M4 core and invoke remote calls from MicroPython scripts.
260+
261+
#### Binding Python Functions, Callables and Objects
262+
263+
Any Python callable object (such as functions, bound methods, callable instances, etc.) can be invoked by the remote core. To allow the remote core to invoke a callable, it must be first bound to a name. The following example binds a function to the name `sub`:
264+
265+
```python
266+
def sub(a, b):
267+
return a - b
268+
269+
# Register a function to be called by the remote processor.
270+
rpc.bind("sub", sub)
271+
```
272+
273+
Note that the name the function is bound to does not have to match the callable name.
274+
275+
Similarly, an object's bound method can also be bound to a name. For example:
276+
277+
```python
278+
foo = Foo()
279+
rpc.bind("sub", foo.add)
280+
```
281+
282+
Both of those functions can be called in the same way from the Arduino sketch:
283+
284+
```arduino
285+
int res = RPC.call("sub", 2, 1).as<int>();
286+
```
287+
288+
Objects can also be bound to allow their methods to be called by the remote core. When an object is passed to `bind()`, all of its public methods (the ones that don't start with an `_`) are bound to their respective qualified names. For example, the following code binds the methods of an object of class `Foo`:
289+
290+
```python
291+
class Foo:
292+
def __init__(self):
293+
pass
294+
295+
def add(self, a, b):
296+
return a + b
297+
298+
def sub(self, a, b):
299+
return a - b
300+
301+
# Register an object of Foo
302+
rpc.bind("foo1", Foo())
303+
```
304+
305+
Now the object's methods can be invoked by the Arduino sketch using their fully qualified name, for example:
306+
307+
```arduino
308+
int res1 = RPC.call("foo1.add", 1, 2).as<int>();
309+
int res2 = RPC.call("foo1.sub", 2, 1).as<int>();
310+
```
311+
312+
#### Starting the M4 Core From Micropython
313+
314+
The next step is starting the M4 core by calling `MsgPackRPC.start()` with the firmware entry point as an argument:
315+
316+
```python
317+
# Start the remote processor and wait for it to be ready to communicate.
318+
rpc.start(firmware=0x08180000)
319+
```
320+
321+
This function will start the remote core (the M4), boot it from the specified firmware address, and wait for the core to be ready to communicate before it returns. The default arguments passed to this function are compatible with the Arduino RPC library and do not need to be changed for the purposes of this tutorial. Note that the firmware address used is a flash address, where the M4 firmware starts, and it's the same one used for the flash split of `1.5MB M7 + 0.5MB M4`.
322+
323+
#### Calling Remote Functions From Micropython
324+
325+
Once the M4 core is started, the `MsgPackRPC` object can be used to invoke its remote functions. Remote calls can be invoked synchronously, i.e., the call does not return until a response is received from the other side, or asynchronously. In this case, the call returns a `Future` object that must be joined at some point to read back the call's return value.
326+
327+
```python
328+
# Perform a synchronous call, which blocks until it returns.
329+
res = rpc.call("add", 1, 2)
330+
331+
# Perform an asynchronous call, which returns immediately with a Future object.
332+
f1 = rpc.call_async("add", 1, 2)
333+
334+
# The Future object returned above, must be joined at some point to get the results.
335+
print(f1.join())
336+
```
337+
338+
That covered most of the `msgpackrpc` library's API and use cases. For a complete example, see the [MicroPython RPC LED Example](#micropython-rpc-led). For more examples and applications, see the `msgpackrpc` [repository](https://github.com/arduino/arduino-lib-mpy/tree/main/lib/msgpackrpc).
339+
340+
238341
## RPC Examples
239342

240343
In this section, you will find a series of examples that is based on the `RPC` library.
@@ -251,12 +354,12 @@ The `Serial.print()` command only works on the **M7 core**. In order to print va
251354
#include <RPC.h>
252355
253356
void setup() {
254-
RPC.begin();
357+
RPC.begin();
255358
}
256359
257360
void loop() {
258-
RPC.println("Printed from M4 core");
259-
delay(1000);
361+
RPC.println("Printed from M4 core");
362+
delay(1000);
260363
}
261364
```
262365

@@ -266,8 +369,8 @@ delay(1000);
266369
#include <RPC.h>
267370
268371
void setup() {
269-
Serial.begin(9600);
270-
RPC.begin();
372+
Serial.begin(9600);
373+
RPC.begin();
271374
}
272375
273376
void loop() {
@@ -308,6 +411,7 @@ void setup() {
308411
}
309412
310413
void loop() {
414+
311415
}
312416
313417
/*
@@ -454,6 +558,53 @@ int servoMove(int angle) {
454558
}
455559
```
456560

561+
### MicroPython RPC LED
562+
563+
This example demonstrates how to use MicroPython (running on the M7 core) to remotely control an LED connected to the M4 core.
564+
565+
**M4 sketch:**
566+
567+
```arduino
568+
#include "RPC.h"
569+
570+
void led(bool on) {
571+
if (on) {
572+
digitalWrite(LEDG, LOW);
573+
} else {
574+
digitalWrite(LEDG, HIGH);
575+
}
576+
}
577+
578+
void setup() {
579+
RPC.bind("led", led);
580+
RPC.begin();
581+
}
582+
583+
void loop() {
584+
585+
}
586+
```
587+
588+
**M7 Python script:**
589+
590+
```python
591+
import time
592+
import msgpackrpc
593+
594+
# Create an RPC object
595+
rpc = msgpackrpc.MsgPackRPC()
596+
597+
# Start the remote processor.
598+
rpc.start(firmware=0x08180000)
599+
600+
# Toggle the LED every 500ms
601+
while True:
602+
rpc.call("led", True)
603+
time.sleep_ms(500)
604+
rpc.call("led", False)
605+
time.sleep_ms(500)
606+
```
607+
457608
## RPC Library API
458609

459610
The `RPC` library is based on the [rpclib](https://github.com/rpclib/rpclib) C++ library which provides a client and server implementation. In addition, it provides a method for communication between the M4 and M7 cores.
@@ -575,4 +726,23 @@ RPC.read();
575726
#### Returns
576727

577728
- The first available byte from the M4.
578-
- `-1` if there is none.
729+
- `-1` if there is none.
730+
731+
### RPC.cpu_id()
732+
733+
Returns the current CPU ID, which can be one of two values: `CM7_CPUID` for the Cortex-M7 core, or `CM4_CPUID` for the Cortex-M4 core.
734+
735+
#### Syntax
736+
737+
```arduino
738+
RPC.cpu_id();
739+
```
740+
741+
#### Parameters
742+
743+
- None.
744+
745+
#### Returns
746+
747+
- `CM7_CPUID` for the Cortex-M7 core.
748+
- `CM4_CPUID` for the Cortex-M4 core.

0 commit comments

Comments
 (0)