Quote  

One more question: MM.SUPPLY:

What board are you using? Only designed to work for standard Pico/Pico2

  dddns said  

My new toy:

PicoMite MMBasic USB RP2350B Edition V6.01.00RC2
OPTION SERIAL CONSOLE COM1,GP28,GP29
OPTION SYSTEM SPI GP22,GP23,GP20
OPTION FLASH SIZE 16777216
OPTION COLOURCODE ON
OPTION KEYBOARD US
OPTION PICO OFF
OPTION CPUSPEED (KHz) 378000
OPTION LCDPANEL CONSOLE
OPTION DISPLAY 40, 100
OPTION LCDPANEL SSD1963_7_16, LANDSCAPE,,,NORESET
OPTION TOUCH GP21,GP19
GUI CALIBRATE 1, 148, 261, 2095, 1366
OPTION SDCARD GP24, GP25, GP26, GP27
OPTION F9 flash run 1
OPTION PSRAM PIN GP47

When storing the options to disk(tried both) and reset them and reload the file it errors with "Display not configured". Having no display configured then save/reload works.

After Option display console 1 it freezes and need clear_flash

Framebuffer L and F don't work for me. It only shows a small section at the wrong place

Many thanks for the fixes!

Option lcdpanel console 1 works as well as saving the image and to calibrate the touch.

What hasn't changed is the scrambled picture with framebuffer. Some graphics are drawn error free other are not shown, only half or only a small tile.
But as I might be the only one using this there is no hurry or need..

p.s. there is no difference between with PSRAM enabled or not. It runs with framebuffer without error and leaves 40k free heap what I think is too much
Edited 2025-10-21 07:30 by dddns

  Quote  

What hasn't changed is the scrambled picture with framebuffer. Some graphics are drawn error free other are not shown, only half or only a small tile.
But as I might be the only one using this there is no hurry or need..

Please provide an example program that demonstrates the issue. I created a program with both framebuffer and layerbuffer and tested both copy and merge with no issues

Good morning,

I'm not able to provide a simple test program.
Please download this save it to a subdir on A: or B: , change into it and comment out the first two lines:


I've prepared it already for using it on SSD1963

Thanks that you care for that issue!

There is something else I observed:
For Mode 1 I use tiling. In some scaling values, printing with Text command will destroy tiling in a small area. This happens especially with Font 1.
In these situations x/y is somewhere but not on a exact tiling position character wise.

edit: The first drawing is so scrabled you can't read the menu. Please press home/end to change to the next one. The third starts looking better
Edited 2025-10-21 18:18 by dddns

  Quote  

I'm not able to provide a simple test program.

Sorry, but in that case I can't look at it. I've tested with a simple program and confirmed that the correct amount of memory is being allocated safely (187.5K each). I've checked FRAMEBUFFER COPY and FRAMEBUFFER MERGE and they both work perfectly.
I can't be expected to dig into a complex program to discover what is either incorrect in the program or the firmware.

No problem. I didn't expect that you look into the code but more that you have a picture how it looks like.

If an object is scaled down to middle of screen it starts displaying correct.
I've just tested Lcd320 on and that looks much better.
320 mode works better that in the versions before but is not correctly centered

A last non technical comment:

Using Picomite with a 7" SSD1963 as local screen is such an amazing experience and stand-alone computer feeling, I can't find words.

I would like to thank you for that!

Maybe it has something to do with Fonts, I don't know.
In the FM application I need to correct the printing position for Font 2,3,5,7 with -1 that that last column is shown on the local screen while tty always fits

edit:as well for a ILI9341
Edited 2025-10-21 19:17 by dddns

  matherp said  

  Quote  

One more question: MM.SUPPLY:

What board are you using? Only designed to work for standard Pico/Pico2

I am using a standard Pico 2



I am applying approx. 5V from battery (via a step-up converter) to VSYS. for the test above, I used a USB dongle that just provides data and ground (no power).

Must be something h/w related. Faulty Pico2? or something in your design? Results are the same with heartbeat on or off.

Edited 2025-10-22 06:25 by matherp

Looking at the Pico 2 schematic the Vsys voltage divider is connected to ADC3 via MOSFET Q1. Q1 gate should connect to 3.3V but if the track is open circuit at the 3.3V end and passes close to the heartbeat led track it might produce the result you are seeing.

Also tested a Pico 2 with same result that Peter got, with heartbeat on and off.

https://datasheets.raspberrypi.com/pico/pico-2-datasheet.pdf

Edit.
Tried another module and get a constant 2.98V. Same with:-
for i=0 to 99: ? pin(gp29)*2 : Pause 100 : next

May be something fishy with these modules. Investigating further.

Edit 2.

  Quote  

Also tested a Pico 2 with same result that Peter got, with heartbeat on and off.

No I didn't. Not paying attention, it also gives 2.9V for MM.SUPPLY and pin(gp29)*2.
A closer look at the schematic and the voltage divider has a second lower leg (100kΩ) on GPIO29 so using ? pin(gp29)*3 gives 4.48V and I measure 4.50V on Vsys.

