The world of international shipping continues to grow more difficult. As of October 1, the US Postal Service has halted acceptance of international package shipments to New Zeleand, due to COVID-19-related service disruptions at the destination. The same suspension was applied to Australia on September 3, so BMOW is now unable to make direct shipments to customers in either country. I had hoped this would be only a brief disruption while the countries’ post offices worked on mitigating COVID-19 impacts. But with Australia’s suspension already stretching to more than a month, my hopes for a quick resolution are dimming.

One bit of good news is that Australia Post’s ShopMate service is still working. It’s a package-forwarding service for Australian residents who are buying products from vendors in the USA. ShopMate provides you with a USA address, so BMOW and other vendors in the USA can make a regular domestic shipment and you pay them the domestic shipping rate. Then ShopMate repackages the shipment and dispatches it to your home in Australia, in return for an additional fee. A few BMOW customers have already tried buying through ShopMate during the past month, and reported that it worked. I’m not aware of a similar forwarding service for New Zealand, but if I find one, I’ll report it here.

The mess on my work desk has gotten out of hand. I think there might be a few square inches of free space in there somewhere, maybe. If I dig far enough into that pile I might even find a working pen, or a loose resistor with exactly the value I need.

Got a messy desk? Let’s see a photo!

For the past couple of weeks I’ve been developing an automated tester for Yellowstone. My goal is to streamline the program and test process for Yellowstone beta cards, and eventually for the first production run. The ugly tangle of wires shown here may not look like much, but I’ve used it to successfully program a card with a blank FPGA, and to simulate 6502 bus cycles for reading and writing from the card’s memory. I was surprised to discover that those looping crisscrossed wires still work reliably even at speeds as high as 10 MHz. I was also able to measure the current consumption of a Yellowstone card at idle, plus the test hardware itself, which is about 80 mA. That’s lower than I’d guessed.

I think I’ve stretched this breadboard prototype about as far as it will go, even though many things remain incomplete. There’s still no testing of the disk drive interfaces, nor have I implemented any of the short-circuit detection that I discussed here previously. Those pieces will have to wait for the final version of the tester, when it’s built into a nice PCB instead of a snarl of loose wires. My next task is to take what I’ve built on the breadboard here, and convert it into a PCB, and add the missing elements for testing drive interfaces and short circuits. There’s still a lot of software to write as well. I’m guessing the whole process may take about four weeks, including the PCB manufacturing time.

Once that’s done, I can hand-assemble a few Yellowstone beta cards and use the finished tester to program and verify them. If all goes well, I may be able to wrap up Yellowstone development by Halloween.

With apologies to BMOW readers Down Under, international deliveries to Australia from the BMOW Store have been temporarily suspended. A few weeks ago, Australia Post paused its processing of inbound international mail shipments due to COVID-19-related service impacts, and on September 3 the US Postal Service halted acceptance of Australia-bound international mail. I had hoped this would be only a brief interruption, but after sixteen days there have been no further updates, and there’s no current timeline for when normal operations will resume.

At the moment there are 21 international destinations for which USPS has halted mail delivery “due to impacts related to the COVID-19 pandemic and other unrelated service disruptions.” Australia is the only large country on that list, and the only one where BMOW has customers. The other countries are Afghanistan, Bhutan, Brunei, Cuba, French Guiana, Guadalupe, Laos, Libya, Martinique, Mayotte, Mongolia, Reunion, Saint Pierre and Miquelon, Samoa, South Sudan, Syria, Tajikistan, Timor-Leste, Turkmenistan, and Yemen.

International shipping is hot mess across much of the world right now, and this is just the latest incident. Thank you for your patience through all of this, and I hope to see Australia deliveries resuming soon.

A couple of weeks ago I shared some thoughts about an automated tester for Yellowstone boards, including how to test for short circuits. One of the questions that grew out of the resulting discussion was whether short circuits could only be detected by functional test failures (test results don’t match expected results) or if they could also be directly detected by measuring the supply current. A second question was how large the short circuit currents would typically be. I’ve recently done some tests to help answer these questions.

There are several different kinds of shorts that we need to think about:

• shorts between power supplies, where short circuit current flows whenever the power is on
• shorts between a signal and a power supply, where short circuit current only flows for certain signal values
• shorts between two signals, where short circuit current only flows for certain pairs of signal values
• shorts where the current source comes from the device being tested
• shorts where the current source comes from the equipment that’s connected to the device

Most of Yellowstone’s external IOs pass through 74LVC245 buffers. All of the tester’s IOs will pass through MCP23S17 port expanders. So I intentionally short-circuited some samples of both chips, alone and then together, to see what would happen. Here’s what I found.

