PIC – Engineer On The Loose

USB on the Microchip PIC microcontrollers – Part II – Tool Chains and Development Environments

Nov 262014

This is Part II of the USB on the Microchip PIC series of articles.

In order to do anything interesting on the PIC we’ll need to install a development tool chain. Typically a tool chain consists of at least a compiler, assembler, and linker. Any modern tool chain will likely also include a librarian, loader, and a handful of utilities for transforming and viewing the tool chain output.

In addition to the compiler tool chain a full featured development environment is almost a requirement. I know of developers that swear by simple text editors for code and command line terminals for running the tool chain. I take the position that tools have advanced to the point where they add significant value in terms of ease of use and speeding development. Modern development environments include syntax highlighting, code completion, parameter filling, version control integration, tool chain integration, and often debugging views.

For the Microchip line of PIC microcontrollers the goto Integrated Development Environment (IDE) has always been, and from where I sit, will continue to be MPLAB and MPLAB-X. Microchip makes MPLAB and MPLAB-X available for download for free. MPLAB-X is the successor to MPLAB and is being pushed as the recommended IDE moving forward. MPLAB is still available for download for older projects that require it but in this series of articles we will be using the MPLAB-X environment. I’m aware that other vendors tried to sell compilers and IDE’s into the Microchip development space but really did they ever get any traction? Can you name two alternatives to MPLAB? Me neither.

Along with the IDE you will need to download a tool chain. Microchip again provides a free solution. Microchip makes available for free download and use, even for commercial projects, compilers for all of their microcontrollers. Microchip sells upgraded versions of their tool chains. The only differences listed on the Microchip website between the free and purchased versions of the compilers are available optimization levels.

From the Microchip website:

MPLAB® XC Compiler PRO Edition:
* Provides powerful code optimization at better than 50% when compared to the free edition, giving the most efficient memory usage

MPLAB® XC Compiler Standard Edition:
* Provides a lower cost compiler option with a 20-25% code optimization when compared to the free edition

MPLAB® XC Free Edition:
* Supports all the devices and commands of the Standard and PRO Editions
* No time or memory restrictions
* Limited code optimizations
* Unrestricted use—ideal for a low-cost academic or commercial solution

What this means is that the free versions of the compilers are viable for any project, commercial or not, that is not speed or code size limited. And if you need the higher levels of optimization the costs are not outrageous for a commercial project.

In this series of articles I will be using the XC8, XC16, and C18 compilers, all available for free download from Microchip, look in the Downloads and Downloads Archive tabs. At the time of this writing the latest XC8, XC16, and C18 compilers are v1.33, v1.23, and v3.46. The latest available MPLABX IDE is v2.20.

Microchip is recommending all new development use the XC line of compilers but older projects may or may not compile cleanly under the XC compilers. MPLABX can import old MPLAB style projects, sometimes seamlessly, sometimes not. The XC compilers can sometimes compile projects that targeted the CXX line of compilers, sometimes not. Microchip publishes a conversion document to migrate from the CXX compilers to the XC compilers, MPLAB C18 to XC8 C Compiler Migration Guide. You can find a link to this and other Microchip compiler related documentation on the Documentation tab.

In the mean time I am using a mix of CXX and XC compilers as required. I am doing all of my new development targeting the XC compilers and am migrating older CXX projects to XC as appropriate.

In order to follow along you will need to download and install the XC8, XC16, C18 tool chains and the MPLABX IDE. Each of these downloads is 50 to 150 MB. After downloading the tools you will need to install and integrate them. Installation is a typical process. I am using MS Windows and the installation is typical double click and install routine. Something thing to keep in mind that you might want to consider, at multiple times in the installation and use of the tools you will need to point to the locations of the tools and application libraries, it can be more convenient to put the tools and application libraries somewhere closer to the top of the file system hierarchy rather than accepting the default Windows installation location. The IDE and compilers want to install in C:\Program Files (x86). I typically install the tool chain and IDE in a C:\apps\Microchip directory. Under each of the IDE and tool chain directories I usually install each particular version in a subdirectory. The MPLAB-X IDE supports multiple different versions of the tool chains installed at the same time and allow you to pick between them. This is a bit of a requirement as deeply embedded projects, for good or bad, often rely on or take advantage of specific idiosyncrasies of the tool chain.

