Home
JAQForum Ver 24.01
Log In or Join  
Active Topics
Local Time 05:30 06 Jul 2025 Privacy Policy
Jump to

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 : MCU speed - is it THAT important?

     Page 1 of 2    
Author Message
Grogster

Admin Group

Joined: 31/12/2012
Location: New Zealand
Posts: 9588
Posted: 02:02pm 31 Jul 2014
Copy link to clipboard 
Print this post

I've been reading the other thread about the bypic, and it is quoted as being able to execute code at 200,000 lines per second.

Do PIC's REALLY need all that code execution speed?
Is speed really that important these days with the average coder?

I can fully understand the need for speed, if you were building something like a graphics controller or something else processor-intensive, but just for running average code from the average programmer, just how important is 10,000RPM engine speed?

I find that most of my projects run perfectly fine at the modest speed of 4MHz(PICAXE) or 8MHz(PICAXE M2's), and even down that slow, I have never had speed-related issues in what I am doing. By default, I leave the uM at it's 40MHz speed, and that is more speed then I can conceivably ever use in a MCU.

I guess it really does depend on what you ARE doing, and higher MCU speed does come into play if you need fast serial baud-rates or something, but all my stuff runs at the very modest 9600 baud, and that is doable even at 5MHz clock speed.

So, I guess my question really is: What kind of code would benefit from these super-fast execution speeds? What kind of application would need that speed?(ignoring graphics control for now, as I fully appreciate the speed factor needed there)
Smoke makes things work. When the smoke gets out, it stops!
 
G8JCF

Guru

Joined: 15/05/2014
Location: United Kingdom
Posts: 676
Posted: 02:11pm 31 Jul 2014
Copy link to clipboard 
Print this post

Rotary Encoders. DDS calculations

Peter
The only Konstant is Change
 
Grogster

Admin Group

Joined: 31/12/2012
Location: New Zealand
Posts: 9588
Posted: 02:12pm 31 Jul 2014
Copy link to clipboard 
Print this post

Why do rotary encoders need speed?
What is DDS calculation?
Smoke makes things work. When the smoke gets out, it stops!
 
hitsware
Guru

Joined: 23/11/2012
Location: United States
Posts: 535
Posted: 02:27pm 31 Jul 2014
Copy link to clipboard 
Print this post

Direct Digital Synthesis......I can envision that getting hairy.
Overall I'm with you.
As far as I'm concerned 1 MHz will do.
(probably less though I've never tried)
Things got ridiculous when they started
putting heatsinks on processors.
 
Grogster

Admin Group

Joined: 31/12/2012
Location: New Zealand
Posts: 9588
Posted: 02:48pm 31 Jul 2014
Copy link to clipboard 
Print this post

Thanks for letting me know what DDS was.

I also understand the need for grunt with PC CPU's(they have a heap more things to do), but for MCU's....
Smoke makes things work. When the smoke gets out, it stops!
 
Justplayin

Guru

Joined: 31/01/2014
Location: United States
Posts: 327
Posted: 03:14pm 31 Jul 2014
Copy link to clipboard 
Print this post

I'm concerned I might need a little more speed than the Maximite can deliver for my GPS clock project. I'm not sure it can finish everything I want it to do in 1 second... receive UTC time and date, time zone adjustment, DST set/reset calculations, day of week, 100+ alarm events to check/reset/sort/save, temperature reading. Plus display the actual time in a large easy to read format, not simple tiny text.

At the moment... more execution speed seems like it might be great thing.

Or, maybe I should'nt be concerned about it.

--Curtis
I am not a Mad Scientist...  It makes me happy inventing new ways to take over the world!!
 
viscomjim
Guru

Joined: 08/01/2014
Location: United States
Posts: 925
Posted: 03:18pm 31 Jul 2014
Copy link to clipboard 
Print this post

Hey Grogster,

I agree, so far, everything I have thrown at uMite has not ever been limited by clock speed. I have had both serial ports, i2c display, keyboard, etc, etc, running at once and never ran into issues. I am not doing crazy math or anything, just real world control things that the uMite is probably yawning at, but a human thinks is really fast. The one project that was recently on this forum, using the signal generator seemed to give the uMite a bit of a headache, but that did involve a good amount of calculation (I think). Anyway, so far so good, what a great little controller this has turned out to be. I have probably used 15 28 pinners so far, all doing great and probably twirling their silicone thumbs more than actually turning on and off the i/o pins, even though they look like they are blazing to a human.

Justplayin, I would love to know how the uMite does with your project. Seems like alot of stuff to accomplish in one second. Keep us posted!!!Edited by viscomjim 2014-08-02
 
G8JCF

Guru

Joined: 15/05/2014
Location: United Kingdom
Posts: 676
Posted: 03:23pm 31 Jul 2014
Copy link to clipboard 
Print this post

Hi Grogster

Decent Rotary encoders generate 128~256 Pulses Per Revolution, "PPR", and the human hand can turn an encoder at least 2 turns per second which generates (at minimum) say 256 interrupts. If those pulses are controlling an RF Synthesizer, then the s/w has 1/256=0.004 secs, ie 4 mS, to calculate whatever is required to change the frequency and update the synthesizer hardware. For a DDS chip that usually means performing at least a Double Precision floating point ADD operation. 4mS for a Double Precision ADD operation and an update of the DDS chip is a tough ask for a uMite, although we are getting very close. At 100 MHz it would be all very doable, but we don't have a 100 MHz uMite yet !

As a general rule, the more speed one has the more one can "beautify" one's program !

I started out working with an Intel 4004 and boy was it hard to do anything properly/elegantly. With modern PC CPUs and associated h/w FPUs, one can, for most ordinary real-world problems, write clean/structured/maintainable code because the CPU is so powerful and memory so plentiful.

The same kind of thing applies when one compares the 8 bit PICs vs the 32 bit PICs.

I loved programming in Assembler, but compared to C/Basic/Pascal, Assembler productivity is orders of magnitude less, so except for real performance critical situations I never use Assembler these days.

Peter
The only Konstant is Change
 
Grogster

Admin Group

Joined: 31/12/2012
Location: New Zealand
Posts: 9588
Posted: 03:26pm 31 Jul 2014
Copy link to clipboard 
Print this post

Cheers, Peter - good information.
Smoke makes things work. When the smoke gets out, it stops!
 
hitsware
Guru

Joined: 23/11/2012
Location: United States
Posts: 535
Posted: 04:50pm 31 Jul 2014
Copy link to clipboard 
Print this post

" CPU is so powerful and memory so plentiful. "

Nobody will accuse you of being too 'green'
 
G8JCF

Guru

Joined: 15/05/2014
Location: United Kingdom
Posts: 676
Posted: 05:05am 01 Aug 2014
Copy link to clipboard 
Print this post

@hitsware



but I don't own a single bit of Apple kit - that surely must count towards my green credentials

Peter


The only Konstant is Change
 
G8JCF

Guru

Joined: 15/05/2014
Location: United Kingdom
Posts: 676
Posted: 09:05am 01 Aug 2014
Copy link to clipboard 
Print this post

@Grogster

Just thought of another reason, in fact one of the most important, the ability to run a Real Time Operating System, "RTOS". An RTOS really, really simplifies the creation of real time systems. State machines are really primitive/difficult in comparison. If one wants to use High level languages, RTOS, have maintainable code, and more than just one programmer on the job forever, one needs the extra speed and memory. These considerations are critical to commercial/industrial/medical/defence applications, whereas consumer applications tend to be driven by price (as in lowest possible).

I think that with PIC32s, and low power 32 bit ARM MCUs we will all have the ability to use high-level languages with an RTOS for just about every application. Have you seen the latest announcement from Freescale - 1.6 x 2.0 mm !

  Quote  
The Kinetis KL03 20-pin CSP microcontroller squeezes a 32-bit ARM® Cortex®-M0+ core, 32KB of flash memory and advanced low-power peripherals into a tiny 1.6 mm x 2.0 mm package


Mind you all this miniaturisation is making it even more impossible for the hobbyist to solder the little things.

Peter
The only Konstant is Change
 
WhiteWizzard
Guru

Joined: 05/04/2013
Location: United Kingdom
Posts: 2932
Posted: 10:03am 01 Aug 2014
Copy link to clipboard 
Print this post

20pins within a 1.6mm x 2mm package - soldering should definitely be no problem with that chip then!!
 
vasi

Guru

Joined: 23/03/2007
Location: Romania
Posts: 1697
Posted: 01:42pm 01 Aug 2014
Copy link to clipboard 
Print this post

  G8JCF said  
The Kinetis KL03 20-pin CSP microcontroller squeezes a 32-bit ARM® Cortex®-M0+ core, 32KB of flash memory and advanced low-power peripherals into a tiny 1.6 mm x 2.0 mm package
Peter


Maybe that is about the the silicon which probably is encapsulated in a bigger plastic capsule?
Hobbit name: Togo Toadfoot of Frogmorton
Elvish name: Mablung Miriel
Beyound Arduino Lang
 
Grogster

Admin Group

Joined: 31/12/2012
Location: New Zealand
Posts: 9588
Posted: 02:07pm 01 Aug 2014
Copy link to clipboard 
Print this post

@ G8JCF - Thanks for the RTOS information. That actually makes sence, and if you needed to run a RTOS, then you would need speed and memory on any MCU of choice - I can see that. However, for the average experimenter, I doubt we will need that 1.6 x 2mm "Beast" - Holy Hell - the fact that it would be impossible to hand-solder not withstanding, how do they get so much technology into such a tiny space!?(rhetorical)

Technology really is amazing - the things you can do and the choices you have of MCU series and brands etc, over even 10 years ago.
Smoke makes things work. When the smoke gets out, it stops!
 
hitsware
Guru

Joined: 23/11/2012
Location: United States
Posts: 535
Posted: 03:42pm 01 Aug 2014
Copy link to clipboard 
Print this post

Yep ...
The MicroMite comes close to doing the whole
of my Vic 20 .... :)
 
Grogster

Admin Group

Joined: 31/12/2012
Location: New Zealand
Posts: 9588
Posted: 05:09pm 01 Aug 2014
Copy link to clipboard 
Print this post

As I have often mentioned around here, my first computer was an Atari 800XL from about mid 80's. This thing had a 6502 CPU running at the glorious speed of 1.8MHz!!!

64K of RAM, and I think it was 16K ROM from memory. The 800XL had Atari-BASIC built in, and all my programs were in BASIC, although I had started to dabble in machine language by the end of that computer's life - then I moved to PC's.

The disk-drives/tape-decks/printers etc were all on an external SIO bus, running at 19k2 baud.
Smoke makes things work. When the smoke gets out, it stops!
 
G8JCF

Guru

Joined: 15/05/2014
Location: United Kingdom
Posts: 676
Posted: 05:16pm 01 Aug 2014
Copy link to clipboard 
Print this post

I've just completed benchmarking some code on the ByPic 'MX150, specifically 18 decimal digit ADD and SUBTRACT, and the ByPic performs an 18 digit Add/subtract in around 800uS compared to about 2.5 mS for the uMite, ie about 3 x faster.

One can never have "too much CPU speed" ! If the uMite ran at 500MHz we wouldn't need to ask Geoff for a Trim/LTrim/RTrim function, we would just write it in mmBasic.

Anyway, here's the ByPic code so as to give you some idea of what ByPic looks like.


constant Billion 1000000000
constant Million 1000000
constant Thousand 1000
constant HalfMillion 500000
constant SizeOfInt 4
constant MillionX10 10000000

//
// Add 2 x 18 digit integers, return result in p
// m, n, p are the base addresses of integer arrays
// p()=m()+n()
//
function AddMN2P(m,n,p)
dim i,Cy

i=peek(m) + peek(n)
Cy=i / Billion
i=i % Billion
poke(p+0,i)

i=peek(m+SizeOfInt) + peek(n+SizeOfInt) + Cy
i=i % Billion
poke(p+SizeOfInt,i)

endf

//
// Add 2 x 18 digit integers, return result in m
// m, n are the base addresses of integer arrays
// m()=m()+n()
//
function AddMN2M(m,n)
dim i,Cy

i=peek(m) + peek(n)
Cy=i / Billion
i=i % Billion
poke(m,i)

i=peek(m+SizeOfInt) + peek(n+SizeOfInt) + Cy
//Cy=i / Billion
i=i % Billion
poke(m+SizeOfInt,i)

endf


//
// Sub 2 x 18 digit integers, return result in p
// m, n, p are the base addresses of integer arrays
// p()=m()-n()
//
function SubMN2P(m,n,p)
dim i,Cy

i=peek(m) - peek(n) + Billion
Cy=1 - i / Billion
i=i % Billion
poke(p+0,i)

i=peek(m+SizeOfInt) - peek(n+SizeOfInt) - Cy +Billion
//Cy=i / Billion
i=i % Billion
poke(p+SizeOfInt,i)

endf


//
// Sub 2 x 18 digit integers, return result in m
// m, n are the base addresses of integer arrays
// m()=m()-n()
//
function SubMN2M(m,n)
dim i,Cy

i=peek(m) - peek(n) + Billion
Cy=1 - i / Billion
i=i % Billion
poke(m,i)

i=peek(m+SizeOfInt) - peek(n+SizeOfInt) - Cy + Billion
//Cy=i / Billion
i=i % Billion
poke(m+SizeOfInt,i)

endf

//
//m, p are the addresses of the first element of the arrays
//p()=m() / 1,000,000
//
function Div1e6M2P(m,p)
dim i,j,Cy,n
dim r$[32]

//m(0)
i=peek(m)
//print "A, i=";print format$( "%9u", i );print "\n"

//m(1)
j=peek(m+SizeOfInt)
//print "A, j=";print format$( "%9u", j );print "\n"

//Add 500000 to make sure we round correctly
i=i+HalfMillion

//Any Carry
Cy=i/Billion

if Cy
i=i % Billion
j=j+Cy
endif

//Now throw away the bottom six digits
i=i / Million
//print "B, i/Million=";print format$( "%9u", i );print "\n"

Cy=j % Million
//print "A, Cy=";print format$( "%9u", Cy );print "\n"

j=j / Million
//print "B, j/Million=";print format$( "%9u", j );print "\n"

//9 Digits per integer var so we divided by 1E6 so the remainder
//has to be multiplied by 1E3
i=i+(Cy*Thousand)
//print "C, i+Cy*Thousand=";print format$( "%9u", i );print "\n"

//Return the results
poke(p+0,i)
poke(p+SizeOfInt,j)

endf


//
// Return String representation of 18 digit BCD variable
//
function BCD2Asc$(m)
return format$( "%9u", peek(m+SizeOfInt) ) + format$( "%9u", peek(m) )
endf


//
// This is a test harness for testing ByPic's capabilities to calculate
// the 32 bit tuning word for an AD9850 DDS chip. The assumptions are that
// the AD9850 is clocked at 125,000,000 Hz, ie as commonly found on eBay
// for the cheap modules.
//
function start()
dim I(2),J(2),K(2),L(2),R$[24]
dim n,i

//10MHz Tuning Word for an AD9850 with CLK=125MHz scaled by 1e6
I(0)=383680000
I(1)=343597
print "Starting I()=";print BCD2Asc$(?I(0));print "\n"

//Increment to add/subtract to the tuning word for a 10,000Hz shift in frequency
J(0)=597383680
J(1)=343
print "Starting J()=";print BCD2Asc$(?J(0));print "\n"

//Move frequency up 10 KHz
//Result should be 343940981063680
tmr_set(?TIMER23, MillionX10)
for i=1 to 100
//AddMN2P(?I(0),?J(0),?I(0))
AddMN2M(?I(0),?J(0))
next i
n=tmr_get(?TIMER23);tmr_set(?TIMER23, 0)
print n/100 ;print " uS AddMN2M";print ""
print BCD2Asc$(?I(0));print "\n"

//Move frequency down 10 KHz
//Result should be 343253786296320
tmr_set(?TIMER23, MillionX10)
for i=1 to 100
//SubMN2P(?I(0),?J(0),?I(0))
SubMN2M(?I(0),?J(0))
next i
n=tmr_get(?TIMER23);tmr_set(?TIMER23, 0)
print n/100 ;print " uS SubMN2M";print ""
print BCD2Asc$(?I(0));print "\n"

//Divide RawTuning Word by 1E6 to get actual tuning word we will send
//to the DDS chip
//Result should be 347033358
tmr_set(?TIMER23, MillionX10)
for i=1 to 100
Div1e6M2P(?I(0),?L(0))
next i
n=tmr_get(?TIMER23);tmr_set(?TIMER23, 0)
print n/100 ;print " uS Div1E6";print ""
print BCD2Asc$(?L(0));print "\n"

print "Tuning Word is ";print toupper$(hex$(L(0)));print "\n"

endf



73's

Peter
The only Konstant is Change
 
Goeytex
Regular Member

Joined: 12/05/2014
Location: United States
Posts: 74
Posted: 05:47pm 01 Aug 2014
Copy link to clipboard 
Print this post

MCU speed ( I assume you mean command processing speed) is important in quite a few applications. Some have been mentioned. Others include applications where a fast jump to an interrupt is required, bit-banging data when necessary, or applications that are math intensive.

For most hobby and even some commercial applications, slower platforms such as Picaxe and Micromite that use interpreted Basic are more than adequate.

However there are some things that these chips simply cannot do due to the high command processing overhead. Try doing a 250ns delay with a Picaxe or Micromite.
Or try interfacing to a DHT-11/22 Humidity sensor where you must read and differentiate between a 22us pulse and a 70us pulse with only 50us between pulses.

The bottom line here there is no "One Size Fits All" when it comes to Micro-controllers and languages. Use what works for the application at hand. If your favorite platform can handle it, great!. And as painful as it may be for fanboys of a certain platform or language, it may mean that they will have to commit high treason and use something else.

I like Picaxe for projects that need to be done in a hurry and where processing speed is not important. I like Micromite when I need lots of I/Os. I like PICs using either PBP or Great Cow Basic(compiled) when I need fast processing or more I/Os than Micromite can supply. Not a big fan of the Arduino language but I still use them when it makes sense (not often).

If I only need 1 ADC, 3 I/0s, and a serial port, I use an 8-Pin micro as it would be rather senseless to use a 28-Pin Picaxe or Micromite for that.

Speed for speed sake is overrated. The faster the processor clock, the more power is required. This is especially important in battery operated applications.

Just use what works and be happy !

 
Grogster

Admin Group

Joined: 31/12/2012
Location: New Zealand
Posts: 9588
Posted: 06:46pm 01 Aug 2014
Copy link to clipboard 
Print this post

...all very good points, well made.
Smoke makes things work. When the smoke gets out, it stops!
 
     Page 1 of 2    
Print this page
The Back Shed's forum code is written, and hosted, in Australia.
© JAQ Software 2025