potato-powered web server

when i see pages like this, it scares me a little to think how similar i am to this person.

myhdl

cool project converts python directly to vhdl or verilog. looks like it's under active development, with demo projects posted. if i ever need to use an fpga or cpld again, i know where to go.

and one of the examples uses the cypress fx2 usb controller chip, with references to other dsp interface projects (at 30 MB/s) including a 33khz adc fpga/fx2 microcontroller demo.

data acquisition, serial interfaces

nice little article summarizing the various serial bus standards for ic networks: rs-232, rs-422, rs-485, spi, i2c, mirowire, 1-wire, and plain old bit banging. a bit dated at 2002, but still handy.

looks like rs485 is what you need for high-speed transmission over significant distances. spi slows down a lot when you take it off the pcb and looks more like a can bus.

maybe the way to go for low volume is a tiny linux server. lantronix makes the xport pro. digi international makes the digiconnect me (or digi connectme?) that can run picotux. marvell semiconductor makes the sheevaplug. all pretty small and lightweight, and you can just plug an ethernet cable into the darn thing and forget about it.

hmm, the xport pro seems to be highly geared toward network services and the external interface is limited to ~8kB/s serial. digi connect me 9210 might be better for data logging. or maybe gumstix? it's hard to find specs for data acquisition on their website.

mccdaq.com have some ~reasonably priced boards, though their stuff looks like it's either pci boards or clunky usb endpoints. multichannel, though.

another route would be a high-speed usb (up to 40MB/s) with the cypress ez-usb fx2lp (like cyzc68013a). check out www.elrasoft.com/hsusbm.htm and the project listed there by dcarr.

chording keyboards

one of these days i'll build myself a chording keyboard, so i can walk around with my netbook in a backpack running knoppix+adriane like a wanna-be cyborg. cursory googling turned up a few good links, foremost among them the spiffchorder for its usbness. http://chorder.cs.vassar.edu/spiffchorder/forside http://cuddlepuddle.org/~adam/pickey/index.html http://www.chordite.com/ http://www.sigchi.org/chi97/proceedings/paper/fkm.htm#U4 wow, there are some scary people out there who take the cyborg thing way too seriously. now i know what my fate would have been had i never married.

circuit protection

i've been thinking that if i want to be a real grown-up with probes or circuit-pc interfaces, i'll need to use some protection. ptc resistors are cheap and easy overcurrent protectors. they basically increase in resistance by orders of magnitude when they pass a critical current. digikey has one that trips at 25 mA, about right for mcu io. varistors (eg mov) and avalanche diodes have a complementary role, passing large currents at critical voltages. so maybe a transient voltage suppressor in parallel with a load with a series ptc (with maybe a ~high power resistor to absorb the energy) could protect against both esd and stupidity in a cheap and easy way. according to littelfuse, though, the tvs can have too much capacitance to use them on high-bandwidth signal lines. they recommend their powerguard pgb0010603, which mouser carries for ~30 cents each.

avr microcontrollers

some frustration with the lack of good open source high-level language support for pics has lead me to investigate accessibility for the avr and other platforms made by atmel. apparently isp is at least as easy, judging by this parallel port programmer. other designs leave out the pull-up resistor on reset and drive it directly; some even leave out all the current-limiting resistors, leaving nothing but a homemade cable. can't get any simpler (and less safe) than that. (one note: some people use pin 18 instead of 20 and 21 on the parallel port for gnd.) plenty of designs out there for usb programmers, too, so i could use my netbook to flash an avr. but i think they all use an avr, so the 2-resistor programmer will always have its place. i couldn't find any refs on using the parallel port to power the mcu during programming, but i guess it doesn't matter since it will need power from the circuit to test/use. still need to familiarize myself with all the available options for avrs. here is the atmel product guide with feature tables, etc. apparently atmel is much more stingy with samples than microchip, so i'll just have to order some from digikey or mouser. gcc has an avr backend! it seems almost too good to be true. and there is the pymite project; still looks young but under active development. if i go far into embedded stuff, i'll eventually need to use a rtos, like freertos, to keep my code modular and simple and to give me some platform independence.

pics and sd/mmc

i found a few links describing how to use sd/mmc flash cards in spi mode with pics. i think this guy has the approach that is easiest to follow with his gps logger, though i haven't tried it yet myself. doesn't look too hard to write raw data, at least.

using picprog

i used picprog successfully to read (on both laptop and desktop) and write (on desktop only; wimpy laptop!) hexes to/from pics. i found that sometimes i needed to use --erase with --burn to get it to start when a totally different hex was already on the pic, and --slow helped with the bad idea of trying to burn a pic in a breadboard (picprog --erase --burn -i code.hex --slow). always make sure to read the pic (picprog -o save.hex) before writing in case you screw up the calibrations. sometimes the auto device recognition didn't work, and i had to use --device pic18f877a (for example) the first time i ran it after plugging in the programmer. after the first time, though, it seemed to remember what i had on there. when i first tried to burn a hex to my pics, i found that picprog 1.7-r1 didn't work with my jdm2 programmer (worked for reading, though). i had to upgrade to 1.8.3, which worked just fine. i haven't encountered this yet, but i might need to upgrade to 1.9.0 to use the --reboot option if i use the internal oscillator. jdm programmers have a well-known problem with pics in this configuration because they will start running as soon as they're turned on.

