Exploring new tools to add to my toolbox

Hardware Platforms

With a successful integration test of our salvaged vacuum fluorescent display (VFD) we proceed to a few other tasks. On the hardware side, we’ll need to simplify our power supply situation. Our test had three separate AC plugs, we only really need one. We’ll also need to transfer what’s on the breadboard to a prototype circuit board.

On the software side, things are less clear because we’re still coming up with ideas on what to do with a salvaged VFD. Our very simple PIC driver code merely controls a pattern of bits, each bit representing a segment to be illuminated. This gives us a lot of flexibility but so far these bit patterns have been created using pencil and paper and quite time consuming. Once we have a project in mind we can write code specific to a theme, but until then it’s wide-open bits.

Well, at least we can streamline the pencil and paper system somewhat. The logic is not difficult, just time consume, and should be easy to automate. I started by creating a HTML form and laying out checkbox controls. I got as far as designing a JavaScript structure for checkbox click events when I realized everything is on a grid and looks a lot like a spreadsheet.

That realization led me to put my basic HTML and JavaScript on hold and switch to investigate what I can do in Google Sheets. The key that made it all possible is the BINTOHEX() function that reads a number, interpret it as binary, and translate to hexadecimal. This is the core functionality for my pattern generation and I was able to build everything else around it.

Here’s the initial build, with a fully populated grid of checkboxes and a test pattern for me to verify things were working.

Once verified, I deleted the checkboxes that didn’t have a corresponding segment. This array now properly corresponds to our specific VFD.

Now creating a bit pattern is as simple as checking on the segments I wish to have illuminated. Here’s the pattern for “12:00”, the canonical Hello World for a time-based VFD display.

I thought it would be fun to make this available for anyone to play with, but that requires keeping the sheet and its formulas fixed while allowing people to check and uncheck boxes. Unfortunately “view only” sharing does not allow checkbox manipulation, and “editable” sharing also allows modifying the sheet formula. Until I figure out how to do what I want, it was shared as “View Only” to the general public.

The time has finally come to put our salvaged vacuum fluorescent display (VFD) together with the prototype driver printed circuit board (PCB) we built for it. First we gave our VFD a little layer of protection. The individual pins of the VFD are small and seemed rather fragile. And as they went into a vacuum sealed chamber we had no means to repair, if one pin should break that would mark the end of our fun.

Fortunately, when we salvaged it from its previous home we noticed that those pins were quite strong in union. A single pin is fragile, but all twenty pins together was pretty strong. So we’ll solder up one of our cheap prototype boards to these pins just for the sake of holding them together. It was a bit tedious getting all the pins to line up. Two more boards were used as spacers to give us the desired distance.

Once lined up, the VFD was soldered in place.

As anticipated, the assembly is now much more robust. Now we can work with this module with a lot less trepidation: if we should break a pin now, the break should stop at this PCB where we could still recover, not break all the way to VFD glass where we couldn’t.

We still had a lot of usable pin length remaining, so we left this unionizing PCB alone and soldered another one where we’ll actually attach wires and headers.

While this soldering work was underway, a breadboard was populated to test our design for interfacing our driver PCB and the VFD. Each VFD grid and segment wire received a 10 kilo-ohm pull-up resistor to the 30V line, and path cords were installed to map pins from our generic driver board to this specific VFD as per the pinout diagram we drew up earlier. Now the VFD, with its new more robust pins, should plug right in.

Finally, power delivery which is far more complex than what a LED project requires. This initial integration test had three different power sources. The power transformer we salvaged alongside this VFD delivers (among other voltages) the ~2.5V AC we need for our filament. With a few rectifier circuits, it should be able to deliver the other DC voltages we need as well, but we weren’t going to worry about it until we got this test working. In the meantime, a HP inkjet printer power supply delivered the 30V DC for grids and segments, and a Raspberry Pi delivers the 5V logic power as well as I²C control signals.

We plugged everything in and… it lives again under our control!

Woooowooowooo! The salvaged vacuum fluorescent display lives. @Regorlas built the driver board and did all the programming, and tonight we wired it up

Tonight at #SGVHAK: big milestone in collaboration with @MLE_Online to bring a salvaged vacuum fluorescent display back to life. Now that it does our bidding, we'll have to design something cool (and not a clock) to use it in. pic.twitter.com/sCY1USUOBR

