Hi,
I am new in the community and have no global view of existing projects and hardware capabilities.
I just want to know if it is possible to do not use a central (discrete-time) clock at hardware level but rather discrete-events driving the computations in arduino.
Is there any existing projects dealing with this subject? (i did not find any)
thanks
lisandru
What sort of events, how often and what sort of computations are to be done?
Most microprocessors spend most of their time waiting for a button to be pushed.
any types of events (from environment or inside the processor). At another scale, IBM is using an event-driven approach for its new processors (IBM Research Blog | IBM Research) I wonder if any analogy is possible with arduino...
to be more precise, an event is usually (in the simulation world) a possible computation.
if there is an event, something happen (a computation)
if there is no event, there is no computations
so, eg, is there a way for microprocessors to do not "wait for a button to be pushed"? but rather to be activated if the button is pushed?
"waiting" is driven by the discrete-time clock that will make a processor check, at a given frequency, something to happen at each time step.
with discrete-events, there is no clock and the event precisely happens at a certain time...
In a way almost everything is somehow clocked in a microcontroller.
Events like digital input states and changes are realtime (but sampled clocked), timers a litte bit, brownout is realtime, ...
Interrupts make the builtin event-scheduler.
So what are you looking for that is not already available?
if any analogy is possible with arduino
No.
lisandru:
Hi,
I am new in the community and have no global view of existing projects and hardware capabilities.
I just want to know if it is possible to do not use a central (discrete-time) clock at hardware level but rather discrete-events driving the computations in arduino.
Is there any existing projects dealing with this subject? (i did not find any)
Each Arduino board offers at least two pins that can be used for "external interrupts" and different triggering modes (HIGH, LOW, CHANGE, RISING, FALLING):
Besides of that much more pins can be used for "pinchange interrupts", but they are not supported by an Arduino core library directly (you'd have to use a third-party library or low-level register programming) and the trigger mode is limited to CHANGE of the pin state only.
thank you!
pin state changes seem to be coherent with discrete-events
at arduino core level, using low-level programming, can you get rid of clock driving?
or an event would be equivalent to interrupt checking at each clock step?
lisandru:
so, eg, is there a way for microprocessors to do not "wait for a button to be pushed"? but rather to be activated if the button is pushed?
And what is the MCU supposed to be doing between button pushes except waiting? I can't think of a third state between doing and waiting,
Why would it make any difference if, during the waiting period, the MCU clock is running?
My sense of what you have said so far is that you are confused between the business of the microprocessor and the business of the program that it is executing. Didn't Turing demonstrate that any machine can emulate any other.
As long as your program behaves the way you want how can it matter what may be happening under the hood?
Perhaps you have not clearly explained what is in your mind?
...R
lisandru:
pin state changes seem to be coherent with discrete-events
at arduino core level, using low-level programming, can you get rid of clock driving?
I don't know anything about "discrete-events".
What is it?
What do you want to do with your microcontroller?
lisandru:
or an event would be equivalent to interrupt checking at each clock step?
Something like that. But not really. Though the hardware will use each clock step to determine whether an interrupt condition is true, the execution of interrupts takes much longer time. So after an interrupt condition has become true, a whole bunch of things is done in a program that has enabled an interrupt handler for an interrupt condition:
- the main program is paused
- the whole status of the controllers main program and hardware registers is saved
- the interrupt handler routine is executed
- the whole status of the controllers main program and hardware registers is restored back again
- the main program resumes executing
For a "do nothing" interrupt handler this means, that the interrupt on a 16 MHz controller takes about 4 microseconds execution time for nothing. Plus the time your interrupt handler routine will take.
Plus: You cannot execute anything you want within an interrupt handling routine. Every hardware and register is only available ONCE within the controller, such like RAM, EEPROM, each Serial port, I2C and SPI busses and so on. So these hardware devices are "shared deviced", shared between "main program" and "interrupt handler". If any overlapping occurs, any used ressource on the controller has to be safely booked, locked and used, or "race conditions" or "dead locks" may occur.
Improper use of interrupts will make your program slow or ineffective, or maybe locks execution to a "hang" of the whole program due to a deadlock, so that nothing is executed any more, neither the interrupt handler nor the main program.
So carefully check if and how you want to use interrupts, or you might get into trouble as a newbie. Interrupts is for advanced programmers and for situations where usage of interrupts is adequate.
you are right a mapping is always possible
my idea is more to get a kind of one-to-one mapping (or as close as possible)
between software and hardware
if you think of many MCUs each one having their own clock or sharing one
their synchronization would be quite hard, inefficient, and unprecise (not for all cases
but one can think to events occurring on different time bases)
think about neurons
they have no clocks
it is why ibm achieve such energy/speed improvements with a discrete-event approach
so you can be in a waiting state but doing no computations
and wake up by the causality of an event
lisandru:
it is why ibm achieve such energy/speed improvements with a discrete-event approach
so you can be in a waiting state but doing no computations
and wake up by the causality of an event
Some MCUs are happy to work with a ZERO clock speed - I don't know if the Atmegas can.
It is easy to arrange for an Atmega to go to sleep and to be woken by an interrupt. Nick Gammon has a good tutorial on power saving techniques
...R
lisandru:
it is why ibm achieve such energy/speed improvements with a discrete-event approach
so you can be in a waiting state but doing no computations
and wake up by the causality of an event
So your question is about "energy saving", i.e. for a battery operated microcontroller?
Yes, also the Atmega microcontrollers support different sleepmodes, including the POWERDOWN sleepmode with no clocking of the microcontroller at all.
In POWERDOWN sleepmode the amount of current used by the microcontroller is much less than 1µA.
But if you like to create battery operated devices with such a low sleepmode current, you will have to design your own circuit and will hardly be able to use any ready-to-use Arduino boards.
On Arduino boards, the extra devices like "voltage regulator" and "USB-Serial" chip draw much more current than the microcontroller in sleepmode itself. So it will not be of much use to you if you just put the microcontroller to POWERDOWN mode consuming nearly no current, while the voltage regulator and USB-Serial IC is using normal power.
Robin2:
Some MCUs are happy to work with a ZERO clock speed - I don't know if the Atmegas can.It is easy to arrange for an Atmega to go to sleep and to be woken by an interrupt. Nick Gammon has a good tutorial on power saving techniques
...R
it seems to be possible to "Arrange to wake the processor from sleep only when needed"
Also, "(…)These techniques would be useful for battery-powered devices where the full power of the processor was only required intermittently"
Then, I wonder if this technic can be dynamically used for events external to the arduino and also internal. I.e., how fast are the wake-up and the go-to-sleep phases... ("For a fast wake-up (which means you get on with what you want to do more quickly) disable brown-out detection by altering the fuses. That's assuming you want to disable brown-out detection.")
Maybe the whole approach is too complicated... i mean using clock-based processors to exchange events.
Ok I just noticed that Jurs answered this question. Dealing with massive interrupts (for representing discrete-events (internal and external to the Arduino), i.e., a possible state change at a certain time) will be inefficient and too complicated.
I will admit this is a bit over my pay grade.
But I just recently was looking at the MSP430
and it seems designed to do exactly what your looking for.
guys
i just found a thesis
is.muni.cz/th/328023/fi_m/Thesis.pdf
embedding interrupts in discrete-events and MSP430:
"By replacing a few low-level components (those shaded in figure 1.2), TOSSIM translates
hardware interrupts into discrete simulator events; the simulator event queue delivers the interrupts
that drive the execution of a TinyOS application. When the core loop executes a simulator event, it
sets global state to indicate which mote is currently running. A simulator event calls an interrupt
handler in hardware abstraction components. The interrupt handler signals TinyOS events and calls
TinyOS commands, just as it would on a mote. The remainder of TinyOS code runs unchanged.
TOSSIM keeps time at 4 MHz. All simulator events are timestamped and processed in global time
order." (page 6)
and for MSP430 :
"Microcontrollers often have several power states, with varying power draws, wakeup latencies, and
peripheral support. The microcontroller should always be in the lowest possible power state that can
satisfy application requirements. Determining this state accurately requires knowing a great deal about
the power state of many subsystems and their peripherals. Additionally, state transitions are common.
Every time a microcontroller handles an interrupt, it moves from a low power state to an active state,
and whenever the TinyOS scheduler finds the task queue empty, it returns the microcontroller to a low
power state.
Tmote Sky sensor motes feature Texas Instrument MSP430 microcontroller. This is an ultra low
power microcontroller featuring 10 kB of RAM, 48 kB of flash, and 128 B of information storage.
This 16-bit RISC processor features extremely low active and sleep current consumption that permits
Tmote to run for years on a single pair of AA batteries [15].
...
However the approach used in MSP430 based platforms is costly,
introducing 40-60 cycles of overhead to every interrupt that wakes the system up, which can be a
bottleneck on the rate at which the system can handle interrupts.
" (page 19)
but it seems to work
lisandru:
Then, I wonder if this technic can be dynamically used for events external to the arduino and also internal. I.e., how fast are the wake-up and the go-to-sleep phases... ("For a fast wake-up (which means you get on with what you want to do more quickly) disable brown-out detection by altering the fuses. That's assuming you want to disable brown-out detection.")
I have not got any sense from all of your writings as to WHY the sort of complexity that you are talking about might be useful.
Just because you CAN (or might be able to) do something does not mean that it is worthwhile.
...R
Robin2:
I have not got any sense from all of your writings as to WHY the sort of complexity that you are talking about might be useful.Just because you CAN (or might be able to) do something does not mean that it is worthwhile.
...R
- i don't think i am adding any complexity. If the MCUs here are clock driven and do not seem to be adapted to discrete-event driving it does not mean that discrete-event approach is complex
- I personally think that discrete-events are more logical than a centralized approach using clocks difficult to synchronize, etc.
and that it is more natural so simple... so you would achieve more complex tasks using simpler tools. - then, it is why i am curious about their implementation at hardware level. Again look at ibm that is using its neuromorphic chips to improve speech recognition (thanks to the precision of discrete-events) and if you want more advantages, pls have a look here : http://www.technologyreview.com/news/529691/ibm-chip-processes-data-similar-to-the-way-your-brain-does/
- finally, i agree that the arduino interactive concept is at another scale but it might be worth thinking about making it a small brain
but then another hardware architecture seems to be required.
Google "asynchronous circuit"
Can"t see it happening any time soon on a low cost microcontroller (it's been a luke-warm topic of debate since the mid 1980s, IIRC)
Groove:
Google "asynchronous circuit"
Can"t see it happening any time soon on a low cost microcontroller (it's been a luke-warm topic of debate since the mid 1980s, IIRC)
maybe using HDL and circuit synthesis?
thanks!
lisandru:
- i don't think i am adding any complexity. ....
- I personally think that discrete-events are more logical than a centralized approach using clocks difficult to synchronize, etc.
and that it is more natural so simple... so you would achieve more complex tasks using simpler tools.
It seems to me that an Arduino does 16 million discrete events per second
Again look at ibm that is using its neuromorphic chips to improve speech recognition (thanks to the precision of discrete-events)
Why would discrete-events be more precise?
How much more precise?
...R