Older blog entries for shimniok (starting at number 33)

3 Oct 2013 (updated 3 Oct 2013 at 20:12 UTC) »

Eagle Tips: Default Via Size

In Eagle, vias are square and overly large by default but you can change the default. All you have to do is create/edit eagle.scr in the scr directory of your Eagle installation. Enter the following lines:


change diameter auto;
change drill 13mil;
change shape round;

I chose 13mil as this is the minimum drill size supported by OSHPark but pick whatever value suits you best, of course.

Problem: default Eagle via is big, square, and ugly.

Syndicated 2013-10-03 16:00:00 (Updated 2013-10-03 19:46:41) from Michael Shimniok

24 Sep 2013 (updated 24 Sep 2013 at 17:10 UTC) »

Logic Analyzer Shootout

This is a smackdown cage match between my three logic analyzers, a vintage HP 1650A, cheap Open Workbench Logic Sniffer and tiny Saleae Logic. Who will win? Read on...

I've used each logic analyzer on a few projects. Without one, writing my
Game Boy Camera driver software on three different MCUs would've taken way longer and most of my of I2C projects would've stalled out while troubleshooting. Writing my Propeller I2Cmaster object would've been orders of magnitude more difficult.

So, which Logic Analyzer is best? What are the strengths and weaknesses of each? Here's the summary first, followed by the full-on cage match comparison.


HP1650A

Cost: free to $200
Where to Get: eBay, Craigslist
Ports: 80
Form Factor: huge, heavy case with CRT
Construction: professional grade test equipment
Triggering: 2-stage, multi-edges + state
Protocol Decoding: none
User Interface: scroll wheel, keypad, buttons
Operating Systems: built-in, no external computer

Mine was free, given to me at a robot club meeting. It's main advantage over modern logic analyzers below is the ridiculous number of ports. The machine is really noisy, cumbersome to use due to lack of a keyboard, and it's huge. I have to really clear off the workbench. Nevertheless, it is still cool and it works flawlessly because even a quarter-century after it was built, industrial grade test gear is typically quite solid and usable. It has complex 2-stage triggering with high, low, edge, rising-edge, and falling-edge.

It cannot do protocol analysis which is normally a big time saver. To get one of these running you may have to find and write your own 3.5" boot floppy with a proprietary filesystem, but that is a path well-trodden by other DIYers. You may also need to get "pod" cables and test clips which aren't cheap.

Despite the fact that I now two more modern logic analyzers I am still somehow unable to part with this dinosaur.

Saleae Logic

Cost: $150
Where to Get: Adafruit, Sparkfun
Ports: 8
Form Factor: tiny machined aluminum case
Construction: high quality intended for professional use
Triggering: 2-stage, 1 edge + state
Protocol Decoding: all the regular stuff
User Interface: computer client
Operating Systems: Windows, Mac OS X, Linux

Saleae gave me one of these to review but I bought it from them. I will give you the straight story good and bad alike. The cost is high. The triggering is a bit limited. But this is one of those rare tools that just works, always, no matter what I do with it. When I'm frustrated with a problem the last thing I need is to also fight my tools, fight some weird serial driver problem on Linux, or who knows what else. The Logic just works.

I hadn't planned to get one but after using it to solve real problems, its value was apparent. Seeing how easily and quickly I could get at the problem--how transparent the tool was, never getting in my way, I decided to buy the demo I was given. I would have given it back, otherwise.

The client software is fully cross-platform. This tool has operated flawlessly on Linux for me for several weeks and a handful of projects. I've played with it on Windows and Mac, no problem. The software is intuitive, minimalist, but powerful.

Triggering is 2-stage assuming a single edge combined with high/low states on the other pins. It has been sufficient for what I've been doing, so far. There's only 8 inputs which is probably enough but I may run up against that limit and the Logic 16 is even more expensive.

Open Workbench Logic Sniffer

Picture from Sparkfun.com
Cost: $50-62
Where to Get: Seeed Studio
Ports: 32, 16 normal use
Form Factor: moderate sized bare circuit board
Construction: hacker style, not productized
Triggering: 4-stage, no edges
Protocol Decoding: all the regular stuff
User Interface: computer client
Operating Systems: Windows, Mac OS X, Linux