Once I had assembled our first prototype vacuum fluorescent display (VFD) driver circuit board, it’s tempting to connect it right up to our salvaged VFD and bask in its glow. But that would have been premature: there were bugs still to be ironed out with potential for fatal errors to damage or destroy our one and only salvaged VFD.

The first tests were what we used to test our bread board prototype: drive a 4-digit 7-segment LED, a Lite-On LTC4627-JR from my earlier PIC display driver project. From there I could verify 8 of 11 segments on this driver board functioned as expected by a demo program that constantly flips between two patterns, one spells “Hello” and the other “Ahoy”.

I then tested the I²C capability with a small update, changing the second pattern from “Anoy” to a very mutilated “MLE”. (It’s hard to do “M” on 7 segments.)

Breadboard contraption @MLE_Online started building at #SGVHAK has been transferred to soldered PCB. RPi3 can now update what's shown on LED via I2C. Good progress towards our real goal: drive a vacuum fluorescent display. pic.twitter.com/J2pP4F4Htz

These experiments exposed a few minor bugs, just as tests were supposed to. After they were fixed I expanded my test with a second LTC4627-JR for eight total segments. I also expanded my use of I²C by continuously updating all digits from Raspberry Pi to create a text marquee. This experiment exposed some timing issues that is visible as a slight lag just as the “u” in “thank you” came up on screen.

That lag was diagnosed to my code inside a timer interrupt service routine (ISR). On a simple chip like this PIC, a hardware interrupt signal could not interrupt another ISR already in progress. So when my code inside a timer ISR grew beyond a certain point, it started interfering with timely response to hardware interrupts necessary for I²C communication. The solution is to put my timer ISR on a severe diet, moving almost all of its bulk elsewhere so that I²C handlers could run with minimal interference.

Once the software problems were sorted out, I started experimenting with the flexibility given by this project’s design decision to keep PIC code simple. It meant I could play with patterns that have nothing to do with displaying letters or text. I decided to try a pattern that keeps a single lighted segment running through the display in a figure 8. When cycled through all digits like a text marquee, it gave us a neat looking wave. I look forward to more experiments in driving a multi-segmented display in unusual ways.

Actual integration with vacuum fluorescent display is on hold while I recover from sickness. In the meantime, start playing with fun patterns on placeholder LED. pic.twitter.com/QlkaqzsF5e

The answer is voltage compatibility: I want my driver board to be capable of running at either 3.3V or 5V, which is easy to do with an old 8-bit chip like the PIC16F18345 I’m using: give it power anywhere in its specified range (and probably a bit beyond that range) and it’ll happy run. But this doesn’t necessarily apply to whatever my driver board will accept commands from. Fortunately, I²C was designed from the start to accommodate devices that work off different VCC levels. So something like a Raspberry Pi (3.3V) can communicate with my PIC. (5V).

Pin Assignments

In addition to moving the decoder output pins so it could be placed immediately adjacent to my PIC, I also took advantage of my particular PIC’s feature of Peripheral Pin Select (PPS) by moving the I²C pins (handled by Master Synchronous Serial Peripheral – MSSP) from their default to RA4 & RA5 for easier routing on the PCB and easier data writes in my code.

Pin Isolation

This is the first time I planned to use pins RA0 and RA1 on a PIC16F18345 project. I usually avoid them because they are used as in-circuit system programming data (ICSPDAT) and clock (ICSPCLK) pins. They’re perfectly usable outside of this scenario, but they must be disconnected from the rest of the circuit during programming. In this case, it meant I had to put in two jumpers that are removed during programming. The jumpers are installed exactly where my PICkit 3 programmer would attach, so there’s no way for me to forget to remove them when reprogramming this chip.

Wires From CAT-5E Network Cable

Even with all these concessions to easier routing on a prototype PCB, there will still be an unavoidable nest of wires. In order to keep things tamed, I harvest my spool of CAT-5E network cable for wires that are thin and rigid. Thin wires help me fit more wires in a small volume, and rigid wires stay where I’ve put them. In addition to being affordable and easily available, the four twisted pairs of wires give me eight different insulation colors to help me keep track of which wire goes where.

While we were building a breadboard prototype for our VFD driver, we weren’t terribly concerned with chip layout as it was largely constrained by the practicalities of a bread board anyway. Once we start thinking about transferring it to a PCB, however, we had more flexibility to be creative. The prototype printed circuit board is a grid of through-holes that we can use in any way we like. How shall we abuse this power?