After you have all of your tool chains downloaded and installed you need to integrate them into MPLAB-X. Load MPLAB-X and go to the Tools->Options menu.

Under Tools->Options pick the Embedded tab and Add.. each tool chain.

Once you have a project loaded

select the project properties from the File menu

and select the tool chain for your architecture

If you can get to this point you should be ready to begin building for the PIC family of microprocessors. In the next article we’ll look at Microchip Library for Applications and begin building and looking at the output of some of Microchips demo code.

USB on the Microchip PIC microcontrollers

Tech No Responses »

Nov 092014

I am working on a project that needs high speed real time data acquisition, large data storage, and a rich interface to the web. Put these requirements together and one solution is to use an embedded real time system for the data acquisition and a general purpose computer for the data storage and web interface.

Of the many ways to implement a solution like this the solution I chose utilizes a Microchip PIC microcontroller for the high speed data acquisition and and embedded PC style platform running Linux for the data store and web interface. The connection between the PIC microcontroller and the embedded PC is USB.

Over the course of the next few posts I will be showing a how to bring up USB on a PIC microcontroller, both as a bootloader and as an embedded application. I will be relying on Microchip’s Libraries for Applications or MLA to provide the USB and bootloader frameworks. Part of the MLA is a USB framework targeting Microchips 8, 16, and 32 bit processors. The MLS also provides a wealth of example code including a USB bootloader. I will be showing how to target the USB framework for a couple different PIC processors and how to go end to end from a naked chip to a USB application exchanging data with a PC.

I plan to post on the following topics:

USB on the PIC – Introduction

Installing the MPLAB-X PIC development environment

Microchips Libraries for Applications

PIC development tools

Bootloaders

Building the MCHPUSB bootloader for the PIC18

Building the HID bootloader for the PIC18

Building the HID bootloader for the PIC24

Building the HID bootloader for the dsPIC33

Writing a USB application

USB slave application on the PIC

USB host driver and application on the PC

You can acquire some of the following tools if you want to follow along:

A USB Bit Whacker. The UBW is a simple, relatively inexpensive development board sporting the PIC18F2553. The UBW is well supported and ships with a an open source USB bootloader and application. This makes it an excellent starting point for USB development. You can get a SMD UBW or through hole UBW from Sparkfun Electronics.

[Update] Since I snagged some PIC18F25K50 P-Star development boards on Pololu’s 2014 Black Friday Sale I’ll be updating this series to also work with these micros.

A Bus Pirate. The Bus Pirate is base on a PIC24 and is an excellent tool to have in your embedded development toolbox. That we can also use it for a development platforms is gravy. You can get a Bus Pirate from Sparkfun, Adafruit, or Seeedstudios.

You will also want to download the Microchip Libraries for Applications v2014-07-22 and the v2010-08-04 version from the Archives tab.

I will be building the demo applications in MPLAB-X which you will want to download and install for you flavor of operating system.

You will need the Microchip XC compiler for the architecture of the chip you will be using, XC8 for the PIC18 chip and XC16 for the PIC24 and dsPIC33.

If you are serious about Microchip PIC development you will need an ICSP. I use the PICkit2 but the ICD2, PICkit3, ICD3 all should work equally as well.

Drawbot electronics – test driving the EiBotBoard (EggBotBoard)

Tech No Responses »

Feb 172014

As mentioned in an earlier post I have decided to use the Eggbot control board (EiBotBoard) to drive my drawbot. I’ve gotten the electronics up and running, mostly just plug it in, screw down the stepper motor wires, and plug in the pen lift servo motor. Here are some videos of the EiBotBoard in action.

Some commentary on why I am using the EiBotBoard. The EiBotBoard is a nicely integrated dual stepper motor, multi servo motor driver that accepts high level motion commands over USB from a serial console.

Description of the motors selected for the drawbot. A couple NEMA 17 stepper motors I had laying around in my parts box. They are 0.8 amp motors, well within the 1.25 amps the EiBotBoard can supply.