Having 16 ports is nice just in case, for complex projects like cameras. The board is just bare which saves money I guess, or you can buy a case. There are two clients, the SUMP client and an alternative OLS client. I've been using the latter. The 4-stage triggering sounds like a lot but edge detection takes up two states. Still, it's powerful. The OLS alternate client is fully cross-platform. I find the software somewhat frustrating to use.

Ready to Rumble

Here's the blow-by-blow of the death-match between the three. Here's what I looked at.

Usability: If you've spent any time being frustrated at a bug while troubleshooting, you already know that efficiency and intuitiveness are gold because wasting time on the interface or fighting your tool adds to your frustration and takes time away from your troubleshooting. You need a zero-hassle tool you can trust, that you can just pick up and use to find the problem, like, now.

Capture: How many transitions can be captured and the rate of capture are both important to troubleshooting particularly if your circuit infrequently bursts fasts protocols, such as reading 8 bytes of 400kHz I2C data every second. Ideally, being able to capture a long period of time with lots of samples means you can find the problem quickly, without creating intricate triggers or rewriting your code for testing.

Protocol Decode: Working with I2C, etc., and manually decoding it, you know that easy, fluid protocol analysis is a huge time saver.

Triggering: Triggering is critical to finding the specific error state you're trying to fix.

Portability: if you do any troubleshooting in the field (like at the Sparkfun AVC) having a giant device to lug along sucks. Having a bare PCB that is easily damaged isn't such a great thing, either.

Value: if it costs a lot it damn well better be worth that in spades. Even then maybe a cheaper option is good enough.

Usability

HP1650A: The HP, after it takes a couple minutes to boot, requires you to use the scroll wheel and keypad to tediously configure which POD you're using, configure the sample rate and time, traversing a few 'screens'. Eventually you get it configured, you enjoy single-button capture and easy scroll. Lack of a keyboard sucks and slows down most operations. It's not bad, but it's not great. From a hardware side of things, the two types of probe clips I got are both genuine HP and industrial grade, high quality stuff. You can interchange them on the POD cable which itself is also genuine HP, costs quite a lot, and is of excellent quality.

OWLS: Start the GUI, plug in the board, click capture, configure the serial port on the first tab, then configure the acquisition settings. You're limited to 24kB of memory which isn't much so you must play around with the acquisition sampling rate to get a capture. Instead of troubleshooting.

When you're trying to fix a problem niggling UI details get really annoying and over many fix-capture-diagnose cycles can slow you down. You can re-run the capture if the settings are ok with no extraneous dialog. Good. If not, you click start capture, a dialog opens which doesn't remember what tab you left off on, so when tuning the sample rate or triggering, it is yet another annoying step to find the right tab, change the options, and try again.

