Go Down

Topic: ino sketches and the infimum of delay/state change interval width being micros (Read 140 times) previous topic - next topic

arduidiot

i am of course new to everything and was wondering about the origins of this limit. is it a commercial availability issue of faster switching tech components? chips in general having the physical limitation?
im a good observer. not the brightest but very curious.

that poor innocent dog died from AC. he died.

I do not refuse my dinner simply because I do not understand the process of digestion."

bobcousins

I really can't make any sense of that. I don't think "infimum" is any english word I recognise.

Obviously though, every thing has physical limits, including chips.
Please don't PM me asking for help. Ask questions in the forum.

arduidiot

Infimum and supremum - Wikipedia, the free encyclopedia
en.wikipedia.org/wiki/Infimum_and_supremum
In mathematics, the infimum (abbreviated inf; plural infima) of a subset S of a partially ordered set T is the greatest element of T that is less than or equal to all .
im a good observer. not the brightest but very curious.

that poor innocent dog died from AC. he died.

I do not refuse my dinner simply because I do not understand the process of digestion."

arduidiot

working in sets seems to be a nice fit with digital logic in some well quite a lot of ways but it probably is in a math dictionary but not a standard one maybe who knows

cheers
im a good observer. not the brightest but very curious.

that poor innocent dog died from AC. he died.

I do not refuse my dinner simply because I do not understand the process of digestion."

CrossRoads

So are you asking why systems running with 16 MHz clocks (62.5 nS period) have software timing limits of 4uS?
Designing & building electrical circuits for over 25 years.  Screw Shield for Mega/Due/Uno,  Bobuino with ATMega1284P, & other '328P & '1284P creations & offerings at  my website.

arduidiot

im a good observer. not the brightest but very curious.

that poor innocent dog died from AC. he died.

I do not refuse my dinner simply because I do not understand the process of digestion."

CrossRoads

It's a combination of hardware and software setting.
Atmel designs the chips, tests them up to some frequency limit (older Arduino chips only worked at 16 MHz, new chips are spec'ed to 20 MHz).  Others have reported overclocking them and they work for whatever they are doing. Will all features work at higher speed? Who knows.  Will they consume more power running at higher speeds? Yes they will. Will they work at full speed at lower voltages? Yes and No - folks have reported Serial for instance not working correctly when underpowered.

The 4uS resolution: It's open source, you can change the software to be finer increment, but consider this: 1uS is 16 clocks at 16 MHz. 4uS is 64 clocks. 64 clocks is enough time for software to do stuff and not thrash around jumping back & forth handling time tracking. 1uS, not so much!

I had an application where I was sending out a lot of data via SPI at 8 MHz rate - things kept getting out of sync with a 2nd signal that I was using for timing. Turns out it was the interrupt handling for the micros() timer. I had to disable interrupts while I blasted the data out using assembly code. Then the 45 bytes I sent went out fast enough to complete at a 20 KHz rate (50uS) and left enough time to turn interrupts back on and catch the next 20 KHz edge to kick off the next blast of 45 bytes and stay in sync. So every cycle was:
turn on interrupts
see an edge, turn off interrupts
send out 45 bytes using 45 lines of:
spdr = dataArray[0]; nop;nop;nop;nop;nop;nop;nop;nop;nop;nop;nop;nop;nop;nop;nop;
spdr = dataArray[1]; nop;nop;nop;nop;nop;nop;nop;nop;nop;nop;nop;nop;nop;nop;nop;
:
sprd = dataArray[43]; nop;nop;nop;nop;nop;nop;nop;nop;nop;nop;nop;nop;nop;nop;nop;
sprd = dataArray[44]; nop;nop;nop;nop;nop;nop;nop;nop;nop;nop;nop;nop;nop;nop;nop;
toggle shift register output latch
turn on interrupts
repeat

The nops just waited out the SPI transfer to complete vs waiting for the library to see an interrupt and respond.
The discrete lines were faster than running in a for loop which I saw on a scope was adding about 12uS for each pass thru the loop tracking code.

So your application of hardware and code will decide whether 4uS is good enough for you, or whether you need faster, and if faster will interfere with whatever your code is doing.
Designing & building electrical circuits for over 25 years.  Screw Shield for Mega/Due/Uno,  Bobuino with ATMega1284P, & other '328P & '1284P creations & offerings at  my website.

bobcousins

So are you asking why systems running with 16 MHz clocks (62.5 nS period) have software timing limits of 4uS?
Ah ok, now that is language I can understand. :)

Ideally, there would be a 32 bit timer running at 1MHz which the software would read to get microseconds. But the AVR does not have any 32 bit timers, and the few timers it has are used for several purposes.

To get a 32 bit microsecond timer, the Arduino code uses the current value of Timer 0 which an 8 bit timer also used for PWM, and an overflow count of Timer0 which is updated using an overflow interrupt.

Probably Arduino could have created a more accurate timer at the expense of other functions, but the current implementation is good enough for most purposes.

So I guess the limitation here is that more bits = more transistors = bigger die = higher cost, although there is a certain amount of marketing involved in choosing what mix of features to include at a particular price point.

Please don't PM me asking for help. Ask questions in the forum.

arduidiot

Sure i mean ive got a handle on adding storage with extra EEPROM but im having huge troubles with the clocks at the moment so much is a translation of terminology coupled with my tendancy to guess terminology
im a good observer. not the brightest but very curious.

that poor innocent dog died from AC. he died.

I do not refuse my dinner simply because I do not understand the process of digestion."

Go Up
 


Please enter a valid email to subscribe

Confirm your email address

We need to confirm your email address.
To complete the subscription, please click the link in the email we just sent you.

Thank you for subscribing!

Arduino
via Egeo 16
Torino, 10131
Italy