 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 : Is this thing fast enough???
  Page 3 of 3 |
|||||
| Author | Message | ||||
| PeterB Guru  Joined: 05/02/2015 Location: AustraliaPosts: 639 |
I agree, SSRs are great but I do think they probably go beyond their SOA on odd occasions and, as in my story, if an inductive load prevents the current from reaching the minimum value before the trigger is removed, things can go pear shaped. Good luck with your quintupliflgilistic thing and it's just as well you didn't have to fight my wife. Peter |
||||
| Tinine Guru Joined: 30/03/2016 Location: United KingdomPosts: 1646 |
I normally use the big-name locally sourced, SSRs but I just bought a bunch of both AC and DC devices from Aliexpress...every installation in the past 5 years involved driving AC solenoids. Wouldn't you know it, my current projects are fitted with DC solenoids. Gonna stay prepared for a quick swap though in case these things prove to be flaky  |
||||
| PeterB Guru Joined: 05/02/2015 Location: AustraliaPosts: 639 |
We really have gone a long way from Paul's original topic buy never mind. I'm not sure what you are trying to do but if you have to add a DC supply just drive some solenoids I would expect that supply to be the weak link. I have this thing about power supplies. Years of experience.....with other peoples of course. Peter for buy read but P |
||||
| Tinine Guru Joined: 30/03/2016 Location: United KingdomPosts: 1646 |
I specialise in retrofitting CNC Tube Forming machines which can involve anywhere from one to twelve axes of motion control. So many machines are scrapped simply because the control system is dead and no-longer supported. A general purpose CNC cannot handle this application. I basically give them a brain transplant at a fraction of the cost of a new machine. Some machines are equipped with DC valves and others AC. I simply tie-in to existing components. |
||||
| Paul_L Guru Joined: 03/03/2016 Location: United StatesPosts: 769 |
Lance Benson has just rerun this benchmark on the ARM based CMM2 platform. Thank you Lance! Here is the updated table of relative speeds. i5 celeron CMM2 MMX MMX ARMMITE MM+ MM+ 5GHz 2GHz 252MHz 200MHz F4 120MHz 100MHz 1 empty loop 266 844 1176 5109 6477 7083 13532 16257 2 read file 7047 19219 109740 170491 202206 190500 491706 565035 3 write file 2891 8203 126305 189127 189466 221530 325843 365102 4 mid$(x$) 1906 6125 24451 51147 64282 108169 119408 143456 5 val(x$) 1391 4157 11555 26971 33824 51852 70604 84823 That's getting to be quite an assortment of platforms!!! As I originally said two years ago, I'm amazed at the speed Geoff has wrung out of MMBasic. The DOS implementation beats the speed produced by Visual Studio FoxPro which is a P code compiler. It almost matches the speed produced by fully compiled Clipper. Thank you Geoff! I hope MMBasic winds up being more long lasting than Visual FoxPro and Clipper. Hmmmmmm ... speaking of dBase, FoxPro and Clipper ... I wonder if MMBasic could be extended to read the header of a dBase file and learn about the difference between variables held in memory and variables which pre-exist before run time in a persistent database??? I know that the newest version of MMBasic for the CMM2 is aimed at graphics and game playing ... BUT there is a vast untapped requirement for efficient flat file database applications in business large and small. A fast starting, close to the metal, portable, standalone database stored on an SD card might be just the ticket to ensure the survival of MMBasic. How about that Geoff? There currently is no viable stand alone programmable database application except those that have to run as a stack of an application development language, on top of a database backend, on top of an operating system. The stack requires all sorts of messaging code bouncing beween the layers which complicates the program an encourages all sorts of bugs. Just thinking ....... Paul in NY Edited 2020-07-05 13:30 by Paul_L |
||||
KeepIS Guru Joined: 13/10/2014 Location: AustraliaPosts: 1353 |
CMM2 V 480 MHz 1 empty loop 918 2 read file 77702 3 write file 92358 4 mids$(x$) 20038 5 val(x$) 9235 Obviously SD/HDD/SSD throughput really hits file R/W results. Mike. Edited 2020-07-05 14:50 by KeepIS It's all too hard. Mike. |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3165 |
Good grief... what a challenge! It would require a processor with a lot of grunt and memory (as has the CMM2). But, would anyone other than dBase fans (and I am one) want to use it for serious computing? Like running a business? Geoff Geoff Graham - http://geoffg.net |
||||
| LouisG Senior Member  Joined: 19/03/2016 Location: AustraliaPosts: 121 |
@ Paul_L "There currently is no viable stand alone programmable database application except those that have to run as a stack of an application development language, on top of a database backend, on top of an operating system." I asked my son for his opinion. This is it below. Erm... Incorrect. Of course there are existing solutions. For example, there's a local-only embedded database called SQLite written in C and is open source which means it can be freely embedded into MMBasic without the need for an independent back-end or operating system. And yes, a database is needed even more than graphics capabilities. Think of the software that runs the EFD plant, it desperately needs a database to make it easier to program. There's a list of steps, each having several fields (step number, step name, step description, wait period, alarm condition, etc) and each step has a relationship (many to many) with a list of outputs, each also with data associated with them (pin number, output type, name, pwm value, on/off state on emergency shut down, etc). There's also a list of sensors, each with their own set thresholds (maybe even per step). And maybe you want to record logging information, such as step timing, faults, operator actions, power loss, alarms, max/min sensor readings, etc. All this structured data should be stored in a database, not in string inside a text file that is parsed by dubiously tested code. It should be a well maintained facility that does all the heavy lifting for you. But it doesn't have to be provided by Geoff since anyone can embed C routines (though a full-fledged database may be a bit too large to embed this way). - |
||||
| IanT Regular Member  Joined: 29/11/2016 Location: United KingdomPosts: 84 |
Many years ago I worked for a company that sold systems based on 8-bit technology that competed on price & performance with more powerful 16bit mini-computers. Each board was intelligent and communicated with a master controller/supervisor. So disk controllers, comms. controllers, VDU controllers all had their own processors and were managed by the supervisor - thus distributing the workload. I sometimes think of this when playing with my Mites - but haven't explored it yet, although I suspect I will need to do so for one of my projects. Getting back to this subject - I see the Maximite as a very powerful device, that will give me not only good I/O capability but also the ability to deliver simple visual data/feedback. However, if I needed a powerful back-end database server, then I'd find some way to connect it to my laptop efficiently (it would need to be Serial) using some form of 'data' protocol (SQL?). I should state right now that I know nothing about SQL or Databases (I used Paradox & Access many moons ago - but Excel is sufficient these days) Another possibility would be to connect it to a RPi and let that do the 'C' work. Probably uninformed nonsense as usual but just a thought. Regards, IanT |
||||
| lizby Guru Joined: 17/05/2016 Location: United StatesPosts: 3013 |
For Micromite/Max family completeness, here's the pi-cromite on one of the slowest pi platforms, the Zero-W, with Buster. It doesn't slot in quite as cleanly, since it's slower than comparable for some tests, and faster for others. The pi has a fairly new and fairly fast 8GB micro SD card (but I don't have specifics). Running on computer 'Pi-ZW Buster' on 05-07-2020 at 09:37:05 Starting 1,000,000 iterations of empty loop ... Finished 1,000,000 iterations of empty loop in 16825ms or 0.0168 ms per iteration. Starting reading 100 line file 10,000 times ... Finished reading 100 line file 10,000 times in 163878ms or 0.1639 ms per iteration. Starting writing 1,000,000 line file ... Finished writing 1,000,000 line file in 93319ms or 0.0933 ms per iteration. Starting parse 9 strings from 100,000 strings ... Finished parse 9 strings from 100,000 strings in 95714ms or 0.1063 ms per iteration. Starting extracting the value from a string 1,000,000 times ... Finished extracting the value from a string 1,000,000 times in 83110ms or 0.0831 ms per iteration. Finished 4,900,000 iterations on computer 'Pi-ZW Buster' in 452935ms or 0.0924 ms per iteration. =============================================== ~ Edited 2020-07-05 22:53 by lizby PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on fruitoftheshed |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 3654 |
Excellent! Ahem - it's a fast P-code interpreter (and 5.0 has a lovely garbage-collected VM). They just called it a compiler and mostly people didn't notice it wasn't. John |
||||
| Paul_L Guru Joined: 03/03/2016 Location: United StatesPosts: 769 |
Hi Geoff, you'd better believe that lots of people would want to use it for serious computing!!! People try to use spreadsheets as databases all the time, but this bound to generate problems. This current thread Little spreadsheet help please ... is an example. People also try to use a non-programmable flat file DBMS like Access all the time, but without a programming language they can't be manipulated conveniently. You have already provided most of the functionality in the MMbasic primitives. Very little modification to the language would be needed. Most of it could be written as more or less reusable MMbasic functions and procedures. If you're interested I'll try to put together a specification for the needed procedures and functions. Three and a half decades ago I had a hand in writing some of the Clipper Summer '87 code and I still have some of the specification notes somewhere on this disk which I can dig out. I suspect that I'm too old to really finish it myself but I'll give it a try. Paul in NY |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8578 |
Results on the PicoMite alpha Starting 1,000,000 iterations of empty loop ... Finished 1,000,000 iterations of empty loop in 4635ms or 0.0046 ms per iteration. Starting reading 100 line file 10,000 times ... Finished reading 100 line file 10,000 times in 268609ms or 0.2686 ms per iteration. Starting writing 1,000,000 line file ... Finished writing 1,000,000 line file in 152930ms or 0.1529 ms per iteration. Starting parse 9 strings from 100,000 strings ... Finished parse 9 strings from 100,000 strings in 105240ms or 0.1169 ms per iteration. Starting extracting the value from a string 1,000,000 times ... Finished extracting the value from a string 1,000,000 times in 54626ms or 0.0546 ms per iteration. Finished 4,900,000 iterations on computer 'PicoMite' in 586056ms or 0.1196 ms per iteration. |
||||
| lizby Guru Joined: 17/05/2016 Location: United StatesPosts: 3013 |
Very good numbers approximately in the MMX/F4 range. Sweet. What speed? What CPU voltage? PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on fruitoftheshed |
||||
Plasmamac Guru Joined: 31/01/2019 Location: GermanyPosts: 501 |
Is this standard clock? Plasma |
||||
| Paul_L Guru Joined: 03/03/2016 Location: United StatesPosts: 769 |
WOW, the thread that won't die is back again! It looks like it sometimes wanders off into another topic but then it's back to my original question. Seems like everyone is interested in overall speed including juggling strings and file i/o. Paul in NY |
||||
| Page 3 of 3 |
|||||
 Print this page |