If you forget to configure the port, it breaks. (So configure the port, you say... well, I don't have to on the HP or the Saleae).

I am pretty good at breaking things
Another example of a niggling issue is that the tool generates error dialogs if the protocol decode doesn't work right. Instead of simply showing me what it knows and letting me use the tool and my brain to do the diagnosis. As mentioned, protocol decode must be run after every Start Capture, which really, really sucks.

Error boxes are like user punishment. Why are we punishing the user?
It's a small point, but the probes bought from Seeed for the OWLS are low grade, rather thick, permanently attached, operate rather roughly, and have wire exits right where you thumb is supposed to go. They're usable but ultimately they suck compared to the Saleae and HP probes. It's one more straw to put on the camel's back.

Saleae Logic: With the Saleae  you fire up the GUI, plug in the device--it automatically detects it--and connect the probes, click Start, and get useful data back. Your friends with HP and OWLS are still dinking around trying to get something working.

My first thought after actually trying to debug an I2C problem the first time using this tool: Wow. That was ridiculously easy. I expected to have to mess around with some things, figure out why I broke something. Instead I was immediately solving my problem.

Oh sure, maybe you have to click on the trigger buttons or select different sample memory or rate, but all that's on the main window a click away. No extraneous dialog boxes appear. You might see the capture dialog the first time only.

Analysis is a matter of intuitive mouse movements. Protocol decode is configured once and stays enabled for every subsequent capture so you can focus on finding and fixing the problem, rapidly iterating through many fix-capture-diagnose cycles.

In short, the UI is fast, fluid, streamlined, easy, transparent. I hardly think about using the tool, it's second nature to just use it to find the problem and move on. That's precisely how diagnostic tools should be.

My superpower is breaking software without trying but this time it took many, many hours and numerous projects without a single failure or issue, until I finally was able to generate error dialogs. That is very unusual for me. And the error dialogs weren't even the Saleae s fault. The cause? I was running a backup to a USB NTFS drive from Linux, hammering the USB bandwidth. I could get away with much faster capture and far more samples once the backup finished.


The probes clips are nearly identical to the HP clips. They are high quality, industrial grade stuff but without an HP logo. They are not permanently affixed, either. The probe wires are thick, very flexible, high quality, tending to stay where you put them. They plug into the probe clips on the side so they don't get in the way of your thumb. Another high quality detail that adds to the value.

Capture

OWLS: The device has a selection to capture at up to 200MHz. Unfortunately, the amount of capture memory, mentioned above, is limited to only 24kB, about 1.2 ms at 20MHz rate. This sucks compared to the other logic analyzers and it gets in the way of using the device. You can increase the sample time by lowering the rate, but to accurately capture timing, you can't go too low. In addition to having a hard time capturing all the samples you need, spending time tuning settings instead of troubleshooting is a downside. It's another example of how the software gets in the way instead of helping you.

Another annoyance: using my superpower, I found that checking the noise filter causes the capture to fail with a device not found error on Linux.

HP 1650A: I never worried if the tool could take enough samples. One simply sets the time/div to between 10ns and 1000s and the sample period is set automatically.

At Time/Div=20us, sample period is 800ns

At Time/Div=1ms, sample period is 40us
Saleae Logic: I rarely have to think about memory limits or how much to capture. I was capturing a few million samples at 24MHz but there is a tradeoff between samples and rate. The UI permits you to select 10 billion samples at 24MHz but in practice it's unlikely the device can actually do this. Lower sample rates are required. At 24MHz it can capture 50M samples (2 seconds) no problem. Also worth noting is that rates below 2MHz generate an error dialog indicating proper analysis may not be possible.

Sampling below 2MHz gives you this every time.

Too many samples, too fast a rate, or USB is overloaded

Protocol Decode

HP 1650A: there is no protocol decode. Huge time-waster and big fail.

OWLS: You must open another dialog out of another menu to decode protocols for every single capture. It's usable, but not fluid. It gets in the way, in my experience with it. The actual decode isn't bad. It shows just enough. It's a bit hard to tell what is a start and what is a stop. That matters when you are writing an I2C driver for an ATtiny and for a Propeller like I was. When the starts and stops get mixed up can you tell instantly? No, you cannot.

A bit hard to tell an I2C stop from a start.
Saleae Logic: You set protocol decode once, then every subsequent capture decodes your protocol, saving you time and letting you focus on debugging rather than configuring the debugging tool. Also I find the I2C protocol decode easier to quickly decipher. You can quickly see that the green circles are starts and red squares, stops. Serial decode features an autobaud analysis that tells you what the real baud rate is. This feature was immensely helpful to me in troubleshooting a communication error I ran across. It's clever little details like these that make this tool so valuable to me.

Decoding I2C on Saleae is simple and quick to set up

Decoding Hello World, serial

The autobaud feature on the Saleae is awesome

Triggering

Saleae Logic: Triggering is based on detecting any one rising or falling edge plus the state of any other pins. Multi-stage complex triggering isn't presently available. I've been happy with it so far and haven't needed anything more powerful, yet. Even decoding the somewhat complicated 7-signal Game Boy protocol is entirely doable because the signal sequence starts with an edge. To detect I2C Start, you click the SCL high button, and the SDA falling edge button. Just two mouse clicks. SPI would require detecting a falling edge on the SS line. A TTL serial start is a falling edge on TX.

OWLS: Triggering is relatively powerful, with 4 stages of triggering. But because it cannot trigger on edges, doing so requires two stages to detect pin transitions on any of the pins. That's still more powerful than Saleae  Setting it up takes a bit of playing with but once you get it figured out using it isn't all that hard and it's worth it if you require it. I haven't, yet. For each stage you identify the bits of interest via the Mask, then you indicate the desired states via the Value. You can choose SIMPLE or COMPLEX for the Type. Complex is multi-stage and you can then select an action to either start the capture, or to pass on to the next Stage. To reliably detect I2C Start, use a complex trigger, select two channels in the mask, both high value, leave Start capture unchecked, go to the next trigger Stage tab, select the two channels in Mask and select SDA low and SCL high and check Start capture. That's considerably more cumbersome than the two mouse clicks required by Saleae.


HP 1650A: HP brings two stage, multi-edge detection to the table. It can detect three possibilities: rising edge, falling edge, or any transition. It can do this for any one of its 80 pins, while also being able to detect static high/low states on any other pins. Full on smackdown.

I never verified but it may only be possible to trigger on a single POD at a time. In the picture below I'm triggering on POD1 with only 8 pins activated, but normally you'd see all 16.

Note only have 8 of the 16 POD1 pins are enabled

Portability

HP 1650A: It's portable. Like a bag of bricks is portable. I don't need to drag a computer along with me, just a giant heavy box. Oh. Wait. Nevermind. Yeah, that's a fail.

OWLS: I can easily stick the raw, bare, uncovered board with its delicate, easily bent pin headers into my bag-o-tools along with sharp, heavy, and/or metallic things like pliers and DMMs. Because that's a great idea. Here's a nice case from Built-to-Spec costing just over $10. I may have to get one of these.

Saleae Logic: It's tiny at about 1.75" (4.5 cm) square and 0.25" (1.0 cm) high, it's light. Having a machined aluminum case with protected, shrouded pin headers means I don't have to worry about hurting it if I threw the bare thing into a random tool bag. But I don't have to do that because it comes with a really nice Case Logic zipper case to store analyzer, probes, and USB cable is one more detail they've taken care of. I will be bringing this to the next AVC and other robotics competitions.

Value

HP 1650A: Mine was free, the cables and clips cost something like $50 for one pod and two sets of clips. I've seen asking prices on ebay range up to $400. Given other logic analyzers available, unless you need 80 channels, to me it doesn't seem worth it to spend more than, say $50-100, the cost of a similarly old analog oscilloscope. I just don't think the value is there compared to OWLS or Saleae.

OWLS: Cost is $50 at Seeed plus $6 for each 8-pin probe/cable set up to $24 for 32 channels bringing the total to $74. You end up with a usable, but somewhat frustrating UI that gets in the way a lot. You could have a better life than this. On the other hand, I understand bare bones hobby budgets personally which is why I bought an OWLS originally.

Saleae Logic: Costs $150 from various sources, comes in a nice equipment-quality enclosure with a sturdy Case Logic case ($15 at Micro Center), high end USB cable, and industrial quality cables and probes. The software is truly outstanding, a study in high quality and streamlined design that balances power and minimalism very well. I don't have to configure serial ports; it just detects the device when plugged in and connects. I've spent $100 on a good, but old, analog Oscilloscope and $50 on a DMM. This tool is every bit as useful and transparent and in that context, $150 isn't that much to ask. Buying a Saleae Logic means you have a high quality diagnostic tool that will help you fix problems very rapidly. You trade money for saving time and reducing frustration over the device's lifetime.

Conclusion

Everyone has their own priorities. I get frustrated easily so I value streamlined software that works flawlessly with robust hardware. I don't have a lot of hobby time so I don't want to waste it on the tools. Doing so makes me really angry. I like quality tools and feel the job is easier and faster that way whether it's hand tools, power tools, or electronics diagnostic tools. But my hobby budget is also tight so I have to spend my money where it really matters.

The OWLS price is great. And it is certainly a usable tool even if it takes some getting used to. And the software and hardware are open source and I value that. And you could conceivably improve the UI yourself. The OWLS will no doubt get better over time.

All that said, I personally wished I'd spent my money on the Saleae first and saved $50 on the OWLS. I went ahead and bought the Saleae once I realized how good it was and how much it helped me in my many projects. I would've sent it back if it wasn't worth $150 to me. But that's me.

Hopefully reviewing some of the main points about all of these logic analyzers gives you a better idea of what you get and what you're getting into with each.

Syndicated 2013-09-24 16:00:00 (Updated 2013-09-24 17:09:50) from Michael Shimniok

Eagle: sudden clearance errors, isolation wrong?

You open up an Eagle board file only to find clearance errors when you run design rule check (DRC). Clearances that were working yesterday, and for the past hundred days on numerous boards, in fact.


Then you notice polygon isolation (clearance between polygon and trace) is too large. Pins that used to be connected to the polygon aren't. You can't manually reduce isolation. How do I fix this strange behavior?

DRC errors? I swear this was working yesterday!
The clearance value in the Edit > Net Classes dialog was set to 0.355mm (~13 mil) for some reason. Zeroing it fixed the DRC errors and isolation issues. 

The Net Classes clearance value overrides your DRU (Design Rule) file settings. OSHPark's clearance is 6 or 8 mil and I rely heavily on these tolerances in my designs. So you can see how suddenly increasing to 13 mil would blow my design.

Syndicated 2013-09-12 17:00:00 (Updated 2013-09-12 17:00:06) from Michael Shimniok

9 Sep 2013 (updated 9 Sep 2013 at 22:12 UTC) »

Out Sick

Reason for no posts lately? Strep throat. The month/year from hell continues...

On the upside my Rover RC Multiplexer is successfully funded on Tindie.

Syndicated 2013-09-09 20:06:00 (Updated 2013-09-09 22:09:05) from Michael Shimniok

23 Aug 2013 (updated 23 Aug 2013 at 18:11 UTC) »

AVR Code Size Reduction

Atmel AVR035 (pdf)) has some tips on code size reduction. Here's what I learned in the real world, reducing my flash-constrained A2D code from 4k down to 1.4k, great because the onboard ATtiny44As only have 4K of flash.