While looking at how wires were run on our bread board, I noticed that there were a few pins that were perfectly aligned from one chip to the next. Placing the decoder output on PIC pins RB4, RB5, and RB6 lines them up perfectly with the input pins of 74138 decoder. As for the decoder output, six out of eight pins were directly lined up with a ULN2003.

This allows some fairly straightforward wiring solder as these wires will not cross over each other and won’t tangle up and make a big mess. By itself that is valuable, but we were tempted to go one step further: how about we eliminate the wires entirely and jam those chips together? If they share the same PCB through-hole, that would eliminate wire soldering entirely.

It sounded good in theory, but in practice the chips are just a little too large for us to fit them three-abreast. I could push my decoder up against my PIC, but couldn’t push the Darlington array alongside the decoder as well. This is probably for the best – there’s value in having the ULN2003 lined up with its siblings.

We may learn in the near future why this is a bad idea, but it’s all part of the fun: trying things and seeing how they work. (Or not, as the case may be.)

Trying to be clever with pin assignment so I could pack chips tightly in my vacuum fluorescent display collaboration with @MLE_Online. We'll find out if this bites me later… pic.twitter.com/YHt76eV9kg

Once we had some idea of what we wanted to do, it’s time to start wiring things up on a breadboard to see if it actually does anything interesting. Dealing with actual chips meant reading their data sheets and figure out where the rubber meets the road and how well theory meets practice.

Not having a lot of first-hand experience with such modules, it was a great way to learn by doing. The first surprise was behavior of the 74HC138 decoder module: Conceptually it takes a three-bit input and decodes it to one of eight pins. Conceptually we thought that meant raising one of eight pins high, but it actually lowers one of eight pins low.

We thought this was going to be a problem and started looking into inverters… before we realized it is a perfect pairing with ULN2003 to do what we actually wanted: The ULN2003 line inverts its input in the sense that when an input pin is high it connects the output pin to ground. So the output of a 74HC138 decoder (seven pins high, one pin low) driving ULN2003 results in seven pins connected to ground and one floating. We can work with this.

A 4-digit, 7-segment LED module stood in for the vacuum fluorescent display while all the logic got worked out. This flexibility is exactly where a breadboard is strong, letting us experiment and verify pieces of our circuit piecemeal. But it is not great for looking respectable or for long-term reliability, so once it successfully ran the LED module, we start planning to commit the design to soldering parts on a prototype PCB.

For the VFD driver project, there were software design motivations to keep things simple. But that’s not the whole picture, there were also motivation from hardware constraints too. My previous projects to make a PIC drive a multi-segmented LED display had fairly simple wiring that connected most output pins of my PIC to current-limiting resistors. A few of the lines could have seen current flow higher than what a PIC is capable of handling, and those were handled with simple transistors. I knew there existed chips designed specifically to drive LEDs, but I wanted to learn the principles of controlling one myself.

Building something to drive a VFD requires dealing with voltages different and sometimes far higher than what is required to drive LED display modules. During our probe of this specific VFD we saw 2.5V AC and 30V DC, atypical of logic circuits. And just as there existed dedicated LED driver chips, there exist chips specifically designed to drive VFD modules, but again the project goal was to learn by building one ourselves.

So we turn to our standard electronic hobbyist toolbox item for controlling power and voltage beyond what our standard parts can handle: the ULN2003A line of Darlington arrays. The go-to solution for controlling inductive loads like relays and small motors, it can handle voltages up to 50V which we need for a VFD.

And again, with multiple different display projects on the horizon, it didn’t make sense to create a controller with hardware pinout specifically tailored to a specific unit. To keep things simple and consistent across displays, all of our controller outputs will be either left floating or tied to ground. If a particular device desires a particular pin to be at a higher voltage, we’ll have to wire up a pull-up resistor on that device’s specific interface board. We will learn if this concession to consistency will cause problems down the line.

In my previous PIC display projects, the code was written for a specific multi-segment display unit as part of the overall project. This meant the source code reflected whether the LED was a common-anode or common-cathode design, it also knew about which segment represented which parts of a particular digit. This knowledge was required because I put priority on making control communication interface easy. For the temperature demo, making my display unit show “72.3F” was a matter of sending the actual UTF-8 text string “72.3F” as bytes. The PIC then parsed that string and determined which segment to illuminate.

