 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 : Armmite roadmap and other Micromites
Page 1 of 2   |
|||||
| Author | Message | ||||
| matherp Guru  Joined: 11/12/2012 Location: United KingdomPosts: 8578 |
There have been a number of requests recently for additions to the Armmite firmware so this thread is intended to clarify my position. There are two main Armmite versions Armmite L4 Armmite H7 and one "one-off" version Armmite F7 The latter was solely to support a number of people who had bought Nucleo-F767ZI boards and will not be updated. The Armmite L4 supports STM32L43x chips in 32, 48, and 64-pin variants, STM32L476 64-pin and STM32L496 64-pin The Armmite H7 supports the STM32H743 and STM32H753 144-pin chips With the exception of the 48-pin chips, development PCBs are available at very low cost in the Nucleo series from ST: NUCLEO-L432KC, NUCLEO-L476RG, NUCLEO-H743ZI. I have developed a small flexible PCB for the 48-pin chips and this is referenced in the Armmite-L4 manual. The Armmite L4 is specifically targeted at battery powered applications where the low power consumption of the L4 chips is ideal and the Armmite L4 firmware supports power saving operations and low power displays. It also has the specific advantage, compared to the MM2, of a full file system implemented on a flash memory chip. The Armmite H7 is the fastest single chip implementation of MMBasic and is targeted at applications with intensive memory, processing and graphics requirements. Where do the Armmites fit in context of the other MMBasic implementations? MM2: very cheap, DIP package available, good for nearly everything, "official version" with support from Geoff - the goto version. Additional future functionality now limited by available flash but expandable with CFUNCTIONS. Armmite L4: same speed as MM2, more in-built functionality, flash file system, optimised for battery use, in-built RTC, DAC, and support for large selection of small displays. Very cheap development PCBs available with no extras needed. Firmware can be programmed with no special hardware. Chips range from medium price (L43x) to comparatively expensive (L496). Additional future functionality now limited by available flash on L43x chips. MM+: medium price 64 and 100-pin chips, full SDcard implementation, advanced graphics with full GUI implementation, "official version" with support from Geoff, stand-alone use with screen and keyboard. 2.5x faster than MM2. Needs dedicated PCB but lots of versions available. MMX: comparatively expensive 64, 100, and 144-pin chips double speed of MM+ (5x MM2), large memory, and more built-in functionality. VGA support (not 64-pin) and USB keyboard for stand-alone use, high performance 16-bit graphics drivers - embedded controller but can also be considered as a Colour Maximite+. Needs dedicated PCB but several open source versions available. Armmite H7: comparatively expensive 144-pin chips but very cheap development PCBs available with no extras needed. Firmware can be programmed with no special hardware. 2x performance of MMX (10x MM2)and more built-in functionality. USB keyboard support. Huge memory. Pi-cromite: Very fast (pi-3), cheap (Pi-Zero). Web connectivity. HDMI support. Full Linux integration. Limited I/O. This is the background against which I evaluate requests for functionality. SDcard support and SSD1963 support cannot be implemented on the current Armmite L4 as there isn't sufficient flash available. A new version for the L476/L496 could be created to include these but this would overlap with the MM+/MMX and would be another version to support so that won't happen. Likewise, a version based on the STM32F4 or STM32F7 would achieve nothing significant that isn't already covered by the MM+/MMX. ST do not have a line of 100-pin Nucleo PCBs so I won't be supporting 100-pin as making a custom PCB for 144-pin is no harder than 100-pin and in any case 100-pin MM+ and MMX are already available. I did get a request for a FREEFLASH function on the Armmite L4 recently and as that is specific to that port and adds useful functionality it was included. I also added a SYNCH command that writes any buffered file I/O so that logging applications to the flash chip can be certain of operating with no data loss. File transfer to and from the flash chip can easily be achieved using the filemanager in MMEDIT or the flash chip can be socketed which makes it easy to replace a "full" one mimicking SDcard usage. In general, where possible I will try and implement requests that support the "niche" where I am targeting the port but am less likely to consider requests that seek to extend any of the versions to be "one-size fits all" which simply won't and can't work. |
||||
CaptainBoing Guru Joined: 07/09/2016 Location: United KingdomPosts: 1985 |
Good post Peter. Is it worth pinning this so it is persistent and the place to refer new-comers/the confused (and I include myself in that last) |
||||
sagt3k Guru Joined: 01/02/2015 Location: ItalyPosts: 313 |
Thanks matherp, useful roadmap that will avoid useless requests in the future. Antonio |
||||
| lizby Guru Joined: 17/05/2016 Location: United StatesPosts: 3013 |
This is a very comprehensive range of chips and capabilities. I very much appreciate the work which has gone into the Micromite family, and the work which is entailed in keeping it updated across platforms, especially for the STM series which includes the Nucleo boards--a godsend for those who don't want to solder SMT chips and don't have bigish budgets. That said (and I don't in any way wish to seem to depreciate the work done), there seems to me to be one gap in the middle of the STM range--and I am willing to undertake trying to fill it. I'm talking about a 64-pinner with GUI and SDCard. If there were a "H"-series Nucleo board with 64 pins, that would do the trick, but there isn't. The part that would seem to fit the bill is the Nucleo F446RE with 64 pins, 180MHz, 512KB flash, and 132KB RAM. My C programming is rusty, but I've made (trivial and guided) changes to the DOS and Pi mmBasics, and I'm willing to take a stab at porting to this board and maintaining the port. I have the H7 code, and will get the L4 code as soon as Peter releases it. If he would also provide the one-off F-series code, I think I'd have a fighting chance at being able to produce a working port. (In any case, thanks for opening up the STM Nucleo board to mmBasic.) I wouldn't bring this up (again) if I weren't willing to attempt it myself. (One other thing I'd like to see is support for touch on the Pi-cromite for HDMI screens which allow for it.) (One omission in the list is DOS--which can allow for a very speedy development cycle.) PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on fruitoftheshed |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8578 |
It is rumoured that later this month the STM32G4 range will be announced. These will be an upgrade to the F4 which is getting long in the tooth. The L4 code won't really help for the F4, it is much nearer the H7. My process for a new CPU For an new STM32 CPU you have to start with CubeMX to create a new project and set up clocks etc, the F4 is much simpler and less flexible than the L4 so things like CPU speed changes will be much harder (H7 and F7 are single speed). It is pretty difficult/impossible/not recommended to change CPU in an existing project other than within the same sub-family (i.e. the same datasheet). Then add the MMbasic code into the version of main.c created by CubeMX and move across all the MMBasic files into the new project. Patch out all things which create compilation errors, mark these for later correction Patch out all MMBasic startup until later Set up the pinouts. Sort out the RAM mapping differences and implement them in memory.h and the loader definition file (something.ld). Get console I/O working Now start unpatching MMBasic startup fixing any issues as you find them. At this point you should have MMBasic working at the command line, saving a program to flash comes next. Sort out the flash memory differences (this is a biggy) and implement them in flash.h, flash.c and the loader definition file (something.ld). Sort out timers so they are correct for things like DS18B20 Finally, fix the various I/O differences, Digital, PWM, SPI, I2C, Count, IR, Analog (always the most difficult) Check for any marked patched out code and correct. NB: The 64-pin L4 and F4 are not exactly pin compatible as the F4 still has a VCAP. The G4 will be different again (rumoured to only need 1 VCC and 1 GND pin) |
||||
| lizby Guru Joined: 17/05/2016 Location: United StatesPosts: 3013 |
Thanks for that outline of the process. Again it suggests the great scope of all the work you have done for mmBasic with the STM32 series. The rumored G4 sounds interesting. Are the Nucleo boards traditionally released simultaneously with the microprocessors as reference designs? Can you provide access to the F7 source? Being able to compare H7 to F7 would be a big help. And even if L4-64pin setup is significantly different from F4, just seeing the L4-64 setup code would probably be suggestive. PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on fruitoftheshed |
||||
darthmite Senior Member  Joined: 20/11/2011 Location: FrancePosts: 240 |
@lizby , you can ask for access to the F7 /H7 sources from the MMBasic page here : MMBasic Cheers. Theory is when we know everything but nothing work ... Practice is when everything work but no one know why ;) |
||||
| lizby Guru Joined: 17/05/2016 Location: United StatesPosts: 3013 |
darthmite--H7 is there today, as I had found before, but not, so far as I can tell, F7 or L4. PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on fruitoftheshed |
||||
| darthmite Senior Member Joined: 20/11/2011 Location: FrancePosts: 240 |
You have to get the ARMSource.zip , in it you will found the "MMBasic-STM32F746". For the L4 i dont know , i doesn't have this MCU  Cheers. Theory is when we know everything but nothing work ... Practice is when everything work but no one know why ;) |
||||
| lizby Guru Joined: 17/05/2016 Location: United StatesPosts: 3013 |
I haven't looked at it, but as far as I know, the ARMSource.zip code is years old--MMBasic V4.5--and incomplete. PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on fruitoftheshed |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 3654 |
I thought the 746 was never available so long ago as V4.5 John |
||||
| lizby Guru Joined: 17/05/2016 Location: United StatesPosts: 3013 |
That too, hence, for my purposes, "incomplete". PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on fruitoftheshed |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8578 |
Geoff has far more to wory about than listing my Armmite L4 source so it will have to wait. As I said previously , there is nothing in the L4 that you will learn for a port to the F446 over and above the H7 source. The F7 is just a minor variant of the H7. 90% of the files are identical. The only differences are main.c, external.c, flash.c, and otherdisplays.c. Everything else is dealt with by a bit of conditional compilation. Header files are now identical. |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 3654 |
I meant: your statement about it being years old and V4.5 is wrong. Had it been right then inevitably it could not have 746 source. The current generally available source is likely always to be out of date until development ceases. If you'd rather no more development be done then that would fix the issue in a daft way! Always bear in mind Geoff's lengthy statement about open source. John |
||||
| lizby Guru Joined: 17/05/2016 Location: United StatesPosts: 3013 |
Do you check the source before accusing someone of being "wrong"? I was referring only and explicitly to the ARMSource.zip code, and I was paraphrasing the automated email which was sent to me 2 days ago in response to my making a request after darthmite's suggesting that the F-series and L-series code was there (since it had been a while since I had downloaded the H7 source). I paraphrased the email, but now I'll quote it: "Source Code for the ARM Cortex-M7 Version (about 3MB) This is a port by Uwe Becker and Fabrice Muller of MMBasic V4.5 to the ARM Cortex-M7 microcontroller running on the STM32F746 Discovery evaluation board. The package includes the full source, a compiled version and documentation. Note that all support queries should be directed to either Uwe or Fabrice on the German webblog (http://mikrocontroller.bplaced.net/wordpress/?page_id=5487) where you can find the binary for any later versions or, for English speakers, The Back Shed forum (http://www.thebackshed.com/forum/Microcontrollers). Download link: http://mmbasic.com/Download/1290/ARMSource.zip I said nothing about the other source being V4.5, and I neither made nor implied nor felt any criticism of anyone concerning the state of the source which is available--I'm grateful for all of it. My biggest problem with a port to the F446RE is complete unfamiliarity with the tool chain. (And extensive changes are needed to IOPorts.h relative to the H7. I appreciate the work which has been done to simplify ports across STM32 targets.) Again, I did not criticize anyone with respect to the source code--merely paraphrased (correctly, I think) what the email said about the old ARMSource.zip code in response to what darthmite had said. I apologize for the diversion my original post to this thread has been responsible for. PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on fruitoftheshed |
||||
goc30 Guru Joined: 12/04/2017 Location: FrancePosts: 425 |
Hi Peter I don't remember if I ever asked you the question my question is about ArmiteH7 and GPS functions you give gps status through the function "GPS(VALID)". Value is 0 or 1 in fact gps has 4 states - no response (gps is out or broken) - gps send frames but all data are null - gps send frames but only time is sending, all others data are null - gps send frames with "valid" flag can you change return value of gps(valid) function with this 4 states, like for exemple 0 = no gps 1 = gps send frames null 3 = gps send time frame 7 =gps is ok thank Peter |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 3654 |
Obviously I did not have that information and it appears not to be about the MMBasic which is the subject of this thread. I suggest you take such a different topic to a separate thread. John |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8578 |
My current version of IOPORTS.h attached. Supports STM32H743, STM32F767, STM32F407, STM32F405, STM32L476, STM32F446, STM32L496 and probably lots of others. Add the symbol STM32F4ports in the project properties/setting/preprocessor definitions to enable F4/L4 pinouts. 2019-04-05_214031_IOPorts.zip This includes what I think is a pretty optimum pinout for 64-pin chips in general with scope for efficient SSD1963 use over an 8-bit parallel I/F (16 bit for 100/144 pin chips) |
||||
| lizby Guru Joined: 17/05/2016 Location: United StatesPosts: 3013 |
Thank you very much for that. I didn't know about the "STM32F4ports" symbol possibility (so much I don't know). I'll see how close I was getting with my stab at IOPorts.h. PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on fruitoftheshed |
||||
| sagt3k Guru Joined: 01/02/2015 Location: ItalyPosts: 313 |
Hi to everybody Here the announcement of STM32G4  Antonio |
||||
| Page 1 of 2 |
|||||
 Print this page |
