Omega's Electronics

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…

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.

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 ;-)

So there I was yesterday, placing an order with Digikey for some spacers, LEDs, pins, etc.  It’s 4:50pm on Thursday, and the parts aren’t exactly time-critical, but I go with the company-standard Fedex Economy (2-day), expecting them on Monday or so.

Then a couple minutes ago (1:25pm Friday) through my headphones I hear somebody shouting outside, competing with the lawn equipment grinding away nearby.  Headphones come off, and it sounds like my name…. Huh?  Then I recognize the local Fedex driver’s voice and run downstairs, apparently I missed the doorbell (gotta find a solution for that).

He hands me a Digikey box, and I’m thinking “was there another order before this I forgot about???”.  He points to the “Monday” on the box and says he’s just “getting a jump on things”.  Out comes the leatherman, and out come the parts I ordered 22 hours and 25 minutes ago…..  These early deliveries are becoming a common event with this driver, and I’m definitely not complaining <g>

Making it even more amazing, one of the parts I ordered was a replacement for some parts Digikey mis-picked for the big assembly order.  I got a call from them around 5pm yesterday and he said he’d try to make sure the confusion with the parts was dealt with before the order shipped out.  I only got the shipment notification from them at 10:51 this morning.

So far so good with the new boards.  I started very carefully by feeding it 5V on the intermediate rail to see if the 3.3v supply comes up, which it did.  Next was hotwiring the microcontroller to my AVR-ISP mkII and confirming the chip is happy, then replacing that with one of my program/debug boards and connecting it to my isolated 8-channel programmer:

I’m taking the old codebase and rebuilding it module-by-module so I can clean things up as I go, and make the main loop more configurable for various experiments.  After getting the serial port (which is running over the same cable, to my programming board) up and running, I moved on to the FD77T (which is an CDCE949 + crystal).  Now I’m starting to build in all the other subsystems necessary to get the thing actually talking to other units…

Just got the panels from EpecTec, and so far they look fantastic! ;-)