September 2005 Entries

Diagnostic Application v0.0.0.1 has been released. The source code is released under the GNU General Public License. The application was built on .Net version 2.0 beta and used Visual Studio 2005 beta 2. If you want to use it, you must install .Net 2.0 at a minimum.

- Source Code (57 kb)
- Compiled Application (54 kb)

Why release the application now?: Cause someone asked me to.
Why release the source?: Cause it is the right thing to do. I'm not the world's best programmer (I may from time to time claim I am if drunk or high on power) so there are flaws in the code and the more eyes looking at it, the better the code hopefully will become.

The code itself is not perfect. It is solid enough to release but far from complete. There are areas of the application in my opinion that do not act properly. When initalizing a floor module, I cannot get the board to send a response code back. This may be built into the write command but I could be wrong.

Threading is built into the application but never really tested since I only tested with one board at any time. Yes, this does mean that the code may not work with more than one module. I don't have enough LEDS for more than one and I'm lazy so I never actually plugged in more than one board. I think it should work but ummm, yeah, ummm *runs away*

XML Configuration File Structure Example:

<ddf>
 <configuration>
  <baudrate>57600</baudrate>
  <tilesperrow>16</tilesperrow>
  <rowspermodule>4</rowspermodule>
  <comports>
   <comport>COM4</comport>
   <comport>COM5</comport>
   <comport>COM6</comport>
   <comport>COM7</comport>
   <comport>COM8</comport>
   <comport>COM9</comport>
   <comport>COM10</comport>
   <comport>COM11</comport>
  </comports>
 </configuration>
</ddf>

The XML file is pretty self documenting. The Com Port order does matter so if you want Com4 to come after Com5, list Com5 first.

I have 6 100% working boards now after doing final soldering tweaks.

I have 2 boards that have their CL LED light up and for the life of me, I don't know what the hell is wrong there. SO my solution will be to do a touch up solder on all the QSOPs. Hopefully this will work.

I have 1 board with LED 48 not displaying Red. Not sure what the hell is wrong but I can deal with 1 tile not having a red LED, sucks but ....

and lastly, I have one board that I believe is dead. I soldered on a QSOP (led driver) incorrectly so it was slightly off. Attempting to remove it damaged the board (this is the second one I've ripped off, the first board actually works peachy). The thing that pisses me off about this is I attempted to be gentle and not force anything off. Maybe there is still something not soldererd properly on it.

Well, the diagnostic application is SO close to being completed. Right now the problem lies within the MashData function. Not really sure what is wrong with it.

I have my "all red" not sending out all reds. A couple come out blue. SO close yet so far. I did do a buffer dump from the *nix code and do a direct shove using mine and it worked so I know that the MashData is the issue. Just annoying about 4 lights don't work properly.

Also why include a "all red" (I also have all blue and green) functions? For easy access on knowing if all your solder joints are correct.

click me for a bigger screenshot

Same thing that happened last week happened this week. I'm at my parent's house since I needed to borrow a car so I lack a board for testing. I did however do a rather large sum of coding and what could be a working state. Now note the work could be. Soon as I have working primaries base classes, I'll release those for public consumption. The WinForm application will be released as soon as all the primary, major bugs are worked out ( I'll be the same day as the base classes ). I haven't touched the Winamp plugin yet. The WinForm application is my testing ground.

AND the diagnostic tool shall be GLORIOUS. Ok, no man should ever use the term glorious again. However the tool seems like it is holding it's own. I have a 'mock module' (may need some rearranging to properly mock the board ) and will have the mock board's color spectrum work like the boards in real time. This functionality isn't added yet but it is just a hook in so shouldn't be too hard. I will need to create an additional delegate / event for this so the UI and the board are not on the thread. I don't see this being that big of a deal but since threading has been implemented, why have a bottle neck. I also still need to add in an open dialog for the XML configuration file instead of hardcoding the name and expecting it to be in the same location as the executable file. In addition, I should modify the mouse icon when you hover over one of the 'LEDs' on the mock board so it is intuative that you click the 'LED' and the color palette will appear.

Floor Modules have three threads, the floor class itself will have 1 I believe, I could be incorrect on this. the thought process was the application that deals with the floor should be dishing out the buffer code to the floor. The modules need to send out that code hopefully at the same time with an async call for all the boards.

