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.

3d pdf objects

apparently there a couple of ways to embed 3d objects in pdf files. viewers can pan, rotate, and zoom on a quite smooth 3d model *drool*. i haven't seen much on the really really new format, and it's only supported in new versions of acroread. but the older u3d format is out there and already seems to be near-abandonware. there's a spec def on sourceforge that is the only free implementation i've found so far, though this page has some links i should check out. (click fast, it's tripod!) maybe one of these days i'll write something to convert meshes to u3d so i can embed them in docs.

project management software

in my never-ending quest for project management software that will organize me, i've come across a few that might be worth a try. ganttproject seems to be focused on gantt charts, and can import and export ms project files. gnome planner (formerly from imenio) looks nice and does gantt/resource management, but i've read reviews saying it lacks too many features that ms project has and can't really replace it. opensched sounds very interesting, as it will do the scheduling for you, given tasks and resources. it produces latex reports, too. but it looks like it hasn't been updated since 1999. projman sounds like it has scheduling capability and import/export compatibility with gnome planner, but i can't find out much more about it. xplan looks ancient and crappy. (developed in an all-sun environment? come on, i don't think sun develops in an all-sun environment.) taskjuggler looks like one of the most feature-rich os pm packages out there. i'm particularly intrigued by the mention of 'risk analysis'. i've also had my interest piqued by descriptions of chandler. from their docs, it sounds like a dream come true. but i've also read bad things about their own project management. doesn't bode well when an organization software project seems disorganized.... but i'll give it a look.

EDIT: they finally kicked 1.0 out the door, just before daddy warbucks kicked them out the door. but then the blog abruptly stops in mid 2008. wonder if it will keep going in the foss wild.

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...