• 74LVC245 with a 3.3V supply, and one logical high output short-circuited to ground: 70 mA short-circuit current
• 74LVC245 with one logical low output short-circuited to 3.3V: 110 mA
• MCP23S17 with a 5V supply, and one logical high output short-circuited to ground: 30 mA short-circuit current
• MCP23S17 with one logical low output short-circuited to 5V: 50 mA
• 74LVC245 logical high output short-circuited to MCP23S17 logical low output: 50 mA
• 74LVC245 logical low output short-circuited to MCP23S17 logical high output: 30 mA

These currents are all large enough that it should be possible to reliably measure and detect them as deviations from the normal supply current (expected to be something in the range of 100 to 200 mA). So is this a good approach? Will it work? I’m going to try it and see, and if it’s successful then the tester will be that much more useful. If it’s not successful, I won’t have lost anything but some time and a few dollars worth of parts.

Why do this at all? Isn’t functional testing enough, with the assumption that any short circuit will cause a test failure somewhere? I say… maybe. In a perfect world, any short circuit would result in a functional test failure, but I don’t live in a perfect world. If I can do something to help detect shorts that functional tests missed, or that don’t result in test failures 100 percent of the time, I think that’s a good thing.

For how long do I need to measure the current? If the tester changes some IO values, waits a microsecond, and then measures the new supply current, is that enough? Or will capacitors on the voltage supplies smooth out the current from short circuits, so that microsecond-level measurements aren’t useful and I need to wait milliseconds or longer to get useful data? I’ll just have to try it and see.

If I measure the current, which current should I be measuring? I’m not quite sure. It might seem that I should measure the 5V supply current for the Yellowstone board (the device being tested). That would catch problems where there’s a short circuit between two elements on the Yellowstone board, whether they’re signals or supplies. It would also catch problems where a Yellowstone input signal was shorted to 3.3V or 5V, creating short-circuit currents whenever the connected equipment tries to drive a logical low to the input. But it wouldn’t catch problems where a Yellowstone input was shorted to ground.

In a case like that, short circuit current would flow whenever the connected equipment tries to drive a logical high value to the input. But since the current would be coming from the connected equipment, and not the Yellowstone board, measuring the Yellowstone supply current wouldn’t help. Maybe this is a rare enough case that I shouldn’t worry about measuring these currents, and I can just assume any such problems will be caught by a functional test.

Firmware version 0.3.7 is now available for the Wombat ADB-to-USB input converter. This version fixes a compatibility problem with some ADB mice that use non-standard communication timing. You can download the new firmware here.

This was an interesting discovery. Apple only ever produced a few different ADB mice, with model numbers A9M0331, M2706, and G5431. You might think that mice with the same model number would be the same, but in fact there are several different versions of each model and they have very different internal parts. It may be possible to tell them apart by checking the country of manufacture printed on the mouse, which could be USA, China, Malaysia, Taiwan, or others.

Some of the “Made in Taiwan” ADB mice have a controller chip inside that’s made by Logitech rather than Apple. These mice communicate over ADB at 75 microseconds per bit, instead of at the normal rate of 100 microseconds per bit. A small change to the Wombat firmware was required to make it more flexible about the bit timing.

 
PICkit 3 R.I.P.

The Wombat is designed around a Microchip PIC32 microcontroller, and I use a Microchip PICkit 3 to program and debug. Somewhere within the last year or so, the PICkit 3 has basically stopped working. It gives every indication of being some kind of Windows 10 problem or USB driver issue, rather than a hardware problem with the PICkit 3. Searching the web turns up many similar complaints, but no solution.

Using Microchip’s MPLAB X IDE for development and debugging, the PICkit 3 doesn’t work at all. The IDE will detect that it’s there, but any attempt to actually use it just gets a “connection failed” error. This means that I can’t use the debugger, and I’m reduced to debugging using print statements over the serial port.

The PICkit 3 sort-of works with the MPLAB IPE, a stand-alone programming tool with no debugging capabilities. But it only works for a short window of time after rebooting my computer. After a few programming cycles, it falls back to the same “connection failed” behavior as the IDE. The only way I’ve found to fix it is to reboot… again. Unplugging and replugging the PICkit3 doesn’t help, nor does updating the PICkit 3’s firmware, restarting MPLAB, or anything else I can think of. The word from Microchip’s own support is basically “Oh, you bought one of THOSE? Ha ha ha. Yeah, those PICkit 3s don’t work very well and we’ve dropped support for them.”

After spending quite a long time trying to resolve this, I eventually gave up, and decided I won’t be using any PIC parts for any future projects. The tools are just too clunky and buggy, and there doesn’t seem to be nearly as large of a community using PIC32 parts as other options like STM32. That means that when something’s not working, there aren’t many people who can offer help, and you’re basically out of luck. Too bad.