usb oscilloscope

wow, i've gotta try this. it gives you about 60hHz with almost nothing but a pic 18f and a usb port. i think i could do it without the serial bootloader, which makes it even simpler. sure, it's not the most powerful dso, but it's so simple and would help me make a better one if i wanted to. the biggest challenge would probably be software. the author wrote his scope code in visual basic. (!!?! well, i guess i can't complain.) so i'd have to reimplement. but it might be a good way for me to learn how to do usb data xfer in linux, anyway. and maybe i can make an inteface to comedi. i think that would let me use it with xoscope. neither looks like it's released a new version in a while, but i've tried xoscope before (with the soundcard oscope, heh) and it worked okay. i've also been thinking about how to do a cheap and easy high-speed dso. i think video capture adcs are the way to go, with data fed directly to 5-10ns sram. the TVP7001PZP, for example, can do up to 165MHz with a pll internally-multiplied clk for 3 syched channels. built-in scaling and offset, with i2c interface would make it easy to control with a usb pic. for triggers, maybe i could set voltages on dacs and use an opamp comparator with a latch so that the leisurely pic could stop the adc a given time after triggering. the position of the trigger time within the data window wouldn't be exact, but the trigger wouldn't need to be checked at the same speed as the adc. i think it could actually work, and i'm surprised i can't find anyone who's already done it. hmm, maybe that should tell me something.... well, i can't find any reports of failure, either. EDIT: there is an updated firmware version here that provides 5 analog and 8 digital inputs. i tried messing around with gpdasm and gpasm on the hexes, and the non-bootloader hexes produced by gpasm for the 18f458, 18f2550, and 18f4550 are identical. i think i will do the same thing with the superprobe and put a diode instead of a resistor on mclr. rb6 and rb7 will already have some leads for the digital io, so i just need to plug in to the +5 and gnd on the usb to program this thing with my serial programmer.

icd2 clone?

now that i've finished a pic icsp, i wonder how hard it would be to make an icd2 clone for debugging. i've seen a few versions out there, but they all look somewhat complicated. this one is probably the simplest i've seen, but according to the author, it worked with mplab 6.5, didn't work with 7.11, and hasn't been tested with other versions. i guess i'll wait until someone smarter than i (and with more free time) comes out with something that does more in software.

finished my superprobe!

i finally finished my superprobe. i even managed to squeeze it into an empty habanero shake-a-salsa bottle for a stylish homebrew aesthetic. i made just a few changes from the mondo-technology design: 1. i put a diode on /mclr and resistors on rb6 and rb7, so i could program the pic in-circuit without frying everything. 2. i used a 16f877a instead of a 16f870. i changed two lines in supmp.asm: <       list      p=16f870               ; list directive to define processor <       #include          ; processor specific variable definitions --- >       list      p=16f877a >       #include but the two parts are similar enough that when i compile both of these with gpasm, the resulting hexes are identical. oddly, these hexes are significantly different from the SUPER.HEX provided by the mondo-technology page, which i assume was compiled from super.src with an unknown compiler. i used the gpasm version and it seems to work just fine. 3. instead of a passive crystal, i used a ECS-2200AX-200 on osc1 and left osc2 flapping in the breeze. so i didn't need the pair of 22pF caps, but i did find that a tiny bit capacitance (<1nF) from clk to gnd helped the osc get started. 4. instead of using power from the circuit, i decided it was much more convenient and a little safer to use a 9v battery. i have so many of those things from changing smoke alarms (and the superprobe takes so little power) that i have practically a limitless supply. it works great, and it has an amazing number of features for such a simple project. there is one glaring omission, however; there is no ohmmeter. were it not for this, i could almost entirely replace my old multimeter with this superprobe. i wonder if i could add such a feature... microchip shows a circuit and code in an512 for an ohmmeter that uses a capacitor for measuring time constants. the problem is, the resistor to be measured needs to be between the cap and gnd, and the superprobe puts the neg probe electrode at gnd. could i just use a simple voltage divider with the existing resistors on rax? the resistance would then be v/(1-v)*r, where v is the ratio of adc voltage to supply and r is the resistance of the feed resistor. by putting ra1-ra5 and rc6-rc7 high, the feed resistance can be as low as 60 ohm, though this probably isn't much better that just using the 100ohm resistor (puts out up to 85mA, too). on the high end, i could use a 100kohm feed resistor which might let me measure up to 750kohm or so. i guess the big question is whether or not there is room on the pic for this. EDIT: maybe an algorithm like this would work. and i could use the 100, 10k, and 100k ohm resistors. that way i could set the decimal location (in kohms) by the resistor that was used. 10.00 to 99.99 for the 100kohm 1.000 to 9.999 for the 10kohm .0000 to .9999 for the 100ohm and i could get up to 1Mohm by moving the decimal for voltage ratios >.5 with the 100kohm 100.0 to 999.9 for the 100kohm, v > .5 i don't think i would get good precision for much higher than 2Mohm, anyway. the max power dissipation would be with a 0omh load, at .25 watt in the 100ohm resistor and 50mA current, which is no problem. the max power dissipation in the measured device would be for a 100ohm load, at .125 watt and 25mA. this could be a problem for smd parts. typically 1206 and bigger resistors are rated at 1/8 watt, but 0805 and smaller are rated lower. maybe i could get away with it if i just used pulses and delayed between measurements, so that the average power is lower. i read somewhere that smd resistors can have ratings as low as 1/20 watt; if a measurement cycles through the three source resistors with the voltage turned off during the computation, the average power should be less than 1/24 watt. so maybe power dissipation is nothing to worry about. hmm. actually it would probably make the code simpler if i used these ranges: 100.0 to 999.9 for the 100kohm 01.00 to 99.99 for the 10kohm .0000 to .9999 for the 100ohm i would lose a digit of precision for the 1k to 9.99k range. but i wouldn't have to do anything to account for the source resistance.

