Virtual Confusion

Okay, I get it. FreePCB is kind of dated and I should really learn Eagle at some point. But it’s still a useful tool — at least, when Windows doesn’t get in its way.

FreePCB, unfortunately, defaults to storing project files in a “projects” folder in its own working directory. This makes some sense, but ultimately documents are supposed to be stored in the proper place — not where the program is installed.

I agree this is best practice — but Windows (since Vista) takes things a step farther, as I found out today. If a 32-bit program is not running with administrator privileges and isn’t compiled for Vista or later, that means it can get “virtualized.”

What this means, in practical terms, is that, since Windows no longer allows programs to write to the “Program Files (x86)” directory structure, it makes a shadow copy of this structure and redirects all writes to that.

The problem arises when you want to, for example, go find these files that the program has written. They’re nowhere to be found in the “Program Files (x86)” structure — and yet, the program can exit, relaunch, and reload the files with no problem at all. Witchcraft!

Figuring that the files had to be somewhere on the drive, I went back to first principles and ran a search.

c:\>dir /s /b *.fpc

After a brief search, the files were found in the c:\Users\…\local\VirtualStore\ substructure. A quick Google search turned up the following explanation, paraphrased above.

Mystery solved. But some notice would have been appreciated, MS. Maybe one of those pop-up boxes you’re so fond of using to steal the focus at the worst possible times. Or something.

Posted in System Administration | Leave a comment

Pointers in BASIC

BASIC, as Rodney Dangerfield would have said, “don’t get no respect.” Even when using modern dialects like FreeBASIC, which allow custom user types, modern-style functions and subroutines, encapsulation, and more, there’s still very much a “Real Men Program In C” attitude.

C is deservedly famous and influential, of course, but it’s often tedious to write small, proof-of-concept programs in C. If a new idea about, say, cellular automata strikes you, it’s very easy to write a few lines of BASIC code and be testing it — in full-color HD.

But still, C proponents say, it’s a “toy” language. It doesn’t have pointers or linked lists or all that.

Except — it does. In FreeBasic, at least, the familiar malloc() and sizeof() functions are available, and memory truly can be dynamically allocated, deallocated, and manipulated as pointers.

Here is a short example that demonstrates creating and printing out a simple linked list in FreeBASIC. Memory is dynamically allocated and user type fields are accessed with the -> operator, just as in C.

'Pointers in FreeBASIC
 'Example: Create and print out a short linked list

'M. Eric Carr / Paleotechnologist.Net
 'Contact: eric (at) the above domain

'Define a simple user type
 type listItem
 payload as double
 link as listItem ptr '"next" is a keyword in BASIC; we can't use it.
 end type

dim as listItem ptr head, current
 dim as integer n

'Teach FreeBASIC about NULL
 const NULL = 0

'Set up the first item in the list manually
 head = allocate(sizeof(listItem))
 current = head
 current->payload = 0
 current->link = NULL

'Use a for loop to add nine more items to the list
 for n=1 to 9
 'Starting conditions: current points to last item in the list.
 current->link = allocate(sizeof(listItem))
 current = current->link
 current->link = NULL 'For safety
 current->payload = n^2
 next n

'Read them back using a while loop, looking for the NULL at the end
 current = head
 while current <> NULL
 print current->payload
 current = current->link
 wend

'Done. Wait for a keypress before exiting.
 sleep

(Don’t tell the use-C-or-die types, but FreeBASIC can use inline x86 assembly, too.)

Posted in BASIC, C, Coding, HOW-TO | Leave a comment

DIY Ionic charging

The Fitbit Ionic is a neat little device, capable of tracking various different exercises as well as providing continuous heart rate monitoring and sleep quality tracking. It is quite well-connected as well, with WiFi, BlueTooth, and NFC capabilities. It can stream music to Bluetooth headphones, sync exercise data over WiFi, and pay for your snacks via NFC.

The battery life is better than I expected, too. It will run for several days of typical use without charging. If I don’t use the GPS tracking feature much, it can sometimes go roughly a week between charges. It even sends you an email when it’s low on energy. Welcome to the future.

