 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : using second core of Raspberry pi pico with MMBasic
| Author | Message | ||||
| Jack Newbie  Joined: 06/12/2022 Location: AustraliaPosts: 5 |
Is there any way I can run 2 Basic programs each using a different core in the Picomite? If not is any expansion of this ability contemplated? Thanks Jack H |
||||
| Bernie3D Newbie Joined: 02/08/2023 Location: United StatesPosts: 19 |
Hi Jack I'm sure that's a questions Peter (matherp) can answer. I have pondered this too. I sometimes run short ASM code on the second core while the Basic runs unaffected on the first core. I typically use this for very deterministic or fast coding needs. Bernie |
||||
Mixtel90 Guru  Joined: 05/10/2019 Location: United KingdomPosts: 6798 |
No. First, there is too little RAM available. Each CPU would need it's own stack and variables area as well as its own program space and RAM is very limited. Also, some parts of MMBasic run from RAM to optimize them for speed. The PicoMite VGA ties up the second core anyway, to generate the video. The standard PicoMite is now also using the second core for some LCD display purposes. Internally both cores are on the same bus, together with whatever RAM blocks are paged in at the time. You'd have to make sure that they ran synchronously anyway. Picos are so cheap, just add another and network them over I2C. :) Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| Bernie3D Newbie Joined: 02/08/2023 Location: United StatesPosts: 19 |
@Mixtel90 A couple of questions, if you know the answers. Which release of the standard Picomite uses the second core? Also is the second core launched only when LCD functions are initiated? The reason I ask, is that some of my code launches the second core, and runs small ASM code. I typically run the second core from RAM, by first making space by creating an integer array dimensioned by the size of code I need. I then memory copy a CSUB block of code to that space including a mini VT and stack (16 entries each). I then launch the second core, by the sequence documented in the datasheet. It seems to work fine. I would like keep this functionality on the standard Picomite. Thanks! Bernie |
||||
| EDNEDN Senior Member  Joined: 18/02/2023 Location: United StatesPosts: 118 |
It is an interesting idea to have two separate MMBasic interpreters running at the same time. But the usability would not be very high. The big problem with those ideas is none of the code is reentrant. A lot of things would have to be done differently. |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 6798 |
matherp did consider finding a way to run separate programs on the second CPU, but I think he hit problems. It may only have been Csubs anyway. Sorry, Bernie. I'm not sure exactly how the second core comes in to play on the standard PicoMite. It was only implemented on a fairly recent beta. You'd better ask matherp about this - or wait for the next manual. :) Edited 2023-11-13 07:36 by Mixtel90 Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| Jack Newbie Joined: 06/12/2022 Location: AustraliaPosts: 5 |
The reason I would like to be able to use both cores is to simplify a project which needs 2 micros to accomplish a relatively simple and non demanding task. It is a clock project which uses the WEB NTP function to drive an analog clock movement every second and then to play Westminster chimes on the hour and quarter hours using MP3 chime recordings on a DF Player mini. If I try to implement this task using only 1 Webmite then whilst it is busy handling the chimes the program can miss some seconds in the clock drive area of the program or if it is driving the clock it can cause the chimes to be unevenly reproduced. Bear in mind that for the 12 noon chimes to completely play it could take well over 60 seconds. It would be an elegant solution if the 2 cores of the Webmite could handle these 2 separate functions Jack |
||||
TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6099 |
Excuse my ignorance, but isn't the DF Player mini stand alone. All you have to do is send commands by serial and it does all the 'playing' Jim VK7JH MMedit MMBasic Help |
||||
| Jack Newbie Joined: 06/12/2022 Location: AustraliaPosts: 5 |
Yes you are right and if I had 12 complete MP3 files for each of the hours and 3 more for the quarter hours there would be no problem. But for the chimes that I like - with the right tempo and actually sounding like a grandfather clock- all I have is the melody segment for the hour and the 3 quarter hours and a single chime example. So the complete chime sequence for say 12 noon would consist of sending the full melody file for the hour and then waiting for that to end before then sending individually 12 chiming strokes and obviously the program needs to wait for the end of each chime stroke before sending the next. So while the program is distracted building the full chiming sequence it can lose seconds in driving the clock mechanism. Jack |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 6798 |
I would seriously consider using two Picos for this as it's "time critical". ;) It really isn't a daft solution and a single stop/run pin is all that's needed. The one driving the chime could be one of the RP2040-Zero thingies (which are excellent!) or a cheap Pico clone - you aren't expecting it to be running at high speed. I have a YD-RP2040 here running at 252MHz and I think they are only a couple of quid. Even if you could run two programs at once they would have to be running synchronously which throws out the idea of the chimes signal being correct. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 9122 |
Ignoring the PicoMiteVGA which runs the 2nd core at full chat, The PicoMite starts up the second core on boot and then it sits waiting for a message sent to its FIFO. In my implementation the first word sent is a command which tells the 2nd core which routine to execute, the main processor can then send additional data through the FIFO as parameters to the command. The command runs to completion and then the 2nd core sits waiting for the next command. The FIFO is, from memory, 16 words deep so you can effectively stack commands for execution. To enable CSubs to run on the second core the mechanism I could create would be as follows: Create a new 2nd-processor command to run a specific routine. That routine would have a call to a further function defined by a function pointer that defaults to a routine that returns immediately. To use the second processor the CSUB would first override the function pointer and then call a new routine CSUB inn-built function to send the required execute command and any required parameters via the FIFO. This is already the mechanism by which user drivers or links to H/W interrupts are programmed. Currently, I haven't used the second processor on the PicoW as all attempts to do so have ended up causing crashes. If there is significant internet activity then it could be that there is too much bus contention for anything significant to be done on the 2nd processor. I haven't implemented this so far as CSUB programmers are so few and far between. For the OPs existing program, on the latest releases he would have to aldd a step to close the second processor before running his current program. Edited 2023-11-13 19:47 by matherp |
||||
phil99 Guru Joined: 11/02/2018 Location: AustraliaPosts: 2135 |
An audio editor such as Audacity could easily stitch together the files you have to make the 12 complete hour files. |
||||
karlelch Senior Member Joined: 30/10/2014 Location: GermanyPosts: 172 |
Very interesting! Would that also be possible with a normal SUB routine? |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 9122 |
You can already call MMBasic from a CSUB using CallExecuteProgram so you could do it but I'm pretty certain MMbasic would then crash into a heap as lots of context is lost/corrupted |
||||
| Bernie3D Newbie Joined: 02/08/2023 Location: United StatesPosts: 19 |
@matherp Thanks for your response. I will attempt to close the second core before running my code on it. I don't need this type of core functionality too often. By the way, I needed the second core to run a higher (than 1us Timer) resolution pulse width measurement, capturing the Systick timer (core clock). Bernie |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 6798 |
Bear in mind that you always have a PIO, They run independently of the CPUs, using dedicated GPx pins and can be controlled from MMBasic. The PIO speed can be up to the full CPU clock speed, carrying out a fetch and execute in the same clock cycle. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
 Print this page |
