suitable Embedded system to be used for image processing and gps/gsm - embedded

i am working on a project, where i would like to install an embedded system in a certain location , the system is provided with a camera , the system has to perform image processing functions on the images obtained from the camera.
The system must be attached with gps and gsm modules.
i am in the process of choosing the hardware needed, i am thinking of using a beagle board or FPGA , which one is more suitable for my application ? do you recommend other boards? do you know any gsm or gps modules that can be interfaced with these modules?
Thank you

If your image processing algorithms are too CPU intensive I'll suggest you consider FPGAs. Otherwise, Beagle board is fine.

What is the interface to your camera? USB / FireWire / I2C / other? If the Beagle Board supports what you need, and can handle the processing, that's probably the easiest way to go - FireWire and USB interfaces are not exactly trivial to do on an FPGA, unless you can get a board and a matching Linux distro for it, where everything is configured and working out of the box (and it's probably going to be expensive then...).
GPS modules typically connect over a simple serial connection, so that shouldn't be an issue for either solution.

Related

how to port uclinux linux to any microcontroller

I have stellaris LM4f232 evaluation borad. I have ported free rtos , sysbios to stellaris lm4f232 board and successfully developed an gps tracking application . But I always wanted to port uc linux for my board . my question are
i) is there any material to port uclinux to any controller
ii)what are necessary knowledge I required to do the same
I have googled a lot . I did n't get the right information, but I have seen posts that its difficult ,but I cant able to realise the same .any help????
iii) what is the road map to achieve it , what are the knowledge I should need to achieve this
Linux, even uCLinux requires considerable memory resources; you'd want to start with at least 2Mb for the boot device and 16Mb of RAM (although a minimal system can be booted in as little as 4Mb). On a microcontroller, this means that you must have external memory.
Another issue is that Cortex-M devices are optimised to run code from on-chip Flash memory, having separate buses for ROM and RAM so that data and instructions can be fetched simultaneously. uClinux must run from external RAM, which has a detrimental effect on the performance, and you will be unlikely to achieve the 1.25MIPS per MHz figure the CM4 is otherwise capable of. It is possible to arrange for time critical code to be placed in on-chip flash is necessary, but it is of course a limited resource.
Some good advice on the issues of deploying Linux on a Cortex-M device can be found here
I would suggest to have a look on buildroot which as far as I know can be build for this board.
adding to #Clifford , you can use u-boot (bootloader) ,already configured for many boards ,if your board is not on list you can edit it.,

Provide input data to FPGA using USB

I am working on Xilinx Spartan 3E platform, using this development board:
http://www.xilinx.com/products/boards-and-kits/HW-SPAR3E-SK-US-G.htm
My program operates on certain data and then provides output. I wish to transfer the input signals externally. The input data is a stream of 8-bit signals.
So, how do I send the input signals from my laptop to the FPGA via USB? Does Xilinx support this or is there standard software to do this?
Thanks.
It sounds like you are describing a uart more than a native USB interface. You can get a USB to logic level serial adapter that will let you easily transfer data to and from a Pc at up to 921.6k baud. A uart/serial port is easy to implement in the Fpga and PCs are easy to use with serial ports.
Here is the cable:
http://www.ftdichip.com/Products/Cables/USBTTLSerial.htm
If you have a development card it is very possible this type of interface is present.
On the software side you can use your programming language of choice as if it was interfacing with a seal port or use a terminal program like hyper terminal or Download teraterm http://ttssh2.sourceforge.jp/
Updated response:
100Hz is not a hard interface to make. At that rate you should use the serial interface if at all possible. The board you referenced has 2 full RS-232 connections. At that point you only need a way to connect that to your computer. If you have a PC with RS-232 connectors you only need a cable if you have a newer computer without you need a RS-232 to USB translator cable (like this one: http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=768-1014-ND or google rs232 usb). This will give you a virtual com port on the pc to interface with the previously mentioned terminal programs or your custom software.
Update 2:
on the resource tab of the development board page you linked to there are several UART based fpga designs that you should be able to use as a starting point.
i.e. the "PicoBlaze Processor SPI Flash Programmer".
That board doesn't provide easy access to the USB interface from the FPGA as far as I can tell. It's just for configuration and debug.
Some of the newer boards and tools do allow something called hardware-in-the-loop testing where the simulator can upload data to the FPGA, wait it to calculate the results and then pull the data back. This is relatively common when using Xilinx's System Generator product as the simulations can be really long.
But I think with that board you'd be better off using the on board RS232 port to get data to and from the board. You will have to build the infrastructure to do it yourself though.
This may also give you some ideas:
http://www.1pin-interface.com/

USB for embedded devices - designing a device driver/protocol stack

