|
Forum Index : Microcontroller and PC projects : PicoMite V6.01.00 release candidates
| Author | Message | ||||
| toml_12953 Guru Joined: 13/02/2015 Location: United StatesPosts: 540 |
I found out why my results are only 67.7% on the regex test. On my RC17 calculator, p$="\d" ? p$ \d but on my RC19 calculator, p$="\d" ? p$ d The newer version is dropping the backslash from strings. Any ideas? Edited 2025-11-24 11:36 by toml_12953 Footnote added 2025-11-24 12:45 by toml_12953 Solved! I had OPTION ESCAPE in my library so whenever I started a program it interpreted strings differently. Once I removed that, the tests ran with a 100% pass rate. |
||||
| ville56 Guru Joined: 08/06/2022 Location: AustriaPosts: 370 |
I found a strange behavior with the EXECUTE command: the following code uses a sub with a string parameter to execute the string. If the sub is CALLED from an EXECUTE statement the string length seems to induce strange behavior. OPTION EXPLICIT OPTION DEFAULT NONE option escape 'activate special characters in strings 'test for nesting exeute statements do_exec("print \qnow in 1st level\q") 'execute print from 1st level of sub do_exec("nest_2nd") 'nest to second level by "execute nest_2nd" end sub nest_2nd 'now in second level of "execute" command do_exec("print \q2nd\q") 'print 3 char string -> success do_exec("print \qL2:456\q") 'print 6 char string -> success, this is the max length (8 inluding the 2 quotes) do_exec("print \qL2:4567\q") 'print 7 chars -> fail end sub sub nest_3rd do_exec("print \q3rd\q") 'print 3 char string -> success do_exec("print \qL3:1234567\q") do_exec("nest_4th") end end sub sub nest_4th do_exec("print \q4th\q") 'print 3 char string -> success do_exec("print \qL4:1234567\q") end sub sub do_exec(uar as string) print "----- execute begin print "cmd to execute: ";uar 'print out string to be executed execute uar 'execute user-action-routine print "----- execute end" end sub ' Result is: > run ----- execute begin cmd to execute: print "now in 1st level" now in 1st level ----- execute end ----- execute begin cmd to execute: nest_2nd ----- execute begin cmd to execute: print "2nd" 2nd ----- execute end ----- execute begin cmd to execute: print "L2:456" L2:456 ----- execute end [33 Execute uar 'execute user-action-routine Error : Invalid character: 6 > So the code crashes after "do_exec("print \qL2:4567\q")" but seems to jump somehow into the middle of the "sub do_exec(...)" without any reason. It cannot have used the regular call mechanism, otherwise the "print "----- execute begin" must have been executed, which it did not. Maybe there is something wrong on the execution stack when executing the EXECUTE command in this constellation. The behavior also changes when the code is changed, e.g. more print statements for debugging or changeing the length of the strings to be printed with execute. Are there any know limitations (except the ones described in the manual) with EXECUTE or is this a bug? Gerald 73 de OE1HGA, Gerald |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10848 |
You can't execute from within an execute if that is what you are doing |
||||
| ville56 Guru Joined: 08/06/2022 Location: AustriaPosts: 370 |
That was my intention ... 73 de OE1HGA, Gerald |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10848 |
V6.01.00RC20 PicoMiteV6.01.00RC20.zip Reset the image size in the build making more space available on the A: drive in most cases Make regular expression processing compatible with OPTION ESCAPE Changes MID$ command so the length to be replaced can be 0 - i.e. insert the new string at the position specified New commands: LMID(array%(),start [,num])=string$ inserts string$ into the longstring array%() at position start replacing num existing characters. If num isn't specified then it is calculated from the length of string$. num can be 0 in which case string$ is inserted at the position specified. Note how MID$ and LMID together with INSTR and LINSTR can be used effectively to edit text ![]() ![]() REDIM [PRESERVE] array(dimensions) This resizes the array specified with the dimensions given. If the optional sub-command PRESERVE is specified the existing data will be copied into the new array. The new array can be bigger or smaller than the original. In the case of string arrays the original LENGTH specified is preserved. Note that for multi-dimensional arrays only the last dimension can be changed if PRESERVE is used. DIM a%(99,9) REDIM PRESERVE a%(99,19) 'OK REDIM PRESERVE a%(199,9) 'ERROR |
||||
| toml_12953 Guru Joined: 13/02/2015 Location: United StatesPosts: 540 |
Not on my setup. When I delete OPTION ESCAPE from my library, I get 100% success from regex.bas but when I add OPTION ESCAPE back in, I only get 63.7% success. |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10848 |
That because of the way the tests are written. The string with the escape sequence is read into a variable with option escape on - nothing I can do about that. However, if you create the string with the correct characters or use a string literal then the regex will work whereas it didn't before. e.g test 31 fails but ? instr("test123","\d",size) works as does s$="\\d":? instr("test123",s$,size) |
||||
| toml_12953 Guru Joined: 13/02/2015 Location: United StatesPosts: 540 |
With RC19 and RC20 GP0 and GP1 don't work for COM1: anymore. GP4 and GP5 still work for COM2: though. PicoMite MMBasic RP2350B V6.01.00RC20 OPTION SERIAL CONSOLE COM1,GP0,GP1,BOTH OPTION SYSTEM SPI GP10,GP11,GP12 OPTION SYSTEM I2C GP6,GP7, SLOW OPTION FLASH SIZE 16777216 OPTION LIBRARY_FLASH_SIZE 50000 OPTION COLOURCODE ON OPTION CONTINUATION LINES ON OPTION CASE UPPER OPTION DEFAULT COLOURS GREEN, BLACK OPTION KEYBOARD I2C OPTION PICO OFF OPTION CPUSPEED (KHz) 360000 OPTION LCDPANEL CONSOLE ,, FF00,, 20 OPTION DISPLAY 26, 40 OPTION LCDPANEL ST7796SP, PORTRAIT,GP14,GP15,GP13,,INVERT OPTION LCD BACKLIGHT 20 OPTION SDCARD GP17, GP18, GP19, GP16 OPTION AUDIO GP26,GP27', ON PWM CHANNEL 5 OPTION PLATFORM PicoCalc OPTION PSRAM PIN GP47 Edited 2025-11-26 14:34 by toml_12953 |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10848 |
Works for me. Sorry but there is no way I can diagnose a build you are doing with modifications to the source that then doesn't work. I would you suggest you start with my release and do an option reset. and then set OPTION SERIAL CONSOLE GP0,GP1,B That definitely works on a rp2350B. If that doesn't work you have a HW issue. If is does then you have an issue with your build |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10848 |
V6.01.00RC21 PicoMiteV6.01.00RC21.zip Edit enhancements: The in-built editor is very useful and personally I use it most of the time rather than using a PC based approach. Two things have always irritated me though: first, having to use shift-F3 to repeat a search and second, no replace function. I was musing on this in bed as you do (sad I know ) when I realised that with a particular approach it should be easy to implement replace functionality without risking the stability of the editor so RC21 contains the editor enhancements as follows:You can now use SHIFT-F3, ctrl-G, OR F6 to get the next match If you then use SHIFT-F5, ctrl-I or F8 the system will replace the search target string with the contents of the paste buffer. That works but requires you to have copied something into the paste buffer using the usual F4/F5 mechanism So, having just done a search using F3 etc. you can now press SHIFT-F4, ctrl-F, or F7 and this will open a dialog allowing you to directly enter a string into the paste buffer and on pressing return, replace the search target string. This is much simpler than that explanation made it seem. Suppose you want to replace every occurrence of GP0 with GP6 then you can proceed as follows: F3 - enter GP0 'define the search target and find the first occurrence F7 - enter GP6 'define the replacement string and do the first replacement repeat until you get a not found message F6 ' find next F8 ' replace next end repeat Edited 2025-11-27 20:57 by matherp |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 5610 |
Peter, I have problems with AUTOSAVE N. Using RP2040 VGA V6.01.00rc21. When I use MMEdit/MMCC (that uses AUTOSAVE N) to upload a program to the pico, the transfer is very fast. But in many occasions incomplete. And I can't get a grip on it. When I look at the block counter, it is clear that not all blocks are transferred. And during the transfer, the part that is not transferred is shown in a listing (as if for a part AUTOSAVE was used, not AUTOSAVE N). It happens at large programs (30+k) but also for smaller programs, such as your recent version of the badapple (in stead of 6k, only 2.5k are transferred). I have nuked flash, re-installed, this is a standard VGA platform. Using MMEdit on linux, but I did never have these problems before. Another observation: when I use an older version of MMEdit (5.30) that does not use AUTOSAVE N, since it did not exist at that time, together with the 5.30 MMCC, the transfer of a program is terrible slow. really slow. 300 baud slow. But the setting is 115200 that I always used (I know pico does not obey the 115200). Volhout Edited 2025-12-02 06:25 by Volhout PicomiteVGA PETSCII ROBOTS |
||||
| EDNEDN Senior Member Joined: 18/02/2023 Location: United StatesPosts: 279 |
I think I have noticed this as well. After generating the .UF2 files for the 'D' version, I always load some different .BAS files onto the PicoMite and make sure things seem reasonable. Mostly I'm loading the .BAS files so I can verify the Debugger is present and working correctly. And I use MMCC with MMEdit to do that. The MMBasic files seem to load slower than I remember them loading. In my case, they have loaded completely (and correctly) so I didn't say anything. . Edited 2025-12-02 06:51 by EDNEDN |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10848 |
What OS? |
||||
TassyJim![]() Guru Joined: 07/08/2011 Location: AustraliaPosts: 6426 |
Tested various systems using Peters badapple bas code and MMEdit/MMCC. Windows 11 2040 standard firmware 200MHz RC14 upload 2692mS RC21 upload 2710mS 2040 VGA firmware 252MHz RC14 upload 2443mS RC21 upload 2375mS Linux Mint 20.4 VM on Windows 2040 VGA firmware 252MHz RC14 upload 2360mS RC21 upload 2331mS Linux Mint 22.2 on own hardware 2040 VGA firmware 252MHz RC14 upload 2349mS RC21 upload 2337mS I can't see any issues. @Volhout Try these exe files. I have made a few changes chasing various bugs. You will have to use your 5.3.6 base to get the support files. Being a ZIP, You will probable have to set permissions. mme.zip Jim VK7JH MMedit |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 5610 |
Hi Jim, Peter, See below screenshot of MMCC (5.3.7). There is (top) the AUTOSAVE N Then it transferred 1350/1356 records, and then a piece of the listing of the end of the copied program. I did not invoke that. The program is not completely stored in memory, and (of coarse) errors. ![]() I will try to replace the genuine pico tonight. I may be the first one to experience flash errors. Note this RP2040 has been programmed at least 1000 times. Volhout P.S. the part of the listing you see is not successive. it is showing blocks of lines that are not successive in the program. But they all belong to the end of the program. First 8 lines are sprite data, the next 7 are from the music, then there are 4 lines of world map, then few lines of font data. This is picofrog. Edited 2025-12-02 17:23 by Volhout PicomiteVGA PETSCII ROBOTS |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 5610 |
Oh, one final remark. On this pico, when I use AUTOSAVE, the download of code is very slow, but in the end, the program is transferred correct, and runs fine. When I put V6.01.00b20 (yes, beta 20) on the pico, and use MMEDIT/MMCC to transfer a program to it, it uses AUTOSAVE (not N) and the program is transferred at the speed the listing can scroll on the screen (relatively fast) and the program is transferred correctly. I have the impression that there is a relation between the problem, and this particular pico chip. Maybe flash is written too fast for this particular RP2040 (which is old, it is from the time that 5.07.01 was developed, and used as my work horse since). Regards, Volhout P.S. Jim, you have 1 platform for "picoVGA-HDMI". But the HDMI version has a larger set of commands than the VGA version. Is that a problem? Edited 2025-12-02 18:57 by Volhout PicomiteVGA PETSCII ROBOTS |
||||
TassyJim![]() Guru Joined: 07/08/2011 Location: AustraliaPosts: 6426 |
The progress counter only prints every 50 lines so 1350/1356 is the last one you will see. "Upload completed 1" indicates that the upload completed and the pico responded quickly. Normally seing "Saved xxx bytes" is confirmation of completion. AUTOSAVE N shouldn't be echoing any lines as far as I know so not sure if it is the pico or my end. In MMCC.inf at about line 50 Autosave N line delay = 1 change that to 2 or 3 and see if there is any improvement. No No difference as far as MMC iss concerned and in MMEDit, extra keywords should worry anyone. Jim Edited 2025-12-02 19:01 by TassyJim VK7JH MMedit |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 5610 |
Hi Jim, I can test tonight. Currently at work. The 1350/1356 is from MMCC ? Or from the pico. Maybe the PC is sending data to fast now, and the pico chokes (some buffer overrun). I will try the line delay. May solve the issue. Volhout. PicomiteVGA PETSCII ROBOTS |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10848 |
V6.01.00RC22 PicoMiteV6.01.00RC22.zip This release finally solves the issue of the USB mouse wheel for the USB firmware variants. This new functionality switches the mouse out of boot mode and properly reads the device descriptor to know how to interpret the mouse reports. It has been tested with a standard mouse and one that gives a 12-bit report of the x and y position (standard is 8-bit). It is configured also to support mice that give a 16-bit position report and up to 8 buttons but I don't have one so this isn't tested. It does not currently support mice that have 16-bit button support as well as 16-bit position data. I can add this if anyone has one. At the moment when you plug the mouse in you will see a diagnostic on the output (if not running a program) ![]() Please try the new functionality with as many mice as you own and check that the function that returns the values - DEVICE(MOUSE n,X/Y/W etc.) makes sense. Try using the mouse in the editor and check the speed is sensible for cursor positioning. There is a new parameter to the function DEVICE(MOUSE n,B). This returns the status of all mouse buttons so if you have more than 3 you can interrogate them. Please report finding on this thread. There is a new function LINPUT(array%(),fnbr,nbr) This reads nbr bytes from a file open as fnbr into the LONGSTRING array%(). The function returns the number of bytes actually read so if you are near the end of the file the number may be less than the number requested. It only works with file I/O and not serial or console I/O |
||||
| twofingers Guru Joined: 02/06/2014 Location: GermanyPosts: 1716 |
Not tested, but I've been waiting for this for a long time! Great! Michael causality ≠ correlation ≠ coincidence |
||||
| The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2026 |