A small twist to an old Classic ...

[LabRat]

I really wasn't sure which forum to post this concept to. There have been some recent posts about the use of the ATTINY in SSR's, and how those of us who are PIC centric would have to pickup new programmers etc. While that was going on I was already looking at the TRIKS-C (sometimes recorded as TRIX-C), board and wondering about re-spinning the concept to make use of a PIC instead. Why? Because I have PICs, and PIC tools. That's it.. nothing more romantic than that. (oh.. and also because the REN24LV boards I ordered from Frank haven't arrived yet.. :( (darned postal service)).

So.. taking the best of two projects, I present to you my first concept of...
(drum roll)... the "PIX-C"!! (yeah.. it wasn't really worth the build up was it?)

The Concept: Use 16F688 in place of the ATTINY in the TRICKS-C

Changes: In my design here, I've got RJ11's for receiving and re-transmission of the serial data. Why? Because I have a bag of them here, and I need to use them up. ;)

The PIC has fewer I/O pins, which means we don't have the pins to set jumper/switches to configure the address in order to support multiple panels. So my initial design was intended to be a smaller single panel only controller. But last night as I was dozing off, I had an epiphany.. why not leverage the code from the JEC pixel that allows for inline address programming. Transmit a coded byte sequence to the board, and re-program it's address that way! Concept wise it seems like it should work, and continue to support multiple panels with fewer pins.

The other caveat is that I don't have a spare pin for the "heartbeat" LED. I've wondered about using a pull=up on
one of the strobe lines, and attach an LED there. A sort of "in-line" logic probe. I've never tried this before, but something to
think about.

Well.. that's the theory anyways. If/when I finally get a) My LED's, b) a LedTriks board (or my own version of it running), I will let you know how this turns out. For now, here's a stab at what the board might look like.

Designed in Eagle, if anyone wants the schematic or board files give me a holler. I'm not posting them to the File share until at least some level of sanity build proves the concept (might just be a breadboard session, but again I will have no way to write/test the firmware until I get a ledtriks operational....of course.. if someone wanted to send me a ledtriks board...:grin:)

Disclaimer: The only novel concept here is combining the fine work done by the predecessors of the JEC Pixel, and the TRICKS-C. Credit where credit is due... I'm just spinning yesterday's technology today, for a better tomorrow.

[budude]

I can't quite tell from the picture but does it have the same mounting hole layout as the original Triks-c? That would be important if you plan to use the LED PCBs from Frank.

[LabRat]

No it doesn't. That wasn't on my design agenda. My goal was to make a board that I could etch here at home, and use PIC's instead of ATMEL. (Again, I'm not saying either is better, it's just the stuff I have on hand).

This version of the board itself is just under 1.75" x 3".

If anything I would have expected we would want to match the mounting holes of the LEDTRIKS, and not the LED PCB panels. But I confess that I haven't read each and every LEDTRICKs forum posting (yet). Though perhaps those two boards (PCB Panel & LEDTRICKs) are already aligned, so the point is moot.

[budude]

Your design would replace the Triks-C, not the Ledtriks interface board (which is still required). The panels have mounting holes for both boards (and they are different) that match the holes on them. Anyway - if you would be looking to use the existing panels you may want to take that into consideration.

[vairmoose]

have you looked at the "bigger" pic chips... The Pic24 (current pic of choice for the Lynx Express) would have the pins needed to do the larger display without having to jump through hoops to address the boards ...

Larry

[LabRat]

No I haven't (nothing stopping *you* though ;) ). This was all about using what I've got on hand, and as I just had a load of the 16F's come in from DigiKey (it was like an early Xmas I tell ya), that's what I've been going with.

[P. Short]

Use a PIC16F722...it has more pins, and is as cheap (or cheaper) than the 16F688.

[LabRat]

Digikey and mouser were both sold out of the 722's. ;)

But yes... that would be a way to go. It certainly has a lot more IO pins.
(though less RAM and code space.)

[ErnieHorning]

Newark’s got them and they’re cheaper than Mouser or Digi-key.

http://www.newark.com/jsp/search/productdetail.jsp?SKU=54M4995&CMP=AFC-OP&CMP=AFC-OP

[scorpia]

Being someone with pic tools and not avr tool i would be interested in this.

but yes i would look at respinning it to a bigger pic. either 16f628a or 16f722 or something in a higher range either 18f or 24f series.

either way i would be interested in seeing the code to check to see if it works and to play.