Two new Feature that I'd like to add will be a "rolling" color pattern along with having the entire board be the same color and every second or two, increment it. It will be very much like the diamond, but will just be horizontal or vertical. Figure the second will allow for colors to be tested from a very anal retentive persepctive.

As a side note, .Net 2.0's WinForm development is DAMN nice. Lining stuff up, refactoring, renaming, they got ride of all that extra code to set up the form's layout in a seperate cs file now. This provides for a cleaner .cs file for the Form. And with cleaner, that means easier to debug. Microsoft's API/IDE is so evil is it actually works like it should in beta form.

I added on little rubber pads on the bottom so they don't ground out. 2.80 for 16 of them. got 4 packages.

My code now sends the echo code and reads the Success response code. Threading isn't really implemented yet but shouldn't be too hard. I'll add in threading soon as I actually get code working.

* gets jiggy with it *

Switched to .Net 2.0 for the Serial Port access. Beta 2 isn't near as bad as I remember it. Got most of the basic structure up. Threading isn't included yet but some mutex locking code is implemented. I did aim to do more today but just got busy doing other things. Simpsons Sunday (Family guy and American dad ... classic .... REGAN SMASH ) took over and today I was just out of the apartment all day.

Things I still need to do are create a event / delegate so the Floor class (a floor contains modules) knows that something was updated (aka sensor or feedback code ) and that the module is done writing. I'm doing a lot of revising, recoding, and restructuring as I'm coding this so that in the future ... for whatever rare need ... if I do need this code or something gets changed in the base Linux package, updating the .Net code will be painless. Also attempting to figure out the best way for threading and locking is causing some thinking. Plus thinking makes me hungry so I eat some jello pudding. And since I ate that, I have to watch the Cosby's. It is a massive downward spirl.

My goal is to have a debugger application on top of the couple neat applications that have been written already and will just be ported. I figure the neat applications will just be built into the debugger app for ease. Debugger first, then Winamp second.

Hoping by the end of the week to have .Net code talking to at least one of the floors.

Not sure if I posted this, but Ledtronics is my LED supplier. My quote for 700 was $1.08 each ($756.00 plus shipping). Not freaking bad at all. Figure buying 1 LED instead of 3 is cheaper and easier to manage. I was given a 6 week turn around but I got my orginal ones in I believe about a bit less than a month.

As for the ribbon cable ( I call it the rib ), I did a quick test wire strip on one and saw how small the gauge wire is. And it is stranded. SO I have two options here.

1.) Buy new solid core cable, if it exists, of a slightly higher gauge.
2.) Solder the ends of the cable and make wiring a multiple step process.

Since both suck and the process is already multi-stepped, why not just add on 10 additional small solders to make the stranded into "solid".

Well, looks like .Net framework 1.1 lacks a needed thing for this project ... serial port access built in. There are 'hacks' to get it but I'm not totally thrilled with what I've seen.

.Net 2.0 in System.IO.SerialPort has this built in. SO ... I'm not sure if I should move over to 2.0 or just use one of the couple hack's I've found.

But my issue is the .net 2.0 framework isn't complete yet and using Visual Studio 2005 beta 2 is really, really slow. Could always port the code at a later point in time.

Ok, so I've started to look over some of the code that the MIT kids produced and in an OOP world, I think some of the code is flawed. I understand why things were done like they were but I'm not sure if I'd recode them that way.

One quick issue I found right away is the mash_data function is a char array when it in actuality is an integer array. I used about 90% of their code for this function actually.

When I was about to start to write the constructor, I was reviewing how some of the code is written and was thinking it needs to be tweaked.

A dance floor contains modules.

So you have a Dance floor object and a module object. What would need to happen on a Dance floor write is each module is given it's data then sent out. What I'd do is have a thread built into each module object that reads from the buffer within that module. This will eliminate the need for the thread to be recreated everytime and since it is just a starter function for the thread, my belief (not betting money on this ) that it will be faster and provide the benefit of threading. What would be nice I guess also would be maybe a thread function within WriteToFloor that would know if all the threads have finished up. Could do a delegate or event raising event too I suppose.

so the code would be something like this. Please note I'm coding this in TextEdit on a mac on a crappy connection so syntax chances are is not correct ... along with my spelling. I lacked access to my best buddy MSDN.

ddf.WriteToFloor( );