Motion demo of the EiBotBoard driving two steppers and a pen lift servo. The script that is running is posted below. I am using a cygwin command window to echo the commands to the USB virtual comm port. Keep in mind Windows enumerates the COM ports starting at 1 and cygwin enumerates /dev/ttySxx starting at 0. In the script below I am echoing to ttyS18 because Windows enumerated the COM port at COM19.

Finally more commentary on why I like using the EiBotBoard.

Commands running in a cygwin shell script. Script with comments below.
echo "v" > /dev/ttyS18 echo "sm,500,500,500" > /dev/ttyS18 echo "sc,4,6000" > /dev/ttyS18 echo "sc,5,26000" > /dev/ttyS18 sleep 1 echo "tp" > /dev/ttyS18 sleep 1 echo "tp" > /dev/ttyS18 sleep 1 echo "tp" > /dev/ttyS18 sleep 1 echo "tp" > /dev/ttyS18 sleep 1 echo "tp" > /dev/ttyS18 sleep 1 echo "em,3,3" > /dev/ttyS18 echo "sm,1000,2000,2000" > /dev/ttyS18 sleep 1 echo "sm,1000,-2000,2000" > /dev/ttyS18 sleep 1 echo "sm,1000,2000,-2000" > /dev/ttyS18 sleep 1 echo "sm,1000,-2000,2000" > /dev/ttyS18 sleep 1 echo "sm,1000,2000,-2000" > /dev/ttyS18 sleep 1 echo "sm,1000,-2000,2000" > /dev/ttyS18 sleep 1 echo "em,0,0" > /dev/ttyS18

Send the version command to the board, establishes communication with the board.
echo “v” > /dev/ttyS18

Move both steppers at 1/16 size steps (the default) for 500 steps each and take 1/2 second to move (500 msecs)
echo “sm,500,500,500” > /dev/ttyS18

Set the pen lift servo min and max values, 6000 and 26000, determined from experimenting with this servo
echo “sc,4,6000” > /dev/ttyS18
echo “sc,5,26000” > /dev/ttyS18

Each TP command toggles the pen position from up or down
echo “tp” > /dev/ttyS18

Set the stepper fraction to 1/4 sized steps.
echo “em,3,3” > /dev/ttyS18

Step the motors for sm, duration in msecs, number of steps motor1, number of steps motor2
echo “sm,1000,2000,2000” > /dev/ttyS18
echo “sm,1000,-2000,2000” > /dev/ttyS18
echo “sm,1000,2000,-2000” > /dev/ttyS18
echo “sm,1000,-2000,2000” > /dev/ttyS18
echo “sm,1000,2000,-2000” > /dev/ttyS18
echo “sm,1000,-2000,2000” > /dev/ttyS18

Disable the motor drivers to avoid over heating the motors.
echo “em,0,0” > /dev/ttyS18

BlinkyPov – the light dawn (or at least brightens)

Tech No Responses »

Oct 182012

I’m man enough to admit when I’m wrong, or at least only 50% right.

If you’ve been reading my blog posts you know we bought and built a blinky pov and have since struggled to get it to program reliably. When you’re a 14 year old with a 14 year old’s attention span it either works, or it doesn’t work, not a lot of patience for debugging.

We tried quite a few different ways to program the blinky, varying displays and display parameters, with limited success. The programming software was clearly running in the chip, or at least causing the programming status LEDs to light in the documented fashion. We did a pin for pin build verification. The blinky assembly instructions on W&L’s site for the BlinkyPov are first rate, so good even a child can build it and get it right the first time. A child did build it and did get it right the first time. The build verification showed the blinky pov was built to the documentation and a little off the cuff design analysis didn’t turn up anything sketchy. It looked like it should be working. We did go to the W&L blinky forums when we were initially having programming failures. The blinky forums have multiple posts by people having issues programming their blinky povs. We followed the advice to try changing displays, browsers, monitor settings, room lighting, etc, mostly without much luck. We could successfully program maybe 10% of the time.

After finally giving up our blinky sat on the shelf for a few months, shelved but not forgotten. As I’ve said before, I believe W&L’s BlinkPov is probably the coolest, most accessible pov toy to hit the market. I thought, and still think, it is a great device, I just can’t get it to program reliably.

