 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 : revisiting an old idea...
| Author | Message | ||||
| robert.rozee Guru  Joined: 31/12/2012 Location: New ZealandPosts: 2350 |
i seem to remember, quite a few years back, the idea being raised of pairing an MX170 with an external SPI or I2C flash chip. the external flash would then be used to hold the tokenized basic program. at the time the idea was dismissed with the comment that using external flash to hold the basic program would be just too slow. since then we have the pico/RP2040 using exactly this approach. i'm just wondering if this idea would be worth revisiting, now that MX170s are starting to become available again? shifting the basic program storage to external (SPI or I2C) flash would: - consume 2 or 3 I/O pins, - free up approximately 50k of onboard flash, - provide additional (external) flash space for data storage. the 50k of onboard flash freed up could be used for implementing double-precision floats, and a file-system driver for the external flash. this would then yield a 2-chip "micromite Mk3" that sat somewhere between the Mk2 and the 'picomite'. an interesting idea? can we get fast 2-wire SPI flash chips? cheers, rob :-) |
||||
Quazee137 Guru Joined: 07/08/2016 Location: United StatesPosts: 571 |
yes interesting  Quazee137 |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 9129 |
Chips like the rp2040 and esp32 use a quad or octo spi bus with an in-built cache to get data from the external flash. They also map the flash into processor memory. The MX170 can't do any of this. The result, if possible at all, would be catastrophically slow. Edited 2023-07-13 17:32 by matherp |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2350 |
the MX170 starts out considerably slower than a picomite - 40MHz (default) vs 133MHz (default). this pretty much negates the quad SPI. and the RP2040 is also executing portions of the interpreter from the same SPI device, which the MX170 would not be doing - the interpreter would be running 100% onboard. mapping SPI flash into processor memory is just a convenience, it doesn't magically get one an extra speed boost. i recall someone once saying that the RP2040 was a trash chip and would never be able to run mmbasic at any useful speed. then someone came along and proved the first someone wrong. it would be an interesting experiment if the same held for the MX170 + external SPI flash. cheers, rob :-) |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 4247 |
Robert, IMHO the strength of the MX170 is that it is single chip and through hole. Pairing it with a SMT SPI flash chip would require development of a module similar to the pico, or arduino nano, or .... (the quad or octal bus flashes are only available in SMT). And the whole interface must be programmed in SW (no HW support in the MX170). Going to single databus pin SPI is possible in through hole components. The idea of having the (basic) interpreter in ROM and the basic program in serial flash is not new. It has been used before (with a 20MHz PIC 16Fxx chip) commercially. But it was really slow, integer basic only. Volhout Edited 2023-07-13 17:49 by Volhout PicomiteVGA PETSCII ROBOTS |
||||
Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 6798 |
That is a point - the external flash is running at MMBasic instruction fetch speed, not CPU speed and you never write to it during runtime. You would probably be reading a line at once into a RAM buffer then processing it. The only major dalay is in storing the tokenized program into external flash in the first place. I wonder if it would be possible to use two RAM buffers and copy into them alternately, process one while pre-fetching the next line? This is getting a bit too far ahead though. :) Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 4247 |
Aha, It took some time to find, but the module that used this architecture, was the "BASIC STAMP". Appart from the real "low power" mode.. is there anything else that the MX170 is better at ? Don't say "the ADC", since the MX170 has only 10 bits, The pico (including the fault in the pico ADC) is still 9 bits, and with minor averaging better than the MX170's ADC. The pico simply outperforms MX170 on all aspects, except low power. And the smaller pico modules available have similar footprint. Volhout Edited 2023-07-13 18:08 by Volhout PicomiteVGA PETSCII ROBOTS |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 6798 |
I never used that, although I remember the adverts for it. Struck me as being a rip-off, TBH. :) It was actually the PicoMite's grandfather.... :) Edited 2023-07-13 18:03 by Mixtel90 Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2350 |
a 20MHz PIC16F has an instruction speed of 200nS (from: https://www.microchip.com/en-us/product/PIC16F877), while a PIC32MX typically executes instructions in a single clock cycle - at 40MHz this translates to 25nS per instruction, or 8x faster than the PIC16F. i'm suggesting a standard 8-pin DIP SPI flash chip, something that can be wired up to the MX170 on a solderless breadboard with just a few jumper wires. i still maintain the experiment would be interesting. cheers, rob :-) |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 9129 |
So do it  |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 6798 |
But the CPU speed isn't the most important factor here. The external flash contains the MMBasic program *only* so runs at MMBasic speed, which is far slower than the CPU. In fact DO:LOOP UNTIL GP0=1 only has a single external flash access yet runs fast as it's running from a RAM buffer. When GP0=1 the next line will be fetched from flash and executed. TBH I wouldn't even consider any of this unless 8-pin DIL flash chips were available. Being locked into SMD isn't my idea of fun. :) How long they'll be available for is something else though. Edited 2023-07-13 18:17 by Mixtel90 Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 4247 |
Mick, Just assume a "GOTO 123" happening on the SPI flash (or for that matter, a call to a function). Scan through the whole program to find the function ? Or pre-parse the whole program before executing RUN ? It is a nice academic excersize. But practical implementation will not satisfy, AND, you would loose the only strong point of the MX170: low power. A SPI memory chip in read mode (check it !) consumes 10 - 20mA. Add that to the MX170 power, and you are almost at the power the pico uses.... Nice academic exercise.... Volhout PicomiteVGA PETSCII ROBOTS |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2350 |
too many other projects on the go... plus it would likely take me a year or two to complete the task. and in the interim, microchip may decide to release an MX190; in principal the MX190 already exists in the form of the PIC32MX170F512L (an MX170 with 512k of flash, 64k RAM, 100-pin TQFP), it would just require a die-shrink and a repackaging to complete. btw peter - i'm not suggesting you do this, you have already done more than your fair share with the 'picomite'  i was perhaps hoping, though, that the idea may tempt geoff!cheers, rob :-) |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 6798 |
That operation takes place anyway. I don't know how it's normally handled, but I *assume* that the destination lines for SUB, FUNCTION and GOTO are pre-parsed into a hash table or something in the existing system otherwise routines at the end of the program would take much longer to call. No, I don't think this is a brilliant idea as you'd also lose precious IO pins and have to add a second chip, making the combination bigger than a RP2040-Zero. However, I don't think it's as slow as I originally thought it would be. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 9129 |
Do loops, for loops, gosub, goto, read, if, all scan ahead. To read the flash you have to send an address (at least 16 bits) + read the data. Max SPI speed on a 40MHz MX170 is 10MHz so 0.8uS per character just in the read assuming zero inter-character. As I said above "The result, if possible at all, would be catastrophically slow." The RP2040 is already very slow in flash access compared to a chip with in-built flash like the MX or STM32. That is why I have to use big chunks of RAM to contain the interpreter. It is running quad spi @ 60Mhz+ with a RAM cache and the flash memory mapped. The latest ESP32 run octo flash @ 80MHz - just the 64 times faster than the MX170 could do. Edited 2023-07-13 18:51 by matherp |
||||
Grogster Admin Group  Joined: 31/12/2012 Location: New ZealandPosts: 9308 |
I find quad-SPI and now modules using octo-SPI to be interesting. Is this not reinventing the wheel to some extent? Octo-SPI seems like the parallel data-bus all over again, but slower!  Yea, I know - there are differences, but it's interesting that we went from parallel, to serial, and now we're adding more serial lines again to get more speed and more data throughput per clock - just like the old parallel bus.  Smoke makes things work. When the smoke gets out, it stops! |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 6798 |
You need 21 address lines for 2 1MB address space and, of course, a pin for each data line. Then, as a minimum a r/w signal. Your microcontroller very quickly becomes a very hairy golf ball by the time you have buffers on that lot - and it runs at 120C. :) Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
 Print this page |
