 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 : High speed Micromite: use case?
Page 1 of 2   |
|||||
| Author | Message | ||||
| matherp Guru  Joined: 11/12/2012 Location: United KingdomPosts: 10315 |
I've been working on porting the Micromite code to the STM32H743. This is a Arm based microcontroller that runs at a 400MHz clock speed ( nearly 10x the MX170). Tests using the various benchmarks show that the performance of MMBasic is very much in-line with the clock speed - it is fast! The chip also has other advantages: 16-bit ADCs 2 x 12-bit DACs Hardware doubkle precision floating point 512kB usable RAM 512kb program size High-speed SD card support (4-bit parallel i/f) In addition, and unlike Microchip, STM produce highly functional low cost development boards. The Nucleo PCB pictured in this thread only costs c£20. The port has been intellectually interesting in that it uses a new technology and keeps the old grey cells active but before I go too much further I'm interested in whether there is actually a use case for the port. What I don't intend to consider is using the port as the basis for a SBC. The Micromite eXtreme is already close to this and I believe Geoff is working on a new generation Colour Maximite. So the STM32 would be a very fast Micromite with a cheap development environment readily available and "better-than-PIC" peripherals. Compared to the Pi-cromite, the STM32 obviously has less network connectivity but has much better direct connectivity (pins, ADC, etc). Speed is roughly equivalent to the Pi-Zero but as there is no OS is much more suitable for real-time applications with immediate switch-on. Is this interesting? - what would you use it for? - is it worth making a backpack PCB for the Nucleo to allow easy connection to a screen and SDcard? - if so what else should the backpack support? I'm very interested in any and all views. |
||||
MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
Interpreted Basic will always be about 50-100 times slower. I think the Micromite does not need that much of speed. If you want to get complicated (large programs, lots of data) and fast, any interpreted language will start to falter. One of the reason why CFunctions are used for anything that needs speed. Would the ARM be so fast that CFunctions are obsolete. With a different processor there might never be a chance to use CFunctions. Is a 5000 line or larger basic program still manageable without a good IDE? Without any debugging facility it becomes really difficult. If i had time i would add single stepping and breakpoints to MMBasic before anything else and integrate it with Visual Studio or Eclipse. Microblocks. Build with logic. |
||||
goc30 Guru Joined: 12/04/2017 Location: FrancePosts: 435 |
I will ask the impossible: install the interpreter in a real time environment (freeRTOS), as a task. That way we could run the interpreter and other tasks written in "C" |
||||
Grogster Admin Group  Joined: 31/12/2012 Location: New ZealandPosts: 9610 |
Speaking as someone who uses A-LOT of MicroMite chips these days, I offer the following observations: 1) The current line-up of MM chips are plenty fast enough, especially when combined with Cfunction/Csubs to do the stuff that NEEDS the speed(like LCD's). 2) I've played with the MMX, and it is super-duper.  Based on what it can do, if I ever needed a really fast MM, the MMX is the chip I would go for.3) In the real-world environment, it should be noted that striving for every last uS of speed is really just academic, as in the real world, no-one would notice anything other then a quite drastic speed difference between one chip and the other. 4) In production, I have never needed anything better then the MM+ chips at this stage. The MMX is useful for native VGA, mouse support and WAV file playback, but GENERALLY SPEAKING these days, most people much prefer a touch-screen, so mouse and VGA screen, while a nice touch, are not really selling points - the touch-screen always is though, so I have never needed to use the MMX in production - yet. These are only MY observations - not intending to upset or offend anyone who like the STM versions, the ARM versions or the Pi versions. All of these are superb to have and give people MANY choices of hardware to use MMBASIC on. An example of the latest PCB I designed, was one that could interface to a 3G cell-phone modem, and simply switch relays off and on using text messages sent to it from any other cell-phone(I will put up a thread about this soon). This was easily handled by a 170 MM chip - no need for anything faster then that. It sounds like I am trying to rain on the 'More speed!' parade, but I really am not. It's just that I feel you need to actually step back and ask yourself if you really NEED that extra speed. If you really do, then fine. But most of the time you don't. Even considering interpreted BASIC is 50-100 times slower then C(in MB's words), because MMBASIC runs so much faster then older BASIC's ever did, to the outside world, they certainly don't appear to be slow or sluggish. Something that COULD be said of the old BASIC's due to the fact that most of them only ran on CPU's clocked at about 2MHz, and then you put the interpreter overhead on top of that.....  Not really such an issue these days. Yes, technically speaking, MMBASIC is still interpreted and thus vastly slower then C, but not so anyone in the real world would really ever notice if you see what I mean. All this is my 2c only. Smoke makes things work. When the smoke gets out, it stops! |
||||
bigmik Guru Joined: 20/06/2011 Location: AustraliaPosts: 2950 |
Hi Peter, My first response was WOW!!! But on reflection, it might not be worth your effort to compile a Version for that chip.. From my perspective I would prefer an HDMI and k/b and mouse (maybe a single USB unifier like the MS keyboards) interface board. God knows I cant program in C so the extra speed `could’ help me in writing code that I need to `bit-bang’ but then most of my code (when I actually do something) is polled and action-reaction like. Ie. Sensor triggered... OK lets do something.. If it takes 100ms to respond... no big deal for me.. I would like to see it done and I know I would buy a board to play with it but really I doubt I would use it.. the cheap sub $10 MX170 will still be my main toy. Regards, Mick Mick's uMite Stuff can be found >>> HERE (Kindly hosted by Dontronics) <<< |
||||
panky Guru Joined: 02/10/2012 Location: AustraliaPosts: 1114 |
Hi Peter, Like others, I don't have an immediate need for more speed but I do see benefits of having a high speed variant of the Micromite that also has CFunction capabilties. It is my understanding that the MMX version can't make use of CFunctions so a version on the STM that could easily get down into sub uSec areas via CFunctions would be a usefull addition to the stable. One of the greatest benefits of the Micromite/Maximite environment is the ability to simply do very complex graphics that are common across a wide range of platforms. To be able to move a multipage graphics menu interface from a MM+ right through to a MMX, Picromite or STM where speed is an advantage, to me is one of the single most usefull features of the Micromite. Without in any way wishing to start another C versus Basic flame war, the task of trying to do this at C level versus Basic level is daunting to say the least. So to me, the additional speed available from the STM would negate my need to learn and become proficient in C. Thus I feel the most likely area the STM would be best suited for would be as the basis of an instrumentation platform (complex timers, function generators, and so on) but with the ease and simplicity of utilising the GUI environment of the Micromite for user interface. My 'wish list' for the STM if you do intend to go ahead with it (in order of preference) would be:- 1. A backpack style PCB along the lines of the ones you have previously designed with both ILI and SSD connections. 2. Close on the heels, a full Bluetooth/WiFi integration both at hardware (on board) and MMBasic level (the much touted 'Internet of Things' seems to be an area that is hard for hobbyists to get into and this would make it much easier). 3. A continuation and extension of the GUI functionality As a final observation and just my own opinions, I would generally go with Grogster in that a touch screen interface on an LCD display is the way to go - keyboard and mouse are nice but that's what PCs are for and VGA is very limited - if external display were considered a must have, then an HDMI interface is really the only way to connect to modern screens. Thank you for the efforts you put in to the Micromite world - I have several of your boards and they work a treat - I look forward to see what you come up with next  Best regards, Doug. ... almost all of the Maximites, the MicromMites, the MM Extremes, the ArmMites, the PicoMite and loving it! |
||||
TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6283 |
I have been playing with the Nucleo STM32H743 board. At $30.45 plus GST from element14 it is very good value. Programming Peters binaries is ridiculously fast compared to the PIC options. I don't have any specific task for it but I don't have one for the MMX either. The speed comes in handy when you are trying to sample analogue signals, and decode Grogster's pager alarm etc. I can live without a backpack board although it would eliminate the rats nest I usually have. If Ethernet can ever get working, the uses escalate in my mind, but there is always the RPi. (I am not a fan of WiFi) Things which will help in the short term are analogue input and perhaps the RTC Jim VK7JH MMedit |
||||
| flip Senior Member  Joined: 18/07/2016 Location: AustraliaPosts: 114 |
Firstly thanks for the quantity and quality output Peter. I'd be keen to see MMBASIC running on whatever cheap stand-alone hardware as fast as possible. Since August when I shared early prototypes for a general-purpose code builder & text-based GUI, I've developed the builder to construct an OO muti-tasker with GUI (+ primitive DB + OS elements) to share that runs as a single MMBASIC program - so needless to say it's performance is average at the moment (and maybe futile to hope it will ever perform as a useful working system  ), but once I'm happy its reasonably functional it could be a good basis for a machine-code port (or maybe work OK with c-functions for critical components)So in short basically I'd love to have the fastest basic /SD performance possible on non-DOS environment. Appreciate Geoff and Peter's efforts and everyone's great contributions/posts to date ! Regards, Phil |
||||
Quazee137 Guru Joined: 07/08/2016 Location: United StatesPosts: 593 |
Like most every one else doing small customized type of controllers the 170 has done so much. Added speed is good but more program space!! Also SD is great but with an 8 pin 128k by 8 FRAM one could put the Cfunctions there like a Rolodex file and pull in the needed function to scratch pad ram. The addition of the SPI driven LCDs with touch are the best GUI for todays users. I started with the 1.8" and now using a 4" on matherp 170 hat stand. "I have a 5" backup display on my dinomite mimi. switch between looking behind me and the speed, volts, amps and travel time in battery" will be moving over to RPi ZERO W as it has color composite video and MMBasic! for my bike. So far anything mattherp touches is GOLDEN and I sure that there are STM32H743 users out there the will love the speed and ease of MMBasic. I do not miss the code, compile, debug cycle that MMBasic frees us from. SO I SAY THANK YOU matterp and Geoff for doing the HARD parts. Quazee p.s. is there any 28pinners in that family of chips  |
||||
retepsnikrep Senior Member Joined: 31/12/2007 Location: United KingdomPosts: 134 |
This is an interesting idea and I like basic so extra speed is good. One plea though if a pcb and or backpack type system is designed can it fit a standard enclosure of some sort. Enclosures are one of my pet hates and we can't all 3d print something suitable. Shabby boxes etc and enclosures seperate a good project from a great one. So something nice, boring grey or black abs with a proper screen cutout and as small/thin as practicable to take your new board/backpak. Gen1 Honda Insights. |
||||
| Micro-80 Newbie  Joined: 03/03/2017 Location: Russian FederationPosts: 26 |
STM32H743 + mmbasic + 16bit ADC + DAC + CFunction for fast interrupt routines + GUI + LongString variables + fast COM ports with COM-to ETHERNET (or Wi-FI) = practically all type of applications. It's a dream! |
||||
| Bill7300 Senior Member Joined: 05/08/2014 Location: AustraliaPosts: 159 |
Sometimes the intellectual interest and challenge is reason enough to invest the effort and I would suggest that a port of MM to the STM32H743 would fall into that category. I will certainly get one to play with, so please continue, Peter. Bill Bill |
||||
lew247 Guru Joined: 23/12/2015 Location: United KingdomPosts: 1702 |
I like the idea, but can't think of a use for the speed other than video |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4044 |
A short list: 1. the speed would allow things such as: 1a. logging each statement in a buffer - which would allow greater understanding of a program and/or tracing why it fails 1b. data acquisition of data which now would be missed 2. the extra RAM allows all manner of things such as: 2a. the above tracing/debugging 2b. data acquisition that now would overflow the rather limited buffers 2c. connecting bigger (higher resolution etc) displays (the extra speed is needed here, too) 2d. more strings / string arrays (this may be more a case of more ROM, too) 3. the better I/Os look useful, such as: 3a. better ADC/DAC 3b. far better USB Item 3b strikes me particularly, as USB is everywhere (despite all its shortcomings). Not that more support of USB is perhaps an immediate goal but at least it becomes doable (though RPi may be an alternative). There are more but this stopped being short! John |
||||
Zonker Guru Joined: 18/08/2012 Location: United StatesPosts: 767 |
I also agree with John S. ... I like the bigger bit depth of the A/D and D/a's..! Also, having a MMBasic port to an ARM class Micro is awesome...  Maybe there is enough room to add more "built in" GUI objects... Like Gauges, (round and Bar) maybe a drop down menu system... lots of possibility's.... Keep going Peter..!! |
||||
HardingJohn Regular Member  Joined: 28/07/2017 Location: AustraliaPosts: 78 |
I have written a very large MMBasic program for the MMX 252 Mhz 144 pin chip, but it is simply not running fast enough. It uses SPI and the W5500 chip to provide TCP Modbus connectivity, and has to handle many Modbus slaves. To speed up the Ethernet, I want to add some functions to utilise the internal Ethernet RMII driver in the PIC32MZ EFH chip and possibly the EFM chip's cryptographic capability. Is it possible to get the source code for the MMX MMbasic, so I can added the C functions needed. Thanks John Just know enough to get me in trouble, but not quite enough to get me out. |
||||
| Octatron Newbie Joined: 01/04/2015 Location: United KingdomPosts: 27 |
It would be interesting to see camera support for the STM32H743 board in a similar way as on MMX with a view to use it for Slow Scan TV (SSTV) as used in amateur radio to create a stand alone device that could be connected to any transmitter/receiver. Keep up the good work Peter. Roy |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 5091 |
MMbasic on ARM.... dear matherp, It is always nice to run the MMbasic source code through a compiler for ARM. And as a proof of concept you succeeded already. It boils down to ironing out all the secondary and IO functions in MMbasic. A non trivial task and to get it all right will require a lot of testing/testers and effort from your side. Unless you want to pull this off on your own of coarse. To make the effort pay (no $$ but in satisfaction) you would like a large user group, or small group of enthusiasts. Both cases it requires - focus on a specific ARM chip (the world is too big). - have a platform that is embraced by the user group. If the user group is perfectly happy with the ST demo board (costing 20 dollar) that is fine. So the question is more a question to yourself - can you bring the effort to pull it off ? - can you find a user group ? - what would they get enthusiastic about. I for myself have sufficient platforms that have microcontroller pins (arduino, picaxe, micromite) and would get enthusiastic about a platform that has at least a set of basic interfaces. in example, that is why I use Arduino more than picaxe...it has a good USB interface and has it's USB power to run the board. Picaxe on the other hand requires a specific cable, and a separate power supply. I have seen in the picture the nucleo board has USB interface, so that is fine. But now it comes down to what people do with it. One post was about Modbus. I expect RS485. This forum member would get enthusiastic when a RS485 is present on the platform itself. Not "it can be wired to pin 13 and 67", but present. Similar to what CGColormax has,. It is a board that has certain interfaces ready for use, arduino pinout for shields, and serial interfaces. You can imagine some people want analog inputs. What ? 0-10V ? 4-20mA ? If you see what people do with MMbasic on the platform, they drive relays or solid state switches, control motors, read inputs, many play with LCD's. The closer you get the HW and SW platform to this (yes, that most likely will require designing HW) the better chance of success. Resuming: a sole port of MMbasic to a ST reference board may not get enough leverage with users to motivate you to pull it off of the end. On the other hand.... Now you are just having fun, without any comitment, and we see where it ends up.... If you don't have fun, it's going to be a dead end anyway... Keep up the fun.... PicomiteVGA PETSCII ROBOTS |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10315 |
Thanks all for the interesting input - lots to think about. Current status is that the Armmite H7 port is nearing MMX functionality (other than VGA) but is considerably faster and with more memory. It seems to be very stable and I've run the very processor, memory, and I/O intensive sprite demo for hours without any issue. What is definitely the case is that the STM development environment is miles ahead of Microchip. STM32CubeMX sets up the peripherals for you and then this code can be easily incorporated into the development. Migrating from SPI based SD card support to 4-bit parallel took just a day, whereas I'm not aware anyone has ever got 4-bit support to work on any of the PICs - certainly the documentation is horrendous and impenetrable. What I particularly like about the STM environment is that the generated code includes lots of pairs of comments like: /* USER CODE BEGIN WHILE */ while (1) { /* USER CODE END WHILE */ As long as you put your code between these brackets in the auto-generated files then CubeMX will leave your code intact but update the system code as you make changes to the configuration. This means that you can add peripherals very easily. (4 serial ports added today) |
||||
geraldfryjr Regular Member Joined: 02/03/2014 Location: United StatesPosts: 61 |
Hi Guys, This sounds Great as I am always on the Hill for the Need for More Speed. On my latest adventures I have been wanting to use my CGColormax2 to work with FPGA's. But.... For one, just as I was getting ready to use it, it was being unstable due to a poor soldering job of the MX795 as bought and delivered. It was intermittent so I couldn't really report it until I had found the exact cause. So, I tried to fix it using my soldering Station instead of the iron that I had special made a custom tip just for working with SMD's and ruined 4 or 5 of the traces and pads. Needless to say it still works but I have to tack some WWwire to the VGA green output pin to the VGA socket and it will be missing a few I/O's unless I decide to tack those up too. Anyhow using the Micromite (MX170,250), I found that the I/O speeds for me were okay for some projects and beginning stuff, but was still slow for my liking. To complicate matters it all depends on how you right the routines as well, and if you are writing to a display (on Maximite) or even slower an LCD this makes the I/O even slower. I had everything hooked up on the Micromite every function working all at the same time and it was really impressive It was after all of this that I had discovered the PORT command for setting many bits at once, but haven't tested it yet. I need to know if they actually all get set at once like I normal 8 bit port or do they get set sequentially but only faster in order as per written in the code? If it is the Latter this won't be good for some of my ideas, as all the bits of data Must Be There At The Same Time! Trying to write efficient code and still have proper port pin timing becomes a big issue at times, Gosub's do slow things down a bit in that matter as well. I do still keep everything within its capabilities, But if it is slow you can only do so much.  I have found that the Jitter of the signal coming out of a single port pin on the Micromite is also very bad (P.S. I just realized there is no Xtal  ).So using it to trigger some counters for frequency or some kind of time measurement is not going to be very very inaccurate as it is inconsistent. This means extra de-bouncing and such in the FPGA, Maybe I am being too picky but we'll see once I get going It didn't matter if I had used a For/Next for the loop or just a string of PIN=1, Pin=0 commands, although the latter was a bit better. At this point I checked to be sure it wasn't the scope and I could see the 8Mhz clock with no jitter (maximite). One remark about the above, My Hitachi V-425 scope was messing up really bad due to a bad cap but it wasn't linked to the trigger circuits anyhow. I did noticed this before that cap went bad, it was just another minor setback for a little while. Since then I fixed it and is rock solid. But, I broke the board before I could retest it with the scope now perfectly solid. I suppose I could recheck it again but with just the RED and Blue active, I might just change it to only monochrome anyhow for this project. I just picked up a Tektronix 2465a last week so I will be able to tell you exactly how bad it is. A few years ago I wanted to see MMBasic on the STM32F429I discovery board Because of it's higher clock rate. But as we all know that went by the wayside. I do have the STM32F407 to give it a try now. I haven't used PIcromite yet but it is on my todo list. I started with CooCox and then Eclipse for the STM32's then the System Workbench openSTM32 for STM32 came out and I liked it a lot. I have read really good things about the ST32MXcube but haven't the time lately to work with the ARM's. A new 32MZ maximite is in the works as well, I have something like 6 or 9 of those in little black boxes. Yes, MPlABX system is a far cry from STM32 system but it does what it needs to do for the PIC's with the sad part of the paid compiler versions to boot. Having the MMbasic source code I can't even compile it to fit.  Don't have those issues with ARM for the most part. Don't get me wrong I like the PIC's very much but ARM seems to be where it is at !!  Especially the cost factor even though it is a PITA to setup the STM32 ports if you do it manually. Many may not need that much speed to do simple everyday tasks like I do. But, I am No C programmer (In fact, I despise it!!!), and, I will snap at the chance any day to get by with using BASIC (or assembly if I have to) if I can. I am more of a hardware guy than software dude, but you have to have both !! He,he,he,he Cheers !! jer Keep on DIYin' !!!  |
||||
| Page 1 of 2 |
|||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
