Home
JAQForum Ver 24.01
Log In or Join  
Active Topics
Local Time 13:40 10 May 2025 Privacy Policy
Jump to

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 : PicoMite V6.00.02 release candidates - all versions

     Page 7 of 44    
Author Message
disco4now

Guru

Joined: 18/12/2014
Location: Australia
Posts: 971
Posted: 09:29am 19 Mar 2025
Copy link to clipboard 
Print this post

On Picomites
OPTION RESET will erase the Library.
This is done because the indicator for the library OPTION.FLASHSIZE is reset to its default value and there is not a way of knowing if the flash slot contains a valid library.(It could be used just as a normal flash slot)
On the ARMmites we have
LIBRARY RESTORE that will test for the existence of a library and restore the OPTION.FLASHSIZE pointer if a library exists.
Latest F4 Latest H7 FotS
 
matherp
Guru

Joined: 11/12/2012
Location: United Kingdom
Posts: 10067
Posted: 09:35am 19 Mar 2025
Copy link to clipboard 
Print this post

  Quote  On Picomites
OPTION RESET will erase the Library.


Yes it does on the PicoMite too. However, I think what electricat may be doing is then loading options from disk that have the library configured. Hence he can't then load the library again. I'm not pursuing this further because the library is working for everyone else other than the COLOR issue which you have solved
 
Amnesie
Guru

Joined: 30/06/2020
Location: Germany
Posts: 529
Posted: 10:58am 19 Mar 2025
Copy link to clipboard 
Print this post

  matherp said  
  Quote  With connected PS/2 Mouse on GP27,GP28 it is impossible to use GP26, since it ALWAYS shows 3,3V (in reality the pin is @ 3,7V measured with multimeter).


Sounds like a H/W fault at your end. Definitely not the case with a bare Pico2 running PicoMiteVGA V6.00.02RC5



I guess you tested this with a level shifter? Even on breadboard I have the same issue! Only way to solve this is with a level shifter (2N7000) between clk & data.
But since the Pico 2 is 5V tolerant I leave out the level shifter for the PS/2 mouse and got this problem. With level shifter it works. But is this normal?

My theory: The Pico 2 ADC isn't 5V tolerant, since GP27 & GP28 belong to the ADC, if voltage >= 3,3 then it overloads the GP26,too.

Greetings
Daniel
Edited 2025-03-19 21:04 by Amnesie
 
Volhout
Guru

Joined: 05/03/2018
Location: Netherlands
Posts: 4854
Posted: 11:20am 19 Mar 2025
Copy link to clipboard 
Print this post

Hi Daniel,

That is important. And new to me.
You could very well be onto something. But that would also influence GP29 (measuring Vbus).
Anyway, I would add a level shifter never the less...

Volhout
Edited 2025-03-19 21:21 by Volhout
PicomiteVGA PETSCII ROBOTS
 
electricat

Senior Member

Joined: 30/11/2020
Location: Lithuania
Posts: 295
Posted: 11:40am 19 Mar 2025
Copy link to clipboard 
Print this post

@Peter, disco4now

Now I see whats going on!
Thank You both, for excelent explanation. Knowing that, I will be carefull with this.
Updated manual (with some carefull hope   ) would protect against such questions from other users, next time.
My MMBasic 'sand box'
 
electricat

Senior Member

Joined: 30/11/2020
Location: Lithuania
Posts: 295
Posted: 12:11pm 19 Mar 2025
Copy link to clipboard 
Print this post

I did not want start new thread for this minor question.

I did not get in, how mm.info$(PATH) might be usefull/used?

If I command prompt -> ? mm.info$(PATH)
it returns NONE

if inside editor I would type in ? mm.info$(PATH) after run it would be changed to ? mm.info(PATH) (and sure, returns NONE) while it seems to me string thingie...

To my understanding it should return path, but I failed to use it properly maybe

for examle

Chdir "B:\somedir"
Print MM.Info$(PATH)


I see path changed from command prompt, but after RUN returns NONE and modified to


Chdir "B:\somedir"
Print MM.Info(PATH)

Edited 2025-03-19 22:23 by electricat
My MMBasic 'sand box'
 
Amnesie
Guru

Joined: 30/06/2020
Location: Germany
Posts: 529
Posted: 12:32pm 19 Mar 2025
Copy link to clipboard 
Print this post

  Volhout said  Hi Daniel,

That is important. And new to me.
You could very well be onto something. But that would also influence GP29 (measuring Vbus).
Anyway, I would add a level shifter never the less...

Volhout


Hello Volhout,

I can confirm my theory.

As soon as I connect a Voltage > 3,3V to GP27 OR GP28, it results in compromising GP26, too (it is constantly at 3,3V).

