What computer are you using.

[ElectroLawndart]

I was just wondering what people were using for their onboard computers and what kind of programming enviroment they are working in.

If I can learn how to use the poll function in this thread I will put one together.

I'm currently using an old 68HC11 with 32K of memory. I'm using this because I have a bunch of them lying around. If somethings gotta break, might as well be the cheap stuff. My programming IDE is ICC11. I currently have some PIC's that I got from Microchip's samples program and a couple of PC/104 single board computers. I'll be using the PICs or Atmel AVR for the pitot tube that I need to build. I'm still intimidated by the PC/104.

Dart

[LukeZ]

Dart, I'm using PICs and a PC104. Originally I figured PC104 would be a quicker way for me to get my feet wet because I had no experience with microcontrollers and lots of experience with PCs, which is all a PC104 is. However, once I got the sucker I realized like you that it's a bit intimidating. What takes but the push of a button on a regular PC (to turn it on), is now an involved research project with the PC104. I had to learn way more than I ever wanted to know about the BIOS and operating systems in general. Having got past that things are going a bit more smoothly now. I have the MZ104 (http://www.tri-m.com/products/engineering/mz104.html) from Tri-M Systems. Now that I know a bit more I almost wish I had spent the extra bucks and gotten one that already had A/D and other bells and whistles built in... but those things get real expensive. My PC104 cost $400 with the accessories (Ram and DiskOnChip hard drive), then I spent another $80 or so for a video card: and so far as I know, I went the cheap route. (The video card is for development purposes, I won't include it on the plane.)

I'll be writing all my programs on the PC104 in C. Currently I'm using DJGPP's (http://www.delorie.com/djgpp/) compiler for DOS (I'm running DR-Dos as the OS), and Dev-C (http://www.bloodshed.net/dev/index.html) as my IDE. It was a bit of a pain to get it to work with DJGPP but it's ok now. The Dev-C IDE is a lot like Microsoft's Visual Studio in the way it's laid out, which is what I'm familiar with, so that helps. I'm new to C programming but it's coming along ok.

After all that, it became clear as I learned more that I'd really need to use some microcontrollers as well... now that I see what they can do, I probably could get away using nothing else. For now though I've decided to have a PIC to run all the A/D for my onboard sensors, that will communicate with my PC104 through RS485. I just got my first PIC a week or so ago, it's an 18F452. So far I've got the light to blink and now I'm working on getting it to to communicate serially. RS485 is nice because if I want to add other PICs to the network it will be easy to do so.

For the PIC I guess I'm just going to use Assembler with Microchip's free MPLab IDE. I may try their C compiler, I don't know. It looks like it's pretty much free for all the functionality I'd need. I suppose I need to fire it up and give it a try.

Boy, there is so much to learn. There's lots of days I go to bed with my brain toasted... this is really going to be a long term project for me.

[ElectroLawndart]

LukeZ

I know what you mean. I bought a PC/104 '486 off of eBay. At least I bought one with onboard VGA...for all the good it does me. After looking at documentation I doubt that I'll have the time or the patience to get past the "Hello World" phase with this thing. I'm more in tune with microcontrollers than the whole x86 thing.

I stopped programming in assembly ages ago when compilers started getting better at building tighter code. I forgot who said it but it true. "The amount of time required to maintain one line of code is the same for Assembly or some other high level language".

Are you doing this as a hobby project or a school project?

Dart

[LukeZ]

I've been out of school for a while, this is just for the fun of it. It's been something I've wanted to do since I was a kid, though I still think I'm probably a year or more away from having something that flies.

By the way, what language do you prefer for PIC programming? I've seen that Quick Basic is popular but I just don't think I can justify the expense at this point.

[Arp]

I am using the following. (Since I desperately want image processing, I cannot use microcontrollers.)

1) Glider

Type: PCM-5335 (PC-104 mainboard)
CPU: Geode GX-1
Storage: 1 GB CompactFlash card
OS (historical): Linux Mandrake
OS (current): Debian GNU/Linux
Language: C++

2) Robot

Type: X-Board / DIMM-PC
CPU: Geode SC 1200
Storage: 128 MB onboard Flash, ext. USB Flash
Language/OS: probably the same

[ElectroLawndart]

LukeZ,
If you have the time and patience try PICC Lite. It's freeware and can be had from Hi-tech's website. Just Google "PICC". Pretty much all of my programming is done in C. I do use Visual Basic for some quickie PC progamming. I am NOT a professional programmer by any strech of the imagination. Just someone that ignorant to realize just how difficult this is BEFORE I commited myself to this project. :D