I have been tasked to write a device driver for an embedded device which will communicate with the micro controller via the SPI interface. Eventually, the USB interface will be used to download updated code externally and used during the verification phase.
My question is, does anyone know of a good reference design or documentation or online tutorial which covers the implementation/design of the USB protocol stack/device driver within an embedded system? I am just starting out and reading through the 650 page USB v2.0 spec is a little daunting at the moment.
Just as a FYI, the micro controller that I am using is a Freescale 9S12.
Mark
Based upon goldenmean's (-AD) comments I wanted to add the following info:
1) The embedded device uses a custom executive and makes no use of a COTS or RTOS.
2) The device will use interrupts to indicate data is ready to be retrieved from the device.
3) I have read through some of the docs regarding Linux, but since I am not at all familiar with Linux it isn't very helpful at the moment (though I am hoping it will be very quickly).
4) The design approach, for now at least, it to write a device driver for the USB device then a USB protocol layer (I/O) would reside on top of the device driver to interpret the data. I would assume this would be the best approach, though I could be wrong.
Edit - A year later
I just wanted to share a few items before they vanish from my mind in case I never work on a USB device again. I ran into a few obstacles when developing code and getting it up and running for the first.
The first problem I ran into was that when the USB device was connected to the Host (Windows in my case) was the host issues a Reset request. The USB device would reset and clear the interrupt enable flags. I didn't read the literature enough to know this was happening, thus I was never receiving the Set-Up Request Interrupt. It took me quite a while to figure this out.
The second problem I ran into was not handling the Set-Up Request for Set_Configuration properly. I was handling it, but I was not processing the request correctly in that the USB device was not sending an ACK when this Set-Up Request came in. I eventually found this out by using a hardware USB protocol analyzer.
There were other issues that I ran into, but these were the two biggest ones that took me quite a while to figure out. The other issue I had to worry about is big-endian and little-endian, Freescale 9S12 vs USB data format (Intel), respectively.
I ended up building the USB device driver similar to UART device drivers I had done in the past. I have posted the code to this at the following URL.
http://lordhog.wordpress.com/2010/12/13/usb-drive
I tend to use structures a lot, so people may not like them since they are not as portal as using #defines (e.g., MAX3420_SETUP_DATA_AVAIL_INT_REQR 0x20), but I like them since it makes the code more readable for me. If anyone has questions regarding it please feel free to e-mail and I can try to give some insight to it. The book "USB Complete: The Developer's Guide" was helpful, so long as you knew what areas to concentrate on. This was a simple application and only used low-speed USB.
While writing a device driver for any interface (USB, Parallel port, etc...) the code needed to be developed would depend upon whether there is any Operating System(OS), RTOS running on that Processor/Micro controller.
e.g. if thats going to run say WinCE - It will have its own Driver development Kit , and steps to be followed in the device driver development. Same for any other OS like Linux, symbian.
If its going to be a plain firmware code(No OS) which is going to control the processor/microcontroller, then it's a different situation altogether.
So based on either of the above situation u are in, one needs to read & understand:-
1.) The Hardware Specification of the processor/micro controller development board - Register files, ports, memory layout, etc.
2.) USB spec
3.) Couple of pointers i found quickly. Google shud be ur friend!
http://www.lrr.in.tum.de/Par/arch/usb/usbdoc/ - Linux USB device driver
http://www.microsoft.com/technet/archive/wce/support/usbce.mspx
-AD
I've used an earlier edition of USB Complete by Jan Axelson. Indeed very complete.
From the editorial review:
Now in its fourth edition, this developer's guide to the Universal Serial Bus (USB) interface covers all aspects of project development, such as hardware design, device firmware, and host application software.
I'm curious, why did you pick the 9S12? I used it at a previous job, and was not pleased.
It had lousy gcc support so we used Metrowerks
which may have been okay for C, but often generated buggy C++
had a lousy IDE with binary project files!
The 9s12 was also slow, a lot of instructions executed in 5 cycles.
Not very power efficient, either.
no barrel shifter, made operations that are common in embedded code slow
not that cheap.
About the only thing I dislike more is an 8051. I'm using an ARM CortexM3 at my current job, it's better than a 9S12 in every way (faster clock, more work done per clock, less power consumption, cheaper, good gcc support, 32-bit vs. 16-bit).
I don't know which hardware you're planning to use but assuming that's flexible, STMicro offers a line of microcontrollers with USB/SPI support and a library of C-code that can be used with their parts. -- I've used their ARM7 series micros for years with great success.
Here is an excellent site maintained by Jonathan Valvano, a professor at the University of Texas. He teaches four courses over there (three undergraduate, one graduate), all are about using a 9S12 microcontroller. His site contains all the lecture notes, lab manuals, and more importantly, starter files, that he uses for all his classes.
The website looks like it's from the 90's, but just dig around a bit and you should find everything you need.
users.ece.utexas.edu/~valvano/
Consider AVR for your next MCU project because of it's wonderful LUFA and V-USB libraries.
I'm working on a project using the Atmel V71. The processor is very powerful and among lot's of high end connectivity offered on chip is a USB engine that will do device or host modes for 480 Mhz or 48Mhz (not USB 3.0). The tools are free and come with a number of host and device USB example projects with all the USB stack code right there. It supports 10 end points and all the transfers are done via DMA so you have most of the processor horsepower available for other tasks. The Atmel USB stack works without needing an RTOS