It would appear the RP2350 VGA firmware MM.SUPPLY is using GP29 x 2 instead of x 3.
PicoMiteVGA MMBasic RP2040 Edition V6.01.00RC4 is correct.


Karlelch's issue remains a mystery.
Edited 2025-10-22 13:15 by phil99

@matherp  

I'm not sure if this is the 'right' place to document this.  I have traced this bug into the USB firmware from the Pico-SDK.     @ville56 made some comments about problems he was having with the USB ports on his computer talking to the PicoMites.

I responded with some extra information and some errata that I know about.  I responded with this post:  https://www.thebackshed.com/forum/ViewTopic.php?FID=16&TID=18382#245931

I wrote a simple (and stupid) MMBasic program to cause the lock up errata I'm seeing doing the work for the PicoMite V6.01.00RC4D.  If you fire up TeraTerm and use the '<' & '>' to move the token back and forth on the line you will see a lock up within a minute.  It is much harder with MMCC to cause the lock up, but it will lock up the PicoMite eventually also.  

I am absolutely convinced the problem is not in MMBasic (or MMDebug).   It is down in the USB code from the Pico-SDK.    

In the build instructions for MMBasic you have some changes that need to be made to the Pico-SDK.   So it might be possible that you are willing to make a change to the Pico-SDK to fix this problem.

Just load this MMBasic program and use '<' & '>' to move the token back and forth for a minute.   You will see a lockup!

More information on the USB lock-up


Sending a long file with errors due to wordwrap etc with AUTOSAVE. I am not sure if it's the errors in the code or the size of the code that causes the problem.

The complete file is sent with each line being echoed as usual but as soon as the ^Z is sent, the picomite does not reply.
Looking with WireShark, the data (^Z) is sent from the PC but not acknowledged.
The PC end then resends and the pico end sends:

  Quote  

IRP USBD_STATUS: USBD_STATUS_CANCELED (0xc0010000)

This goes on until the pico is unplugged and reinserted.

I tried ^C <ESC> <CR> and nothing breaks to lockup loop.

This occurs when using TeraTerm and MMCC

I think TeraTerm handles the fault better than MMCC (MMCC goes "not responding") but neither solves the problem.

Jim

edit
The same program loads without error on this:

Edited 2025-10-22 17:24 by TassyJim

Pico2 still has the HW bug on GPIO pins. Some software register juggling is in the SDK to minimize the effect. But this may relate to the issue. Although ADC pins do not exhibit the bug when used as ADC, uncontrolled switching of the pin may.

Volhout
Ps another cause could be that you loaded Webmite code on a pico2, or reverse, picomite code on a webmite
Edited 2025-10-22 17:52 by Volhout

  TassyJim said  

More information on the USB lock-up

> OPTION LIST
PicoMite MMBasic RP2350B V6.01.00RC4
OPTION FLASH SIZE 16777216
OPTION COLOURCODE ON
OPTION PICO OFF
OPTION CPUSPEED (KHz) 300000
OPTION PSRAM PIN GP47
>

Sending a long file with errors due to wordwrap etc with AUTOSAVE. I am not sure if it's the errors in the code or the size of the code that causes the problem.

edit
The same program loads without error on this:

> OPTION LIST
PicoMite MMBasic RP2350A V6.01.00RC4
OPTION FLASH SIZE 4194304
OPTION COLOURCODE ON
OPTION CPUSPEED (KHz) 300000
>

I need to increase the line delay in some cases. Please try it with 50ms.
I'm using a RP2350B "PGA2350"

p.s. my finding is, that long lines could be a problem
Edited 2025-10-22 19:02 by dddns

Jim, EDNEDN

Please test this RP2350 standard PicoMite version for USB issues. Do and option reset before testing. Thanks
NB: I can run this using autosave with teraterm with a paste delay per line of just 5mSec and no other transmit delays


PicoMite.zip
Edited 2025-10-22 19:58 by matherp

V6.01.00RC5


PicoMiteV6.01.00RC5.zip


I believe this fixes a longstanding issue with USB communications locking up but this may be wishful thinking

  matherp said  

Must be something h/w related. Faulty Pico2? or something in your design? Results are the same with heartbeat on or off.

Strange. Not aware that the Pico 2 is faulty - everything else works. Unfortunately, I cannot easily replace it because I soldered it in ...

  phil99 said  

Karlelch's issue remains a mystery.

Thanks for testing - I agree.

Is "OPTION HEARTBEAT OFF" is switching the 1Hz interrupt off or does it just disable the LED blinking?

In any case, it may be just a side-effect of my circuit. As said above, everything else works and I was just curious about "MM.SUPPLY".

Best
Thomas

Hello,

I've only quick tested but get "line to long" errors when reading with input # or line input # opened as Input(tested on drive B:).
The transmission via Autosave(95kb) was clean:Edit:with 25mSec

Edited 2025-10-23 01:58 by dddns