finished my pic programmer!

i finally finished my high-voltage pic programmer and tested it out. i used ian's icsp jdm2-style design, with a few modifications: 1. i made a one-sided board with 3 jumpers. (ian mentions this variant; i think he designed it to be easy to do one-sided.) 2. i use alligator clips instead of header pins. 3. most significantly, i used a stack of diodes in place of the 8v2 zener. radio smack didn't have an 8v2, and i didn't want to pay s&h for a $.30 part. so i used a 5v1 zener, an led, an ordinary silicon diode, and a 100ohm resistor in series. that puts the programming voltage right in the 12-13v sweet spot, and the led gives me a nice programming activity indicator. i tried it out on a 16f877a and a 18f458 with picprog. my dell laptop couldn't muster the 12v for burning, but it can read them okay. the desktop could also read just fine, but i had problems burning the chips while they were in a breadboard. i could barely limp with a little blink-an-led test program by repeatedly burning without erasing. each time it would write a few more bytes before failing to verify. when i tried it on a 16f877a that i had soldered into a perf board, though, it worked perfectly. first time, every time. lesson learned: breadboards are evil. when i tried out the blink-an-led on the breadboard, i couldn't get a stable clock. that's not too surprising, considering i was using a 20MHz crystal. but i didn't think that nasty capacitance was so bad that couldn't even use the relatively low-speed programmer. oh, well. now that i'm used to soldering, i don't really see an advantage to the breadboard anymore. i think the easiest way to do it is to solder the pic in first, program it, then solder other components and test along the way.

pic bootloaders

the tiny pic bootloader page lists a number of other bootloaders. i haven't looked at all of them in detail, but it sounds like zpl might be the best one for me. it's not much bigger than the tiny bl, and it requires no modification of the bootloaded hex. i think it can even use hexes written to use other bootloaders, but i'd have to try that to be sure. the interface hardware is really simple (3 resistors, one transistor, and an optional led). other than vdd and vss, it only connects to /mclr. so it doesn't use _any_ i/o pins and can be left in while the pic is running. the front end is in python (with pyserial) so it's multiplatform. i just had to change 'import serial' to 'import serial.serialposix as serial' in zpl.py and delete the non-functional serial.py that comes with it so it would use my built-in pyserial. one downside is that the communication is one-way; there is no way to verify the reprogramming. there is an option to rewrite the hex a given number of times, as a quick fix in a noisy situation. given the way it works, it might also be quite a bit slower but i'll have to check that. the bootloader won't overwrite itself, nor will it change the fuses (even though the pic could do either). so fuse configuration changes and changes in clock frequency will need the old jdm2 with the vpp sledgehammer, but at least zpl will never kill itself. for quick dev/debug iterations without big changes to the circuit, this bootloader should be ideal.

free space optics

i just stumbled across RONJA. sounds pretty cool. they claim to get almost a mile with just a high-brightness led.  i wonder if it would work better than my cantenna...

wireless measurements

right now, with one of the default whip monopoles, i get about 30 yards range outside my house for my wap. i'd like to go about 10 times that in one direction. so that would be 10 dbi gain needed for an antenna. that should be doable with a homebrew.

homebrew eeg

i came across this project today. looks pretty cool, especially when combined with brainwave synchronization with binaural beats. i would need to make some electrodes, but they have designs for both passive (saltwater) electrodes and fairly simple active ones. i could probably get silver wire from a jewelry supplier. EDIT: i think active electrodes are the way to go. the links here to joe's, jim's, and pedro's (the other 2 links to bioera.net are dead) show schematics and construction tips. jim and pedro use joerg's modification of jarek's original v2 prototype. looks like joerg made the following changes. 1. added a 200 ohm decoupling resistor between the opamp and the shield 2. changed the power bypass cap from 100nF to 10nF 3. added what looks like a lowpass with 2 100pF caps and a 10k ohm resistor 4. added 100 ohm power protection resistor to power supply 5. added a 2v 'vgnd' for bias current electrode

led circuits

i've seen a number of circuits online lately for squeezing the last joule from dead batteries and using it to power an led. this page seems to have the most info.