 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/PicoMiteVGA V5.07.03 release candidates
  Page 6 of 9   |
|||||
| Author | Message | ||||
phil99 Guru  Joined: 11/02/2018 Location: AustraliaPosts: 1813 |
Restoring options A bits and pieces text file can hold all the OPTION LISTs for your Mites. If you forget to use Peters method it won't matter. Copy and paste back from the file as often as needed. A File System? For most seven slots is enough, if not more than one program can go in a slot. Turn them into subroutines of a menu program. The best way to get CMM2 capabilities is with a CMM2. It's already there. |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2294 |
hi peter, the statistics you quote are quite misleading. UNIX operating systems, of which Linux is just one variant (just as Ford Cars are just a subset of Cars) include: macOS (the operating system formerly known as OS X), which is built on BSD UNIX; Chrome OS, essentially a wrapper around Linux; and various mainstream Linux distributions such as Mint (which many of us here run). if one looks at the statistics for the United States: Windows - 61.69% (just under 2/3) UNIXes - 35.35% (just over 1/3) Oceania (including Australia): Windows - 66.84% (2/3) UNIXes - 30.59% (just under 1/3) Worldwide (including enormous numbers of pirated copies of Windows in China): Windows - 73.75% UNIXes - 19.62% So any adversity to UNIX operating systems risks disenfranchising about 1/3 of the computer users out there. As for 'limitations', i'm afraid that is just the price the non-Windows universe has to pay for our computers to not be riddled with viruses, and to not have to be wrapped up in layers of software prophylactics that chew up inordinate quantities of computrons and electrical energy. imagine a world free of computer viruses, where all the electricity currently used to protect the 73.75% of Windows computers could be redirected towards mitigating climate change... cheers, rob :-) Edited 2022-01-07 22:19 by robert.rozee |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2294 |
using dmesg -w you still get a whole load of information that varies widely between different devices, and between different flavours of Linux - type it at a console and observe for yourself. it is not easy finding an algorithm to make sense of it in any way that is foolproof. the fact is that a serial device suddenly disappearing is not something any operating system is designed to handle gracefully - be it Windows or UNIX (ie, Linux, macOS or Chrome OS). GFXterm handles it within the serial thread itself (a small, separate, independent thread partitioned from the rest of the program). this thread flags what one may call a 'hard error' message, then within itself closes the port - a process that may block for up to 30 seconds depending upon what was going on when (usually) the USB cord was pulled. this 'hard error' message percolates up to the error message you see on screen some time (up to 300ms) later, while the serial thread may still be blocked. the semicolon idea was just a possible solution - it appealed as it borrows from the existing syntax (and mechanics) of the PRINT command. it does need to be something simple, that doesn't require creating extra tokens. that was just wishful thinking... although would be a very nice feature. i was thinking of just matching filenames, not directories, and only kicking in if there was a single matching filename. it would, as has been noted, only be something used at the command prompt, and just a timesaver (as is aliasing OVER to OVERWRITE) cheers, rob :-) Edited 2022-01-07 22:51 by robert.rozee |
||||
Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 5771 |
You sure know how to bait the linux contingent, Peter. :) Can't resist... UNIX =/= linux =/= BSD =/= macOS =/= ChromeOS Something running on one of them almost certainly won't run on any of the others, even if they are related in history. Not even all the mainstream linux distros are fully compatible with each other. Yes, you can often make something work on the "wrong" flavour (recompile with different libraries etc.), but there's no guarantees and it's not something many users will want to do. I like linux. I like using it, but I'm quite happy to use Windows where it's easier / more convenient. It's just horses for courses as far as I'm concerned. The thing about viruses being a problem on Windows is a bit of a red herring. Those using linux in one of it forms are liable to be more tech savvy and know how to avoid a lot of the nasties. It's not just that linux is more secure. On the other hand, the vast majority of Windows users have little idea of how to protect their systems and are remarkably trusting. As a more popular OS anyway, it's no surprise that the number of malware infections on Windows is much higher than on any other platform. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 3678 |
Android is also Linux, of course. Currently I suspect people don't plug 'mites into Android systems, though that could change. If MMBasic causes a (USB) reset, well, multiple resets, clearly a headache but so be it. It would pretty much be chance that any pre-existing OS would just "do the desired thing" in that case. Heck, would be reasonable if the OS blacklisted the device for behaving that way! John |
||||
TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 5923 |
My limited experience with Linux; A quick reset of the pico will result in the port number increasing by one. (Linux is 'slow' to clear the old port) Easily fixed by a long 2-3 seconds press of the reset button I have installed and the port reverts to it's original number. Windows does reuse the same port number with a fast reboot of the pico but can result in a non-responsive port. Easily fixed by disconnecting, waiting a few seconds then reconnecting. (All done in software so no need for a manual button press) Either system is too arduous. Jim VK7JH MMedit MMBasic Help |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 3678 |
A fix for MMBasic might be possible. E.g. SoftReset() ... perhaps disconnect cleanly from USB, wait a short time, then do the current stuff. Would likely be better for Windows & Linux. John |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2294 |
peter's port to the pico has improved significantly since he started - originally it would frequently knock out the USB subsystem completely, requiring a reboot if you didn't know the exact hardware-specific incantations needed to just restart USB. a good part of the problems lie in 'tinyusb', the component that the pico SDK uses uses for the USB stack. i have previously raised an issue with the developers, but since it mostly relates just to the MMbasic case (python does things differently) have achieved little traction. i have spent over a hundred hours making GFXterm more 'pico-proof', with a couple of complete rewrites of the serial code involved until i found an approach that was reliable enough. this applied to both UNIX and Windows ports. cheers, rob :-) Edited 2022-01-08 09:38 by robert.rozee |
||||
mobluse Newbie  Joined: 10/02/2013 Location: SwedenPosts: 24 |
Option settings that reset or manual reset using the run button on Maker Pi Pico is no big problem in Raspberry Pi OS Buster Linux using Minicom. It comes back automatically and no restart of Minicom is needed. I would prefer if more option settings didn't require a reset. It is a bigger problem if I use Picocom, because then the program is stopped with: FATAL: read zero bytes from port term_exitfunc: reset failed for dev UNKNOWN: Input/output error Maker Pi Pico Rev1.2, DuinoMite-Mini, Raspberry Pi 0-4, iCE40HX8K, Arduino Uno, VM111, STK500, ZX81 |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 5771 |
Option settings are just that. They set some system options for your 1980's home computer. All the main ones are in flash memory (like editing your ROM) - I don't think the general idea is that you'll *keep* changing them (or they'd be in your program like OPTION BASE) so the occasional reset for those that make major system changes is fine. It might be annoying, but they should normally be treated as set & forget. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 3678 |
Maybe not in this case. It looks as though the picomite will just disappear without letting the USB host know. That, I suspect, may leave the host timing it out, so that it can continue comms in the more typical case of a slow device (or retry?). Then a device appears. We know it's the same one but the host may not due to the timing out it needs to do to meet the USB specs. The host figures it out after some time. It looks rather like it may be a sort of software race. I don't know if tinyusb has a way to close/disconnect, though. John Edited 2022-01-08 19:49 by JohnS |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8607 |
A first draft of the updated manual for V5.07.03 is now included in the download and attached below https://geoffg.net/Downloads/picomite/PicoMite_Beta.zip For those who have raised issues with the manual it would be appreciated if you could check that we have picked up on your comments. PicroMite User manual 5.07.03 draft.pdf Currently I don't intend to make any further changes from RC10 before the full release of V5.07.03 Edited 2022-01-08 22:11 by matherp |
||||
| lizby Guru Joined: 17/05/2016 Location: United StatesPosts: 3027 |
Shouldn't this be "PicoMite", not "PicroMite"? PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on fruitoftheshed |
||||
| flasherror Senior Member  Joined: 07/01/2019 Location: United StatesPosts: 159 |
Suggestions below, most from thread https://www.thebackshed.com/forum/ViewTopic.php?TID=14377&P=1 but check thread for others. Applies to User Manual MMBasic Ver 5.07.03 DRAFT There should be a note pointing out the difference in numbering between the Raspberry Pico datasheet and the Picomite manual pinout diagram (Manual P9). For example, physical pin 1 (GP0) is UART0 TX in Raspberry datasheet but is COM1 TX in PicoMite. This has been done to maintain backwards compatibility) Similarly, there is offset in I2C pins, for example Physical pin 9 (GP6) is I2C1 SDA in Raspberry datasheet but is I2C2 SDA in PicoMite I strongly feel there should be warning note about this. Interrupts P26/27 Mention LCD commands such as clearing LCD (and what other? SD card?) may take a long time to execute and thus may delay interrupt response for frequently occurring interupts. Also BITBANG WS2812 disables interrupts to achieve the precise timing needed for these LEDs (which may delay interrupts when driving long strings of LEDs). Also mention that interrupts are checked after each basic statement has completed processing. P35 - typo "with the BITBANG WS8212 command" should be WS2812 SD cards P36 should mention "The PicoMite uses the SPI protocol to talk to the card and this does not care what the card type is. So all types (Class 4, 10, UHS-1 etc) are supported." Bold/underline 5v level conversion warnings on Pages 42, 49 # of files that can be LISTed not included in Implementation details P37/38 and P71 MM.INFO$(VERSION) is not listed under "Predefined Read Only Variables" on P73 Analog inputs P25 and Command table P74 Reminder that usable ADC inputs are ADC0/1/2 (ADC3 is hardwired on Pico board to measure 1/3 Vsys) OPTION DEFAULT on P76 should mention what happens if OPTION DEFAULT NONE is set and vars don't have their type explicitly defined then "Error: Variable type not specified" occurs (there is no default type). Edited 2022-01-09 01:01 by flasherror |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 5771 |
The PicoMite is NOT a RPi Pico. They run a different OS even if the hardware is the same. The PicoMite is designed to be similar to a 1980's home computer so it uses that terminology rather than linux, Python or C. Also, The PicoMite uses pin terminology generally in line with other members of the MMBasic family. You wouldn't expect to be able to use Circuit Python on a Pico without first reading the documentation if you had only had previous experience of MMBasic. I would expect the reverse to also be true - RTFM. There is no need for any sort of pin conversion chart, we are not documenting the RPi Pico. Did you get CP/M documentation with your PC? It's capable of running it. ;) Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8607 |
Not an issue - I've just included |
||||
| flasherror Senior Member Joined: 07/01/2019 Location: United StatesPosts: 159 |
Sigh... I don't understand the opposition to including a simple sentence to point out a potential pitfall. In the same way the manual warns that the pico is a 3.3v device and 5v I/O must be level shifted, why not include a note that Picomite I/O names are unique/different and do not use the Raspberry Pi pinout/names? It is very likely that a beginner might miss this (or quickly Google the Pico pinout diagram instead of the Picomite one) so why not save users from a potentially time wasting issue? |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2294 |
it would have been even easier - and far less confusing - to use the same names as printed on the published RPi Pico documentation that is all over the web. after all, is it really that much more difficult to type I2C0 instead of I2C? it is just one extra character  and then also used COM0 and COM1 to see everything kept consistent. cheers, rob :-) |
||||
| mobluse Newbie Joined: 10/02/2013 Location: SwedenPosts: 24 |
Correction to manual draft: "Function keys F5 to F9 can be programmed with custom text. See the OPTION FNKey command." should probably be "Function keys F1 and F5 to F9 can be programmed with custom text. See the OPTION FNKey command." Maker Pi Pico Rev1.2, DuinoMite-Mini, Raspberry Pi 0-4, iCE40HX8K, Arduino Uno, VM111, STK500, ZX81 |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8607 |
That's what the original versions did and then everyone said NO It ain't going to change again |
||||
| Page 6 of 9 |
|||||
 Print this page |