But there’s a good chance we have several other matrix display projects in the future, and I didn’t want to invest the time to hard code intricacies of each unit into the PIC. It would be much easier to adapt and experiment if such logic was moved to a more developer-friendly environment like Python on a Raspberry Pi. In the case of the current NEC VFD under consideration, there are segments corresponding to days of the week and other function specific segments like an “On and “Off” text, “OTR”, little clock icon, etc. Most of which won’t necessarily be present on another VFD unit, why spend the time to embed such knowledge in my PIC driver?

We also want the flexibility to explore using the display in ways that are far afield of its original intent. For starters, that seven-segment display in the center doesn’t have to be constrained to display numbers for a clock. All these desires meant moving away from performing data interpretation on the PIC.

Instead, the PIC will accept a raw data stream where each bit corresponds to whether a segment is on or off. Each byte will correspond to 8 segments in a grid, and so forth. This means the task of mapping a desired digit to a set of segments will be the responsibility of driver code on host device rather than PIC peripheral. PIC will only concern itself with rapidly cycling through the matrix of digits keeping them all illuminated.

The code compiled fine, but it didn’t actually work. It would give a response to the first I²C query but then it would stop responding. Here’s the default boilerplate code, which responds to address 0x08, as probed by a Raspberry Pi using i2cdetect tool.

It has disappeared from scan, as it no longer responds to I²C commands sent to its address.

Comparing the I²C boilerplate code with my old LED project, I saw no differences worth mentioning. It should be the exact same code but it no longer does the exact same thing. What has changed between my old LED project and now?

The solution is the same as before: change project properties so XC8 compiler uses its old C90 compatible mode. Once I switched over, the I²C boilerplate code functioned as expected.

Since Microchip has marked this old I²C boilerplate code as deprecated, I don’t expect them to bring it up to date with the new compiler. And given its history of causing me headaches, I guess I’ll plan on using C90 mode for all my projects for the foreseeable future.

I’ve since figured out how to resolve the two error messages to compile the new thing, formally called Foundation Services Library.

The first compiler error message was this:

In file included from mcc_generated_files/USBI2C_app.c:25:mcc_generated_files/drivers/i2c_slave.h:55:34: error: unknown type name 'interruptHandler'void i2c_slave_setReadIntHandler(interruptHandler handler);^

Searching elsewhere in the generated boilerplate, I found a declaration for interruptHandler in another different header file. Copying it into i2c_slave.h addressed the “unknown type name” error.

typedef void (*interruptHandler)(void);

However, that error was replaced by a warning that there are now duplicate declarations of interruptHandler. This seems silly – if there were a declaration to collide with, it should not have thrown an unknown type name error signifying the declaration’s absence.

MPLAB should either not throw the error, or not raise the warning, but it is doing both. I have yet to figure out if the toolchain is busted or if the boilerplate code is. For now, though, I could proceed to the next problem.

The second compiler error message was this:

mcc_generated_files/USBI2C_app.c:30:14: error: no member named 'SSP1IE' in 'PIE3bits_t'PIE3bits.SSP1IE = 1;~~~~~~~~ ^1 error generated.

This one was easier to figure out – go into the header files for this chip and look for SSP1IE. I found it declared on PIE1bits instead of PIE3bits. So to get this code to compile, I changed the boilerplate code from this:

void USBI2C_Initialize(void){PIE3bits.SSP1IE = 1;i2c_slave_open();}

To this:

void USBI2C_Initialize(void){PIE1bits.SSP1IE = 1;i2c_slave_open();}

What does PIE1bits.SSP1IE actually do? I’m not sure so I’m not positive this is actually the correct fix. But at least all of the foundation boilerplate compiles, and I start browsing through sample code for MikroElektronika USB-I2C Click module to figure out what it does and what I can do with it. Reading through code and comments, I saw this comment block.

This comment implies Microchip has decided to deprecate their previous I²C library even though the new library is unable to duplicate important functionality. If true, this is… unsatisfactory. I want block read and write operations for my project.

About a year and a half ago I poked my head into the world of I²C programming with my PIC16F18345 chip. I was pleasantly surprised the MCC boilerplate code actually included an example implementation emulating an I²C EEPROM. That turned out to be a great way for me to get started.