good to see people playing with things. thats what this site is all about.

ps you can allways order pics from microchipdirect. if anyone os going to have stock its the maker :)

Peter

[TimW]

Making stuff with what we have lying around is the essence of DIY. A lot of innovation happens that way....

As far as I know, the first mention of microcontroller support for ledtriks was on a PIC. See here (http://www.doityourselfchristmas.com/forums/showthread.php?t=3191) for discussions on the original 'PICtricks'. Some of holtm's code might be a good starting point?

Tim

[LabRat]

Making stuff with what we have lying around is the essence of DIY. A lot of innovation happens that way....

As far as I know, the first mention of microcontroller support for ledtriks was on a PIC. See here (http://www.doityourselfchristmas.com/forums/showthread.php?t=3191) for discussions on the original 'PICtricks'. Some of holtm's code might be a good starting point?

Tim

Very cool.. thank for the link Tim.

[Edit] Hahaha... there I was thinking I was doing something a little 'novel'. ;)

[LabRat]

Being someone with pic tools and not avr tool i would be interested in this.

but yes i would look at respinning it to a bigger pic. either 16f628a or 16f722 or something in a higher range either 18f or 24f series.

either way i would be interested in seeing the code to check to see if it works and to play.

good to see people playing with things. thats what this site is all about.

ps you can allways order pics from microchipdirect. if anyone os going to have stock its the maker :)

Peter

I've been thinking about this quite a bit (insomnia ya know). As it is the board with the 16F688 should be able to do everything the Tricks-C does, and have room to spare (additional wipes & transitions??). Furthermore, we should be able to flash one (or two) frames into the device (something to consider adding to the protocol).

What are you hoping to gain by going with a larger part? Control for multiple panels from a single board? Perhaps do-able, but then we risk increasing the cost/complexity to the point of not making this a reasonable solution for the "diy@home" types (which was my goal, and may not be everyone's).

The only thing I see this board not having compared to the TRICKS-C, is the "status LED". This is due to having the crystal oscillator added to the board. I see from HOLTM's attempts previously, he managed to get the PIC to LEDTRICKS operational. If we/I can get this talking to the PC without the need of the external OSCILLATOR, then I can buy back those pins, and add in the status LED.

Of course.. I need to make a LEDTRICKS first.. and the panel.. and solder all those LEDs... (how many days until Xmas??)

[Post Thought] This board has enough RAM for TWO frames - either buffer swapping for faster/cleaner transitions, or it should be possible to drive two LEDTRICKS at once. (Unless my blurry eyed Sunday morning thinking has missed something)

[scorpia]

yes to me the main reason was the extra i/o.

Also being that the 16f722 can be got cheaper than the 16f688 and can be run on either its internal 16mhz osc or run from memory upto 32Mhz external crystal.

basicly its the old addage bigger must be better :p

Also something i know tim has been playing with that might require some more grunt is the ability to add dimming to the ledtriks. this makes the whole mcu controller board worth it to me.

Plus i like playing with code. so why not :)
ps liking playing around with the code and being good at it are 2 diff things

the 18f and 24f range of pics would be a "cause i can" reason and nothing more. Allthough a usb controlled ledboard could be cool.

Peter

[LabRat]

the 18f and 24f range of pics would be a "cause i can" reason and nothing more. Allthough a usb controlled ledboard could be cool.


Oddly enough (when it comes to me.. it usually *IS* odd), I considered the 18F series for USB, but dismissed it, due to the extended range of the RS485. Hooking up to the USB stack would be fairly painless (heck, take the basic UBW board, and just re-direct all those I/O's to an RJ45 ). This even allows for a boot loader, so you can compile new code and load it over the USB. Now *that*'s an interesting twist. Software upgrades to the PIX-C. ;)

However, that would mean new SW on the PC side as well. If I manage to adhere to the existing serial protocol, I should be able to leverage the existing PC side of things. No changes required there.

Anyhow.. current status, I've fixed several issue with the version I had posted before (amongst other things, the pinout to the ledtricks was COMPLETELY wrong), and whipped out a version 1.4. Etched up my proto-type (I think it might actually have been faster than trying to wire up the breadboard), and dropped the 16F688 into play. The "I've got power Blue LED" is operational, and the PicKit clone recognizes the chip as being out "there". I haven't populated the serial portion of the board yet, figuring that can wait until I had the proof that the PIC was setup correctly.

Now to see if I can compile the "Test" code from years gone by, and stuff that into the device.

It feels good to move from "armchair observer" to "actively doing something".

[LabRat]

:shock: Just discovered that I will required an *special* adapter/dongle if I want to do in circuit debugging. (That's a bit of an eye-opener.. and here I am without even a gpio to an LED... trying to tell if this code is doing anything).

Ok.. time to hit the sack and thing about the implications here.

On the bright side, I built the original pictricks.asm code, and loaded it. No idea if it *DID* anything.. but I loaded it. ;)

[scorpia]

Oddly enough (when it comes to me.. it usually *IS* odd), I considered the 18F series for USB, but dismissed it, due to the extended range of the RS485. Hooking up to the USB stack would be fairly painless (heck, take the basic UBW board, and just re-direct all those I/O's to an RJ45 ). This even allows for a boot loader, so you can compile new code and load it over the USB. Now *that*'s an interesting twist. Software upgrades to the PIX-C. ;)

However, that would mean new SW on the PC side as well. If I manage to adhere to the existing serial protocol, I should be able to leverage the existing PC side of things. No changes required there.



i dont see why it would require new software. there is a usb boot load + software. i think the ubw uses it. and as the usb port can be made to look like a serial port the software doesnt need to change on the pc side.

[LabRat]

Had a thought that my progress may be better suited to a "blog" than a forum, so I'm moving my updates/postings to that venue.

LabRat's Blog Attempts (http://doityourselfchristmas.com/forums/blog.php?b=119)

[LabRat]

Just letting all of those saying to use the "other bigger PIC" know, that it's time to say "we told you so". I discovered that my current board is flawed when I read the following snippet from manual.


Note: When the SPEN bit is set the TX/CK I/O
pin is automatically configured as an
output, regardless of the state of the
corresponding TRIS bit and whether or not
the EUSART transmitter is enabled. The
PORT latch is disconnected from the
output driver so it is not possible to use the
TX/CK pin as a general purpose output.

I don't have any spare pins in the current design, and I had wanted to re-task the TX/CK pin as a GPIO to the RJ45. As I can't do that, I will have to look at re spinning with a larger PIC, or dropping the external oscillator, and buying back two pins.

Oh well.. in the worst case, I convert *this* board over to a version of the JEC PIXEL, that can drive 7 channels of downstream DC SSR's.

[LabRat]

I was progressing very well until last night when I started on the "Roll Left" command. No matter what I tried, the data in the buffer just isn't correct, so I've been chasing it down all evening. There is definitely something *amiss* here (and I'm not 100% certain it's my code).

So here's a call for PIC guru's for help to identify why the rrf command, is mis-behaving.

Here's the relevant info (I hope):

BANK0 contains the "Top 1/2" of the frame
BANK1 contains the "Bottom 1/2"
In the 16 bytes of "common" data, exist the shared rxBuffer, which includes:bitShifter (countdown from 8 to zero), column_count (6 to 0), and row_count (8 to 0). Input1&Input2 - the new bits for the roll, and Voldemort the "BYTE that shall not be named" which simply contains a flag that indicates whether I'm processing the top or bottom portion of the frame (need to know when to exit the loop).


As we are shifting Left, I'm processing the buffer in reverse, and "C"arrying in the new bit from the bitShift register. (lsb first)


cmdLeft
BANKISEL Fr0Row0
movlw Fr0End
movwf FSR ; Point in the BANK
movf input2,W ; Get the appropriate byte from the payload
movwf bitShifter ; Everything is where we want it.
clrf voldemort ; Indicate 1st time throught this loop

cml_forEachBank
movlw d'8' ; 8 rows per frame
movwf row_count ;
cml_forEachRow
movlw d'6' ; 6 bytes per row
movwf column_count ;
rrf bitShifter,F ; Put the "next" lowest bit into 'C'
cml_forEachColumn
decf FSR,F ; Decrement to the next BYTE in the stream
rrf INDF,F ; Rotate the payload NOTE: inverse rotate due to msb output ordering
decfsz column_count ; Count down all 6 bytes in the ROW
goto cml_forEachColumn

decfsz row_count
goto cml_forEachRow

btfsc voldemort,1 ; Was this the second frame?
goto doneCmd ; Yes - we are done

BANKISEL Fr1Row0
movlw Fr1End
movwf FSR
movf input1,W
movwf bitShifter
bsf voldemort,1 ; Flag that we are executing the SECOND 1/2 of the shiftloop
goto cml_forEachBank

Ok that's the setup.. here's the bizarre problem. The rrf INDF command, appears to be shifting 3 times, instead of 1. (Yeah.. I know it sounds unreal.. ).

I tweaked the code to exit after processing the first memory location only.
It contained 0x80 at the start, and after the shift... I'm left with 0x10??

I've tried all sorts of tests, to narrow this down. I've copied the value from the INDF into W, output it into a new location (still 0x80), did an rrf of W and spat that out into yet ANOTHER location.. 0x10!!
It gets worse... if I double up the RRF INDF, so that I perform the operation twice.. the output is... 0x10?!?

(I'm not making this up)

To make things even more confusing.. if I add some "wait" time at the very start of the routine.. 3+ms (of thereabouts). The output will be... 0x20 .
If I go larger.. around 4-5 ms, then I get the expected values.

Anyone have any ideas on where I could look next? (For now I've left the wait states in there.. but that just seems oh so wrong.)

Thanks for any feedback.

Oh.. the Roll Right command which uses a rlf INDF works without issue. :(

[djulien]

What is the value of STATUS.C going into the code? If it's not 0, the first rrf will be turning on upper bits. That's probably not the cause of what you're seeing, but could cause other data corruption problems.

don

[LabRat]

AAAAAGHHHHH..... (translated - I figured it out)

"It was almost like it was shifting things 3 times instead of 1"

Answer - because it was.

The source code for the PC (BASIC) does not appear to align with the functionality of the corresponding executable. So my request to Tx a single command, resulted in (you guessed it) three copies of the command being sent to the PIC. Which resulted in 3 shifts.. and 0x80 becomes 0x10!! :confused:

(sound of my head pounding on the table) So this has been working properly for days... (ugh)

Adding in the delays, and extra blinks, meant that the PIC was ignoring the extra content on the serial line, and thus appeared to be working correctly.

Thanks everyone who provided feedback (here and on the "PIC" boards).

It's just been one of THOSE weeks.. (just when things seemed to be getting better).

On the bright side... the only thing left now is the bit bashing out to the LedTriks. (oh..and *building* my LedTriks (a minor step I'm sure))

[djulien]

So my request to Tx a single command, resulted in (you guessed it) three copies of the command being sent to the PIC. Which resulted in 3 shifts.. and 0x80 becomes 0x10!!

I was hoping you had found a fancy new way to do multi-bit shifting. I could have used that ... :P

don

[LabRat]

This isn't dead, I've been sidetracked for a while. Finished the build on my LedTriks this weekend, and the panel is ready to be attached. I'm trying to get the PIK-C to talk to the LedTriks so that I can validate the wiring to the panel.

The work is continuing. (Will post more details in my Blog)

[LabRat]

Just an update - It is ... *ALIVE* the PIK-C (pixC, piksC) is driving my ledtriks, and my panel is operational. I've still got some work to do, including tracking down why that one led is staying off (very odd.. if I press the board "near" the led, it lights up. (Nope.. not a cold solder joint.. redid the connections, and even swapped out the LED). The entire column is "ghosting" as a result. If I touch the lead and push (or pull) the led lights up, and the rest of the column goes dark.

Anyhow.. back to the PIK-C. It's working, but I'm not sure I'm happy with the overall response time. I'm thinking about reversing the code logic, and having the IRQ's handle the incoming serial traffic, and use the "main loop" to write out to the LCD. (reverse to what it's doing right now).

I'll post pictures when I can.

Running:
16F688, internal 8 Mhz oscillator, confounded method of getting serial RS232 to the board. I'm planning to respin my PIC-C, so I haven't populated the serial portion of the board. I'll do a new one, and populate *THAT* board instead.

[LabRat]

Brief update.. haven't tried the *REAL* serial transceiver yet, but the rest of the PIK-C is running the way it should (found the problem with the rows ghosting (firmware issue)).

[LabRat]

Just a status update:

The serial circuit is now working flawlessly, and I've done an update to the FW so that it will "timeout" on serial inactivity. At that point it will start cycling through the ROM images (not fancy transitions, just cutting from one to the next every 4 seconds).

It's working flawlessly (so far) as a PIC based version of the TRIKS-C. I've run some animations using LTC, and even configured it to be panel 0 or panel 1 so that the "countdown" function would display properly.

My original plan was to have it "inline" with the panel, and stuffed inside a standard "ARCHER" project box. The board layout was based upon this enclosure and I think I can do better.

I'm re-thinking this now, and the version 2.0 of the layout will be simplified to a 1.8"x2.45" board. I believe it will be easy enough to mount this inside my LEDTRIKS panel, somewhere beside the LEDTRICKS board itself. Thus keeping the "parallel" cable nice and short.

That's the update so far..


Brief update.. haven't tried the *REAL* serial transceiver yet, but the rest of the PIK-C is running the way it should (found the problem with the rows ghosting (firmware issue)).

[LabRat]

Just an update - the proto-type has served its purpose, and I'm moving onto the next "version" of the board. Just trying to decide if I stick with home etch, or send this out to get a couple of boards made up. If I go to double sided (send out), I can pack this down fairly small (1.8 x 2.2 inches). The home etch is running at around 1.8 x 2.45 inches.

Here are the two images, home etch vs "send it out to be made". I suspect many of you already have the Tricks-C and/or are happy doing AVR development. If there's interest I can look into getting a small run of the boards made (NOT a coop... I would front the cash/risk etc).

[LabRat]

Ok.. so this morning's epiphany is/was...

... "oh look.. I just made a REN8 without the ZC support"...

Sure 'nuff, the PIX-C is pretty much a serial input to a PIC, with 8 I/O outputs going to the RJ45 jack. Admittedly not the exact same *pinout* as
the default REN8, but there are implications here:

a. My PIX-C fw should be easily adapted to run inside existing REN8's.
So a fw upgrade to a REN8 + a custom cable, and you have a serial
interface to the LEDTRIKS.

b. My PIX-C hw should be easily adapted to run as an 8-channel DCSSR
driver board.


Just some observations.

[LabRat]

YouTube of the PIX-C (and my LedTriks) in action. (http://www.youtube.com/watch?v=YZL4-ljagBY)

[joeytx]

Labrat,
Could I look at the code you are using for this project?

[LabRat]

Labrat,
Could I look at the code you are using for this project?

I've posted the HEX file in the files section already.

Pix-C Hex File Link (http://doityourselfchristmas.com/forums/dynamics/showentry.php?e=42&catid=22)

I'm in the midst of re-arranging my desktop/pc (new machine), and the one with the code on it isn't accessible at the moment. I need to find some more desk space, to get the little beastie operational again.

Still hoping to hear feedback if this is working for others. My Ledtriks has a non-standard Address MUX. When I put the proper (expected) 74HC4514 in place, the images were corrupted and I saw a lot of blinking etc. So I'd like to hear other peoples experiences.

The image I posted, has a timeout behaviour. If no serial traffic, it will start displaying the hard coded images (courtesy of my kids). When I'm done I would hope to have a web page where you can edit your default pics, and then download the compiled HEX image for inclusion in your PIC.

[joeytx]

Thanks LabRat, I burned the board and wanted to try this project with a Microchip instead of Atmel. Sorry I missed your attachment. Will let you know how it works.

[LabRat]

Pardon my paranoia... but .. it was the PIX-C board you etched. Correct?
(Your last comment left room for a little ambiguity, and I wanted to make sure)



I've posted the HEX file in the files section already.

Pix-C Hex File Link (http://doityourselfchristmas.com/forums/dynamics/showentry.php?e=42&catid=22)

I'm in the midst of re-arranging my desktop/pc (new machine), and the one with the code on it isn't accessible at the moment. I need to find some more desk space, to get the little beastie operational again.

Still hoping to hear feedback if this is working for others. My Ledtriks has a non-standard Address MUX. When I put the proper (expected) 74HC4514 in place, the images were corrupted and I saw a lot of blinking etc. So I'd like to hear other peoples experiences.

The image I posted, has a timeout behaviour. If no serial traffic, it will start displaying the hard coded images (courtesy of my kids). When I'm done I would hope to have a web page where you can edit your default pics, and then download the compiled HEX image for inclusion in your PIC.

[joeytx]

Yes that is correct. I had a max232 to 16F688 that i had used earlier for another project and that is what I used filling in the blanks from your posted pic.

[joeytx]

Just wanted to give an update. I designed and etched a new board using the SN75176B and the 16F688, very simple board with minimal components. I programmed the pic with the hex code found in this thread.
The only issue I had was that I had to reverse the Cat 5 wire on the cathodes. Each section of 8 cathodes ran backwards. Not the whole display each section of 8 vertical LEDs. It displayed fine using Vixen and the parallel port. I didn't have access to the code but I did have a soldering gun, and since I wanted to use the Pik-C and not the parallel port, I moved wires. I uploaded a video file to YouTube if you would like to see it work. Thanks LabRat for your work on porting this to the 16F688.

Video:http://www.youtube.com/watch?v=J9TMYhB6czw

[LabRat]

D'oh.. I could have fixed that in FW.

I guess I must have wired mine up backwards, but then made the "Pix-C" FW to match. Sorry about that.

So.. do we both re-wire our panels to match the rest of the world?
and I reverse the bit push logic?

OR...

Update the FW to have a compile option to reverse the output?
So that the PIX-C can support either mode?

OR...

Update the FW to have a runtime option to reverse the output?
So that the PIX-C can support either mode?


Decisions.. decisions...

ps. Thanks for the video.

Just wanted to give an update. I designed and etched a new board using the SN75176B and the 16F688, very simple board with minimal components. I programmed the pic with the hex code found in this thread.
The only issue I had was that I had to reverse the Cat 5 wire on the cathodes. Each section of 8 cathodes ran backwards. Not the whole display each section of 8 vertical LEDs. It displayed fine using Vixen and the parallel port. I didn't have access to the code but I did have a soldering gun, and since I wanted to use the Pik-C and not the parallel port, I moved wires. I uploaded a video file to YouTube if you would like to see it work. Thanks LabRat for your work on porting this to the 16F688.

Video:http://www.youtube.com/watch?v=J9TMYhB6czw

[joeytx]

I say update the firmware. But I don't know how much more work that is for you to do. If I can help let me know.

I posted another video this one is of the idle processes: http://www.youtube.com/watch?v=AWaShFqK-iY

[ukewarrior]

I'm not sure I'm following this.

Are we saying a connector is simply incorrect, or are we saying the LEDs on the panels had cathodes/anodes switched?



D'oh.. I could have fixed that in FW.

I guess I must have wired mine up backwards, but then made the "Pix-C" FW to match. Sorry about that.

So.. do we both re-wire our panels to match the rest of the world?
and I reverse the bit push logic?

OR...

Update the FW to have a compile option to reverse the output?
So that the PIX-C can support either mode?

OR...

Update the FW to have a runtime option to reverse the output?
So that the PIX-C can support either mode?


Decisions.. decisions...

ps. Thanks for the video.

[LabRat]

I'm not sure I'm following this.

Are we saying a connector is simply incorrect, or are we saying the LEDs on the panels had cathodes/anodes switched?

I think we're saying that within each of the 6 bytes that makes up a row, the PIX-C was clocking that data out MSB vs LSB (and/or vice-versa). It will be an easy fix/change, and I can setup conditional compile easy enough.

[joeytx]

Here is a video of what was happening: http://www.youtube.com/watch?v=C-_JU10JQ6g

[dirknerkle]

Here is a video of what was happening: http://www.youtube.com/watch?v=C-_JU10JQ6g

sO If yeR DySLExIccc U kin REED it PurtIE gud.

[LabRat]

!sey

[joeytx]

Being partially Lysdexic I was able to figure it out :)

[LabRat]

The time has finally come to release the PIX-C into the wild. My development on this is now completed (well.. as completed as it's going to be for this year).

http://doityourselfchristmas.com/forums/attachment.php?attachmentid=7471&stc=1&d=1283990625


Check out the PIX-C (http://www.christmasinshirley.com/wiki/index.php?title=PIX-C)section in the WIKI for schematic, gerbers, photographic log of the build (not really warranted for this little board, but what the heck), as well as a link to the full source code. Take the files, add your own "Stand Alone Images" (HINT: look at the .inc file folks) and enjoy.

Thanks to the folks to built their own PIX-C and assisted with the testing.
Thanks to TimW for adding the extended PIX-C commands to LTC (version 11!!).
Thanks to the DIYC crew in general for inspiring me to contribute, rather than just lurk.

Phew.. hope I didn't miss anyone.. oh yeah.. thanks to SWMBO for putting up with me, and my "you gotta see this" annoyances. :)


Oh.. I've also got 8 boards here at $4.00 a pop, if anyone local wants one, or if anyone cares to pay the shipping charges (about $6.00 if you don't want tracking.. about $16.00 if you do). Etch your own, or send the gerbers to a board house. Enjoy!