Side note: My A2D boards convert Sharp Rangers or other analog signals to digital -- I2C, and soon SPI and Serial, with oversampling, decimation, and filtering to reduce noise and increase resolution.

The biggest saving by far? Well, sorry, you have to read all the way to the end to find out. The suspense must be killing you... ;) 
  1. Compile with full size optimization. In gcc, use -Os
  2. Use local variables whenever possible. This saved a few bytes here and there.
  3. Use the smallest applicable data type. Use unsigned if applicable. This definitely helped shave some space. With an 8-bit micro it takes more instructions to deal with > 8-bit data.
  4. Use for(;;) { } for eternal loops. No effect. Apparently gcc knows how to optimize while(1){}
  5. Use do { } while(expression) if applicable. Didn't seem to matter in gcc the one time I tried this.
  6. Use descending loop counters and pre-decrement if applicable. Didn't seem to matter in gcc the one time I tried this.
  7. Declare main as C_task if not called from anywhere in the program. This is an IAR-ism. The avr-gcc compiler automatically ensures that main doesn't return a value.
  8. Use macros instead of functions for tasks that generates less than 2-3 lines assembly code. They're right. I tried converting some macros to functions in the TWI slave library I was using. It added size.
  9. Code reuse is intra-modular. Collect several functions in one module (i.e., in one file) to increase code reuse factor. I don't know for sure if this helped but I program this way normally for maintainability.