So Peter, is this a general fault in the Pico ADC? Of course I can solve this via level shifter (and I will!) but I think this is an important thing to notice, since it no langer has to do with a PS/2 mouse, but with any voltage > 3,3V on other ADC pins. I always read that the Pico 2 supports 5V ?!

Greetings
Daniel
Edited 2025-03-19 22:32 by Amnesie
 
Mixtel90

Guru

Joined: 05/10/2019
Location: United Kingdom
Posts: 7503
Posted: 12:55pm 19 Mar 2025
Copy link to clipboard 
Print this post

Certainly on the RP2040 the ADC pins are different to the others. They all have ESD protection diodes up to IOVDD (linked to 3V3 on the Pico), which none of the others do. Attempting to put more than about 3V3+10% on one will attempt to power the whole chip at the input voltage. This also applies to the ADC inputs of the RP2350.

You shouldn't attempt to use more than 3V3 on *any* ADC pin on either chip, even if used in digital mode because the diodes are formed on the substrate and are not actually on the other side of the ADC multiplexer. (There is actually only one ADC on the die which is multiplexed to a number of pins.)
Mick

Zilog Inside! nascom.info for Nascom & Gemini
Preliminary MMBasic docs & my PCB designs
 
matherp
Guru

Joined: 11/12/2012
Location: United Kingdom
Posts: 10067
Posted: 01:24pm 19 Mar 2025
Copy link to clipboard 
Print this post

  Quote  I did not get in, how mm.info$(PATH) might be usefull/used?


It returns the location that the current program was loaded from - if from disk
use CWD$ to get the current working directory
 
matherp
Guru

Joined: 11/12/2012
Location: United Kingdom
Posts: 10067
Posted: 01:24pm 19 Mar 2025
Copy link to clipboard 
Print this post

  Quote  Certainly on the RP2040 the ADC pins are different to the others. They all have ESD protection diodes up to IOVDD (linked to 3V3 on the Pico), which none of the others do. Attempting to put more than about 3V3+10% on one will attempt to power the whole chip at the input voltage. This also applies to the ADC inputs of the RP2350.

You shouldn't attempt to use more than 3V3 on *any* ADC pin on either chip, even if used in digital mode because the diodes are formed on the substrate and are not actually on the other side of the ADC multiplexer. (There is actually only one ADC on the die which is multiplexed to a number of pins.)


Correct ADC pins are not 5V tolerant
 
Amnesie
Guru

Joined: 30/06/2020
Location: Germany
Posts: 529
Posted: 01:36pm 19 Mar 2025
Copy link to clipboard 
Print this post

OK

I never read about that, only that the PICO 2 is 5V tolerant. Good to know, I will redesign my PCBs :)

Thank you!
Daniel
 
matherp
Guru

Joined: 11/12/2012
Location: United Kingdom
Posts: 10067
Posted: 10:33am 20 Mar 2025
Copy link to clipboard 
Print this post

Harm and others using PIO

I want to make a big change to PIO initialisation to allow all pins on the RP2350B to be used from MMBasic. For various reasons this simply can't be done with the current Basic interface routines.

The proposal will be to eliminate the PIO helper functions and have one big INIT call to replace them and replace PIO SET BASE

PIO INIT MACHINE pio, sm, clock, startaddress,
sidesetbase, sidesetno, sidesetout, setbase, setno, setout, outbase, outno, outout, inbase,
jmppin, wraptarget, wrap, sideenable,
pushthreshold, pullthreshold, autopush, autopull, inshiftdir, outshiftdir, joinrcfifo, jointxfifo, joinrxfifoget, joinrxfifoput

In this approach you will use the actual GP numbers even when they are above GP31. The system will automatically check that you are using GPs in the range 0-31 or 16-47 and give an error if they are not. It will automatically set the GP base for you.
It is important to note that the pin base (GP0 or GP16) applies at the PIO level and not at the state machine level.

As always I want to have a single code base so would much prefer this to be a change which applies to all variants.

It would mean a change (simple) to all programs using PIO but would be future proof in a way the current approach isn't.

Thoughts?
Edited 2025-03-20 20:34 by matherp
 
falcmax
Newbie

Joined: 15/02/2025
Location: Italy
Posts: 7
Posted: 10:54am 20 Mar 2025
Copy link to clipboard 
Print this post

I have a question for Matherp. Since there are several boards (like the Pimoroni Pico plus 2) that don’t work under overclock and therefore can’t be used in the HDMI version, I was wondering if it would be possible to use the technique described here:

https://github.com/Panda381/DispHSTX/blob/main/_doc/DispHSTX.pdf

