| Menu | JAQForum Ver 19.10.27 |
| Menu | JAQForum Ver 19.10.27 |
Forum Index : Microcontroller and PC projects : MMBasic on the Raspberry Pi Pico - proposed functionality
  Page 5 of 6   |
||||||
... but is 27UKP rather than 3.60UKP. About twice the price of an Armmite F4 (ok, it has a bit more on it...). |
||||||
The flash handling is built into the boot rom. i.e part of the silicon and not changeable. This means that it is not only unreliable but also unchangeable. The question therefore is "Is it worth pursuing this development since the cheap single module approach no longer seems viable?" My instinct is NO. The ArmmiteF4 is very equivalent, reliable and ready to use. Sorry folks but yet again Raspberry promise much but let us down in the detail |
||||||
:-( This is probably my fault for ordering three of them yesterday on the back of the promising progress. I guess I will now be programming them in "C"; I was wondering if I might be able to run my SPFORTH code bare-metal on them anyway, I now have even more reason to find out. Best wishes, Tom Edited 2021-05-31 07:37 by thwill |
||||||
As another comparison The time taken to calculate factorial 47 with my big integer maths program: MX170 28.2 Seconds picomite 14.3 Armite F4 10.4 CMM2 1.5 I haven't timed the L4 yet The only real advantage of the pico is price. The Armite F4 seems to be the best fit for convenience, speed and usability. Jim |
||||||
perhaps it is worth not giving up after only finding this problem less than 48 hours ago. peter, is it possible to distil the problem into a short piece of example code (both a set of project files and a UF2 file), that the RPi engineers can look at and consider? that is, just the USB CDC code + something that accepts a few single kepress commands from the console: 'e': erase a 64k block of flash (at a fixed address near the top of flash) 'w': write a 64k block with a given pattern 'c': check a 64k block, and print a response message of 'blank' if the block is all 0xFF 'match' if the block matches the pattern 'ERROR' if the block is neither blank nor matches the pattern this way we can sit there exercising the problem. erasing the 64k block of flash, checking if blank, writing, checking that the written pattern matches. all the while also watching for the USB to fail or the device to lock up. this is what we would usually furnish geoff with when a bug is encountered, and i am sure the RPi engineers would appreciate a simple example to help them find a solution. cheers, rob :-) Edited 2021-05-31 08:19 by robert.rozee |
||||||
I understand the " not changeable " , but why " unreliable " ? It seems " not changeable " might be defined as ' reliable ' ...... |
||||||
Now I have updated the DLL that MMEdit uses, I can talk to the pico The File Manager seems to work without jumping through any hoops. Just select ArmiteH7 as the syntax.  Required DLL LBcoms.zip Put it in the MMEdit program folder Even if this doesn't go any further, it has been an interesting couple of days... Jim Edited 2021-05-31 12:43 by TassyJim |
||||||
I got two, but they aren't wasted. I've been playing with micropython, some buttons and LEDs and I'm rather enjoying it. :) I can see possibilities for these little things. Flash access or no, I'd like them even more with MMBasic on them though. Even paired with a micro SD card it's a cheap and easily accessible option. |
||||||
Thanks for your effort Peter, it is much appreciated. |
||||||
Hi Peter, I have no idea how you have been fighting the quirks of the pi pico SDK, and your reason to give up. But looking at the focus you are drawing there is a lot of interest in this particular port. I see TassyJim wanting to bring the problem we have under the attention of the Pi guys. Many here bought pi's on the future they see for it. Maybe you should have TassyJim go off an work the Pi guys to find a solution to the flash problem, while you focus on implementing the IO related functions (setpin, pin). And if there is no solution to the flash problem, I know Bigmick will design a small PCB with a micro SD card reader that you can solder on top of the pi pico (right over the Raspberry logo). To be honest, that is what I would have done if I where the designer of the board. There is plenty of free space there that is not used, just put the footprint of an SD header there. In our world of "big data" you can never have enough storage. Don't give up yet Peter, there is interest in a device with breadboard footprint, as successor to the MX170. Volhout P.S. if you are really planning on stopping this development, there are other similar platforms you can take on (as the proposed Teensy). Maybe they do not have as good documentation, but some contain an STM chip, so porting would be easier. And, to be honest, a blackpill (not the bluepill) is also cheap, has STM32 on board and is also breadboard friendly. And there have been "questions" on this forum for ESP's with MMBasic. Although I am not sure how good ESP documentation is. The ESP32 is quite capable. P.P.S. My personal interest in the RP2040 is the PIO sequencer. That is something new. That is why I was eager to be early adopter. |
||||||
+1 my route too if PicoMMBasic can't be salvaged. Edited 2021-05-31 17:04 by CaptainBoing |
||||||
Even if you had to use an SD card and forget the flash idea, I still think it would be a good addition to the MM family. We could think of it as a 170 on steroids, with full SD card support. That would still be a useful device I think, considering how cheap the PICO modules are. My 2c is not to give up, rather, drop the flash idea and replace it with the SD card instead. |
||||||
I may have found a magic combination that works Please try a2 and hammer the flash commands PicomiteV5.07.00a2.zip NB: FLASH BLANKCHECK n replaced with FLASH LIST |
||||||
That seems *much* better so far, Peter. Thanks. :) It seems to have fixed the problem I had with disappearing programs too. FLASH LIST is a huge improvement - less typos when I use that instead of BLANKCHECK too. lol |
||||||
Hi Peter, The SD support in a1 works. I have put the micro SD card over the berry logo. It "just fits". Only the wiring to GP2-5 is far away (as is 3.3V). If we need a small "piggy back" board for the SD card reader, it would be best if pins in the range GP12-GP19 could be used. I just saw there is an a2, will try that tonight. Volhout |
||||||
Using a2: Chaining 1-2-3-1- etc. in a ring, works fast enough not to notice the fact that the programs are being switched. I appreciate the flashing LED too. :) |
||||||
Hi Peter, Something strange I noticed. n=1000 Timer =0 For i=1 To n Print "hello world "; Next Print Timer/n Values for Timer vary between 0.9 and 0.3 (speed difference is also visible in terminal). Looks like the speed through the USB UART varies. Tried different terminal programs (Teraterm / Putty) but this is not in the terminal program or the PC. If you replace the Print statement with any other (i.e. a=sin(i)+cos(i)) the values for Timer are consistent. Volhout |
||||||
OK, that works much better. FLASH ERASE no longer hangs, SAVEing and LOADing are much faster XMODEM RECIEVE is now working MEMORY is not reporting properly: >list ... Colour 0,cGy:CLS Dim Integer Objs=20,P=0,Flags,Xt,Yt,CMM2 Dim Integer O(Objs,10)'GUI object settings Dim String Ot(Objs) Length 63'GUI object text 'CMM2 Compatibility - and any others if necessary Select Case MM.Device$ Case "Colour Maximite 2" mp=MM.info(Option Mouse) ' mouse port CMM2=1 Option Console Serial GUI Cursor On 0,100,100,rgb(red) Controller Mouse Open mp Case Else PRESS ANY KEY ... ^C > memory 0 % Program (0 lines using 0KB of 96KB) 0 % Array, strings and general (using 0KB of 96KB) 0 % Variables (using 0 of 512) > > ? mm.ver 5.07 > Like the LED, nice to know the thing is awake. Will it be controllable under program or is it fixed to f/w only? Can't try myself as SETPIN etc not working in the alpha happy bunny Edited 2021-06-01 05:47 by CaptainBoing |
||||||
Also, thinking about the Pico moving into the controller space, what thought has been given to how OPTION AUTORUN will work with the 10 flash pages. I am thinking there needs to be a default action of some sort because the program loaded in the executable space might not be appropriate for when the thing wakes up - not necessarily a known state. It may be more meaningful to load the default prog from one of the flash slots. Perhaps renumber the slots 0 - 9 and make 0 the default program which leaves the "more programmatically logical feeling" 1-9 for chaining as part of your overlays etc. I am just throwing ideas about. Edited 2021-06-01 06:39 by CaptainBoing |
||||||
autorun will have a parameter that specifies which flash slot to run. The concept of running the program loaded is meaningless as that is in RAM i.e doesn't exist on power up or reset |
||||||
| Page 5 of 6 |
||||||
 |
The Back Shed's forum code is written, and hosted, in Australia. |
