 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 2 of 3   |
|||||
| Author | Message | ||||
| lizby Guru  Joined: 17/05/2016 Location: United StatesPosts: 3016 |
Here's the output from running on a Pi Zero W. Running on computer 'pi-zw' on 12-07-2018 at 11:27:38 Starting 1,000,000 iterations of empty loop ... Finished 1,000,000 iterations of empty loop in 11763ms or 0.0118 ms per iteration. Starting reading 100 line file 10,000 times ... Finished reading 100 line file 10,000 times in 207839ms or 0.2078 ms per iteration. Starting writing 1,000,000 line file ... Finished writing 1,000,000 line file in 1.897624000e+06ms or 1.8976 ms per iteration. Starting parse 9 strings from 100,000 strings ... Finished parse 9 strings from 100,000 strings in 86038ms or 0.0956 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 69442ms or 0.0694 ms per iteration. Finished 4,900,000 iterations on computer 'pi-zw' in 2.272835000e+06ms or 0.4638 ms per iteration. =============================================== Write to file is a good bit slower than any of the others, perhaps for the reason Peter gave for the Nucleo. Others are generally a bit faster than the MM+ at 120mHz. The SD card is (nominally, at least) a SanDisk Ultra 16gb class 10. PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on fruitoftheshed |
||||
| Paul_L Guru Joined: 03/03/2016 Location: United StatesPosts: 769 |
Well, isn't that interesting. You can get SD cards with write speed ratings from 2MB/sec all the way up to 90MB/sec. My test program writes a 46MB file as follows: ms MB/sec i5@5GHz 2891 15.91 Cel@2GHz 8203 5.61 MMX@252 189127 0.24 MMX@200 189466 0.24 MM+@120 325843 0.14 MM+@100 365102 0.13 nucleo 566168 0.08 pi-zw 207839 0.22 Then, in the next paragraph, the SD speed standards mention that disk fragmentation drastically reduces the writing speed of SD cards and suggests that they be reformatted if they are observed writing slowly. I have no way of knowing the fragmentation level of the cards used in the above tests so I can't judge if fragmentation slowed the writing speeds as observed. Nothing in this will cause me to not continue to select the MMX for my project. Paul in NY |
||||
TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 5911 |
Just to make things interesting, different operating systems write to disk differently. Most write to a buffer in memory and only occasionally flush the buffers to disk. Similar with reads. They read a big chunk on the assumption you are doing a sequential read. They also read/write full sectors, the size of which varies a lot. It all makes comparisons 'interesting' but not a true indication of raw performance. Jim VK7JH MMedit MMBasic Help |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3165 |
An SD card can be driven in a number of modes. 4-bit mode uses 4 signal lines and is used in computers, cameras, etc but last time I looked the protocol was propriety and you had to pay to use it. SPI mode is free to use and that is what the Micromite Plus uses. In this mode the speed is limited by the speed of the SPI bus so there is no point in buying a fast card. Geoff Graham - http://geoffg.net |
||||
| Paul_L Guru Joined: 03/03/2016 Location: United StatesPosts: 769 |
Hi Lance, actually the Pi is a tiny shade faster than the MMX in writing the file. ms MB/sec i5@5GHz 2891 15.91 Cel@2GHz 8203 5.61 MMX@252 189127 0.24 MMX@200 189466 0.24 MM+@120 325843 0.14 MM+@100 365102 0.13 nucleo 566168 0.08 pi-zw 207839 0.22 The Pi sounds interesting but .... it requires an operating system which reduces the stand alone run forever suitability, doesn't have many general I/O ports, and it's so darned small I'll probably break the darned thing. It's unfortunate because Ada (Limor "Ladyada" Fried) located her business, Adafruit, about 75 miles south of me in NYC when she left MIT and it would be an ideal parts supplier for me. I think I'll stick with the MMX. Paul in NY |
||||
| isochronic Guru Joined: 21/01/2012 Location: AustraliaPosts: 689 |
It is worth remembering, the useage of SD cards is different on micros wrt PCs etc. A micro typically uses a sd card for logging / limited power and it is best for the software to at least close a file, and maybe power-off the sdcard between accesses, as often as realistic. Restarting it and opening a file takes a long time, but saves your data, particularly in unknown timeframes etc. Using a sd card on a PC on the other hand is usually always-on with ongoing access so software is usually optimised for that. ed- by PC I mean Pi's etc , things with OS's |
||||
| Paul_L Guru Joined: 03/03/2016 Location: United StatesPosts: 769 |
@chronic - I agree that you should close files on an SD card when you're not actually writing to them, but how do you power-off the SD card with a PIC based MMBasic program? Paul in NY |
||||
| isochronic Guru Joined: 21/01/2012 Location: AustraliaPosts: 689 |
For the pic/MMbasic kits, it might take a hardware mod to allow the power to the sdcard to be switched under software, maybe associated software mods too. So I'll throw that open to the MMBasic gurus, it is probably worth a different thread if the answer involves much. |
||||
| Paul_L Guru Joined: 03/03/2016 Location: United StatesPosts: 769 |
Hey Stuart, why would you want to cut power to an SD card when all files are clsoed anyway? |
||||
| isochronic Guru Joined: 21/01/2012 Location: AustraliaPosts: 689 |
I am not using the pic/MMbasic for it, (pic/MMBasic is probably more reliable than what I am doing), but in general I have found that a card hard power reset just before access is more reliable (particularly for writing records) than to leave the sdcard powered on for a long time (say an hour) between use. A card soft reset doesn't seem to be as reliable. My impression is, some RF noise on the leads can glitch the card state after a while and it doesn't reset well - thats just a guess at this stage. Pity because it makes the overall process quite slow. There are other factors which make it useful as well, but they are probably irrelevant to most people so I'll leave them out here. I guess it would would save a little power too, if access is only infrequent. |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8592 |
Latest results with speed improvements on ArmmiteH7 in the more recent releases, the ArmmiteF7, the ArmmiteL4 (flash drive rather than SD) and the soon-to-be-released ArmmiteF4 that is in development. All these benchmarks are very useful in proving that critical aspects of a port and its reliability are working properly. The ArmmiteF4 is coming in between the speed of the MM+ and MMX which given the clock speed is what is to be expected. The flash memory on the ArmmiteL4 is interesting, quick on read given the slower processor but pretty slow on write. The empty loop tests on the Armmites in general are interesting, much faster than expected compared to the PICs. I assume this is because the STM32 keeps the code in cache when the code segment is fairly small. Overall, of course, these benchmarks are dominated by the Sdcard performance and that is ultimately limited by the speed of the SPI bus connection that the cards can accept so although the Armmite H7 is more than twice as fast as the MMX for the normal Basic tasks in the benchmark it is only marginally faster at SDcard I/O loop read file write file mid$() val() total Dell i5 3.4GHz 266 7047 2891 1906 1391 13516 Cel Quad 2GHz 844 19219 8203 6125 4157 38579 ArmmiteH7 @ 400MHz 1472 187489 124697 24667 11849 350178 MMX @ 252MHz 5109 170491 189127 51147 26971 442913 MMX @ 200MHz 6477 202206 189466 64282 33824 496432 ArmmiteF7 @ 216MHz 4046 309310 122871 67921 31849 536001 ArmmiteF4 @ 168MHz 7353 393757 212357 98676 48341 760493 MM+ @ 120MHz 13532 491706 325843 119408 70604 1021110 MM+ @ 100MHz 16257 565035 365102 143456 84823 1174760 ArmmiteL4 @ 80MHz 8234 473333 763910 195705 93618 1534800 |
||||
| Paul_L Guru Joined: 03/03/2016 Location: United StatesPosts: 769 |
Hi Peter .... thanks for digging out this old thread of mine. Between the L4, F4, F7 and H7 it looks like ARM has surrounded the PIC chips! My chip selection of the H7 is pretty obvious based mostly on the large number of i/o gadgets, each of which needs its own pin. The speed bump provided by the SPI bus will not seriously impair the overall performance of the gadget while it is writing the historical logging data to the SD card. The machinery being controlled reacts slowly to changes in operation, in fact it is so slow that I have inserted a lot of wait states into the main program loop. My principle remaining problem is deciding how to easily change the many calibration settings used by the algorithm which are initially read from an SD card disk file. I could change them using a layered mess of interactive display pages but it would be a complicated set of menus, or I could change them by replacing the disk file and causing the program to re-read it but there is no convenient way to transfer a disk file to the live SD card. My second remaining problem is designing multiple opto-coupled zero crossing detectors driving TRIACs which feed the various fractional horsepower water pumps. I really want to avoid using mechanical relays if possible. My third remaining problem is that the underground heat exchanger has been in operation continuous since 2013 and the anti-freeze mixture in there is getting a little too viscous. I've got 250 gallons of stuff that resembles Jello circulating in 6500 feet of HDPE pipe to dispose of. I'm also trying to figure out how to take advantage of the 144 btu/lb heat of fusion of water by building an insulated ice bank in the crawl space and pumping ice melt water through the underground heat exchanger which would completely avoid using anti-freeze altogether. I also find myself considering a way to put the H7 nucleo board on display in a transparent enclosure, maybe alongside of the display. The darned thing is pretty! Does anybody have any good ideas? How about some bad ones? Paul in NY |
||||
| PeterB Guru Joined: 05/02/2015 Location: AustraliaPosts: 639 |
G'Day Paul I have been reading this without really understanding it and thinking "these blokes are too clever for me" but then I came on your comment about using a zero crossing opto to turn on a FET and I thought " I understand that......I think" If you switch on a transformer or motor with a zero crossing switch, it will go into saturation because flux is proportional to the integral of voltage. I think that is correct. That is just a small point but sometimes it's the small points that can make a real mess. Now you can get back to the real work. Peter |
||||
| BrianP Senior Member  Joined: 30/03/2017 Location: AustraliaPosts: 292 |
@PeterB I'm trying to get my head around your mention of saturation due to a zero crossing switch. I've probably missed something, but my understanding of zero crossing switching is that the connection takes place at a voltage zero point in the cycle. Are you saying that because of inductive effects the current is not zero (it would have to be because the thing has been not connected at some point in the previous cycle) or is there some weird effect due to back emf from being disconnected mid-cycle? This is the mode of operation of "trailing edge" dimmers - start at a zero voltage & current, disconnect when the required power value is reached. (This is for resistive loads though). My grey cells probably need a stem cell hit...  Regards Brian P. |
||||
| PeterB Guru Joined: 05/02/2015 Location: AustraliaPosts: 639 |
G'Day Brian. I think I'm correct. With an iron cored inductor, flux is proportional to the integral of applied voltage so if the voltage starts at zero and climbs to Vpk, the flux reaches it's maximum value in that first half cycle and that is what causes the "thump" when some things are switched on. With a resistive load, current is in phase with voltage and things are well behaved. I suspect Paul will come storming in on this when he gets out of bed  But we are going back, 1968 was my last lecture. Peter |
||||
| Tinine Guru Joined: 30/03/2016 Location: United KingdomPosts: 1646 |
He also stated TRIAC, not FET. SSRs drive AC inductive loads all the time. I have just received a bunch from Aliexpress but have yet to test. |
||||
| PeterB Guru Joined: 05/02/2015 Location: AustraliaPosts: 639 |
Good evening Tinine You are quite correct but my theory is still OK. As a bit off topic, I was involved with the design of power transformers to be spread across the donga in underground bunkers and powered by a large generator. All went well until the transformers started bursting into flames. Panic all round, but the cause was the customer used SSRs to turn the things on remotely and failed to install snubbers so it was possible for one half of the SSR to turn on and put DC into the transformer. I think it then went into saturation  Peter |
||||
| Tinine Guru Joined: 30/03/2016 Location: United KingdomPosts: 1646 |
https://www.electronics-tutorials.ws/power/solid-state-relay.html |
||||
| PeterB Guru Joined: 05/02/2015 Location: AustraliaPosts: 639 |
I'm not sure my search turned up the correct item but can you explain your point. Are you with me or "agin" me. In other words, is mt wife going to have to fight you?  Peter |
||||
| Tinine Guru Joined: 30/03/2016 Location: United KingdomPosts: 1646 |
LOL, No, it's just that I have been using zero-crossing SSRs since the early '80s on all kinds of loads, without any problems. Great solution, in my experience. Here is an interesting device that I have just received: ￡12.67 | 10DA 5 Channel Din rail SSR quintuplicate five input 3~32VDC output 24~380VAC single phase DC solid state relay https://s.click.aliexpress.com/e/bKQTQixA Just have to find a use for it now...  |
||||
| Page 2 of 3 |
|||||
 Print this page |