Arp,
How hard is it to get a PC/104 to become something useful? I have a couple of PC/104 '486s with video and 32Mb of RAM that I got off of eBay. I downloaded the Debian CD images off their website a couple of weeks ago for an old Intel PII PC box I'v got kicking around to test my interface designs. If I'm gonna blow something up because shorted the +12v to the PCI bus, might as well be that old box instead of the Athlon 64. :rolleyes:

Thanks
Dart

P.S. My PC programming experience is limited to Visual Basic and trying to get through "Learn Visual C++ in 21 Days" book. That one is very frustrating. Are there some other books you might recommend?

[Arp]

My experience:

1) Supply voltage

The board which I use... has single supply voltage (5 V only). Therefore, I never faced the question of where to get 12 V. Had the question arisen... I would have probably used a DC/DC converter (I already use some converters from TracoPower).

2) Cables

Vendor provided cables for keyboard/mouse, VGA, LAN and USB and RS-232. During my initial experiments, I used those (later made my own). I had to additionally obtain an IDE cable/converter between my board (slim laptop connector) and CD-ROM drive (full desktop connector, separate power connector).

3) CompactFlash

CompactFlash cards are supposed to be IDE-compatible. One should buy only cards which have wear-leveling implemented (otherwise they wear out quickly, especially if measures are not taken to reduce disk use).

I encountered some problems with the CompactFlash card. Some distros failed to recognize it ("no device where to create filesystems"). Some required that I switch off DMA (frequently done with the boot option "ide=nodma").

2) Installation

Eventually, I got an old Mandrake installed, and later found that Debian also worked. Both were installed from CD (although I also played with floppies, I decided to abandon those -- although a floppy-loaded network install might be convenient enough).

Since I knew that my graphics card was touchy, during installation, I avoided touching it. Graphical interfaces are neat, and highly recommended to successfully configure Mandrake (Debian has comfortable command-line tools)... but if your first intall crashes upon XF86 installation, better choose VESA (instead of the card's own brand) or leave it entirely unconfigured second time.

3) Developing

I personally... like native development (on the target platform). Cross-compiling is something I consider the field of OS developers -- and won't touch if given a chance. Thus (and having enough space on the CompactFlash card, although I could have hooked up a remote disk via LAN for this purpose) I installed the GCC toolkit directly on my PC-104 board, and even now, develop stuff directly on it.

4) Sample code

If someone wants sample code for doing something fairly ordinary under Linux and C... for example accessing COM ports, or driving a Parallax servo controller (NOTE: Parallax controllers use TTL-level signaling, so if you have RS-232 level ports, you need a converter between them)... then if I have it... I might be able to provide some.

[radiohound]

I am using the following. (Since I desperately want image processing, I cannot use microcontrollers.)


Hello Arp,

I'm not sure how technical you want your image processing to be, but there is still an option for those who wish to use microcontrollers. The CMU Cam does color tracking accross it's pixels, and a bit more. It is fairly powerful for its size. Requires only a serial connection. Here are it's capabilities:

The CMUcam2+ has the following functionality:

Track user-defined colors at up to 50 Frames Per Second (FPS)
Track motion using frame differencing at 26 FPS
Find the centroid of any tracked data
Gather mean color and variance information
Gather a 28 bin histogram of each color channel
Manipulate horizontally pixel-differenced images
Transfer a real-time binary bitmap of the tracked pixels in an image
Arbitrary image windowing
Adjust the camera's image properties
Dump a raw image (single or multiple channels)
Up to 160 X 255 resolution
Supports multiple baudrates
Control 5 servo outputs
Automatically use servos to do two axis color tracking

http://www-2.cs.cmu.edu/~cmucam/

www.acroname.com has them for sale. Parallax also has one of their models for sale.

Again, don't know if it will work for what you want to do, but it is a viable option for those working with microcontollers.

[Arp]

It seems a most interesting option indeed.

Unfortunately, I will require possibility of accessing all pixels of each incoming frame (currently 320x240) -- and analyzing, depending on features found, some 25% of them using a custom algorithm. It may become necessary to pull frames from two cameras simultaneously (unless I get one camera with a very wide field of view).

For successful tracking different-colored surfaces and lines (walls, floor, ceiling and regions separating them) I expect that my code must obtain and process at least 15 frames per second, in suffiently adaptive fashion... as to never (in predictable conditions, that is, no sudden darkness or blinding light) lose track of what is happening.

In short... a level of flexibility is needed... which demands at least 266 MHz from a 32-bit processor (with various accelerating lookup tables smeared around notable amounts of RAM)... and even then, I may find myself running short on processing power (I very much hope that either Kontron, E-Value or some other manufacturer of system-on-modules will eventually produce somthing small enough to hover indoors in gigahertz class).

[TimAuton]

I'm using a Gumstix, plus a Linksys NSLU2 for development (not flying) as Gumstix doesn't have USB-host yet. USB is for a webcam for digital video, I thought about machine vision but I won't try that for a while (except perhaps a horizon sensor, just because it should be easy!).

