I was pretty frustrated again this weekend, I could not seem to get any recognizable output, then I decided that I really needed to look at what I though had been set for each value...

That was when I discovered that the "PWR_UP" bit was not getting set in my config register, guess what that one does...

So I chatted with a friend here and throughout the conversation a couple of things came up, which I decided I needed to try. First one was disconnect the bus pirate and see what happens. Option 2 was to bitbang the SPI as the pin I controlled was reaching 5v.

So I spent most of this weekend getting my light controller working, I found a couple of problems, with the firmware. The floating weird pin on the PWM was due to the SPI code being greedy and not letting the PWM interrupts get set up. Then I saw some other weirdness, which was due to the PWM not relinquishing control due to the number of instructions per interrupt vs length of the interrupt handler. I fixed these, and things started behaving much more predictably.


I found that I was seeing some wierdness with my PWM again, turning things off didn't make them off, in particular the blue channel seems to light even when it should be off. I _think_ the problem is with the uC not being properly soldered down so the gate is actually floating and it drifts up into conducting through the FET.

Also the SPI breakout seems to be preventing the bus pirate from seeing the SPI. Although this might be as simple as incorrect wiring, I will test it further once I have the rest of it working properly

Well last night I got some meaningful results, I stopped sending infinite amounts as fast as possible, and put a counter in so it only sends 5 characters at a time. It also sends 5 different characters (0x41-0x45 or 'A' - 'E') and guess what I saw?

The bus pirate showed me receiving stuff that resembled what I sent (it was reversed nybbles but that's fine, I can fix it if I need to) So this weekend I will build my breakout board and start using "sump" as a logic analyzer and get it fully tested, I can see this getting to a working state in the next few days.

I am sold, Osh park is the way to go, what a difference solder mask makes!!!

I will probably still do stuff, but only simple things for example I want some SPI breakouts to make it easy to hook the bus pirate to it.

I have figured that all that's left for solar dock is the NRF thing and buying the solar system.

Below is the light controller in various stages of built

I have broken down and ordered solar dock controllers from osh park. I was looking at the main controller PCB to figure out my SPI, and discovered things not connected as tracks had lifted etc. So I bit the $50 bullet and got some main controllers and some light controllers ordered.

Frustrating but exciting

After the brief foray into implementing the JSON thread for network traffic, I have decided that I need to retire my old network thread and update all the old clients to use JSON.

As I developed the Java client, and then later a Universal Windows Program (read this as "Windows phone app") I find myself encoding and decoding the network protocol over and over. My solution is to use JSON on the wire.

With one thing and another, I decided that it was necessary to knock the rust off my Java skills. What better way to do it that create a PLC client in Java?

In just a few hours I had created the application and made it talk with the server, the communications object spins a thread to handle the asynchronous messages from the server, and for each message it generates a command object that is then sent to the main thread for processing. At the moment the only command that is handled is "DEVICE". This is usually in response to "GET DEVICES" from the client at login.


Subscribe to RSS - blogs