* Video switcher for the security system on the MX Missile Train
* Mechanical shuttered camera control system for high speed photography (back in the day)
* Multispectral camera control system (used to detect hydrogen fires around the shuttle engines)
* Laser range gating control systems (used in conjunction with low light level cameras to see through dust storms, etc.)
Primarily all done with Motorola and Zilog processors.
It's not real hard because you don't actually program it per se it's more like a series of waypoints and other structures that you add in an .xml file, among other formats to a special directory and the machine recognizes. I might have some links to pertinent sites if the hamsters ever start behaving.
I started before PC's were even a glimmer in the mental eye of a hardware designer.
Mainframes, dont'cha know.
Then moved into embedded software and stayed there for a goodly number of years.
Which do I prefer? Depends really. It's a lot easier to do some things in a PC app, because you have such a huge framework beneath your code. But it's also easier to do some things in embedded code - because you haven't got any massive framework getting in your way.
The fun thing is to do both - PC for HMI, net and storage, communications with embedded which handles sensors and real time interface that the PC is truly cr@p at...
If you get an email telling you that you can catch Swine Flu from tinned pork then just delete it. It's Spam.
Got some dev work to do for a Raspberry Pi but I currently can't find the time to get it started although I would love to get it to control the points and lights on my lads train set. Unfortunately I don't think it's powerful enough to do the project I really want and that is to have a video and audio input and then host a web site of the live input feed, so sort of a 1 way Skype.
Before I jumped to C# I did quite a lot of embedded programming. Infra-red and microwave motion detectors, vehicle and driver's license barcode readers and biometric access controllers to name a few.
Real fun comes in using your PC or mobile device to control these devices, In university I edited my one project to receive sms's and control a relay switch, I connected it to my kettle in my dorm room. Thus in the cold winter days I would start boiling my kettle when we left the classroom by just sending an sms
I once wrote code for a PIC microcontroller, doing data acquisition that required precise timing. It was only a single page of code, and I actually had to count instructions to get the timing right. We were triggering a sensor at one interval, and an audible alarm at another.
The project was for a local raptor[^] rescue center, so the whole thing was...
As I guess most coders at a certain age have done, I developed for some pre PC Era computers like KC85 (uses Z80 Clone) and C64 (6510). I don't think they were ment with "Toys or Gadgets".
Nowadays embedded devices are available und affordable. It became more convenient and more easy to run your own code on such mobile computers like smartphones and even embedded boards. They are everywhere.
While programming a single device is fun, new challenges arise with (mobile) sensor networks as you have lots of them to run "one application" in the net. If you already have say one quadrocopter - why not use it to update the map of an NXT-Type Lego robot? I guess the future in gadget development to have a whole zoo of devices which should act toghether.
Wrote a controller for a washing machine many many years ago. This didn't have a CPU. My memory is a bit hazy but it was basically a 4 bit memory chip where the lower 2 bits of the output data lines were fed into the lower 2 bits of the address bus. There was a water level sensor, that would also turn off the water when it was full using some logic gates, and a single bit timer that both fed into the upper 2 bits of the address bus, and upper 2 bits of the data bus went out to water on/water drain, and a Timer start/reset line that also turned on the motor when the timer was running.
So it was very sequential. The output at address 0 turned on the water. When the water hit full it raised the 3rd bit on the address bus, and the instruction at (binary) 0100 turned off the water, started the motor and output 00 for the lower 2 bits still (so data is 1100 - timer on, motor on, water on/not draining but was stopped by the water full sensor). So then address 1100 (timer finished, water still full) stopped the motor, reset the timer, and output 01 to the address bus. 0101 (timer stopped water full, but at next instruction) drained the water. The water level sensor was a flip flop thing, so once full the sensor wouldn't return zero until it was empty. So then at 0001 we start the rinse cycle. Etc.
I've been messing around with Arduinos the last 6 months or so, even down to programming the ATTiny85 chips...fun stuff making your code do something in the physical world. Just blinky LED projects so far, but I'm working up to a robot
Not an Arduino but Netduino and used that to make a full sized traffic light for my kids to play with.To keep the nerd level up, the sources of the toy were properly Unit tested
Toying with the physical world is always fun.
Yeah, I did something similar with stop lights at a 4 way intersection for a model train set...haven't tried a Netduino yet, thought it would be good practice to dust off my C/C++ with Arduino...anyway, plain old Arduinos are cheaper...you can get an Arduino Nano on eBay for $11.00 Cdn or an ATTiny85 for $1.50 Cdn.
I am planning on buying some Arduino's and some Raspberry PIs and making a fully 'computized' Lego city with my approx. 100+ pounds of Legos, my HO-Scale model trains, the computer things above, a lot of wires, and a LOT of time (and space)! I also am going to write a remote control system for it.
That is, if I ever get enough money, time, space, and patience to do this!
The internet is a great way to get on the net.
Last Visit: 31-Dec-99 18:00 Last Update: 28-Jul-16 16:02