How can I do bi-directional communication with a custom USB device?

I'm planning to build a USB device that has buttons that some software needs to respond to, and indicators that the software needs to control. I'm new to USB, so I'm looking for any pointers that will get me started.
When I did some USB development a while ago, I found the information at USB Central extremely valuable.
For low bandwidth requirements, you can use something like the FT232R which is a single-chip USB serial implementation. The FTDI drivers are readily available and make the device appear as a regular serial port to the host computer. This is orders of magnitude easier than rolling your own USB implementation (for either end!).
Kinda vague, but in the past I've done a little bit of USB development. The easiest stuff tends to be HID related device as the subset of USB used to commincate is very to implement on both sides. There are hardware devices which are essentially stubbed out to work with HID, you just customize some circuity and go.
The USB standard is actually quite readable. Though it might be a bit overkill if you just want to create a simple device. You could probably get something like this, which is basically an 8051 controller with a USB connector together with firmware and a DLL.
Checkout WinDriver, which is a commercial multiplatform tool what give you easy way to implement usb drivers in user mode, source code compatible between Linux and Windows.

GPS and Embedded Development - Where to find resources?

I'm just starting to design some embedded devices, and am looking for resources.
What I want to be able to do is to connect a GPS receiver to a lightweight SBC or mini-ITX, x86-based computer, and track a remote-controlled vehicle's location/progress.
Ideally, this could morph into building some hobby, semi-autonomous vehicles.
But what I need to start with is a development board for GPS programming.
What boards/packages have you used, and where can I find [preferably open source] development for them?
OpenEmbedded is a good place to go to get started. A lot of embedded products use ARM and other processors, so cross-compiling is a big deal. Buildroot is another resource for building custom linux kernels for small systems.
You can also find lots of manufacturers with Single Board Computers (SBCs) that have tools to do what you want - do a google search for "SBC Linux" and you should have a gold mine.
LinuxDevices keeps a pulse on the linux embedded community and you should find several good articles there that lead you to products or software to help you.
Debian has an embedded build, but I haven't explored that.
There are several books on embedded linux available if you want to go that route.
The GPS receiver simply connects to a serial or USB port, and present an NMEA stream of data, which you can parse with GPSD and several programs can access it through GPSD. It's a very simple text based format.
I've used regular PC motherboards, and Atmel AT91 processors for embedded systems (with GPS, cellular, etc). There's a lot of information out there right now, and it's not expensive to get into. If I were to start a new project, I'd look at the AVR32 processors from Atmel - they are very hobbyist friendly, and provide a lot of community support for linux on the AVR32 architecture. They provide free GCC compilers and significant framework and examples if you want to go the OS-less route and have a single program running on the processer as well.
Good luck!
-Adam
"NMEA" is the keyword to be searching for when looking for this stuff. While I haven't done anything with this in a long, long time, here is a good source for some boards and other hardware:
http://www.sparkfun.com/commerce/categories.php?c=4
We have had good luck with Holux GPS recievers (designed for samsung q1). A farily simple connect over serial port and you can read the NMEA string.
What OS are you targeting? If it's Linux there are a lot of GPS libraries available (here's a good list). GPSd and GpsDrive are two of the more popular ones I've seen.
I haven't see any GPS devices specifically for lightweight/embedded use, but many of the consumer GPS devices have USB hookups available that could probably work (watch out for low end ones, they usually don't have the computer interface).
I suggest starting with a plain old c project that reads and parses NMEA from a serial port. You can do this in Windows or Linux.
I usually break down any project like this into a set of smaller projects like:
read and parse NMEA from serial
port
establish a serial /
network link from the remote device
to the tracking system server
integrate the components
Wikipedia has a good article on the NMEA protocol. As Adam points out it's actually pretty simple.
Circuit Cellar magazine often has projects like this as well.
Depending on what you want to do, there are various sizes of target to consider. Use Atmel AVR for small low power (battery) stuff. Perhapse use Linux on an old laptop if I just wanted to rough out the concept and needed WiFi (or cellular) for internet.
The laptop Linux prototype then could be trimmed down and ported to an embedded Cinux system for even lower battery usage and portability later on. (not as low as Atmel though).
If you are comfortable with programming in Linux I would recommend the Gumstix range of small computers - http://www.gumstix.com/
You could pair the vedex motherboard with the GPSstix expansion board tp make a tiny GPS receiver with a well supported programming environment.
I suggest GPSBabel to communicate with your GPS receiver.
GPSBabel
Handles waypoints, tracks, and routes,
Knows lots of format (this explains the name Babel),
Runs on Windows, Linux, OSX,
Free.
Some people here have suggested devices like the gumstix - embedded devices which cost $149 without GPS. I don't understand that bit. A off-the-shelf TomTom comes with running Linux on ARM, built-in GPS, lots of flash, battery and screen. It's hard to beat the price advantage that comes with mass production. For your hobby project, the map included is not needed, but who cares?