![]() |
Forum Index : Microcontroller and PC projects : PicoMite V6.00.02 release candidates - all versions
![]() ![]() ![]() ![]() |
|||||
Author | Message | ||||
disco4now![]() Guru ![]() Joined: 18/12/2014 Location: AustraliaPosts: 971 |
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 KingdomPosts: 10067 |
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: GermanyPosts: 529 |
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: NetherlandsPosts: 4854 |
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: LithuaniaPosts: 295 |
@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 ![]() My MMBasic 'sand box' |
||||
electricat![]() Senior Member ![]() Joined: 30/11/2020 Location: LithuaniaPosts: 295 |
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: GermanyPosts: 529 |
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 KingdomPosts: 7503 |
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 KingdomPosts: 10067 |
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 KingdomPosts: 10067 |
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: GermanyPosts: 529 |
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 KingdomPosts: 10067 |
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: ItalyPosts: 7 |
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 KingdomPosts: 7503 |
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: NetherlandsPosts: 4854 |
@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: GermanyPosts: 529 |
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 KingdomPosts: 10067 |
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: NetherlandsPosts: 220 |
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 StatesPosts: 390 |
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 KingdomPosts: 10067 |
The upload doesn't seem to have worked - try again |
||||
![]() ![]() ![]() ![]() |
![]() |
![]() |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |