Archive for July, 2011


New monitor and more OctoPDI5 boards


Today a new monitor arrived for work, a 1920×1080 pivot-able LCD.  I’ll hold all the debug consoles for stations I’m building as I  scale out to as many as I can before the bus starts to fail (hopefully quite a ways).  I also built up more OctoPDI5 boards a couple days ago, so I now have 24 ports of fully-isolated program & debug.

I’ve actually managed to cram all 24 debug windows onto the screen at the same time.  Time will tell if they’re actually too small…  So far I’ve got 4 stations and the port controller hooked up, though I need to see if I can get a single-port PDI5 controller built to isolate the port controller.  For some reason when I have too many stations attached to the same OctoPDI5 as the port, engaging the power-cut relay on the controller causes enough noise that the controller resets and turns everything back on again…


Absolutely ridiculous packaging from Arrow


I order parts from various places, though mostly Digikey.  Sometimes parts are only available from certain distributors, or in some cases they can be noticeably cheaper even after counting in shipping to get parts from multiple distributors.  In this case one particular part I need qty.16 of was $7.48 from Arrow and $11.13 from Digikey, while another I needed qty.2 of was $7.17 vs $10.20.  The parts are 100-TQFP and 16-SOIC-W, so.. not very big.

Imagine my surprise when UPS shows up with a 7″ x 8″ x 27″ box:

Inside this monstrous box there are 3 (!) large static bags, 7″ x28″ and 11″ x 18″.  One of them is covered in bubble-wrap, and all 3 of them are packed inside a large volume of loose paper.  Unpacking all 3 of these bags yields a full tray with 2 parts in it (the TQFP), a tube with 14 of the SOICs, and a second tube with 2 more of the SOICs (besides the large dessicant bag and moisture card in each):

Now, under absolutely no circumstances is this even remotely acceptable.  The SOIC parts should have been consolidated into a single tube, or at least they might have shortened the tube rather than cut additional plastic strips to fill the immense amount of empty space in them.  Even with 2 tubes they should have been packed in a single (smaller) bag.  The tray designed to hold 67 parts should have been chopped down significantly and packed in a smaller bag.  The entirety of this should have been in a radically smaller box, with less waste material.

In theory I saved $64.46 on the components by ordering them from Arrow rather than Digikey.  However, the shipping cost from Arrow was $14.99, reducing the cost savings to $49.47.  Saving $50 is a pretty good deal, but if the savings were any smaller, I would refuse to order anything from Arrow until they fix these absurd shipping practices.  The larger cost is in garbage, recycling, shipping volume and the resulting additional fuel cost for more trucks on the road with the additional traffic and noise.  You might say that this one package is a drop in the bucket, but unless I’m presented with evidence that Arrow only ships things like this to me (repeatedly, I might add), the impact is far larger than it might seem on the surface.

Responsible packing and shipping has been the watchword for years now, and Arrow needs to get a clue.


Teensy-based PDI5 programmer


I’m preparing to radically scale out my product development, which means a number of things.  First, I’ve ordered parts to populate 2 more of the “OctoPDI5” boards, so I can scale out to a total of 24 units under development at the same time, all of them electrically isolated from each other and the host computer.  I’ve also got an inexpensive 1920×1080 monitor on the way that will have enough room for me to actually put 24 copies of by debugging console on it in pivot mode.  However, I’ve still got to program/debug the controller board for this whole mess.  So far I haven’t had enough stations active at the same time to make me hit the 8-port limit on the OctoPDI5.  However, with 24 stations and 3 OctoPDI5’s, I’m going to need another programmer…

Luckily I have a Teensy++ sitting on my desk, which I haven’t had a chance to do much with yet besides play with the loader and core examples.  It’s nominally got all the stuff I need to pull this off, though before I actually connect it to anything I’ll need to alter it to run on 3.3V lest it blow out my port controller with 5V…

The software stack porting turns out to be quite trivial, because of the way I’ve set up all the code for the existing PDI5-related boards.  Basically I’ve built a rough object-oriented system for the various “streams” such as USARTs and the STK500V2 engine.  A little bit of hacking gave me both an “avrmega” standard USART module (though it’s hard-coded for USART1 so far; I’ll need to enhance it to run on “any” AVR mega, especially the one with more than one…) and a “USART” that uses PJRC’s usb_serial code.  A little more code gives me the “iosmux” mainloop that multiplexes the serial and stk500v2 streams through the upstream.  Some quick tweaks to my host-side software so it handles the /dev/ttyACM0 path instead of /dev/ttyUSB0, and I’ve got the basic ability to send a text substream out to hardware.

The next step will be porting the PDI physical layer to the “avrmega” type, and shuffling the pdi5 code around so it’s not hardcoded to the Xmega PHY.  Neither of those will be particularly difficult.  At that point I’ll be able to hook up a PDI5 cable (USB micro-B) to the Teensy and my port controller, and I’ll have a nifty single-port version of the OctoPDI5 (albeit without isolation in this form).

At some point in the future I hope to implement an ARM SWD interface in the same style as PDI5, using the same cable, connector, and pinout.  If all goes well I should be able to run this on a Teensy as well, which means I might have a particularly killer ARM programming interface at some point ;-)