After a few months on the shelf I pulled the blinky down and started digging around to see if I could figure out what was causing the programming failures. I rechecked the build verification, everything looked ok. I walked through the programming sequence, observing the LED’s, noting the states described in the BlinkyPov documentation. Still no go. At this point it was time to break out a scope and see what was going on.

I typically keep my main monitor at a reduced contrast and brightness. My main monitor is Samsung SyncMaster P2770 set at 50% brightness and 30% contrast.

Scoping the blinky SCLK and SDAT lines with the monitor at B50/C30 produces this trace.

The upper trace (yellow) is SCLK, and the lower (blue) is SDAT. Clearly this is sketchy. With the wild swings in the data and clock lines it is easy to see how the programming could, and would, go awry.

I scoped a couple other display devices, changing browsers and room lighting, posted the results here, and jumped onto the blinky forums and posted my findings. Wayne and Layne quickly responded with a couple good suggestions. In particular the idea that the display noise was coming from the LCD PWM. That made a lot of sense. I gathered up a couple displays, my main desktop monitor, and an Acer InspireOne netbook, and captured the following scope traces with varying brightness and contrast.

It is obvious from the traces below that the brightness and contrast have a huge affect on the signal captured by the blinky sensors.

I normally keep my main desktop monitor at 50% brightness (B50) and 30% contrast (C30). I first wanted to see what affect changing the contrast would have while keeping the brightness fixed. The following series of scope traces are at 50% brightness (B050) and 0%, 30%, 50%, and 100 % contrast (C000, C030,C050,C100).

Brightness 50% Contrast 0%

Brightness 50% Contrast 30%

Brightness 50% Contrast 50%

Brightness 50% Contrast 100%

The strength of the received signal is proportional to the contrast, more contrast, more signal. Since more signal sounds better than less signal, cranking the contrast up to 100% when trying to program seemed like a good idea. Changing the contrast doesn’t seem to help with the wild swings in the signal, but hey, at least they’re bigger, and bigger is always better.

With the contrast decided, 100%, it was time to try varying the brightness. Starting at a brightness of 50% (B50) and contrast 100% (C100) I stepped through, brightness levels of 50%, 60%, 80%, 90%, 95%, 98%, and 100%.

Brightness 50% Contrast 100%

Brightness 60% Contrast 100%

Brightness 80% Contrast 100%

Brightness 90% Contrast 100%

Brightness 95% Contrast 100%

Brightness 98% Contrast 100%

Brightness 100% Contrast 100%

It is clear that turning up the brightness, on my monitor really anything past 50%, will pull the LCD noise off of the black level far enough that it should allow the blinky to program. Cranking the brightness well above 50% cleans up the signals tremendously and gets them to the point where they start to look like digital signals.

With the huge benefit seen by turning the brightness up to 100% I wondered what the signals would look like with the brightness at 100% and the contrast something lower. On my monitor it is mildly annoying to change the brightness and contrast using the touch sensitive buttons provided by Samsung. If I only have to turn one setting all the way up, that is half the hassle.

The following traces are with the brightness at 100% and the contrast at 100%, 50%, 30%, and 0%.

Brightness 100% Contrast 100%

Brightness 100% Contrast 50%

Brightness 100% Contrast 30%

Brightness 100% Contrast 0%

With the brightness at 100% the signals stay pretty clean, even with the contrast turned down. BUT, I do see some funky steps in both the clock and the data with reduced contrast. My take away is, to get the cleanest signal turn up both the brightness and the contrast to 100%.

With the brightness and contrast at 100% I tried room lights on vs room light off.

Brightness 100% Contrast 100% Lights ON

Brightness 100% Contrast 100% Lights OFF

Having the room lights off seemed to clean up some noise near the black level. I haven’t looked at exactly how the blinky programming code determines the black level so the black level noise might or might not be an issue.

