I have a photocell that gives me the intensity of light in voltage. I want to add a unique number (that I can hard-code on the chip) along with the photocell info and send in a format I can read using a digital computer (Arduino). Any suggestion when I can start?
Sounds like you want to shop for a cheap micro controller that's easy to work with, has an ADC, and a small amount of flash memory. Almost every silicon vendor will claim to have something meeting that requirement, what you are familiar with and can easily buy in appropriate quantities may matter as much as the technical details of the offering. If you already have an arduino, another atmel part such as one of the 8-pin attiny's might be attractive.
You write a little program with a loop that reads the photocell through the ADC, bundles it with an ID number which you store in the flash beside your program, and ships it off through something like a serial port to whatever system needs the information.
Serial port can be a UART peripheral or bit-banged in a software timing loop. For short runs people often skip the line driver/receiver on each end and signal at logic voltage rather than the higher voltage (and inverted sense, the drivers/receivers invert for you) of the RS232 spec. Or you can use other schemes, synchronous ones like SPI or I2C being popular as well.
You might want to look at maxim one-wire bus devices.
They share a bus connection and ground and your ardunio can interrogate the bus.
Each device has a unique identifer and can be read.
The DS2438 is a cheap member of the family that can measure voltage.
(The DS2450 was a quad A/D converter but it was a buggy chip and is now obsolete.)
Ardunio drivers at http://www.arduino.cc/playground/Learning/OneWire
Related
I am a physicist, and I had a revelation a few weeks ago about how I might be able to use my personal computer to get much finer control over laboratory experiments than is typically the case. Before I ran off to try this out though, I wanted to check the feasibility with people who have more expertise than myself in such matters.
The idea is to use the i/o ports---VGA, ethernet, speaker jacks, etc.---on the computer to talk directly to the sensors and actuators in the experimental setup. E.g. cut open one side of an ethernet cable (with the other end attached to the computer) and send each line to a different device. I knew a postdoc who did something very similar using a BeagleBone. He wrote some assembly code that let him sync everything with the internal clock and used the GPIO pins to effectively give him a hybrid signal generator/scope that was completely programmable. It seems like the same thing should be possible with a laptop, and this would have the additional benefit that you can do data analysis from the same device.
The main potential difficulty that I foresee is that the hardware on a BeagleBone is designed with this sort of i/o in mind, whereas I expect the hardware on a laptop will probably be harder to control directly. I know for example (from some preliminary investigation, http://ask.metafilter.com/125812/Simple-USB-control-how-to-blink-an-LED-via-code) that USB ports will be difficult to access this way, and VGA is (according to VGA 15 pin port data read and write using Matlab) impossible. I haven't found anything about using other ports like ethernet or speaker jacks, though.
So the main question is: will this idea be feasible (without investing many months for each new variation of the hardware), and if so what type of i/o (ethernet, speaker jacks, etc.) is likely to be the best bet?
Auxiliary questions are:
Where can I find material to learn how I might go about executing this plan? I'm not even sure what keywords to plug in on Google.
Will the ease with which I can do this depend strongly on operating system or hardware brand?
The only cable I can think of for a pc that can get close to this would be a parallel printer cable which is pretty much gone away. It's a 25 wire cable that data is spread across so that it can send more data at the same time. I'm just not sure if you can target a specific line or if it's more of a left to right fill as data is sent.
To use one on a laptop today would definitely be difficult. You won't find any laptops with parallel ports. There are usb to parallel cables and serial to parallel cables but I would guess that the only control you would have it to the usb or serial interface and not the parallel.
As for Ethernet, you have 4 twisted pair with only 2 pair in use and 2 pair that are extra.
There's some hardware that available called Zwave that you might want to look into. Zwave will allow you to build a network of devices that communicate in a mesh. I'm not sure what kind of response time you need.
I actually just thought of something that might be a good solution. Check out security equipment. There's a lot of equipment available for pc's that monitor doors, windows, sensors, etc. That industry might what your looking for.
I think the easiest way would be to use the USB port as a Human Interface Device (HID) and using a custom built PIC program and a PIC that includes the USB functionality to encode the data to be sent to the computer and in that way be able to program it independently from the OS due to the fact that all mayor OS have the HID USB functionality.
Anyways if you used your MIC/VGA/HDMI whatever other port you still need a device to encode the data or transmit it, and another program inside the computer to decode that data being sent.
And remember that different hardware has different software (drivers) that might decode the raw data in other odd ways rendering your IO hardware dependent.
Hope this helps, but thats why the USB was invented in the first place to make it hardware and os independent.
I would like to have Arduino operating in a CAN network. Does the software that provides OSI model network layer exist for Arduino? I would imagine detecting the HI/LOW levels with GPIO/ADC and sending the signal to the network with DAC. It would be nice to have that without any extra hardware attached. I don't mind to have a terminating resistor required by the CAN network though.
By Arduino I mean any of them. My intention is to keep the development environmen.
If such a software does not exist, is there any technical obstacle for that, like limited flash size (again, I don't mean particular board with certain Atmega chip).
You can write a bit banging CAN driver, but it has many limitations.
First it's the timeing, it's hard to achieve the bit timing and also the arbitration.
You will be able to get 10kb or perhaps even 50kb but that consumes a huge amount of your cpu time.
And the code itself is a pain.
You have to calculate the CRC on the fly (easy) but to implement the collision detection and all the timing parameters is not easy.
Once, I done this for a company, but it was a realy bad idea.
Better buy a chip for 1 Euro and be happy.
There are several CAN Bus Shield boards available (e.g: this, and this), and that would be a far better solution. It is not just a matter of the controller chip, the bus interface, line drivers, and power all need to be considered. If you have the resources and skills you can of course create your own board or bread-board for less.
Even if you bit-bang it via GPIO you would need some hardware mods I believe to handle bus contention detection, and it would be very slow and may not interoperate well with "real" CAN controllers on the bus.
If your aim is to communicate between devices of your own design rather than off-the shelf CAN devices, then you don't need CAN for that, and something proprietary will suffice, and a UART will perform faster that a bit-banged CAN implementation.
I don't think, that such software exists. CAN bus is more complex, than for example I2C. Basically you would have to implement functionality of both CAN controller and CAN transceiver. See this thread for more details (in German).
Alternatively you could use one of the CAN shields. Another option were to use BeagleBone with suitable CAN cape.
Also take a look at AVR-CAN.
I'm looking for a GPS for a small class project. We want the smallest GPS possible and all we really need it to do is to give us longitude and latitude values when we poll it.
I tried looking at sparkfun, but since we haven't really worked with this type of hardware before, it's hard to know which kind we really want/what parts we need.
What We Need:
smallest possible
longest battery life
only need long and lat
able to be polled from some other device such as a mobile app or website
Thanks!
there are two paths to this, one is just get a bluetooth receiver, you will be able to poll it from a mobile phone or whatever. going to likely be as big as the phone, have the battery inside, etc. not sure how long it will last on one charge.
There are other solutions designed for putting in packages being shipped, better battery life, but their goal is as data loggers and not necessarily something you can cable up and poll and likely not wireless if that is what you are after.
Now if you want to build your own, and you already went to sparkfun, here is another path.
I know that leaving links in an answer at SO is bad...This was longer than a comment and will add some more info...
You want small you can go with this
https://www.sparkfun.com/products/11571
It is a GP-635T gps receiver, if you look at the picture it really is around the size of a quarter. 50 channel. Point it up the way they tell you, antenna is built in, just power it and it works.
You will need to hook up to it. It is the serial version not usb, in either case you need a cable like this.
https://www.sparkfun.com/products/10361
This link is to a cable with 6 or 8 inch pigtails, the gps receiver comes on a board with a not so uncommon connector on it, this cable allows you get at those connections, you only need three.
The datasheet on the sparkfun page or probably just search for the part number, you need to look at the UART TTL pinouts not the usb pinouts. Yo uneed 3.3 to 5.5volts to power it pin 2, pin 1 is ground. then pin 3 is txa serial out. This is where you get your data.
these are various solutions that will work
https://www.sparkfun.com/products/9873
https://www.sparkfun.com/products/718
http://jim.sh/ftx/
some soldering may be required. The above links are various solutions between $10 and $15 for ftdi usb to serial/uart break out boards. These will include 3.3v and ground and the rx pin is the receiver for the ftdi uart, you tie that to txa on the gps unit.
What you may not know and may be interested in is that almost universally gps units do their math magic and come up with the various items time, position (2d or 3d), speed, etc. And they output this data in a serial manner. search for NMEA or NMEA-0183. The data sheet for this and any other should give an indication of the default data rate (4800, 9600, 19200, etc baud) and what messages are sent. sometimes you can change the baud rate, sometimes you cant. The ftdi chips/boards are very flexible use a usb cable to plug in the board to a computer, configure your software or a dumb terminal program like minicom or hyperterm or teraterm or whatever (no parity, no hardware flow control) and the messages will appear usually once a second. Whether it is your car navigation, handheld gps, whatever, buried inside is some flavor of gps reciever (sparkfun will give you an indication of just how many different flavors there are and their selection is just scratching the surface) that outputs serial and the software in that unit is receiving that serial data and then doing its thing (mapping, navigating, etc). As with modems back in the day the ones you find in your cell phone might have some of the software/math done by the main processor in the phone to save on money, these libraries are not generally available, when you make the deal to buy thousands or millions of units they allow you to pay for the software to go with it along with your signature on a bunch of legal documents. I assume this is the case, that is how the ones in phones are down to $10 or so where these fully contained solutions are usually $50 to $100 in single quantities and likely not a lot cheaper in quantity.
Once powered, even if it says X number of seconds hot or cold to lock it doesnt always take that, sometimes if it has to search it may still take a while, the less metal you have around (like being in a building or the center of a car) the worse it is to the point it may not lock.
if you have an older garmin street pilot (that is otherwise dead I would hate to kill one of those if it is working) you can rip it apart and likely find a sirf III or other module in there, likely a 5V not 3.3 (there are 5V ftdi based breakout usb to serial. the microftx is both 5v and 3.3, note the gps receiver linked above is also 5v or 3.3) googling will be required to figure out the pinout and such, and soldering might or might not be a challenge.
you can also find old etrex or other handhelds on ebay or wherever (that work!) and for $15 or so get a serial cable, well then you need a serial to usb likely which will also need a level shifter like a max232, you dont plug this right into a ftdi break out board, it will fry it. newer ones have usb and you can power the unit from the usb and likely see the nmea data over the usb as well.
Most of the stuff you see on sparkfun in the gps area is going to be related to these various brands and models of gps recivers that output nmea data over serial. some are 5V some are 3.3, many do not have antennas and you have to buy those separately (and get the right kind, one that plugs into the connector provided, etc). I have a number of these items and they all work just fine, some do better than others around buildings or in trees, etc. Around sparkfun you will also find lipo battery solutions and bluetooth or xbee or other wireless solutions, very quickly if you need wireless, I think you will find just buying an off the shelf solution is best. I have had my eye on the garmin bluetooth thing google
Garmin GLO Portable GPS and GLONASS Receiver
it is about $99. I have not pulled the trigger yet so I dont know how good or bad it is, the el cheapo brands just look cheap.
Of course, a smart phone has both wireless and a gps and you can get a lot of used phones for cheap on ebay. Ios and android. You could "just write an android app" and put it on the phone and use one of the wireless interfaces built into the phone. It will chew through the battery yes, how fast? who knows.
I have been searching around [in vain] for some good links/sources to help understand GPIOs and why they are used in embedded systems. Can anyone please point me to some ?
In any useful system, the CPU has to have some way to interact with the outside world - be it lights or sounds presented to the user or electrical signals used to communicate with other parts of the system. A GPIO (general purpose input/output) pin lets you either get input for your program from outside the CPU or to provide output to the user.
Some uses for GPIOs as inputs:
detect button presses
receive interrupt requests from external devices
Some uses for GPIOs as outputs:
blink an LED
sound a buzzer
control power for external devices
A good case for a bidirectional GPIO or a set of GPIOs can be to "bit-bang" a protocol that your SoC doesn't provide natively. You could roll your own SPI or I2C interface, for example.
The reason you cannot find an answer is probably because if you know what an embedded system is and does, or indeed anything about digital electronic systems, then the answer is rather too obvious to write down! That is to say that if you get as far a s actually implementing a working embedded system, you should already know what they are.
GPIO pins are as a minimum, two state digital logic I/O. In most cases some or all of them may also be interrupt sources. These interrupts may have options for be rising, falling, dual edge, or level triggering.
On some targets GPIO pins may have configurable output circuitry to allow, for example, external pull-ups to be omitted, or to allow connection to devices that require open-collector outputs, and in some cases even to provide filtering of high frequency noise and glitches.
In most embedded systems, a processor will be ultimately responsible for sensing the state of various devices which translate external stimuli to digital-level logic voltages (e.g. when a button is pushed, a pin will go low; otherwise it will sit high), and controlling devices which translate logic-level voltages directly into action (e.g. when a pin is high, a light will go on; when low, it will go off). It used to be that processors did not have general-purpose I/O, but would instead have to use a shared bus communicate with devices that could process I/O requests and set or report the state of the external circuits. Although this approach was not entirely without advantages (one processor could monitor or control thousands of circuits on a shared bus) it was inconvenient in many real-world applications.
While it is possible for a processor to control any number of inputs and outputs using a four-wire SPI bus or even a two-wire I2C bus, in many cases the number of signals a processor will need to monitor or control is sufficiently small that it's easier to simply include the circuitry to monitor or control some signals directly on the chip itself. Although dedicated interfacing hardware will frequently have output-only or input-only pins (the person choosing the hardware interface chips will know how many signals need to be monitored, and how many need to be controlled), a particular family of processor may be used in some applications that require e.g. 4 inputs and 28 outputs, and other applications that require 28 inputs and 4 outputs. Instead of requiring that different parts be used in applications with different balances between inputs and outputs, it's simpler to just have one part with inputs that can be configured as inputs or outputs, as needed.
I think you have it backwards. GPIO is the default in electronics. It's a pin, a signal, that can be programmed. Everything is made up of these. For a processor, dedicated peripherals are a special case, they're extras for when you know you want a more limited function.
From a chip manufacturers perspective, you often don't know exactly what the user needs so you can't make the exact peripherals on your chip. You make generic ones instead. Many applications are so rare that there's no market for a specific chip. Only thing you can do is use GPIO or make specific hardware yourself. Also, all (unused or potentially unused) pins are worth turning into GPIO because that makes the part even more generic and reusable. Generic and reusable is very nearly the whole point of programmable chips, otherwise you would just make ASICs.
Some particularly suitable applications:
Reset parts (chips) in a system
Interface to switches, keypads, lights (all they have is one pin/signal!)
Controlling loads with relays or semicondctor switches (on-off)
Solenoid, motor, heater, valve...
Get interrupts from single signals
Thermostats, limit switches, level detectors, alarm devices...
BTW, the Parallax Propeller has practically nothing but GPIO pins. Peripherals are made in software. It works very well for many uses.
Almost all electronic devices comes with firmwares. I know it is stored in ROM (Read only memory) so it becomes non-volatile (no power source required to hold the contents from getting erased like RAM)
What I want to know is "How firmwares communicate to the electronic devices to perform its operations?"
Let say there is a small roller.. On press of a button, how it makes it to move?
Can someone please explain what is residing behind, to make it happen..
I think it may require a little brief explanation to unwind it..
Also what is the most popular language used for coding firmwares?
Modern hardware like you're describing has a program stored in ROM and an all-purpose microcomputer (CPU) executing that program.
The CPU reads information from ROM by setting up addresses on its address bus and then asking the ROM to tell it the value stored at that location. There's something like a read pulse being raised (on a separate line) to tell the ROM to make the value accessible on the lines of the data bus. That, in a nutshell, is reading.
To get the hardware to do something, the CPU basically executes a kind of write operation. It puts a value, which is just a bunch of bits if you want to look at it that way, on the address bus to select a certain device and perhaps function on that device, then it raises another signal line saying "write!" The device that recognizes its address on the address bus responds to that signal by accepting the data from the data bus and then performing whatever its function is. Typically, one of the data bus bits will be connected within the output device to a power output stage, i.e. a transistor stronger than the ones used just for computation, and that transistor will connect some electrical device to current sufficient to make it move/glow/whatever.
Tiny, cheap devices are coded in assembly language to save costs for ROM; in industrial quantities, even small amounts of memory can affect price. The assembly language is specific to the CPU; some chips called "8051", "6502" and "Atmel (something or other)" are popular. Bigger devices with more complex requirements may have their firmware written in C or a C-like dialect, which makes programming a little easier than assembler. The bigges ones even run C++ code. Compiled, of course.
In most systems there are special memory addresses which are used for I/O. Reading and writing on such addresses executes some function instead of just moving data around. In x86 systems there are also special I/O instructions IN and OUT for that.
The simplest case is called general parallel I/O (GPIO), where you can read or write data directly from/to external electrical pins on the device. There are several memory addresses, called registers, where you can read data from the port (voltage near 0 = 0, near supply voltage = 1), where you can write data to the port, and where you can define whether a particular pin is input (the corresponding bit is typically 0) or output (the bit is 1). Every microcontroller has GPIO.
So in your example the button could be connected to a pin set to input, which the software could sense. It would typically do this every 10ms and only react if it has a stable value for several reads, this is called debouncing. Then it would write a 1 to some output, which via some transistor for amplification could drive a motor. If it senses that you release the switch it could turn the motor off again by writing a 0. And so on, this program would run until you turn the device off.
There are lots of other I/O devices for other purposes with typically hundreds of registers for controlling them. If you want to see more you could look into the data sheet of some microcontroller. For example, here is the data sheet of ATtiny4/5/9/10, a very small controller from the Atmel AVR family.
Today most firmware is written in C, except for the smallest devices and for a little special code for handling resets and interrupts, which is written in assembly language.