I started out at 4.2k and doing these things reduced code size to around 3.1k.

I encourage you to read the document as some of the tips I didn't mention may also help you.

Biggest Savings?

The biggest savings by far was to avoid floating point operations at all costs. This saved me in a prior project as well. Floating point on a Tiny is just murder on flash memory.

Take a look at your map file (avr-gcc -Wl,-Map,MyProject.map in your makefile) and find any unnecessary or unexpected library calls. In my case I saw stuff like this:


...
                              A2Di2c.o (usiTwiSlaveInit)
/usr/local/lib/gcc/avr/4.7.2/../../../../avr/lib/avr25/libm.a(floatsisf.o)
                              ../A2D/libA2D.a(adc.o) (__floatunsisf)
/usr/local/lib/gcc/avr/4.7.2/../../../../avr/lib/avr25/libm.a(pow.o)
                              ../A2D/libA2D.a(adc.o) (pow)
/usr/local/lib/gcc/avr/4.7.2/../../../../avr/lib/avr25/libm.a(exp.o)
                              /usr/local/lib/gcc/avr/4.7.2/../../../../avr/lib/avr25/libm.a(pow.o) (exp)
/usr/local/lib/gcc/avr/4.7.2/../../../../avr/lib/avr25/libm.a(fp_inf.o)
                              /usr/local/lib/gcc/avr/4.7.2/../../../../avr/lib/avr25/libm.a(exp.o) (__fp_inf)
