|
Forum Index : Microcontroller and PC projects : PicoMite Firmware Release Version 6.01.00
| Author | Message | ||||
| Sasquatch Guru Joined: 08/05/2020 Location: United StatesPosts: 383 |
Found a couple of minor typos when using VGA222 drivers. The VGA222_640 driver shows as just VGA222 in the option list while the others seem to show the full name of the driver. The Blue L pin is listed twice on the Pins List where Blue H should be. Cut and paste will get you every time! Other than that, RGB222 is working great! > option list PicoMite MMBasic RP2350A V6.01.00EXP2 OPTION FLASH SIZE 4194304 OPTION COLOURCODE ON OPTION CPUSPEED (KHz) 252000 OPTION LCDPANEL CONSOLE OPTION DISPLAY 80, 160 OPTION LCDPANEL VGA222,GP15,GP17 > list pins GP0 1 OFF GP1 2 OFF GP2 4 OFF GP3 5 OFF GP4 6 OFF GP5 7 OFF GP6 9 OFF GP7 10 OFF GP8 11 OFF GP9 12 OFF GP10 14 OFF GP11 15 OFF GP12 16 OFF GP13 17 OFF GP14 19 OFF GP15 20 Boot Reserved : VGA HSYNC GP16 21 Boot Reserved : VGA VSYNC GP17 22 Boot Reserved : VGA BLUE L GP18 24 Boot Reserved : VGA BLUE L GP19 25 Boot Reserved : VGA GREEN L GP20 26 Boot Reserved : VGA GREEN H GP21 27 Boot Reserved : VGA RED L GP22 29 Boot Reserved : VGA RED H GP23 41 DOUT GP24 42 DIN GP25 43 HEARTBEAT GP26 31 OFF GP27 32 OFF GP28 34 OFF GP29 44 AIN > -Carl |
||||
| mozzie Senior Member Joined: 15/06/2020 Location: AustraliaPosts: 200 |
G'day, Some further testing of Xmodem indicates a change between V6.01.00RC0 and V6.01.00RC2 Tested on WinXP, Win7-32 and Win10-64 with TeraTerm Fresh Install of firmware after Clear_Flash.uf2 - no options set. Using genuine Raspberry Pi Pico1 and Pico2 boards PicoMite MMBasic RP2040 V6.01.00RC0 PicoMite MMBasic RP2040 V6.01.00RC2 PicoMite MMBasic RP2350A V6.01.00RC0 PicoMite MMBasic RP2350A V6.01.00RC2 PicoMite MMBasic RP2350A V6.01.00 > option list PicoMite MMBasic RP2040 V6.01.00RC0 OPTION COLOURCODE ON OPTION CPUSPEED (KHz) 200000 > Line endings up to RC0 are the normal CR/LF pair and padded with &h00 (I believe this has been since Xmodem on MMbasic began) Xmodem s = CR/LF + &h00 Xmodem s "filename" = CR/LF + &h00 Line endings from RC2 vary as below and padded with &h1A (used V6.01.00 to test Ymodem) Xmodem s = LF + &h1A Xmodem s "filename" = CR/LF + &h1A Ymodem s = CR/LF Ymodem s "filename" = LF This means depending on how you move a file off the Picomite, you could end up with 4 different files. Ymodem S being the only one to move a faithful copy of the original. For program listings this is not really a problem, but means anything that parses a file from a datalogger etc is going to have to be re-written to suit. Considering that CR/LF is how the MMBasic print command has terminated lines since the beginning, and a lot of files and parsing software will be written around this they may no longer work. Also means files cannot be edited in older versions of notepad as no support for LF only line termination (that I can find). As TeraTerm is common to all my systems, could it be the problem? Next test.... Has this change been made for compatibility with Linux? Regards, Lyle. Edited 2025-12-31 15:16 by mozzie |
||||
| Martin H. Guru Joined: 04/06/2022 Location: GermanyPosts: 1339 |
I couldn't find it. Could someone explain the update procedure for Olimex USB again? Edited 2026-01-01 23:10 by Martin H. 'no comment |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 5648 |
Hi Martin, your question Volhout PicomiteVGA PETSCII ROBOTS |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10923 |
mozzie I'll fix this in the next release. All will transmit cr/lf and xmodem will pad with null |
||||
| Peter63 Senior Member Joined: 28/07/2017 Location: SwedenPosts: 116 |
Hello Is it a bug or... X and Y mouse position can be set fine, but not wheel position... ' ' wheel-pos is set to 0 at start, last wheel-pos is still showing ' Mouse set 2,100,50,0 ' mouse at X100,Y50,wheel-count=0 Do mx=DEVICE(mouse 2 ,x) my=DEVICE(mouse 2, y) mw=DEVICE(mouse 2, w) If mx<>tx Or my<>ty Or mw<>tw Then Print mx,my,mw tx=mx:ty=my:tw=mw Loop End Using this: > option list PicoMiteHDMI MMBasic USB RP2350A Edition V6.01.00 OPTION SERIAL CONSOLE COM2,GP8,GP9 OPTION FLASH SIZE 4194304 OPTION COLOURCODE ON OPTION MOUSE SENSITIVITY 1.0000 OPTION KEYBOARD US OPTION RESOLUTION 640x480 @ 252000KHz > Mouse Type: Standard 8-bit X/Y bits: 8/8 Buttons: 3 Report length: 4 bytes Has wheel: Yes (byte 1) Has pan: No USB Mouse Connected on channel 2 /Peter63 |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 5648 |
@Peter, There is a bug in official release 6.01.00 (also in the EXP7). PIO INTERRUPT p,s,rx,tx does not generate an interrupt when data is pushed into the FIFO. See below demo program. I used RP2040 non VGA for this demo. The program pushes a value in RX fifo (from ISR that is not initialized, so the value is random) at every key press. The key press pulses GP2. When GP2 is wired to GP0 the PIO pushes a value in RX fifo. GP1 follows GP0 to ensure the PIO runs. FSTAT is shown, and the FLEVEL for this fifo. There should be text "interrupt" when the RX interrupt fires. But it does not. 'PIO MMBasic INT demo 'uses GP0 as an output, that is pulsed under keyboard control 'each time a pulse is generated, a (any) value is pushed in RX FIFO 'the program lists FSTAT and FLEVEL for that RX FIFO 'PIO section ---------------------------------------------------- PIO clear 0 pio assemble 0,".program RX" .line 0 set pindirs,1 'set GP1 output .label ret wait 1 pin 0 'wait for GP0 to become 1 set pins,1 'GP1 mirrors GP0 push noblock 'push just any value in RX FIFO wait 0 pin 0 'wait for GP0 to become 0 again set pins,0 'GP1 mirrors GP0 jmp ret 'and repeat .end program list p=pio(pinctrl 0,1,0,gp0,,GP1,)'gp0 is base for IN, GP1 is SET f=1e6 '1MHz pio init machine 0,0,f,p,,,0 'start at adress 0 ' MMBasic section -------------------------------------------------------- setpin gp2,dout 'control GP0 from MMBasic pin(gp2)=0 setpin gp1,pio0 'assign GP1 to PIO for output setpin gp0,pio0 'assign GP0 to PIO for output pio interrupt 0,0,RX_int,0 'assign RX_int to an RX FIFO interrupt. pio start 0,0 do do : k$=inkey$ : loop while k$="" 'wait for a key press print bin$(pio(fstat 0)),pio(flevel 0,0,RX), pulse gp2,100 loop until k$=chr$(27) 'escape end sub RX_int pio read 0,0,1,dummy% print "interrupt"; end sub Ouput is : RUN 0: E081 1: 20A0 2: E001 3: 8000 4: 2020 5: E000 6: 0001 1111000000000000111100000000 0 1111000000000000111000000000 1 1111000000000000111000000000 2 1111000000000000111000000000 3 1111000000000000111000000001 4 1111000000000000111000000001 4 Options: PicoMite MMBasic RP2040 V6.01.00 OPTION SYSTEM SPI GP18,GP19,GP16 OPTION SYSTEM I2C GP14,GP15 OPTION COLOURCODE ON OPTION CPUSPEED (KHz) 200000 OPTION SDCARD GP17 OPTION F5 flash run 2 Volhout Edited 2026-01-04 07:25 by Volhout PicomiteVGA PETSCII ROBOTS |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 5648 |
@Peter, There is another "bug" in the official release 6.01.00. Tested on RP2040 non VGA. I found it when researching the PIO RX interrupt, where I had to use GP2 to create a test signal for GP0. That separate pin was not needed before, when I could drive GP0 and sense it at the same time. I confirmed it this morning with different programs. In MMBasic you have made provisions so a GPx pin could be driven by MMBasic (DOUT, PWM, etc..) but at the same time could be sensed by PIO (JMP PIN, WAIT x PIN x, IN x). That functionality is not present anymore in 6.01.00. My frequency counter does not work anymore with 6.01.00 (neither the old one, nor the new). Some examples in the PIO training thread do not work anymore. Please find out what happened for this to disappear (again). It existed in 5.07 .... 5.09.00rc5, then vanished, you re-introduced it in 6.00.01, now it vanished, in 6.01.00. Is it a new compiler from RP ? I would really appreciate this feature to be revived in 6.01.00. 6.01.00 is a good "final" for the RP2040, especially when this is fixed. Thank you, Harm Edited 2026-01-04 17:22 by Volhout PicomiteVGA PETSCII ROBOTS |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10923 |
Please list a non-working program and how to wire to run it. I tested la_24_2 as always. Edited 2026-01-04 18:54 by matherp |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 5648 |
Hi Peter, I have shrunk the problem down to a pin set for DOUT. A PWM set pin does work (as shown by the logic analyzer). Example programs GP2.BAS : connect a wire between GP2 and GP0. Monitor GP1. GP1 should follow the signal on GP0 (and thus GP2). GP0.BAS : no wire needed. GP0 is pulsed from MMBasic. The same PIO routine tries to monitor the pin, but can not. Thus GP1 is not pulsing. I used LED's connected to GP0 and GP1, but a scope would do even better, gp0_gp2.zip Volhout Edited 2026-01-04 19:58 by Volhout PicomiteVGA PETSCII ROBOTS |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10923 |
I've fixed the RX interrupt bug. The GP0 issue is caused by the order of commands in your program. You are setting GP0 to output after you have initialised the PIO which overrides the setting as also an input in PIO INIT. You should also set any pins to PIO before enabling the machine This works 'PIO section ---------------------------------------------------- PIO clear 1 PIO assemble 1,".program RX" .line 0 Set pindirs,1 'set GP1 output .label ret Wait 1 pin 0 'wait for GP0 to become 1 Set pins,1 'GP1 mirrors GP0 Wait 0 pin 0 'wait for GP0 to become 0 again Set pins,0 'GP1 mirrors GP0 Jmp ret 'and repeat .end program list p=Pio(pinctrl 1,1,0,gp0,,GP1,)'gp0 is base for IN, GP1 is SET base f=1e6 '1MHz SetPin gp1,pio1 'assign GP1 to PIO for output SetPin gp0,dout 'control GP0 from MMBasic Pin(gp0)=0 PIO init machine 1,0,f,p,,,0 'start at adress 0 ' MMBasic section -------------------------------------------------------- PIO start 1,0 Do Pause 300 Pulse gp0,100 Loop End Edited 2026-01-04 21:08 by matherp |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 5648 |
Hi Peter, I Will re-order the setpin commands in my frequency counter. Most likely it will work then. Volhout PicomiteVGA PETSCII ROBOTS |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10923 |
AFAIremember this hasn't changed since the fixes for RP2350 E9 were made way back when. The fix I introduced is in PIO INIT and automatically turns on input mode for all GPIO. This would always have been countermanded by setting a pin to an output after the init. As I noted above I always test with LA_24_2 and that definitely works without modification. |
||||
| homa Guru Joined: 05/11/2021 Location: GermanyPosts: 536 |
Good to hear! Can I have the corrected version, please? |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10923 |
It is in the 6.02.00RC0 release |
||||
| Bleep Guru Joined: 09/01/2022 Location: United KingdomPosts: 723 |
Hi Harm, I agree with you, that the 2040 should probably stay at 6.01.00 apart from bug fixes, if I want the new features like structured types, I can easily use a 2350. I haven't updated any of my 2040 to 6.02.00.... Regards Kevin. |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10923 |
Sorry, but I'm not retrofitting bug fixes back into 6.01.00. That would mean supporting two parallel versions. 6.01.00 is as now and you will have to accept the bug list that goes with it. If you want the bugs fixed then 6.02 is the option to use whether RP2040 or RP2350 |
||||
| homa Guru Joined: 05/11/2021 Location: GermanyPosts: 536 |
Thanks. I tested it (rp2040), it works for receiving. I think the error still exists for transmit interrupt when the FIFO is full: FSTAT: 00001111000000000000111100000000 Flevel: 0 LEVEL TX: 4 LEVEL RX: 0 FSTAT: 00001110000000010000111100000000 <<-- I miss the interrupt here. |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10923 |
The idea is that the interrupt can keep the fifo topped up. It is a "was full and not now" interrupt. If you don't believe this is working please provide a test program for me to use to investigate. |
||||
| homa Guru Joined: 05/11/2021 Location: GermanyPosts: 536 |
You're right, I got it wrong again and thought backwards . This interrupt works too. Now I can continue with the PIO studies.Thank you! |
||||
| The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2026 |