Mine only collects data so far, it doesn't control anything. For that I'll use a microcontroller of some description, probably an AVR. The Robostix board for the Gumstix looks nice, but I'll need another mcu for power management and sensor processing anyway, so may end up with two AVRs, plus the ARM in the Gumstix. Storage is SD cards, so up to 1GB if I buy a bigger card.

Code is mainly C.

[Arp]

If you have a version with Bluetooth...

...would it not be possible to port Gnokii onto Gumstix (unless it is already ported) and start pulling images from a Nokia camera phone?

(I know, silly thought -- performance will probably be awful. But one *would* get pictures at some rate.)

[sesat]

With BT you could trawl for people's address books ala Paris Hilton / TomsHardware tutorial.


Ram.

[LukeZ]

As I had mentioned it before I thought I'd post a quick follow-up: I did finally download and install Microchip's C18 C compiler. Dart had recommended trying PICCLite which is free, but it doesn't run on the 18's which are the chips I'm currently using. Hitech has a C compiler for the 18 line (PICC 18) but it's definitely not free - about a thousand bucks.

Anyways, Microchip's C18 is free. After 60 days a certain optimization routine becomes disabled, I didn't read into it very much, only enough to see that it was not something which I would ever even need, and if it was something you needed, you'd also likely be someone with the bucks to afford it.

I'm not the world's most knowledgeable C person so getting it set up took some research, but it wasn't so bad. After that it's a breeze to use. There's tons of documentation; I'd post some links but currently the Microchip site is down. The two documents that were of most use to me were the C18 User's Guide and the C18 Libraries Documentation.

You get to use the same MPLAB IDE, so if you're used to programming in Assembly it's an easy conversion. And in fact the support for assembly is really great: I had a lot of assembly functions I didn't want to re-write, but no problem- they can be called directly from C with very little modification. As can C routines from assembly.

Microchip has recently added support for formatted output (fprintf, etc), which is really great for things like printing to an LCD, for example. The only thing they seem to have omitted with the formatted output is support for floating point characters; however, I found some routines for Float to Ascii on the net that can be used. I expect this will be something added in a future upgrade, as it's been heavily requested on the Microchip forum.

The download also comes with tons of sample code - for example, they have routines for UART, SPI, I2C, CAN, RS232, ADC, and PWM included, and not only that, many of them come with code for hardware and software implementations, should you need both, or if your particular chip doesn't happen to have a hardware UART, for example - all very nice.

Anyways, if you're using a PIC18 device, and want to program in C, I'd highly recommend Microchip's C18 C compiler. Otherwise if you're using a PIC16, which I suspect the majority of people are, it looks like PICC Lite is a good, free way to go.


Luke

[kbosak]

P.S. My PC programming experience is limited to Visual Basic and trying to get through "Learn Visual C++ in 21 Days" book. That one is very frustrating. Are there some other books you might recommend?
Don't tell me you cannot learn it in 21 days! :rolleyes:
In fact strong nackround in C was helpful for me (Kernighan& Ritchie), then directly into Stroustrup and 3-5 years to get mature programming style and stop shooting yourself in the foot. The real benefits of C++ over C came only with nontrivial research projects, some 2-3 yrs from starting point.
Read at least few of them, real value:
* Kernighan, Ritchie "C programming language" (thin starting point)
* Stroustrup "C++ programming language" (solid reference)
* Meyers "More efficient C++" (take special look at this one)
* Sutter "Exceptional C++" (as previous)
* Lippman "Inside C++ object model" (for gurus and realtime C++)
* Murray "C++ strategy & tactics" (as Meyers)
* Plauger "The C++ standard library" (reference, complementary to stroustrup which is more about syntax than library)
* Knuth "The art of computer programming" (a reference, nobody will surprise you with amazing, revolutionary discovery in IT if you have this 20yrs old book)
* Sedgewick "Algorithms in C++" (to get the ammo)
* Press, Teukolsky, Vetterling, Flannery "Numerical Recipes in C" (2nd ed.) (to get even more ammo)
* Müllges, Uhlig "Numerical Algorithms with C" (more ammo for smooth targets)
* Petzold "Programming windows in C" (for ground station programming ;-) )
The rest are just poor imitations of those classics.

[kbosak]

Otherwise if you're using a PIC16, which I suspect the majority of people are, it looks like PICC Lite is a good, free way to go.

Luke
Any comparisons between CC5X free from bknd vs PICC Lite? I know free bknd has 1kb code limit than could be avoided with linker and makefiles. But how about code optimization and real world efficiency, in particular interrupt latency and the fact that bknd tends to reject compiling complex math expressions in conditions (ifs) - requires expanding the code line by line.