/usr/local/lib/gcc/avr/4.7.2/../../../../avr/lib/avr25/libm.a(fp_nan.o)
                              /usr/local/lib/gcc/avr/4.7.2/../../../../avr/lib/avr25/libm.a(pow.o) (__fp_nan)
/usr/local/lib/gcc/avr/4.7.2/../../../../avr/lib/avr25/libm.a(fp_powser.o)
                              /usr/local/lib/gcc/avr/4.7.2/../../../../avr/lib/avr25/libm.a(exp.o) (__fp_powser)
...


Lots of libm (math library) calls. I had carelessly made a call to pow() which converts to floating point and thus adds a ton of space. Instead I converted to a simple multiplication loop using integer math. Size dropped from 3.1k down to 1.4k. Wow.

Did this help you? If so, do me a favor and share via redit, twitter, Google+, etc. Thanks!

Syndicated 2013-08-23 17:00:00 (Updated 2013-08-23 17:25:12) from Michael Shimniok

Geek Destinations: Micro Center, DTC

Micro Center in the DTC is quite the maker oasis with gear from Arduino, Sparkfun, Adafruit, Parallax, Karlsson Robotics, Digispark, Velleman, Raspberry Pi, and more. 


This is just one wall.
In this age of internet shopping, you may not know that browsing through many shelves of geekware in person is very fun. You pass by rows of products, imagination spinning out of control, dreaming of all the miraculously cool things you could do...

And so, I walked out $56 poorer but with a new Raspberry Pi Model A, black case, SD card, and Pi Cobbler. 

Those of us in Denver have suffered ever since the demise of TechAmerica up on Colorado which stocked lots of component parts, test equipment, kits, and more. Well, Micro Center is heading in the right direction.


They stocked Sparkfun retail packages for quite awhile. 

Almost all the Arduino goodies from Uno through Esplora
They were also carrying Arduino products and some clones.  Now they've  massively expanded their DIY section from one wall to two walls plus two islands. I wouldn't be surprised if the trend continued.

I ended up buying this very RPi Model A, right here.
It reminds me of how cool it was to look at logic gates and speech synthesizers at Radio Shack.

The FIRST kids are no doubt going to love this!
They carry the PiBow and also my favorite case, which I got in black.
They also carry a few components parts like LEDs, at somewhat cheaper prices than Radio Shack.

Digispark is a cool concept built around an ATtiny85.

I love Adafruit. I got a Pi Cobbler today, too.

Lots of goodies from Parallax even an Elev-8 and PropScope.

Lots of robot kits, too.

Even an Egg-Bot!

Syndicated 2013-08-15 17:00:00 from Michael Shimniok

Robot Club Line Following

Congratulations to Ted who kicked all our respective butts in line following at this month's SHARC meeting. He completed the short course in only 5 seconds, less than half of most everyone.

Except me--I had an embarrassing 30 second time. Hey I'm just happy mine worked at all, given the failure rate of everything else I've touched the last few days.

SHARC meeting, my 3pi on the left, RPi telerover on the right
He and I were both running Pololu 3pi robots. His was nearly maxed on speed but perfectly tuned. I have my work cut out for me if I want to compete next month!

Syndicated 2013-08-12 16:00:00 from Michael Shimniok

3-State Jumper


Up to 27 A2D adapters can live on the same I2C bus. The address is configured with 3 jumpers, each with 3 states: soldered high, soldered low, and unsoldered. Pull-down and pull-up resistors are the key to detecting all three states.

Hardware

I use a 220k pull-down resistor on each of the pins. That's because the MCU I'm using has a 50k pull-up resistor. If the jumper is left disconnected, it is pulled down with the 220k resistor and appears logic low until  the 50k pull-up resistor is enabled creating a voltage divider that applies logic high to the pin.

Internal 50k pull-up used to detect if jumper connected to VCC, GND, or nothing.

If the pin is high regardless of the pull-up resistor, it's because it's been soldered to VCC. Likewise if the pin is low regardless of the pull-up, it's soldered to GND.

Code

Here's the code to get the address based on the jumper attached to the specified pin. ADDR_PORT and ADDR_DDR are defined in this case as PORTA and DDRA