----------------------------------------------
DanceFloor
{
Module[] moduleArray;
int[] buffer;

public void WriteToFloor()
{
// mutex lock possibly
this.SegmentBuffer( ); // module array is part of dancefloor

for( int i = 0; i < moduleArray.Length; i++)
{
moduleArray[i].OutputBuffer();
}
// some form of knowing all threads are done would be nice here.
// mutex end lock
}

public void SegmentBuffer()
{
// for loop segmenting buffer for each module.
// moduleArray[i].buffer = buffer[ x to z ]; ...
}
}

module
{
Thread thread;
int[] buffer;

SerialPort comPort;

module( string SerialPortName )
{
comPort = new SerialPort( SerialPortName ); // example, need way more for this to be properly set up
thread = new Thread( new ThreadStart( this.threadOutputBuffer ) );
}

private void threadOutputBuffer()
{
comPort.Write( buffer ); // buffer may need to be translated or something to a straight string in hex.
}

public void OutputBuffer()
{
thread.Start();
}
}

After I did a couple different permutations, I found that I didn't have the fuses properly programmed.

By using 8 Mhz with a 4ms delay, I got the board to actually work. I have yet to try it with a 0ms delay yet.

Time for a quote on the remaining LEDs I need I do believe

Talk about weird. Now the boards are working. Readded in some error checking code and now it returns 80 instead of what it did before. however the Write command, it returned 50. After the read however, I get a code of 80. According to the Protocol Specification, an 80 is a Test Pattern.

It is a threadfunc() that it is failing.

Today when attempting to send the command byte ... the screen claims a Bus error. whatever the f-bomb that is.

I can't get anything to work after yestarday it was working when I left it last night.

Time to express myself myself colorfully with four letter words. Lots of four letter words.

Well, I have 7 boards that return the error "1C" and two that act a bit weird. Both have the SCL or SDA light on during power up which says there is a problem since the others don't.

More I think about it, the more I may think I didn't properly flash them.

I'm from a windows programming background. The college I went to was a Microsoft College ( maybe not anymore since they switched to java ) but atleast when I was there ... they were a Microsoft college. SO yes, this may be common knowledge for most, but I did not know how to use a make file.

After 5 minutes with my buddy Dave McNelis, how worked on some C based Open Source stuff, informed me how. For those who don't know, open up a terminal window and change the directory to where you need. Then just type "make".

cd /desktop/disco-0.1
make

Yes ... it was that simple.

I learned while dealing with a piece of metal that is super heated to 625 degree is not to listen to Dane Cook. Laughing is not a good idea. VERY BAD IDEA. you will get burned ... or least I did ... cause I'm stupid

I realized something last night ... I have working code (the public release code from MIT ) and I do have an iBook. While I don't want to use the iBook in the long run, I can at least test to see which boards actually are functional by compiling the code and testing one by one. Long process but still ... has to be done some how.

From here then, I know what boards are actually functional and can be used as a testing platform for the c# port.

As for the c# port, I kinda gave up yestarday and started to do some SIPP soldering. By the end of this, I'll have put a pretty decent dent in the 1lb roll of solder due to the SIPPs if not totally finished it off. Buying two was overkill, buying one for 10 boards worths of soldering wasn't a bad idea.

As for just general coding progress, I created a XML configuration file so the code isn't hard coded in. I also mapped out two parts of code. Found some Serial Port communication code but this is where I stopped. I need to know what boards actually work so I can determine how to create a proof of concept debugger app. From there I can continue writing a full out app along with the WinAmp port from XMMS.

And I have to ask ... who the hell still programs in C? The answer ... Scott Torborg from MIT.

porting C is evil ... more so when you don't fully understand what is predefined. Pays to have a buddy that actually did some C to Java porting.

Ok ... life just got a bit harder since their code is C based, not c++. I only know c++. I also need to know what the hell allegro.h is and what a non-linux (*cough .NET cough*) equivalent would be. This is in fire.c .... mmmm, fire.

after a quickie look at the code, I'm thinking .Net has what they use allegro for. Anyways, I think I'll need to work more so on ddf.c and ddf.h porting instead of caring about fire.c right now.

Stats

3 out of 10 have sipps on the board.

10 out of 10 have all parts except the sensor resistor pack.

9 out of 10 have been flashed with firmware.

 

Why only 9 with firmware? I have in theory 9 working boards so I can move on but just label the mistake. I'm not really sure why it doesn't work after looking at the board for an extended period of time. I think it maybe be one of the LED drivers causing a short. I don't think I can do much to save it. Since i did do a smart thing and buy extra, I can remove pin by pin the chip and pop on a new one.