All of the above images are from my main desktop monitor. The Acer Netbook displayed large swings with reduced brightness so I decided to check it next. The Acer seems to only have brightness control on the keypad. It wasn’t immediately obvious how to change the contrast so I only took traces varying the brightness levels. The following images are at brightness 10%, 40%, 50%, 70%, 90%, and 100%. On the Acer the brightness needs to get up around 90% before the noise starts to pull off of the black level. And then at 100% the signal cleans up nicely.

Acer Brightness 10%

Acer Brightness 40%

Acer Brightness 50%

Acer Brightness 70%

Acer Brightness 90%

Acer Brightness 100%

So with all of this you’d think I’d have it nailed, the problem finally solved, turn the contrast and brightness both up to 100%, clean signals result, and programming should go off with out a hitch. Unfortunately not, nope, nada. I tried half a dozen times, nothing. Just a blinking error code. Man what a drag. Maybe it’s just me, maybe my blinky pov programming technique just sucks, but I’m turning up snakes eyes every time. I’m not giving up though. I know it can be done. I’m not going to let a bit of wires and blinking lights bring me to my knees. I will prevail…..

ps. I know it looks like I don’t have a life. Usually I do. In this case I really want to get this puppy working. Wayne and Layne have produced a nice little toy and I’m having a good time fencing with it. I shall emerge victorious !!

BlinkyPov – an issue in the programming web page

Tech No Responses »

Oct 152012

It looks like there is an issue in the BlinkyPov programming web page.

The blinky pov reads data on each low to high and high to low transition of the clock. The data is set, high or low (white or black), and the clock is transitioned, low to high or high to low. The clock then maintains it’s present state while the data is setup for the next bit value and then the clock is transitioned again.

If the clock is ever out of sync the data will not be read properly… It turns out it is fairly easy to get the clock out of sync.

Let’s say you are trying to program your blinky pov and you are becoming increasingly frustrated. You are changing messages, changing monitor settings, changing programming timing, starting and stopping and restarting and stopping again.

The blinky pov programming web page expects the initial value of the clock state variable (current_clock) be zero and the initial value of the clock to be black. The first data bit is setup and the clock is expected to transition from the initial value of black to white. The bliny pov programming page does not initialize the clock state variable properly at the beginning of each run and if the programming stopped when the clock value is high, the clock will be out of sync on the next programming cycle. Which will yield yet another failure to program.

This is fairly easy to show.

Let’s say you are trying to program a simple message, something short and sweet like this..

The bit pattern that needs to be programmed into the blinky pov is this…

You can see the hex and bit dump of the programming message by running my modified (and fixed) version of the blinky pov programming page at http://techspin.info/blinky_pov_web/blinky_programmer.htm.

If you look at the message the first 8 bits should be 0000 0101. That is, the clock should transition 5 times with the data black, the data should be set to white, the clock transition again, the data set to black, clock transition, data set to white, clock transition, data set to black, and so on.

To see the proper clocking reload the W&L blinky pov programming page (this initializes the clock properly) and setup the message above. Slow the delay to 1000 ms (one clock per second) so you can count the clock transitions while looking at the data. On a proper transmission you see the clock change state 5 times with the data black, the data change to white, the clock transition again and so on properly.

To see the failure reload the W&L page (do not use the TechSpin blinky pov programming page because it does not have the issue) and setup the message as before. Set the message delay to 1000. This time wait until the clock is white and hit the stop button. This is going to leave the clock state variable in the wrong state for initial programming. Now run the programming again with a delay of 1000 and count the number of clocks until the first data white. You will find the data appears to come one bit time too early. In actuality the clock dropped a transition. The data transitioned properly but one of the clock pulses was lost so the data seems to be bit slipped in the data stream.

Fundamentally the issue is twofold. First the web code assumes an initial state for the clock variable, which it does not enforce, and second, the code does not enforce synchronization of the clock state variable and the color displayed on the screen for the clock value during programming.

Look at the following snippet taken from the blinky programming web page source code…

function toggle_clock() { // this function toggles the color of the clock panel each time it is called if (current_clock == 0) { current_clock = 1; set_color_clock("white"); } else { current_clock = 0; set_color_clock("black"); }

setTimeout('set_data()', delay); }

