In the age of low power, connected devices, one can imagine a world where many IoT sensors (Internet of Things) are basically everywhere, from water tube joints, light bulbs, gas pipes - basically in every place where a fault requires notification.
Low power means they ought to consume the least they can under normal conditions, and eventually use higher power to communicate the detected failure.
It might be possible, in some cases, to have a zero-power (or near zero) consumption device, which, by means of electronics, could be bootstrapped and powered just in case of a hardware-detected fault.
Let's take a light bulb for example. You apply power to the bulb, and you expect a current to flow through it. This smart device could, with very low consumption, only power up if the power is applied and current is near zero, and warn that the bulb is defective.
An idea.
quarta-feira, 30 de abril de 2014
terça-feira, 8 de maio de 2012
Transmission lines ? Algo que a malta de Electro devia saber....
I guess I'm in the mood :)
I just came across this article on Transmission Lines and series termination:
http://www.vagrearg.org/?p=transline
something our electronic students should know about, but rarely are told or teached.
The article is not 100% correct, but the basics are there, and definitely worth a read.
Just to wrap up: note that all DDR (from DDR1 to DDR3) use what is called SSTL signalling (Stub Series Terminated Logic), which is based on the very principle the article displays. There are many more signalling/interface standards, just google for them, but all high-speed are also based on the transmission line concept.
Kudos to Dangerous Prototypes for always supporting and encouraging these articles.
Alvie
I just came across this article on Transmission Lines and series termination:
http://www.vagrearg.org/?p=transline
something our electronic students should know about, but rarely are told or teached.
The article is not 100% correct, but the basics are there, and definitely worth a read.
Just to wrap up: note that all DDR (from DDR1 to DDR3) use what is called SSTL signalling (Stub Series Terminated Logic), which is based on the very principle the article displays. There are many more signalling/interface standards, just google for them, but all high-speed are also based on the transmission line concept.
Kudos to Dangerous Prototypes for always supporting and encouraging these articles.
Alvie
segunda-feira, 7 de maio de 2012
Never free() before you exit()
Due to a recently bug in my ZPUino programmer while running on Windows 7, which was caused by an invalid free() just before exit() the program, I came to the conclusion that all those free() before exiting are absurd under the operating systems we use.
Truth is all resources (non-shared) by your application will be released when the program exits. The memory allocation routines and algorithms run almost exclusively on your program domain (such as *alloc() in "C", and "new()" in C++), and there's no direct connections between those allocators and the chunks they allocate (all goes into a space called heap). So, when your program exits, all "heap" allocated by it will be lost, independently of how many malloc() you called, on how many new() you did [side note: on C++ you would still have to call all destructor eventually, but not release memory per-se].
The way your operating system allocates heap space (memory) for your application is often done using very simple methods like brk()/sbrk() on Linux / UNIX. And HeapAlloc() and friends on Windows. The management of this big memory area is done by your application itself (although using userspace OS methods to ease your path, like malloc() ).
When you're leaving the program, if you free() all of your memory, your application will:
a) Spend a whole lot of CPU cycles going through all your alloc() tables, eventually reclaiming memory space to the OS,
b) Release everything to the OS.
Why do a) ? Just spending CPU cycles, and power. OS does not know how you manage your memory (it does not have to), so it's a pretty much useless step.
So, if you're to exit your application, just forget memory allocation. Your OS will free all of your memory, despite you "freeing" it yourself or not. And, more important, there's absolutely no difference if you do free() it, or not.
Alvie
Truth is all resources (non-shared) by your application will be released when the program exits. The memory allocation routines and algorithms run almost exclusively on your program domain (such as *alloc() in "C", and "new()" in C++), and there's no direct connections between those allocators and the chunks they allocate (all goes into a space called heap). So, when your program exits, all "heap" allocated by it will be lost, independently of how many malloc() you called, on how many new() you did [side note: on C++ you would still have to call all destructor eventually, but not release memory per-se].
The way your operating system allocates heap space (memory) for your application is often done using very simple methods like brk()/sbrk() on Linux / UNIX. And HeapAlloc() and friends on Windows. The management of this big memory area is done by your application itself (although using userspace OS methods to ease your path, like malloc() ).
When you're leaving the program, if you free() all of your memory, your application will:
a) Spend a whole lot of CPU cycles going through all your alloc() tables, eventually reclaiming memory space to the OS,
b) Release everything to the OS.
Why do a) ? Just spending CPU cycles, and power. OS does not know how you manage your memory (it does not have to), so it's a pretty much useless step.
So, if you're to exit your application, just forget memory allocation. Your OS will free all of your memory, despite you "freeing" it yourself or not. And, more important, there's absolutely no difference if you do free() it, or not.
Alvie
quarta-feira, 27 de maio de 2009
São agora 21h51, 27 de Maio de 2009, e acabei de ver um meteorito entrar na atmosfera e ficar visivel por imenso tempo (cerca de 3 minutos - ou mais) que sinceramente pensei que fosse um avião ou qualquer outro engenho. Só quando se desfez (o que se nota pela mudança de cor - fica avermelhado) me apercebi que realmente era um meteorito. Estúpido que até pensei is buscar a máquina fotográfica - mas como seria um engenho iria fazer figura de tal.
Acho que é altura de pedir um desejo.
Acho que é altura de pedir um desejo.
Vai ser de vez....
Desta vez vai ser de vez ! :)
À boa maneira dos bloggers, vou começar a partilhar as coisas mais estúpidas, sem interesse, e ademais absurdas que me passarem pela mente. Ou talvez não...
À boa maneira dos bloggers, vou começar a partilhar as coisas mais estúpidas, sem interesse, e ademais absurdas que me passarem pela mente. Ou talvez não...
Subscrever:
Mensagens (Atom)