 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 V5.07.00b0 - beta firmware
  Page 8 of 13   |
|||||
| Author | Message | ||||
| robert.rozee Guru  Joined: 31/12/2012 Location: New ZealandPosts: 2294 |
peter - a suggestion and a question: 1. at the moment, if you try to save to a flash slot that is already in use, an error message is returned, Error : Already programmed instead, might i suggest asking the user the question, Overwrite existing slot contents? (Y/N): and then erase/write if the user replies 'y', otherwise do nothing. 2. as far as i can tell, there is a total of 160k of RAM available to hold program code and variables. program code is limited to 80k, variables are limited to 80k. there is a 'hard split'. there seems to also be 32k of 'general' RAM, am not sure what this is used for. the following shows the results of MEMORY after running a program that dimensions an array of 300 strings x 256 bytes each = 77k, as well as containing a large number of data statement that fill up almost all the program space: Saved 78433 bytes 9480 data items 17.875266 seconds > memory Program: 75K (78%) Program (1202 lines) 5K (22%) Free RAM: 76K (67%) 5 Variables 0K ( 0%) General 36K (33%) Free > my question: is there any interest in being able to trade-off variable RAM for increased program space, and vice versa? at the moment, the 80k/80k split seems to be driven by the need to maintain plain-text as well as tokenised versions of a program in RAM while doing the conversions between the two forms at editor startup and exit. this can be got around by: at editor startup, shift the tokenised code from the bottom of (the 160k block of) RAM to sit at the top. you can then start de-tokenising (at the beginning of the program), with the plain-text being written starting at the bottom of (the 160k block of) RAM. at some point the tokenised version will begin to be overwritten, but this does not matter once in the editor. at editor exit, likewise shift the plain-text version to sit at the top of the 160k RAM block. tokenise, writing from the bottom of the 160k RAM block, part-way through starting to overwrite the plain-text. cheers, rob :-) |
||||
dMajo Newbie  Joined: 18/05/2020 Location: ItalyPosts: 24 |
I think that the program get tokenized only in one direction text->tokens That's why the text is preserved Part of the text are also the code comments that are skipped during tokenization, I think ALLdataEE.com EDU Promos |
||||
Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 5756 |
You have to be careful with the RAM on the PicoMite. It's not a contiguous block, being split into several pages. There is a limit on how many of those pages you can have accessible at any one time. OPTION MEMORY will allow you to allocate *up to* half the available space (after reserving some or none for GUI controls) as program memory. You can allocate extra variables space at the expense of program area, but not vice versa. While you are editing, the variables area is used by the editor. The PicoMite doesn't use tokenisation in the same way as on the CMM2. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2294 |
as far as i'm aware, the pico code is based upon the MX170 base. with the MX170, the user program is saved in flash in the tokenised form, including comments in plain-text. when edited, it is converted from tokenised to plain-text. when saved from the editor it is converted back from plain-text to tokenised form (with comments still included as plain text). with the MX170 et al, the division between RAM (holding variables at runtime) and flash (that holds the tokenised user program) is rigidly imposed by the two different types of memory. the pico is a somewhat different beast. everything has to be held in RAM, with the user program(s) backed up to 10 program slots in flash. i'm picking that in each of these slots, the user program is held in a tokenised form with plain-text comments. fortunately, the pico has enough grunt to convert back and forth quickly enough for the user to not notice too much. is there any semi-complete pico manual yet? cheers, rob :-) Edited 2021-08-05 02:01 by robert.rozee |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 5756 |
The PicoMite doesn't depend on the flash slots to run. MMBasic is copied into RAM in order to run the program - it was considered too slow to run it from flash. Consequently you have MMBasic, variables and the user program all occupying RAM at run time. Only the TINAM that I keep posting. :) Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2294 |
i believe only select portions of the mmbasic interpreter reside in RAM, most of it still runs from the external flash chip. a diagram showing how the 264k of RAM is divvied up would be most helpful! cheers, rob :-) |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8601 |
5.07.00b10 PicoMiteV5.07.00b10.zip This has a breaking change in the pin numbering - sorry. I have now given access to all 30 I/O pins to allow use on boards other than the Pico. The firmware still defaults pins GP23, GP24, GP25, GP29 as per their use on the Pico but their function can now be overridden with any of the alternative functions available - see the list below. The new numbers are now as follows: pin41 = GP23 ' automatically configured as a digital output and set to the value of OPTION POWER (PWM=ON, PFM=OFF) pin42 = GP24 ' automatically configured as a digital input pin43 = GP25 ' Heartbeat LED pin. Automatically configured as the heartbeat pin44 = GP29 ' automatically configured as an analogue input However remember all pin access can use the board independent GP number - e.g. SETPIN GP28,AIN { 1, 0, "GP0", DIGITAL_IN | DIGITAL_OUT | SPI0RX | UART0TX | I2C0SDA | PWM0A,99,0}, // pin 1 { 2, 1, "GP1", DIGITAL_IN | DIGITAL_OUT | UART0RX | I2C0SCL | PWM0B ,99,128}, // pin 2 { 3, 99, "GND", UNUSED ,99,99}, // pin 3 { 4, 2, "GP2", DIGITAL_IN | DIGITAL_OUT | SPI0SCK | I2C1SDA | PWM1A ,99,1}, // pin 4 { 5, 3, "GP3", DIGITAL_IN | DIGITAL_OUT | SPI0TX | I2C1SCL | PWM1B ,99,129}, // pin 5 { 6, 4, "GP4", DIGITAL_IN | DIGITAL_OUT | SPI0RX| UART1TX | I2C0SDA | PWM2A ,99,2}, // pin 6 { 7, 5, "GP5", DIGITAL_IN | DIGITAL_OUT | UART1RX | I2C0SCL | PWM2B ,99,130}, // pin 7 { 8, 99, "GND", UNUSED ,99, 99}, // pin 8 { 9, 6, "GP6", DIGITAL_IN | DIGITAL_OUT | SPI0SCK | I2C1SDA | PWM3A ,99, 3}, // pin 9 { 10, 7, "GP7", DIGITAL_IN | DIGITAL_OUT | SPI0TX | I2C1SCL | PWM3B ,99, 131}, // pin 10 { 11, 8, "GP8", DIGITAL_IN | DIGITAL_OUT | SPI1RX | UART1TX | I2C0SDA | PWM4A ,99, 4}, // pin 11 { 12, 9, "GP9", DIGITAL_IN | DIGITAL_OUT | UART1RX | I2C0SCL | PWM4B ,99, 132}, // pin 12 { 13, 99, "GND", UNUSED ,99, 99}, // pin 13 { 14, 10, "GP10", DIGITAL_IN | DIGITAL_OUT | SPI1SCK | I2C1SDA | PWM5A ,99, 5}, // pin 14 { 15, 11, "GP11", DIGITAL_IN | DIGITAL_OUT | SPI1TX | I2C1SCL | PWM5B ,99, 133}, // pin 15 { 16, 12, "GP12", DIGITAL_IN | DIGITAL_OUT | SPI1RX | UART0TX | I2C0SDA | PWM6A ,99, 6}, // pin 16 { 17, 13, "GP13", DIGITAL_IN | DIGITAL_OUT | UART0RX | I2C0SCL | PWM6B ,99, 134}, // pin 17 { 18, 99, "GND", UNUSED ,99, 99}, // pin 18 { 19, 14, "GP14", DIGITAL_IN | DIGITAL_OUT | SPI1SCK | I2C1SDA | PWM7A ,99, 7}, // pin 19 { 20, 15, "GP15", DIGITAL_IN | DIGITAL_OUT | SPI1TX | I2C1SCL | PWM7B ,99, 135}, // pin 20 { 21, 16, "GP16", DIGITAL_IN | DIGITAL_OUT | SPI0RX | UART0TX | I2C0SDA | PWM0A ,99, 0}, // pin 21 { 22, 17, "GP17", DIGITAL_IN | DIGITAL_OUT | UART0RX | I2C0SCL | PWM0B ,99, 128}, // pin 22 { 23, 99, "GND", UNUSED ,99, 99}, // pin 23 { 24, 18, "GP18", DIGITAL_IN | DIGITAL_OUT | SPI0SCK | I2C1SDA | PWM1A ,99, 1}, // pin 24 { 25, 19, "GP19", DIGITAL_IN | DIGITAL_OUT | SPI0TX | I2C1SCL | PWM1B ,99, 129}, // pin 25 { 26, 20, "GP20", DIGITAL_IN | DIGITAL_OUT | SPI0RX | UART1TX| I2C0SDA | PWM2A ,99, 2}, // pin 26 { 27, 21, "GP21", DIGITAL_IN | DIGITAL_OUT | UART1RX| I2C0SCL | PWM2B ,99, 130}, // pin 27 { 28, 99, "GND", UNUSED ,99, 99}, // pin 28 { 29, 22, "GP22", DIGITAL_IN | DIGITAL_OUT | I2C1SDA| PWM3A ,99, 3}, // pin 29 { 30, 99, "RUN", UNUSED ,99, 99}, // pin 30 { 31, 26, "GP26", DIGITAL_IN | DIGITAL_OUT | ANALOG_IN | SPI1SCK| I2C1SDA | PWM5A , 0 , 5}, // pin 31 { 32, 27, "GP27", DIGITAL_IN | DIGITAL_OUT | ANALOG_IN | SPI1TX| I2C1SCL | PWM5B , 1 , 133}, // pin 32 { 33, 99, "AGND", UNUSED ,99, 99}, // pin 33 { 34, 28, "GP28", DIGITAL_IN | DIGITAL_OUT | ANALOG_IN | SPI1RX | UART0TX | I2C0SDA| PWM6A , 2 , 6}, // pin 34 { 35, 99, "VREF", UNUSED ,99, 99}, // pin 35 { 36, 99, "3V3", UNUSED ,99, 99}, // pin 36 { 37, 99, "3V3E", UNUSED ,99, 99}, // pin 37 { 38, 99, "GND", UNUSED ,99, 99}, // pin 38 { 39, 99, "VSYS", UNUSED ,99, 99}, // pin 39 { 40, 99, "VBUS", UNUSED ,99, 99}, // pin 40 { 41, 23, "GP23", DIGITAL_IN | DIGITAL_OUT | SPI0TX | I2C1SCL| PWM3B ,99 , 131}, // pseudo pin 41 { 42, 24, "GP24", DIGITAL_IN | DIGITAL_OUT | SPI1RX | UART1TX | I2C0SDA| PWM4A ,99 , 4}, // pseudo pin 42 { 43, 25, "GP25", DIGITAL_IN | DIGITAL_OUT | UART1RX | I2C0SCL| PWM4B ,99 , 132}, // pseudo pin 43 { 44, 29, "GP29", DIGITAL_IN | DIGITAL_OUT | ANALOG_IN | UART0RX | I2C0SCL | PWM6B , 3 , 134}, // pseudo pin 44 Edited 2021-08-05 02:41 by matherp |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 5756 |
That's quite possible - it would make sense to just put the most accessed parts in RAM. I suspect that such a diagram would only confuse things even more. It may make things look as if they can be rearranged when in actual fact it's impossible due to the RAM paging system. And I'm already confused enough, thanks. :) Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 5756 |
Nice one, Peter. :) The pin numbering is a minor issue really. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| lizby Guru Joined: 17/05/2016 Location: United StatesPosts: 3027 |
I admit to a degree of confusion. For instance, is there any functional use an MMBasic programmer can make of pseudo pins 42 and 43 being I2C0SDA and I2C0SCL or UART1TX and UART1RX? { 42, 24, "GP24", DIGITAL_IN | DIGITAL_OUT | SPI1RX | UART1TX | I2C0SDA| PWM4A ,99 , 4}, // pseudo pin 42 { 43, 25, "GP25", DIGITAL_IN | DIGITAL_OUT | UART1RX | I2C0SCL| PWM4B ,99 , 132}, // pseudo pin 43 PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on fruitoftheshed |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8601 |
The memory utilisation on the Pico is as follows: 32Kbyte for the hashed variable table 160Kbytes to be shared between the Basic program, GUI controls, and MMBasic working space, arrays and strings. As mentioned above. The rule is that the MMBasic working space array and string area must be equal or greater in size than the program space in order to be able to edit the program. The remaining RAM is used for the stack, heap, system variables and loading the most time-critical bits of MMBasic. The stored program in RAM and as saved to flash is tokenised exactly like the MM2 with all comments intact. You can use Autosave or xmodem with crunch to reduce program size if you edit offline using MMEDIT or similar |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8601 |
Yes on board that exposes all the GPIO pins (i.e. not the Pico) e.g. here Edited 2021-08-05 03:12 by matherp |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 5756 |
@lizby All those non-brought out GP pins are useful in their own way on the PicoMite. If you want to go hardware hacking on the PCB you can bring them out. Peter will have restricted some to read or write only because of the fact that they are hard-wired to onboard stuff. In theory you *could* allocate them to other things, they are actually normal ports, but on the Pico and PicoMite there's no point. You can now get a RP2040 on a little "breakout" board, where you could do what you want with them. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 3856 |
My Pico is currently buried under a heap of weather station PCBs and other toys from Lewis, would someone mind telling me if the PicoMite has the CALL command like the CMM2 ? and if not then would it be possible to add it Peter? Best wishes, Tom Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8601 |
Does now PicoMiteV5.07.00b11.zip |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 5756 |
It's not listed in the commands, Tom and I don't think there's room in the command table for it. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 5756 |
Yay! :) I posted too soon... You're on form tonight, Peter. :) EDIT: Does it include CALL() too, Peter? I just happen to have the TINAM open for editing. :) Edited 2021-08-05 04:07 by Mixtel90 Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 3856 |
Thank you Peter. Better luck next time Mick  .Best wishes, Tom Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8601 |
No: no more function slots available |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 5756 |
Ok, thanks. :) Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| Page 8 of 13 |
|||||
 Print this page |