The web page assumes the initial value of the current_clock is 0 and paints the initial color of the clock image as black. IF the initial value of current_clock is 0 AND the initial color of the clock image is black, then this snippet toggles the current_clock to 1 and paints the clock image to white. If on the other hand the current_clock is left at a value of 1, because you stopped the programming when the clock was white, the initial painted color of the clock image is black and then this function fails. It fails to toggle the color of the clock to white. If the current_clock enters this routine as a 1 the current_clock is reset to 0 and the clock image is painted black, which it already is so no image transition occurs so no data bit is read by the blinky pov device.

So how do you fix it? Basically two things should happen, the current_clock variable should be initialized on each programming attempt and the clock state variable and the painted clock image should be forced to be in sync.

Like most problems there are multiple ways to solve this problem. Here is how I tweaked the code…

First initialize the current_clock on each start of programming…

Second, maintain synchronization between the clock state variable and the painted image….

Doing this forces the clock state variable to the expected initial value and forces it to be in sync with the painted clock image at the beginning of the programming sequence.

As a work around if you stop the programming mid stream you should reload the programming web page to insure the state variables are set properly.

BlinkyPov – a possible solution to programming failures?

Tech No Responses »

Oct 132012

Looking at the traces from the last post I wonder if something as simple as a capacitor in parallel with R1 and R2 from SCLK and SDAT to ground wouldn’t be enough to filter the LCD update noise and allow the BlinkyPov to finally program.

Sensing Leds

The question is, how much capacitance, and will enough capacitance to filter the noise be too much for the LED / photo sensor to drive.

Grabbing a random cap out of my parts box turned up a 1uF electrolytic. I hooked it across R2 with some hook grabbers and grabbed some scope traces.

Here is the first trace without any added capacitance.

When I first ran the web programming app I had the bit delay at 40 msec. At that rate with a 1uF cap the loading was such that the data line was not moving much at all. Slowing the data rate down to 200 msec and then 500 msec resulted in this trace.

I think I’m onto something here. Assume that everyone who has a blinky pov can solder, seems reasonable since the blinky pov is a kit that requires you to solder it up in the first place. It is not unreasonable to think most people with a blinky pov could solder a small cap dead bug style across R1 and R2. Then with appropriate slowing of the blinky pov web page you might be able to get to a reliable programming solution.

It is late where I am so I’m not going to figure out the proper value of the caps tonight but if someone else comes up with a good set of values please leave them in the comments below.

BlinkyPov – clock and data phasing issues

Tech No Responses »

Oct 132012

I was beginning to look at the blinky pov firmware and how it interprets the SCLK and SDAT signals but got sidetracked looking at the scope traces and phasing between the clock and data signals.

I scoped both the clock (yellow) and data (blue) and captured these traces.

scope hookup clock and data

It is pretty clear where the clock and data are supposed to be “1” and “0”.

According to the W&L Blinky POV design page

"The above diagram shows how we prepare the binary data values for transmission. First, we look at the binary value of each byte. For example, the hex value 0x6D is binary 01101101. We are using a “data and clock” transmission scheme, where the data value is sampled when the clock changes."

This says the data will be sampled each time the clock transitions, from low to high or from high to low.

If we zoom in on a particular transition, say from high to low, we see something interesting.

The clock is the yellow trace and data the blue trace. The first question I have is, where does the clock decide it is high or low? Looking at the nearly full scale swing in both clock and data it is hard to see where the “rising” and “falling” edges of the clock are and what the corresponding value of the data is when the clock rises or falls. Looking at the last scope trace in this series it is not clear what the value of the data will be read as when the clock is finally determined to be low. Clearly the data, the blue trace, is supposed to be high before and after the negative going transition of the clock.

BlinkyPov – measuring SCLK and SDAT

Tech No Responses »

Oct 132012

To repeat the intro to the last post, the blinky pov uses a neat little trick to read in new words and symbols to program into the blinky pov display.

Two light emitting diodes are mounted on the blinky pov and used in a fashion that causes them to act as light receptors rather than the traditional LED use as light emitters.

SCLK and SDAT, the incoming program data clock and data lines, are wired to pins RA2 (pin 11) and RA4 (pin 3).

