 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 questions and suggestions
Page 1 of 2   |
|||||
| Author | Message | ||||
| flasherror Senior Member  Joined: 07/01/2019 Location: United StatesPosts: 159 |
Picomite questions/suggestions based on user manual v5.07.01 I am waiting on Picomites I ordered so I haven't had "hands-on" experience but have been reading the manual. I have the following questions/suggestions: Terminal baud rate from Page 5 "Finally, the PicoMite ignores the baud rate setting so it can be set to any speed (other than 1200 baud which puts the Pico into firmware upgrade mode)." Does this mean the Pico auto adapts to the user's baud rate (if not 1200) and changes its speed to match for convenience? Wouldn't that mean that faster baud rates are still desirable since screen refresh etc would be faster? Power consumption Table on P10 should have entry for 133mhz Watchdog P13 - This section does not actually mention that the Watchdog time is programmable compared to the summary on P111. RTC GETTIME P13 The discussion on MM.STARTUP uses RTC GETTIME as an example. But isn't a better option to use OPTION RTC AUTO ENABLE to accomplish setting the current time based on the RTC (with the benefit of the hourly RTC sync)? I understand this is an example for MM.STARTUP but perhaps mentioning the OPTION RTC AUTO ENABLE here is a good idea. (By the way, what occurs during the hourly sync if error communicating with RTC, whether a program is running or not?) Playing .WAV audio P28 does PLAY WAV abort/terminate or fail silently if file is not present or error reading SD card? WS2812 LEDs P35 due to the protocol timing for these LEDs I'm guessing that interrupts are disabled during sending. What is the max time that interrupts are disabled for (assuming longest 256 LED string), and how does this affect other interrupts (Timer, UART, etc)? Might need to add mention about BITBANG WS2812 to Interrupts section? SD cards P36 What are the supported SD card types (Class 4/10, UHS-1 etc)? Apart from not using really old cards or >32GB, is there any recommendation other than using quality SD cards and using FAT16/32 filesystem? Option Default P71 The manual says OPTION DEFAULT FLOAT | INTEGER | STRING | NONE Used to set the default type for a variable which is not explicitly defined. If OPTION DEFAULT NONE is used then all variables must have their type explicitly defined. When a program is run the default is set to FLOAT for compatibility with Microsoft BASIC and previous versions of MMBasic What happens if OPTION DEFAULT NONE is set and vars don't have their type explicitly defined? P18 mentions error message but perhaps it should be on P71 as well since it is the summary table. (might also apply to OPTION EXPLICIT) Other: What is the max # of files in a folder? In the past, for Duinomite MMBASIC v4.5 I had an issue where there was a limit to the # of files in a folder (not listed in documentation), resulting in having to create logs in individual month folders (rather than all files in one folder) so as not to exceed "max files in folder" limit. I remember getting an error complaining about "too many files" or similar when using FILES command to list folder contents. Does Picomite (or Armmite F4) have a similar restriction? There is nothing listed under "Implementation Characteristics" on P66. For program optimization (loops etc) is it faster to use a signed integer loopcount% than a double precision floating point loopcount! ? (The manual specifies that variables default to double precision floating point if type is not specified, assuming not changed with OPTION DEFAULT INTEGER). Maybe there could be a page or two on optimizing for speed / space? Unless you know the internal implementation details it is not easy to optimize programs. Although Pico CDC USB is not officially supported by Raspberry Pi for Windows 7, I have gotten it working by following instructions online. Pico should show up as "Board CDC" in Device Manager (unplug/replug USB if it doesn't show up) Install Zadig and run. Select Board CDC (Interface 0) from the drop-down box. Select USB Serial (CDC) as the driver. This will install driver so serial port will be properly installed so TeraTerm etc will work. Thanks |
||||
TassyJim Guru  Joined: 07/08/2011 Location: AustraliaPosts: 6218 |
It means that whatever speed you tell Windows/Linux to set the port to, it will run at full USB speed. This is not an issue except when you are running an application on the PC that expects/needs a slow speed. You have no control over the actual speed. Jim VK7JH MMedit |
||||
Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 7498 |
I think requiring a current consumption for 133MHz is a little pedantic really. The PicoMite's default clock speed is 125MHz (as is the RPi Pico's). 133MHz is the recommended maximum for the Pico, not the PicoMite, which most of us have no problems with at 250MHz. The consumption figures given are approximate anyway and will vary from device to device and with whatever devices are attached. They are not reliable figures that you could use to, say, calculate the battery size for an application. IMHO it wasn't really necessary to specifically state that the watchdog time is variable. It can be safely assumed, I think, that anyone wanting to use unfamiliar commands will look for them in the Commands section. RTC GETTIME has the advantage over OPTION RTC AUTO ENABLE in that the update occurs only when the user requires it. The command does take a finite time to run and it is often better to put the delays where you want them rather than have them occur via interrupts. Both systems have their place. All interrupts are stopped while writing to WS2812B LEDs. It is up to the user to ensure that data corruption on COM ports etc. doesn't occur. Sorry, I can't give a maximum time the interrupts will be off. I would guess at very slightly more than you could calculate from the WS2812B data sheet. If OPTION DEFAULT NONE is in force then all variables are float unless they are explicitly defined. e.g. a="string" will cause an error whereas a$="string" will perform as expected. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3269 |
A lot of good points and questions. I will try to answer some and hopefully Peter and others with a PicoMite handy can answer the others. What are the supported SD card types? The PicoMite uses the SPI protocol to talk to the card and this does not care what the card type is. So all types are supported. What happens if OPTION DEFAULT NONE is set and vars don't have their type explicitly defined? You get: Error: Variable type not specified For program optimization (loops etc) is it faster to use a signed integer loopcount% than a double precision floating point loopcount! ? Integers are slightly faster (about 20% in an empty loop). Maybe there could be a page or two on optimizing for speed / space? This is something that I'm not keen on. An interpreted language is inherently slower than others and trying to "optimise" it does not make a lot of difference. For example, you might use integers for a loop counter but the small speed increase will be swamped by the time taken to execute the commands/statements within the loop. People do all sorts of crazy things to go faster (delete comments, delete whitespace, have one character variables, etc) with the result that the program is a few percent faster but is completely unreadable. The PicoMite is way faster than most people need and if you really need blazing speed (unlikely) then you need to learn C. Thanks for the tips on improving the manual. I will look at them for the next release. Geoff Geoff Graham - http://geoffg.net |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3269 |
Sorry Mick but that is not quite right. If OPTION DEFAULT NONE is in force then all variables must have their type defined otherwise you will get an error (there is no default type). Geoff Graham - http://geoffg.net |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2398 |
it strikes me that perhaps an FAQ list for each type of 'mite would be a useful thing to have, as there seem to be quite a few questions that pop up repeatedly. regarding speed optimization: i did do it once, to get a loop that was fast enough to reliably clock in (100+) variable-length bits from a remote control for grogster. as i recall, i was able, with care, to get just enough speed to do this on a 40MHz MX170. but that was a rather obscure case. reminds me, a year or two back i asked about extending the PULSIN function to read the length of a series of pulses, storing their lengths in an array. for decoding the output of arbitrary remotes and other complex serial data. not sure if the idea went anywhere in the end... cheers, rob :-) |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 7498 |
Ah! Thanks, Geoff. I was pretty sure there was a default... Sorry for misleading anyone. Applicable to all platforms apart from the CMM2 (IIRC - someone will correct me if I'm wrong. ;) ): One thing that can be done to get a slight speed increase is to keep the first 4 characters of the names of frequently accessed variables unique as that gives faster searching of he variables table. The CMM2 uses a hash table which is already fast so nothing is gained. . Edited 2021-12-12 19:59 by Mixtel90 Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| bigfix Senior Member Joined: 20/02/2014 Location: AustriaPosts: 129 |
For Robs PULSIN request Peter proposed using his logicanalyser CFunction Logicanalyser CFunction |
||||
CaptainBoing Guru Joined: 07/09/2016 Location: United KingdomPosts: 2137 |
I have this page that I add to occasionally with hints & tips. May give you something |
||||
| flasherror Senior Member Joined: 07/01/2019 Location: United StatesPosts: 159 |
Do you design at datasheet max specs/limits?  The reason I asked is that it would be useful to know approx current at the fastest recommended speed, especially if Picomite is much faster than older MX170 etc and there's no need to overclock for most uses. Not sure what you mean about your point Pico vs Picomite, if you're running MMBasic on Pico hardware then not sure why the recommended 133MHz speed wouldn't apply to Picomite unless there's something else I'm unaware of.Agree but even better would be a central wiki where one could easily check firmware versions, board photos, LCD pinouts and OPTION mappings, current bugs, beta versions etc. The reality is that compared to other platforms (Arduino etc) it is often more difficult to easily find information quickly. It would be nice if as firmware versions etc are posted here the wiki or FOTS would be updated simultaneously. Currently, even a simple thing like finding out what is the latest firmware or user manual for a specific platform requires searching and hunting various topics/posts and "guess the search keywords that will give best results". (Now that Geoff has "officially" added Picomite to his website this is helpful, but above challenges still exists for Armmite ports) The above isn't meant to insult anyone or the backshed forum itself but is a suggestion. (I don't mean to come off as ungrateful for Geoff/Peter/others hard work) Edited 2021-12-12 22:03 by flasherror |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 7498 |
The PicoMite was tested at various speeds until it became unreliable. At first the top limit was set high so we could see what worked. We settled on 250MHz max as no-one reported problems at that speed. :) Specifications are always a guide. You have to remember that the RPi recommended max is set at a point where *all* boards should meet full operational spec when tested at random. We don't particularly care if a board won't run at 250MHz. Just slow it down until it's ok. There isn't a recommended speed for the PicoMite, only a default one (well it has to be set to something). If you want to stay on top with current versions of the firmware etc. then this is the only place. It would be impractical to update a wiki fast enough sometimes! Also, remember that *everything* to do with MMBasic and the various platforms is voluntary, unpaid work. Someone has to spend their own time updating something like that, sorting and editing photos, designing the pages - and sorting out hosting. All current firmware versions, both stable & beta, are hosted on Geoff's web site. He also has pages about most of the various platforms. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| lizby Guru Joined: 17/05/2016 Location: United StatesPosts: 3309 |
It would be nice, but I suspect that most of us would prefer that Peter do what he appears most willing to do--update the firmware and do new releases for new platforms. Anyone can add to FOTS (hint), but it does take someone stepping up to do it. Same is true for CMM2.fun. Most ports don't have a FOTS champion. All that is needed, though, is volunteers. CaptainBoing did a great deal for the MM2, with code examples useable on or adaptable to most MMBasic platforms. Everyone is invited to add to PicoMite on FruitoftheShed and ArmMite F4 on FruitoftheShed, and to create or add to entries for other MMBasic platforms. PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on fruitoftheshed |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 4845 |
Sorry, that is not true. Between a1 an a2 some picomites would not boot anymore. It took some time for the dust to settle, but in the end Peter clocked down 250Mhz to 125Mhz so all boards would boot. Simply said, most boards will work on 250, but not all. PicomiteVGA PETSCII ROBOTS |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 7498 |
I thought there only appeared to be one board that was having problems and that was later found to be something else? I may be wrong, of course. I'd have to go back through the posts. I know for certain that all four of the boards that I have used personally have had no trouble whatsoever booting or running at 250MHz. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 4845 |
I did send my not working board to Peter for investigation, he still has it. PicomiteVGA PETSCII ROBOTS |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 7498 |
You might get it back disguised as a VGAmite now. :) Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10055 |
Using it for development at 252MHz (Turbo mode for the VGA) |
||||
| flasherror Senior Member Joined: 07/01/2019 Location: United StatesPosts: 159 |
More comments on PicoMite docs based on manual v5.07.01 One potential BIG thing that could trip up users is 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 might have been done to maintain COM port order starting with "1" instead of "0" for backwards compatibility with previous mites? 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 and a small table of pin differences for Raspberry Pi pinout/PicoMite pinouts as it is easy to get this confused because the PicoMite references are unique compared to everything else on the Internet. It looks to me that PicoMite references to UART/I2C/SPI are +1 compared to Raspberry Pi references (but strangely enough the ADC references (ADC0/1/2) match the Raspberry Pi ones which start at zero). 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) Suggestions for driving higher loads than 5mA (@ 3V) pin current draw? Should manual have a few sample circuits for interfacing to common loads? (I realize interfacing is application specific but might be helpful to someone who is new to electronics interfacing or only has experience with older 5v (PICs) chips with better drive capability). |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 7498 |
There was a lot of thought about this. Eventually it was decided that PicoMite being compatible with other MMBasic platforms was important. The PicoMite isn't the RPi Pico, doesn't run the same language and only shares pin numbers on the RP2040. It has its own manual, which the user is encouraged to read. The original Maximite was designed to feel like an old computer, so all ports start at 1. This has been continued across all platforms and allows quite a bit of software to be compatible between them. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| CaptainBoing Guru Joined: 07/09/2016 Location: United KingdomPosts: 2137 |
This is only partially true - compatibility evidently wasn't important enough to NOT introduce a specific version of the language. I am sure I got on everyone's nerves banging the drum about this early on in the MMBasic for RPI2040 development. MMBasic for RPI2040 is best thought of as a fork of MMBasic - yes it is; there is new functionality peculiar to the platform and mandatory language changes to established, foundational functionality *required* for the RPI2040 platform and only for it (because of the pin mapping ability not having a default config). All mite platforms have some degree of customization/configuration but not foundational language changes. Code from the RPI2040 is not backward without some research and it goes quite a bit beyond changing a pin number when you go to another platform. Yes I know every 'mite platform has (e.g.) I2C on different pins but you aren't expected to define the pins, you can simply start using them as soon as it's running. With the RPI2040, pin mapping means you can put I2C, SPI, UARTs etc. (almost) anywhere - a powerful feature, true, but I reckon necessary use-cases are incredibly rare. Compatibility could have been assured by having a default pin mapping and avoiding a *fundamental* change in MMBasic functionality (SETPIN) that is as old as MMBasic itself. Mapping the pins (if you must) to other functions could have been included as the OPTIONs or something, that are specific with almost every flavour of MMBasic. Thousands of 'mites spread across a dozen(?) or so other platforms have no issues with fixed functionality. I flew the flag. So I ceded from the discussion and any following RPI2040 testing because I had no interest in something that introduced compatibility issues. I am minded that just because you can do a thing, it doesn't follow that you should. I would be interested to see any instances where pins had to be mapped one way because another wouldn't work that couldn't be sorted in the design/layup stage... guys? This is why I am excited about the Black Pill (promises to be a match for the PiPicoMite, with dedicated pin functionality) and my three RPI2040s are gathering dust. If they weren't so cheap I'd sell them. jus' sayin' h Edited 2021-12-14 03:48 by CaptainBoing |
||||
| Page 1 of 2 |
|||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
