Co-Processor

Place your projects here
Post Reply
lew247
Posts: 2
Joined: Tue Mar 09, 2021 6:17 pm
Been thanked: 1 time

Co-Processor

Post by lew247 »

I've been thinking about using an ESP32 as a co-processor for an RP2040
I was going to use an ES8266 but it's old, I have used Annex RDS before on another project and I found it really easy to use and love how much support it has

Ive been wondering if there is a way to send simple wifi commands over either UART or SPI to the ESP32 such as "wget", "wpost" and so on?
I know that Annex RDS has them built in but I'#m wondering if they can be called and the reply sent back to the main processor?
I've been reading the thread on CMM2 Compagnion with ESP32 and AnneX Wifi and it looks kind of similar to what I was thinking about i'm not sure how the two talk to each other and which one has the real program in use on it
If it was possible them it might be possible to also use the play commands and so on, or read the state of any devices such as attached to the ESP32 "on demand" by the other processor and the reply sent back? such as a bme280, VL53L0X and others
That way the esp32 inputs/output pins could be used where the RP2040 pins are all used?

Or is this a really stupid idea and I'd be better off sticking with an Esp8266 and the AT commands?
User avatar
Electroguard
Posts: 836
Joined: Mon Feb 08, 2021 6:22 pm
Has thanked: 268 times
Been thanked: 317 times

Re: Co-Processor

Post by Electroguard »

It's not actually that difficult to bridge to another 'co-processor'.

Read this overview first to get a general idea, then the CMD snippet at the bottom should make more sense.
I actually use this CMD functionality for most of my remote devices, but in my case I want my devices to recognise and respond to unique local instructions which can be sent to them via the network from other devices (or browser).

Whereas for a bridge between 2 hardwired processors its just a matter of passing stuff through to the other for the other to recognise.
If you are just intending the device to be a serial bridge for sending/receiving instructions with an attached alien, then any esp device should do, cos other than serial TX and RX none of its resources will be used.


Using your chosen comms method, its corresponding ONSERIAL? event handler subroutine can to look for whatever you want it to, then respond to any recognised incoming key words however you've programed it to.