Normally we think of digital signals as ON or OFF, digital data is a 1 or it is a 0. Unfortunately reality intrudes and 1 and 0 do not apply. Looking at the previous post we can see the clock and data signals presented to the blinky pov processor are decidedly not clean 0s and 1s.

Pins RA2 and RA4 can be, and are in the blinky pov, configured as analog input pins. Looking at the traces from the previous post there appears to be a good reason for wiring the clock and data to analog input pins.

(More to come here….. I’m looking at the code and I see some effort to calibrate for the black level….)

BlinkyPov – Sensing the data

Tech No Responses »

Oct 132012

The blinky pov uses a neat little trick to program new words and symbols into the blinky pov to display.

Two light emitting diodes are mounted on the blinky pov and used in a fashion that causes them to act as light receptors rather than the traditional LED use as light emitters.

Programming my blinky pov is not working, it’s as simple as that. There are a variety of reasons why programming might not work, from hardware issues to software issues. Either the data is not getting to the programmer or the programmer is not interpreting or programming properly.

The first place to look is the output of the sensor. Is the sensor generating Highs and Lows, 1s and 0s. Hooking an oscilloscope to the SCLK and SDAT lines generated the captures below.

First I hooked up SCLK and tried to program from my desktop monitor. It is a Samsung SyncMaster P2770. It supposedly has a 1ms response time and 70,000:1 contrast. The hookup and traces look like this…

Each burst of activity on the scope is a SINGLE clock pulse. One flash of white from the blinky pov web programming application.

Looking at the various scope traces it is clear the incoming data is neither a 1 nor a 0. This group of traces is from my main desktop monitor running Google Chrome at the Blinky POV programming website.

scope hookup desktop

The traces above are from Google Chrome. Somewhere in the random postings on the blinky pov forums was an assertion that different web browsers will display the white and black squares differently and thereby affect blinky pov programming performance.

The following traces are from the same monitor, at the same height, in the same lighting conditions, at the same distance from the monitor. These captures are from running Mozilla Firefox.

The trace above is with Firefox and the room lights on. It was also recommended to turn the room lights off. The trace below is the exact same setup as above with the room lights turned off.

So far what I’m taking away from the various recommendations to try different browsers and lighting is that it is a smokescreen. I’m not seeing a difference in traces when trying to program from the same monitor.

Switching back to Google Chrome and pointing at my second desktop monitor, a Samsung SyncMaster P2350 produced the following traces.

Using Firefox and hooking the scope to the data line (SDAT) produced these traces.

Next I tried my netbook. It is an Acer Inspire One. The scope hookup was the same, the browser was Google Chrome pointed to the W&L Blinky POV programming website. This time I do see a difference. The light to dark transition from the netbook is much stronger and also has a much higher frequency carrier.

Switching to Firefox on the netbook produced similar results as on the desktop, that is, no real change.

Switching to a smart phone produced an interesting difference and probably explains why we had any success at all when using a smart phone to program the blinky pov.

BlinkyPOV Programming – time to crash and burn

Tech No Responses »

Jun 072012

Like apparently so many others we can’t get our blinky_pov to program. Perusing the BlinkyPov forums shows we are far from the only ones having problems programming the blinky pov.

I’m not thrilled with the technical feedback from Wayne and Layne either. Try turning off the lights, try turning on the lights, try using a different web browser, try using a different device, try turning the contrast up, try turning it down, and then the final pat answer, contact tecnical support through a private email. Hmm, I wonder how many of the frustrated blinky pov owners ever get the programming to work. We tried all of the advice, it turned out using the browser on a smart phone did actually work once or twice. None of the laptops, netbooks, multiple LCD monitors at home or work ever worked to program the blinky pov. Something aint right. Of course the icing on the cake is the final final pat answer from W&L, We have thousands of successful and happy blinky pov owners who are not having any problems. I wonder if that is true or if the majority of blinky pov owners just give up in frustration.

Now, with all that said, I am not giving up. The blinky pov is a cool little device and if it can be made to work it’ll be a neat little trick. Fortunately W&L have released the blinky pov as an open source project…. time to start digging.

Blinky Pov Design

Blinky Pov Source Files

Older Entries