The DispHSTX driver is controlled by the system clock by default. This requires that the system clock is set to 5 or 10 times the pixel clock by the driver.
There is another alternative yet - by turning the DISPHSTX_USEPLL switch to 1, another variant is used. Specifying the DispHstxClockReinit() function at the beginning of the program redefines the clock control in the processor so that all peripherals and the system clock are controlled from the common PLL generator PLLUSB, while the PLLSYS generator is used only for controlling the HSTX driver. The clock generated by the PLLUSB generator should preferably have a frequency equal to the integer multiple of the USB clock, that is 48 MHz. This allows the HSTX driver timing to be controlled independently of the system clock. It is even possible to overclock the HSTX clock a little more than would be possible when driving from the system clock. If the HSTX driver malfunctions due to overclocking, there is no risk of the entire system crashing, the system can even check the correct function of the driver and adjust its clock if necessary. However, it is important to remember that the processor must be fast enough to generate the display signal in this mode, so it is recommended that only experienced users use this mode.
 
Mixtel90

Guru

Joined: 05/10/2019
Location: United Kingdom
Posts: 7503
Posted: 11:32am 20 Mar 2025
Copy link to clipboard 
Print this post

IIRC the issue with overclocking isn't that it is needed to output HDMI, it's to give enough time to be able to use layers. These have to be copied into the framebuffer between video frames. The higher the resolution the more data there is to copy in the same time. You can get HDMI at much lower CPU speeds but with reduced resolution and without layers.

No doubt I'll get corrected if I've misunderstood this.  :)
Mick

Zilog Inside! nascom.info for Nascom & Gemini
Preliminary MMBasic docs & my PCB designs
 
Volhout
Guru

Joined: 05/03/2018
Location: Netherlands
Posts: 4854
Posted: 12:53pm 20 Mar 2025
Copy link to clipboard 
Print this post

@Peter,

About PIO: Is this something that can be postponed for 6.00.03 ? Un tp now we have managed to have 6.00.02 compatible with virtually all legacy PIO programs (actually, virtuall all MMBasic programs).
With this change all PIO programs will need a re-write of the MACHINE INIT, in which the order of items is also changed.

I do understand why this is handy, but please delay to 6.00.03.

A second thing to wory about is the number of characters that are in this new INIT (the line length). Even in case some values can be empty (default) or a 0 or a 1, there are some that are longer (i.e. PIO(WRAP_TARGET) ), so the line will become unreadable/not editable in the internal editor.

Again, nice suggestion for 6.00.03. Please release 6.00.02rc5, with only the LIBRARY fix. Then continue with MMBasic command changes like these in a new release. Pico is not finished yet, you will continue to find optimizations and new idea's for many more months/years. 6.00.02 is not the end, but let it be a milestone.

Those a re my 5 cents.

Volhout
Edited 2025-03-20 22:54 by Volhout
PicomiteVGA PETSCII ROBOTS
 
Amnesie
Guru

Joined: 30/06/2020
Location: Germany
Posts: 529
Posted: 03:23pm 20 Mar 2025
Copy link to clipboard 
Print this post

  Volhout said  @Peter,

Pico is not finished yet, you will continue to find optimizations and new idea's for many more months/years. 6.00.02 is not the end, but let it be a milestone.

Volhout


I share those thoughts. But in general the idea is great!

Greetings
Daniel
 
matherp
Guru

Joined: 11/12/2012
Location: United Kingdom
Posts: 10067
Posted: 07:18pm 20 Mar 2025
Copy link to clipboard 
Print this post

V6.00.02RC6 is available on

https://geoffg.net/Downloads/picomite/PicoMite_Beta.zip

Fixes bug in library when COLOR command is used and spaces appear before it in the line
Fixes bug in VGA versions when changing to a smaller font at the command prompt

LINE x1,y1,x2,y2,w,c now supports the width parameter for diagonal lines

RP2350B only
OPTION VGA PINS and OPTION AUDIO I2S both now support pins in the range GP32-GP47

Note: in all cases pins specified must all be in either the range 0-31 or 16-47
In the case of VGA/VGAUSB with AUDIO I2S this applies to all pins for both functions
 
JanVolk
Senior Member

Joined: 28/01/2023
Location: Netherlands
Posts: 220
Posted: 08:32pm 20 Mar 2025
Copy link to clipboard 
Print this post

Oops...
When I unpack the update V6.00.02RC6 it still says V6.00.02RC5

Greetings,

Jan.
 
toml_12953
Guru

Joined: 13/02/2015
Location: United States
Posts: 390
Posted: 09:58pm 20 Mar 2025
Copy link to clipboard 
Print this post

  JanVolk said  Oops...
When I unpack the update V6.00.02RC6 it still says V6.00.02RC5

Greetings,

Jan.


Same here.

Tom L
Edited 2025-03-21 07:58 by toml_12953
 
matherp
Guru

Joined: 11/12/2012
Location: United Kingdom
Posts: 10067
Posted: 10:29pm 20 Mar 2025
Copy link to clipboard 
Print this post

The upload doesn't seem to have worked - try again
 
     Page 7 of 44    
Print this page
The Back Shed's forum code is written, and hosted, in Australia.
© JAQ Software 2025