You can create a list of 'local instructions' that the device should listen for and respond to when recognised, each with a corresponding subroutine with whatever code needs to be executed for each instruction, eg:
instructionslist$ = "Reply Report Restart Blink Cmd TimeSync On Off ? Toggle1 Relay1 Temp " 'each instruction needs a local subroutine branch of the same name.
If an incoming instruction is matched with any of the local instructions (eg: IF INSTR(instructionslist$,incominginstruction$) > 0 THEN GOSUB incominginstruction$ to execute the appropriate code (convert everything to the same case for comparisons).

I use ONUDP to route all incoming UDP msgs to a UDPRX handler subroutine, which extracts the target ID (to ensure the message is intended for it), and if so then extracts the 'instruction, so anything else remaining must be parameters for the instruction.
If the sender is expecting a reply in response, then the senders ID must obviously also be extracted.
Here's how I extract target, instruction, parameters etc from a data string... https://sites.google.com/site/annexwifi ... -barebones

In your case, if using serial then the sender will always be the same, so any responses can simply be returned straight back by serial.


I like to have a little list of easily-remembered network-accessible functionality (eg: TargetID RESTART)
But notice the "Cmd" instruction in instructionslist$, which can actually make all other local instructions obsolete, by responding to everything.

It allows sending ANY Annex instruction to the local device by passing it through to the interpreter using the COMMAND instruction.
(ignore errors while sending COMMAND instructions to avoid halting on errors)
Note that these are individual Annex instructions, so if you wish to execute a sequence of instructions you should GOSUB branch.
But COMMAND does not recognise or action the GOSUB instruction.
That's easily sorted in the Cmd subroutine simply by checking for mention of GOSUB then issuing GOSUB parameter$ if found, else just issue COMMAND parameter$.
So to branch to any subdirs to execute that codes functionality you would send CMD GOSUB branchname [parameters].
Else to send any individual instruction to the local device interpreter you would send CMD instruction [parameters]

Code: [Local Link Removed for Guests]

Cmd:
if data$<>"" then 
 cmd$=replace$(data$,"|",|"|)
 data$=""
endif
if cmd$="" then return
if (ucase$(word$(cmd$,1," ")) = "GOSUB") then 
 data$ = "": getdata data$,cmd$," ",2      'extract any data that follows the instruction
'wlog data$
 onerror skip
 gosub word$(cmd$,2)
else 
 onerror skip
 command cmd$
endif
cmd$=""
return
User avatar
Electroguard
Posts: 836
Joined: Mon Feb 08, 2021 6:22 pm
Has thanked: 268 times
Been thanked: 317 times

Re: Co-Processor

Post by Electroguard »

Last nights post showed a way that any and all of a device functionality could be accessed remotely.

This time I'll step back a bit to explain 2 examples of it being used daily in practice, to give an idea of what can be done, and how.
To avoid our internet use interfering with my Annex devices I have them on an isolated subnet.
This means I don't need to bother with UDP hand-shaking or error-checking, but it also means that my devices cannot connect to an internet timeserver.

The EasyNet protocol is intended to allow all the devices to broadcast to each other, but only those specifically targeted (by name or IP address) will take any notice of the broadcast. This allows some devices to act as servers to share their local functionality with others.
So one of my devices is called Timeserver (as one of its EasyNet groupnames) and recognises a local Timesync instruction with appropriate functionality.
All EasyNet devices issue Timeserver TimeSync at startup (without parameters), and the TimeServer responds by broadcasting TimeSync back to ALL plus the current time and date as parameters. It has its own RTC module, but stays synced to internet time by bridging serially to another annex device on the internet subnet. I only use the internet bridge to sync to internet time, but of course I could also use it to bridge out to any internet cloud services if I wished, but cloud services cannot be relied on, and pose a constant access risk, so I prefer to keep my system safely isolated and independent of the outside world.

The serial co-processor device is basically just another TimeServer which recognises TimeSync without parameters as a request for it to reply with TimeSync plus its current date and time as parameters... which it sends back serially to its host on the isolated subnet.

The co-processor could of course be any device which is programmed to receive a serial instruction, respond to it by doing some local processing, then reply as appropriate.


Another co-processor functionality made available to my EasyNet devices is AnnounceServer.
In this case the co-processor is an XFS5152CE serial Text to Speech module which is sent text to be spoken (with optional control codes to change voices and volume etc). It recognises Say or Speak as an instruction (to behave slightly differently), followed by any text to be spoken as the parameter. It can receive info quicker than it can speak it though, so it has a busy pin to signal the host device to only send more when it is ready for it.
https://sites.google.com/site/annexwifi ... announcer
lyizb
Posts: 93
Joined: Fri Feb 12, 2021 8:23 pm
Has thanked: 37 times
Been thanked: 23 times

Re: Co-Processor

Post by lyizb »

Hello, Lewis--lizby here from thebackshed (I mistyped my ID here, didn't notice, and don't know how to fix).

The easiest way to do this might be to make the Pico(mite) the coprocessor. Then the ESP32 with Annex could be the I2C master, and the Pico(mite) with MMBasic could be the slave. Something like Geoff's I2C slave code in the "Getting Started with the Micromite" manual should just work. The best of both.

But the question arises, what do you want to do with the Picomite that can't be done with Annex on the ESP32?

Lance
User avatar
PANNO
Posts: 114
Joined: Thu Feb 25, 2021 4:03 am
Has thanked: 121 times
Been thanked: 25 times

Re: Co-Processor

Post by PANNO »

Network for the cmm2 😜
peridot
Posts: 46
Joined: Mon Mar 08, 2021 4:54 am
Has thanked: 7 times
Been thanked: 93 times

Re: Co-Processor

Post by peridot »

Hi Lew, I just did a bit of a test using a Wget request to OpenWeather (I know it would be the sort of thing your after), this was using the latest Annex32. You will see from the images the request code and the result of the request sent out on serial port (@ 256000 baud), all completed in a flash!
So it would be perfectly possible for the Pico to send commands to the ESP32 requesting eg " the call to the OWM - API" . You could even have the ESP do some "early" data parsing down to a more manageable data block size so you didn't have to involve the extra complexities of using Longstring when receiving the data in the Pico.
Any way you could certainly write a library, or not even use the Pico like Lance suggests. :D
Annex32-Wget.png
Annex32-Wget-result.png
You do not have the required permissions to view the files attached to this post.
User avatar
Electroguard
Posts: 836
Joined: Mon Feb 08, 2021 6:22 pm
Has thanked: 268 times
Been thanked: 317 times

Re: Co-Processor

Post by Electroguard »

Without knowing the destination its not easy to plan the journey, but speaking about co-processors more generally, a few simple questions might help point the way...

A co-processor obviously needs a host processor - so would the host be half of a stand-alone host+co-processor pair, or would it be acting as a bridge between networked devices and the co-processor.

Would the co-processor be a dedicated 'black box' such as a serial module or something else only recognising a fixed subset of alien language?
If so, then everything targeted at the co-processor would first need translating by the host (or remote devices sending instructions to the co-processor via the host).

If the co-processor would be a programmable device, then the host could simply funnel everything targeted at the co-processor straight through to it, for it to interpret and deal with.

Either way, if the host is only a bridge between the co-processor and other networked devices, then it would not need its own identity, cos it would basically just be a network funnel to the co-processor (even if it needed to do some translation in passing).
But if any of the hosts shared resources need to be available to networked devices, then the host needs its own ID to respond to, as well as an alias for the co-processor.

Those questions would help define what needs doing... but it's all achievable.
Post Reply