The one drawback, of course, is that (being waterproof) the Ionic uses a proprietary MagSafe-like connector for charging. And naturally there’s no information readily available about what pins are what. So if your Ionic’s battery is low and you don’t have its charging cable handy, you’re pretty much out of luck.

Time for some detective work.

The back of the Ionic. The three gold pins are for the charging cable.

I knew that the charging connector was symmetric; it will work in either orientation. So the two outside pins must have the same function. This, with the fact that the charging cables don’t look like they contain more than just wires, means that, in all likelihood, either the center pin is ground and the outer pins are 5V, or the other way around. If I were designing a watch like this, I’d go for one 5V pin in the center and two ground pins. Let’s try that, I figured.

So I hacked together a small breadboard-based adapter and connected it to a current-limited lab power supply. (The current-limited part is important: if you get the polarity wrong and forward-bias a protection diode, you don’t want your power supply dumping three amps of current through it. That’s how the magic smoke gets let out. With the current limiting, the supply will back off on the voltage if too much current is flowing. This gives you time to disconnect it before anything gets too warm.)

I limited the power supply to 300mA and gave it a shot. With a little adjustment to get it to sit on the pins properly, it works, drawing about 180mA at 5V.

Details of the connections. The outer two pins are tied together and to Ground. The center pin is 5V.

The Ionic, less its wristband, on its makeshift charger.

The adapter itself is straightforward: Three standard row-connector pins, with the outer two bent slightly inwards to match the Ionic’s connector pitch. The outer two are connected together and to Ground (black, on a USB cable); the center pin is connected to a 5V supply (red, on a USB cable).

The Ionic on the makeshift charger, showing some of the connections.

Disclaimer: Use this technique at your own risk; this is a hack, not an engineered solution. It worked for me, and properly implemented, should work for anyone, but will certainly void your warranty if you get it wrong (and maybe even if you do it right.)

 

Posted in Hacks, HOW-TO, Power, Reverse Engineering, Toys | Leave a comment

NeoPixels

“Civilization advances by extending the number of important operations which we can perform without thinking about them.”

–Alfred North Whitehead

More interesting components make for more interesting devices. This is certainly the case with one of Adafruit Industries’ latest creations — the NeoPixel.

NeoPixel (breadboardable version) (Image: Adafruit.com)

 

The idea behind NeoPixels is both simple and brilliant. Make a true-color RGB LED as easy as possible to drive with a microcontroller. Normally, in order to get full color from a RGB LED, you need to send PWM signals to the three signal pins. Controlling this on a small microcontroller with limited resources can be demanding, leading to design compromises like using only the eight basic steady-state RGB colors or only flashing the color intermittently, when the processor has nothing better to do.

With NeoPixels, the PWM functionality has been offloaded onto the LED. NeoPixels have a four-wire interface — and that’s counting ground, power, and signal out. Now running a full-color LED only takes one wire, and takes far less of the processor’s attention. Instead of continually monitoring the RGB pin states, the CPU sends a new color whenever it changes, and goes about its business (or goes to sleep) at other times.

Adafruit has an excellent “Uberguide” to everything NeoPixel. Load an Arduino library or two, and two or three lines of code later, you have color. Interfacing with a PIC is almost as easy once you have a few bit-banging routines written.

NeoPixels can be daisy-chained, too. The signal-out pin of one connects to the signal-in pin on the next one. There’s no practical limit to the number that can be chained this way, if you don’t mind the latency and distribute power and ground. Once a NeoPixel has received its twenty-four bits, it sends all subsequent bits down the line. So the first three bytes sent control the first NeoPixel in the chain, the second three bytes control the color of the second, and so on. (The NeoPixels don’t know and don’t care if anyone is listening downstream, which makes interfacing easy but doesn’t allow for verification.)

They come in single units, strips, rings, panels, and now they’re even available in 5mm and 8mm through-hole.

I love living in the future.

Posted in Arduino, Components, Design, Digital, Electronics, PIC Microcontrollers, Reviews | Leave a comment