In file included from mcc_generated_files/mcc.h:55:mcc_generated_files/i2c1.h:55:2: warning: "This version of the I2C driver will be removed soon and the correct driver to use is the Foundation Services driver" [-W#warnings]#warning "This version of the I2C driver will be removed soon and the correct driver to use is the Foundation Services driver"

Looks like what I had used before is on its way out.

Since this is a new project, I thought I might as well check out what the new shiny object has to offer. Reading around the web, I found complaints that the previous MCC I²C code would work when conditions are ideal, but it was not very good at letting developers write code to handle error conditions. This might not be important in hobbyist projects like mine, but it was of great importance to people trying to engineer real products.

I added the Foundation Services Library module for my PIC’s MSSP. After code generation was complete, I went into the generated header files and saw a lot more functions declared than previous boilerplate code. There were a few related to overflow and bus collision errors, which I assume were there to address complaints about error handling capability.

Unfortunately, there is no longer a friendly example implementation to reference. There are a lot of declarations but no information on how to use those functions. Microchip’s claim that the Foundation Services Library code is self-documenting has been wholeheartedly laughed at by other forum users. But the forums did point me to Microchip’s MikroElektronika Click Library which interfaces between those nifty little Click modules to a PIC using Foundation Services Library. The trick is finding one that most closely matches what I’m trying to do. Many Click modules are I²C slaves controlled by a PIC acting as master, I wanted my PIC to act as I²C slave accepting commands. A first pass through the Click library found only the USB-I2C Click module, so I installed sample code corresponding to that module and tried to build it.

In file included from mcc_generated_files/USBI2C_example.c:36:mcc_generated_files/drivers/i2c_slave.h:54:34: error: unknown type name 'interruptHandler'void i2c_slave_setReadIntHandler(interruptHandler handler);

Sample code that fails to compile is… not the height of beginner friendliness.

After 30 minutes of hunting around, I failed to find a solution to this problem and decided to return to the old deprecated I²C driver. It may not be the newest and shiniest thing, but it does compile and run.

While the VFD salvaged from a VHS timer/tuner unit was designed to run on voltages unfamiliar to me, once we probed the control pinout I found it much less intimidating. The entire array can be treated as a matrix with its eight grids along one axis and ten elements along another axis. The array is only partially filled: there aren’t actually 80 elements on the VFD. A driver chip will energize one grid at a time, and energize the desired elements within that grid. After some time, the driver will move on to the next grid and its corresponding elements. When the switching happens quickly enough, our human eye sees only a completely illuminated display and would not notice that grid-to-grid cycling.

This general principle is identical to how I drove a LTC-4627JR 7-segment LED array in an earlier PIC project. The only real difference is that the transistors I had used earlier is only good for the +5V used by that LED array and not suitable for +30V for this VFD, but that can be addressed by substituting some switching components.

In the previous project, I was interested in learning KiCAD and the process of ordering custom PCBs for a device for potential low-volume production. Many lessons were learned, most of which discouraged me from pursuing the thought further. This time around there is no fantasy of volume production, this will be an one-off project for a single salvaged VFD.

But now that I know the concept of a display matrix is generically applicable across multiple units, this time around I’m more inclined to keep the PIC side very simple and move more display-specific logic into driving logic which usually runs on a more programmer-friendly device like an Arduino or Raspberry Pi. (Or maybe even a ESP32!) So this time around I’m not going to decode ASCII characters or anything along those lines: I’m going to create a PIC driver that listens for commands over I2C specifically about cycling through and toggling pins. The idea is to avoid unnecessary PIC code churn that uselessly reinvent the wheel from one LED display to another, instead moving that to the Arduino/Pi/ESP32/etc side.

Sawppy was a great ice breaker as I roamed through the expo hall of SCaLE 17x. It was certainly the right audience to appreciate such a project, even though there were few companies with products directly relevant to a hobbyist Mars rover. One notable exception, however is the BeagleBoard Foundation booth. As Sawppy drove by, the reception was: “Is that a Raspberry Pi? Yes it is. That should be a BeagleBone Blue!”

With this prompt, I looked into BBBlue in more detail. At $80 it is significantly more expensive than a bare Raspberry Pi, but it incorporates a lot of robotics-related features that a Pi would require several HATs to reach parity.

All BeagleBoards offer a few advantages over a Raspberry Pi, which the BBBlue inherits:

Integrated flash storage, Pi requires a separate microSD card.

Onboard LEDs for diagnosis information.

Onboard buttons for user interaction – including a power button! It’s always personally grated me a Raspberry Pi has no graceful shutdown button.

On top of that, BBBlue can also handle charging a 2S LiPo battery! Being able to leave the battery inside a robot would be a huge convenience. And people who don’t own smart battery chargers wouldn’t need to buy one if all they do is use their battery with a BBBlue.

8 PWM headers for RC-style servo motors.

4 H-bridge to control 4 DC motors.

4 Quadrature encoder inputs to know what those motors are up to.

9-axis IMU (XYZ accelaration + XYZ rotation)

Barometer

Sadly, a BBBlue is not a great fit for Sawppy because it uses serial bus servos making all the hardware control features (8 PWM header, 4 motor control, 4 quadrature input) redundant. But I can definitely think of a few projects that would make good use of a BeagleBone Blue. It is promising enough for me to order one to play with.

On the Hackaday.io project page of my Luggable PC, I wrote the following as part of my reason for undertaking the project:

The laptop market has seen a great deal of innovation in form factors. From super thin-and-light convertible tablets to heavyweight expensive “Gamer Laptops.” The latter pushes the limits of laptop form factor towards the desktop segment.

In contrast, the PC desktop market has not seen a similar level of innovation.

It was true when I wrote it, and to the best of my knowledge it has continued to be the case. CES (Consumer Electronics Show) 2019 is underway and there are some pretty crazy gamer laptops getting launched, and I have heard nothing similar to my Luggable PC from a major computer maker.

So what’s new in 2019? A representative of current leading edge gamer laptop is the newly launched Dell Alienware Area-51m. It is a beast of a machine pushing ten pounds, almost half the weight of my luggable. Though granted that weight includes a battery for some duration of operation away from a plug, something my luggable lacks. It’s not clear if that weight includes the AC power adapter, or possibly adapters plural since I see two power sockets in pictures. As the machine has not yet officially launched, there isn’t yet an online manual for me to go read what that’s about.

It offers impressive upgrade options for a laptop. Unlike most laptops, it uses a desktop CPU complete with a desktop motherboard processor socket. The memory and M.2 SSD are not huge surprises – they’re fairly par for the course even in mid tier laptops. What is a surprise is the separate detachable video card that can be upgraded, at least in theory. Unlike my luggable which takes standard desktop video cards, this machine takes a format I do not recognize. Ars Technica said it is the “Dell Graphics Form Factor” which I had never heard of, and found no documentation for. I share Ars skepticism in the upgrade claims. Almost ten years ago I bought a 17-inch Dell laptop with a separate video card, and I never saw an upgrade option for it.

And finally – that price tag! It’s an impressive piece of engineering, and obviously a low volume niche, but the starting price over $2,500 still came as a shock. While the current market prices may make more sense to buy instead of building a mid-tier computer, I could definitely build a high end luggable with specifications similar to the Alienware Area-51m for less.

I am clearly not the target demographic for this product, but it was still fun to look at.

Today’s little research adventure came courtesy of a comment on one of my earlier posts: my Dell 7577 laptop has a USB-C port. Some laptops – like the latest Apple MacBook – charge through their USB-C ports. Does that mean I can charge my Dell through its USB-C port?

Well… no. No I can’t. But it was an interesting experiment.

As is my usual habit, my first thought was to find if there’s any mention in the online version of my manual. Clicking on the “Power” section had the usual information about a standard Dell AC adapter but no mention of USB-C charging. Clicking on the “Ports and Connectors” section returns a list that listed several functions for the USB-C port, but that list did not include power.

However, it was still an impressively long list! I had not realized the full extent of what a USB-C connector could do. I was first introduced to this connector with my Nexus 5X cell phone, and I was happy enough just to have a charge connector that had eliminated frustration with orientation.

But it’s not just convenience, USB-C tries to solve an impressive set of problems all with a single connector. The fact it can transfer data was a given due to USB legacy, and I knew it could transfer more power than older USB connectors from the aforementioned Apple MacBook. But it wasn’t until I found the Wikipedia page on Thunderbolt 3 that I realized how wide the ambition spread.

Not just low-speed data like classic USB, but there’s also the option for high speed video data in the form of DisplayPort support. And that’s not all – it can tap into a computer’s internal high speed PCI bus. This part of the spec is how some laptops could utilize external GPU enclosures. Such a wide range of capability explains why Apple decided their latest laptops need only USB-C plugs: one plug can handle all the typical laptop port duties.

But as my blog comment pointed out, there’s also the risk for customer confusion. A USB-C port might do all of these things someday, but clearly not all USB-C ports could do everything today. One marvel of our current system is that, for the most part, if a plug fits into a port then it is the right plug for the right port. Now we’re moving away from that. Sure, it’s nice the protocol negotiation allows the computer to throw up a dialog box telling me I can’t charge through my USB-C port, but would it have been better to avoid this confusion to begin with?

Maybe one day we’ll get to the point where every USB-C port can do everything, bringing us back to the “if it fits, it works” world we once had. In the meantime, there’s going to be a lot of confusion. Let’s see how the industry adopts USB-C over the next few years…

As a thanks for participating in the ESP32 mesh network project by Morgan and Ben, people whose badges became nodes on the network were generously gifted the ESP32 module mounted to each of our badges. Unfortunately, I managed to damage mine before the big stage demo so sadly I didn’t put in the honest work to earn that ESP32. Still, I now have a damaged ESP32 that I can try to fix.

Before I start trying to fix it, though, I should have a better idea on how to tell if a ESP32 is up and running. The only mechanism I had before was to run the badge mesh network app and see if there’s any response, but I want to know more about how a ESP32 works in order to better tell what’s broken from what’s working. Also – since I’ve desoldered my ESP32 from the carrier board, it is not nearly as easy to test it against the badge.

I’ve read about a lot of projects built using the ESP32 on Hackaday, so I know it’s popular for and it would be cool to add it to my own project toolbox. Given its popularity, I thought it wouldn’t be a problem to find resource on the internet to get started.

I was right, and wrong. There is no shortage of information on the internet, the problem is that there’s too muchinformation. A beginner like myself gets easily disoriented with the fire hose of data presented by ESP32.net.

How about other individual tinkerer’s adventures on their own blogs? Here’s one person’s initial report poking around an ESP32, including using an oscilloscope to see how quickly it can change output based on input. And here’s another Hello World, and there are many more blogs covering ESP32. (Soon including this one, I suspect.)

It’s going to take a while for me to get oriented, but it should be fun.

I received a Adafruit Hallowing in the Supercon sponsor gift bag given to attendees. While reading up about it, I came across this line that made no sense to me at the time.

OK so technically it’s more like a really tricked-out Feather than a Wing but we simply could not resist the Hallowing pun.

I can tell the words “Feather” and “Wing” has some meaning in this context that is different from their plain English meaning, but I didn’t know what they were talking about.

But since this is Adafruit, I knew somewhere on their site is an explanation that breaks down whats going on in detail. I just had to follow the right links to get there. My expectations were fully met – and then some – when I found this link.

So now I understand this is a counterpart to the other electronics hobbyist programming boards and their standardized expansion board form factor. Raspberry Pi foundation defines their HAT, Arduino defines their Shield, and now Adafruit gets into the game with feathers (a board with brains) and wings (accessories to add on a feather.)

Except unlike Raspberry Pi or Arduino, a feather isn’t fixed to a particular architecture, or a particular chip. As long as they operate on 3.3 volts and can communicate with the usual protocols (I2C, SPI), they can be made into a feather. Adafruit make feathers out of all the popular microcontrollers. Not just the SAM D21 at the heart of Hallowing, but also other chips of the ATmega line as well as recent darling ESP32.

Similarly, anyone is welcome to create a wing that could be attached to a feather. As long as they follow guidelines on footprint and pin assignment, it can fit right into the wings ecosystem. Something for me to keep in mind if I ever get into another KiCad project in the future – I can build it as a wing!

One of the gifts to Supercon attendees was a Sparkfun Roshamglo badge. While reading documentation on writing software for it, one detail that stood out about this Arduino-compatible board was the lack of a USB-to-serial bridge. Such a component is common on Arduino boards. The only exceptions I’m aware of are the Arduino Leonardo line using the ATmega32u4 chip which has an integrated USB module.

The ATtiny84 on the Roshamglo is far too humble of a chip to have an integrated USB functionality, so that deviation from standard Arduino caught my interest. In fact, not only does the board lack a serial-to-USB bridge, the ATtiny84 itself doesn’t even have a UART peripheral for serial communication with a serial-to-USB bridge. Now we’re missing not one but two things commonly found in Arduino-compatible boards.

What’s the magic?

The answer is something called V-USB, a software-only implementation of basic USB fundamentals. It is not a complete implementation, most notably it does not handle all the error conditions a full implementation must gracefully handle. But it does enough USB to support the Micronucleus boot loader. Which creates a very basic way to upload Arduino sketches to an ATtiny84 without an USB serial interface engine (SIE), or even a UART, on the ATtiny84 chip.

Yes, it requires its own custom device driver and upload tool, but there are instructions on how to make all that happen. The point is minimizing hardware requirements – no modification on the host computer, and minimal supporting components for the ATtiny84.

It looks like a huge hack, and even though SparkFun cautions that it is not terribly reliable and won’t work on every computer, it is still impressive what the V-USB people have done under such limits.

What’s big, orange, and a mystery? The Supplyframe cube given to Supercon attendees. It is a pretty neat physical manifestation of the Supplyframe logo. It is made of injection-molded plastic that’s been given some sort of surface finish treatment. The result is a vaguely satin feel more upscale than commodity plastic. It also comes in a nice cardboard box whose description of its contents were not sufficiently technical for the hardware hackers looking it over. Likely intentionally to give it an air of mystery.

We see a micro USB port on the side, and a clear plastic rectangle mounted on the bottom. Also visible on the bottom are four screws, and removing them to see the insides revealed an expected circuit board behind the micro USB port. What was less expected was the wire soldered to the board, and a sheet of copper foil at the other end of the wire. What is this thing?

This being Supercon, people quickly figured out there’s a FTDI USB to serial chip behind the port, so computers see the cube as a serial port. When plugged in, the plastic rectangle at the bottom reveals its function to diffuse light from the twelve LEDs shining downwards. It’s all very pretty, but what does it do?

People were making headway figuring it out, and they got to check their answers during Voja’s scheduled talk about the 2018 Hackaday Supercon badge. Voja did say a few words about the badge, but he was clearly more interested in talking about the cube which he also designed. He switched gears to the cube around the 6:40 mark of the recorded talk.

The default firmware implements a random number generator that could store up to 2 megabytes of random bytes. The copper foil works as one half of a capacitor for transmitting data between two cubes sitting next to each other, so one cube can get an identical copy of the random bytes in another cube. Once copied, each cube could be used as one-time ciphers to encrypt up to two megabytes of data that only a person with the other cube can decrypt.

But of course, that’s just the default firmware. Voja went over what’s on the board and what else it can do. The LEDs are random (except when they all light up to signal a cube is waiting for transmit or receive) and there’s currently an accelerometer sitting unused. After the conference Voja created a Hackaday.io project for the cube and now we wait to see if people do fun things with it.

In the pre-Superconference badge hacking call to action, wireless badge communication was raised as a specific challenge laid out for attendees to tackle. One particularly ambitious effort was to build a mesh network for wireless communication using ESP32 modules mounted to the badge expansion header. The ESP32 mounting system is straightforward, it was the software that would prove to be tricky.

At the end of the weekend, Morgan and Ben got the network up and running with just over an hour to spare. They started recruiting people to join their IRC-style chat network for the final demo, and I signed up. In the test session I was able to see messages sent over the network, and send a few myself. But when it came time for the actual demo on stage, my badge was unable to connect! Fortunately they had enough other participants so my participation was not critical, but I was sad to have missed out. After the presentation (and winning a prize) the team told everyone on the network we could keep the ESP32 as a token of thanks.

After the conference I examined my ESP32 mount and found a few cracked solder joints. It looks like I had accidentally smashed my ESP32 module sometime between the test session and the presentation. Looking on the Hackaday.io project page, I found the simple schematic and tested connections using my multimeter. Several connections were indeed severed between the badge header and the mounting circuit board. I tried the easy thing first by reheating all the solder to see if they could bridge the gaps. This helped, but two lines remain faulty and were patched with wires.

After this patch, I tested with [mle_makes] ESP32-equipped badge and we could not communicate, indicating further problems with my ESP32. The next step is to desolder it from the board to see if I could use the ESP32 as a standalone module. Once the module was removed from the carrier board, I saw a problem: three of the pads had separated from the module, one of them being the EN(able) pin critical to a healthy ESP32. The other two damaged pads (IO34 and IO35) I hope I could live without.

Is this the end of the road for my gifted ESP32? I thought it was, but [mle_makes] disagrees. The next experiment is to try soldering to the trace leading to EN pad, or the via further inboard. This will be a significant challenge – that via is smaller than the tip of my soldering iron!