JWoodrell

My gift arrived yesterday!
 

 
Awesome circuit board necklace - sweet! Thanks so much :-)
(I think it was from @JWoodrell maybe?)
 
-Katie

hey guys I'm throwing my project on here I am finishing up.
 
It is an audible alarm player I am building for the company my dad works for.  to put on some of their equipment there.
 
[VIDEO]
 
the requirements were there are 2 signal wires at +24 volts and a common wire.  It had to power up and play one of two different sounds (they didn;t specify the sounds, but described it as wanting a "bongie bong" type of sound.)  oh and it had to be able to achieve 85 decibels in loudness.
 
this is what I had to work with.  talking to my dad i convinced him to let me make it with a microcontroller playing a wave file from an SD card (even though I didn't know exactly how to do that yet)
 
so I was off to the races, looking through various sound playing, and sd card reading projects to figure it out.
 
I settled on the Petit FatFS based "SD Card Booster Pack" that Bluehash put together as a good base to start from.
 
Originally used a PWM based output to the amplifier to generate sound but the quality was basically junk, you could tell what was being played but barely.
 
I decided to switch over to a R2R based DAC circuit to generate actually voltage outputs.  to keep it simple I made it an 8 bit DAC being driven by the entire P2 bank of I/O.  I just write an 8 bit value to "P2OUT" and I get an analog voltage out the other end automatically so it keeps things simple.
 
This worked pretty well but I had card reading issues in that it would play a segment then read a new segment (no sound output) then play that new segment.  no good.   So I researched how the buffer might work in RickTA59's sound project as well as how to stream data byte by byte and wrote my own FIFO buffer based on those ideas.
 
this got me 90% of the way there sound quality was good, but there was static and other glitches still being heard.
 
my next trick was multi sampling the wav file to improve on the 8kHz sample rate.  so since the processor had alot of extra time twiddling its thumbs between samples, I put it to work,  I bumped up the timer ISR rate by 4 times, and only pulled a new "sample" from the wav file once every 4 ISR cycles.  but had the processor generated an interpolated point in between those two values in the remaining 3 ISR cycles, so now it is producing a new "sample output" at 32kHz from an 8kHz file, this helped alot as well.  and playing with a few filter caps for the R2R ladder pre volume pot and a low pass filter at the audio amplifier input got me the rest of the way there.  now I am very happy with the sound quality.
 
so there is the work in progress on this thing so far, I just have to solder the amplifier into the protoboard instead of having it bread boarded.  and mount everything in its enclosure for them.
 
it works with Fat32 perfectly well so its just popping the card into your computer, and dropping a file onto it
 
the next challenge is if they approve of the design, i get to make 100 units of this for them by Christmas ish to early january
 
 
oh and if you enable "use print" then it will spit diagnostic information out the serial port to read in termite or whatever console you wanna read it in.
 
here is the code, and the eagle file that is the planned production PCB so far (may well be changed before its made)
JWoodrell_Audible_Alarm.zip
audio_board_single_supply-v2.zip

they accepted the quote, and now are having me build 104 of these (4 quickly to test them on the line) and the other 100 soon after.
 
have the first version of the PCB in. it is close enough so I can use it for these initial 4.
 
partially built

 
pile of bits layed out on the floor, tomorrow these will be assembled into 4 PCBs

 
here is the bare board before separating the two pieces

 
should have the boxes and new speakers in on monday i hope

I personally use the standard bitmap import function, then redo the lines by hand using the other as a guide (in one of the transparent green layers)  so i get my lines like I want, but have the stencil to follow.  that's how I build the 2d barcodes, and my logo also.  takes a bit of work, but the results are polished rather than "just good enough" from some automatic one

they accepted the quote, and now are having me build 104 of these (4 quickly to test them on the line) and the other 100 soon after.
 
have the first version of the PCB in. it is close enough so I can use it for these initial 4.
 
partially built

 
pile of bits layed out on the floor, tomorrow these will be assembled into 4 PCBs

 
here is the bare board before separating the two pieces

 
should have the boxes and new speakers in on monday i hope

got mine in today, its glowing EL wire, pretty cool, the power supply has an audible whine but meh the wire itself is really cool
 

Well got the thing soldered and finalized and shipped out to the customer today (so sorry no video of it playing hiphop chicken)  but here are pictures of the final "Prototype build"
 
it ended up with 3 possible sounds (2 input as a binary, 10, 01, 11 setup) hopefully they will accept the design and I'll get to make the production version.

hey guys I'm throwing my project on here I am finishing up.
 
It is an audible alarm player I am building for the company my dad works for.  to put on some of their equipment there.
 
[VIDEO]
 
the requirements were there are 2 signal wires at +24 volts and a common wire.  It had to power up and play one of two different sounds (they didn;t specify the sounds, but described it as wanting a "bongie bong" type of sound.)  oh and it had to be able to achieve 85 decibels in loudness.
 
this is what I had to work with.  talking to my dad i convinced him to let me make it with a microcontroller playing a wave file from an SD card (even though I didn't know exactly how to do that yet)
 
so I was off to the races, looking through various sound playing, and sd card reading projects to figure it out.
 
I settled on the Petit FatFS based "SD Card Booster Pack" that Bluehash put together as a good base to start from.
 
Originally used a PWM based output to the amplifier to generate sound but the quality was basically junk, you could tell what was being played but barely.
 
I decided to switch over to a R2R based DAC circuit to generate actually voltage outputs.  to keep it simple I made it an 8 bit DAC being driven by the entire P2 bank of I/O.  I just write an 8 bit value to "P2OUT" and I get an analog voltage out the other end automatically so it keeps things simple.
 
This worked pretty well but I had card reading issues in that it would play a segment then read a new segment (no sound output) then play that new segment.  no good.   So I researched how the buffer might work in RickTA59's sound project as well as how to stream data byte by byte and wrote my own FIFO buffer based on those ideas.
 
this got me 90% of the way there sound quality was good, but there was static and other glitches still being heard.
 
my next trick was multi sampling the wav file to improve on the 8kHz sample rate.  so since the processor had alot of extra time twiddling its thumbs between samples, I put it to work,  I bumped up the timer ISR rate by 4 times, and only pulled a new "sample" from the wav file once every 4 ISR cycles.  but had the processor generated an interpolated point in between those two values in the remaining 3 ISR cycles, so now it is producing a new "sample output" at 32kHz from an 8kHz file, this helped alot as well.  and playing with a few filter caps for the R2R ladder pre volume pot and a low pass filter at the audio amplifier input got me the rest of the way there.  now I am very happy with the sound quality.
 
so there is the work in progress on this thing so far, I just have to solder the amplifier into the protoboard instead of having it bread boarded.  and mount everything in its enclosure for them.
 
it works with Fat32 perfectly well so its just popping the card into your computer, and dropping a file onto it
 
the next challenge is if they approve of the design, i get to make 100 units of this for them by Christmas ish to early january
 
 
oh and if you enable "use print" then it will spit diagnostic information out the serial port to read in termite or whatever console you wanna read it in.
 
here is the code, and the eagle file that is the planned production PCB so far (may well be changed before its made)
JWoodrell_Audible_Alarm.zip
audio_board_single_supply-v2.zip

I'm going to throw my project on here.
 
It is a SD card based audible alarm player. *now with sound quality*
 
the user provides a 24v signal on one of two input wires, and the unit takes that 24v power and uses it to power up the MSP430 and amplifier.  It reads the file linked to that input signal and plays it out the speaker.  I did a couple of tricks to improve sound quality.  right now it is working best with 8kHz 8 bit wav files, but it adapts to other sample rates on the fly.  right now it doesn't understand how to read 16 bit files, but this is just the first draft, and that is in the planning.
 
http://www.youtube.com/watch?v=wJ-gWZK3wAQ

hey guys I'm throwing my project on here I am finishing up.
 
It is an audible alarm player I am building for the company my dad works for.  to put on some of their equipment there.
 
[VIDEO]
 
the requirements were there are 2 signal wires at +24 volts and a common wire.  It had to power up and play one of two different sounds (they didn;t specify the sounds, but described it as wanting a "bongie bong" type of sound.)  oh and it had to be able to achieve 85 decibels in loudness.
 
this is what I had to work with.  talking to my dad i convinced him to let me make it with a microcontroller playing a wave file from an SD card (even though I didn't know exactly how to do that yet)
 
so I was off to the races, looking through various sound playing, and sd card reading projects to figure it out.
 
I settled on the Petit FatFS based "SD Card Booster Pack" that Bluehash put together as a good base to start from.
 
Originally used a PWM based output to the amplifier to generate sound but the quality was basically junk, you could tell what was being played but barely.
 
I decided to switch over to a R2R based DAC circuit to generate actually voltage outputs.  to keep it simple I made it an 8 bit DAC being driven by the entire P2 bank of I/O.  I just write an 8 bit value to "P2OUT" and I get an analog voltage out the other end automatically so it keeps things simple.
 
This worked pretty well but I had card reading issues in that it would play a segment then read a new segment (no sound output) then play that new segment.  no good.   So I researched how the buffer might work in RickTA59's sound project as well as how to stream data byte by byte and wrote my own FIFO buffer based on those ideas.
 
this got me 90% of the way there sound quality was good, but there was static and other glitches still being heard.
 
my next trick was multi sampling the wav file to improve on the 8kHz sample rate.  so since the processor had alot of extra time twiddling its thumbs between samples, I put it to work,  I bumped up the timer ISR rate by 4 times, and only pulled a new "sample" from the wav file once every 4 ISR cycles.  but had the processor generated an interpolated point in between those two values in the remaining 3 ISR cycles, so now it is producing a new "sample output" at 32kHz from an 8kHz file, this helped alot as well.  and playing with a few filter caps for the R2R ladder pre volume pot and a low pass filter at the audio amplifier input got me the rest of the way there.  now I am very happy with the sound quality.
 
so there is the work in progress on this thing so far, I just have to solder the amplifier into the protoboard instead of having it bread boarded.  and mount everything in its enclosure for them.
 
it works with Fat32 perfectly well so its just popping the card into your computer, and dropping a file onto it
 
the next challenge is if they approve of the design, i get to make 100 units of this for them by Christmas ish to early january
 
 
oh and if you enable "use print" then it will spit diagnostic information out the serial port to read in termite or whatever console you wanna read it in.
 
here is the code, and the eagle file that is the planned production PCB so far (may well be changed before its made)
JWoodrell_Audible_Alarm.zip
audio_board_single_supply-v2.zip

I'm going to throw my project on here.
 
It is a SD card based audible alarm player. *now with sound quality*
 
the user provides a 24v signal on one of two input wires, and the unit takes that 24v power and uses it to power up the MSP430 and amplifier.  It reads the file linked to that input signal and plays it out the speaker.  I did a couple of tricks to improve sound quality.  right now it is working best with 8kHz 8 bit wav files, but it adapts to other sample rates on the fly.  right now it doesn't understand how to read 16 bit files, but this is just the first draft, and that is in the planning.
 
http://www.youtube.com/watch?v=wJ-gWZK3wAQ

Since the MSP430 is a 16-bit system, shifts by multiples of 16 will often reduce to simple word memory accesses, but shifts by multiples like 8 or 24 will be expensive unless the compiler successfully guesses what you're trying to do and is permitted to optimize the expression.
 
The cast I proposed above works only if the addresses are aligned. If your 4-byte integer started at array offset 5 (and the array was word aligned), you'd get something but it wouldn't be the value you want. Technically, shifts of single-byte objects are the only robust way to get the answer. When working with char arrays (which may produce signed values) or with values that are larger than the native integer size (which may overflow with left shifts) be sure to get the necessary casts in the right place.

unsigned long STREAM_TO_UINT32_f(char* p, unsigned short offset) { unsigned char * up = offset + (unsigned char *)p; return ((unsigned long)up[3] << 24) | ((unsigned long)up[2] << 16) | (unsigned long)(up[1] << 8) | up[0]; }In this code, both the cast of p to up, and the cast of the individual values, are necessary for different reasons. This code will be slower than the originally proposed *(long*)p approach because it has to use byte reads. 
As for type conversion using a union: don't. Since at least ANSI/ISO C 1990 it has been explicitly illegal to write a value to one member of a union type and to then read from another in an attempt to do type conversion. Modern versions of GCC, starting from a couple years ago (I think 4.6) now support some optimizations that produce the wrong answer when this is done.

Been reviewing undefined behavior here and here, in light of the fact that the *(long*)p approach I recommended produces a gcc warning about dereferencing type-punned pointers. So for truly portable code, don't do that either. 
Below are three approaches that I believe are standard conformant. The second and third differ only because mspgcc is stupid and doesn't inline the memcpy. The third is the smallest and fastest. I'd use the second if I was developing under a supported compiler (or if I chose to fix mspgcc).

#include <string.h> unsigned long f1(char* p, unsigned short offset) { unsigned char * up = offset + (unsigned char *)p; return ((unsigned long)up[3] << 24) | ((unsigned long)up[2] << 16) | (unsigned long)(up[1] << 8) | up[0]; } unsigned long f2(char* p, unsigned short offset) { long l; memcpy(&l, p+offset, sizeof(l)); return l; } unsigned long f3(char* p, unsigned short offset) { long l; char * pl = (char*)&l; *pl++ = p[offset++]; *pl++ = p[offset++]; *pl++ = p[offset++]; *pl++ = p[offset++]; return l; } Here's another approach. Again if mspgcc wasn't stupid about memcpy, it'd be optimal; because it is stupid, the evidence comes from gcc 4.8.2 on x86_64, which notices that (a+4) is word-aligned and just reads the value out (doing the equivalent of *(long*)(a+4) but without the source code expressing undefined behavior:
extern void fill(char * p); unsigned long f4() { long l; char a[10]; fill(a); memcpy(&l, a + 4, sizeof(l)); return l; } I'm sure this is far more than most folks wanted to know, but it is important to understand that even if there is an easy way to do something, it may have hidden thorns that come back to bite you years later when you port the software to a new platform or upgrade/switch compilers.

Try brackets around TestArray, e.g. (long *) (TestArray)[] or some such.
 
Or you could get fancy and use the union keyword:
http://en.cppreference.com/w/cpp/language/union

Assuming the address of the fourth char (TestArray + 4) is aligned to a word boundary and the data is encoded in little-endian format, it should be as simple as:

char TestArray[10] = { 0,1,2,3,4,5,6,7,8,9 }; ... TestLong = *(long *)(TestArray + 4); //spits out 0x07060504 I'd use uint8_t instead of char and uint32_t instead of long, to make the intent clear.

Resistor net is far cheaper for a DAC, you can get a pre packaged 12 input r2r ladder for about 10 cents , as long as you have the pins to drive it, you can have a good fast 12bit DAC for under almost nothing, whereas an IC DAC is about a dollar and the cheap ones all use a serial interface so they will be slower than just switching a bank of I/O on
 
 
 
My 2 cents
 
14 sip r2r ladder

I have done some silly things to these chips in the year or so I have been playing with them.  but they always came back, may have needed to reflash the program and recheck connections but they were durable and didn't die.
 
but now apparently in playing with motor driving, a transient spike somewhere has now fried the 430 on the board.  when I apply power, it doesn't respond to programming calls from CCS, and it heats up to the touch rapidly.  so something internal has gone and melted.
 
I guess this is a sort of milestone of sorts   now I have to desolder it and replace it. I just hope it didn't take out the OLEd screen at the same time, I only have 1 more of those left till I have to order more (have a whole stick of processors)
 
i get to look forward desoldering tomorrow i guess
 
[update]
as an update, the OLED screen was not killed, however the battery charging chip, and the voltage detect chip both were dead as well, so basically all the chips on the board died at the same time, im guessing that "ground" got pulled to negative voltage showing a large voltage spike to all the chips at the same time.
[/update]

One more fried board, courtesy of a colleague of mine.  I know it's not an MSP, but the LM3S parts make some pretty patterns when you hit with mains voltage.  Just another reminder to always triple check when working with HV.
 

I have done some silly things to these chips in the year or so I have been playing with them.  but they always came back, may have needed to reflash the program and recheck connections but they were durable and didn't die.
 
but now apparently in playing with motor driving, a transient spike somewhere has now fried the 430 on the board.  when I apply power, it doesn't respond to programming calls from CCS, and it heats up to the touch rapidly.  so something internal has gone and melted.
 
I guess this is a sort of milestone of sorts   now I have to desolder it and replace it. I just hope it didn't take out the OLEd screen at the same time, I only have 1 more of those left till I have to order more (have a whole stick of processors)
 
i get to look forward desoldering tomorrow i guess
 
[update]
as an update, the OLED screen was not killed, however the battery charging chip, and the voltage detect chip both were dead as well, so basically all the chips on the board died at the same time, im guessing that "ground" got pulled to negative voltage showing a large voltage spike to all the chips at the same time.
[/update]

@@JWoodrell has been awarded the Smoke: Fry some chips? award.

stitch together the top and bottom ground plane as much as possible thicken up the sense resistor trace and vias because it handles almost 4 amps during current chopping replace the copper cutout in the mounting screw (right hand hole on top side) to use that as return path for sense resistor remove seperate ground runs because thermal continuity is more critical than alittle ground noise. went with TI's recommended via pattern under chip to maximize thermal transfer overall very helpfull guys

stitch together the top and bottom ground plane as much as possible thicken up the sense resistor trace and vias because it handles almost 4 amps during current chopping replace the copper cutout in the mounting screw (right hand hole on top side) to use that as return path for sense resistor remove seperate ground runs because thermal continuity is more critical than alittle ground noise. went with TI's recommended via pattern under chip to maximize thermal transfer overall very helpfull guys

with some helpfull input from the TI guys on the Motor Drivers Forum.  I made some updates and here is what I sent up to fab.
 
when i get it working and finalized, I will make it into a boosterpack for my micro launchpad, just not yet It is a standalone board.
 

[update]
have text displaying in 3 sizes now (1,2,and 3 bytes tall, although the 2 and 3 byte tall font takes up a CHUNK of memory for the bitmaps (around 1.5k for the 2 byte tall, and around 3k for the 3 byte tall.  so if all 3 sizes are enabled then it takes up about 5k of memory.)

 
also have preliminary work done on displaying an image at an arbitrary pixel height.  but the display breaks sometimes when you feed a certain byte into the image data.  and it makes no sense, the display code is exactly the same, and it isn't a timing thing.  so I'm stumped :-(


Video of the ball bouncing around  you can see the byte boundries by the black box that follows the ball around (this is the true "image" being written to the screen, im just reediting it every frame to move the image within the image.
 
 
here is my image display code
void imageShift(char IMAGE[], char ImageOut[],char Ishift, char IRowIndex){     char IColumn = 0, width = IMAGE[0];                        //load image width     int ImageScratch;                                        //make 16bit scratch pad     if (IRowIndex == 0){         for (IColumn = 0; IColumn < width; IColumn++){        //cycle through each image column             ImageScratch = IMAGE[2+IColumn]; //copy 1 byte of image data to the scratch pad             ImageScratch &= 0x00FF;             ImageScratch = ImageScratch << Ishift;         //shift the scratch pad by the shift amount             ImageScratch = ImageScratch >> 8;         //swap bytes to put the image data in the lower byte             ImageOut[IColumn] = ImageScratch; //move the shifted image data to the output array         }     }     if (IRowIndex == 1){         for (IColumn = 0; IColumn < width; IColumn++){        //cycle through each image column             ImageScratch = IMAGE[2+IColumn]; //copy 1 byte of image data to the scratch pad             ImageScratch = ImageScratch << 8;         //swap bytes to put the image data in the upper byte             ImageScratch += IMAGE[2+width+IColumn]; //add 1 byte of image data second row to the lower byte of the scratch pad             ImageScratch = ImageScratch << Ishift;         //shift the scratch pad by the shift amount             ImageScratch = ImageScratch >> 8;         //swap bytes to put the image data in the lower byte             ImageOut[IColumn] = ImageScratch; //move the shifted image data to the output array         }     }     if (IRowIndex == 2){         for (IColumn = 0; IColumn < width; IColumn++){        //cycle through each image column             ImageScratch = IMAGE[2+IColumn]; //copy 1 byte of image data to the scratch pad             ImageScratch = ImageScratch << 8;         //swap bytes to put the image data in the upper byte             ImageScratch &= 0xFF00;             ImageScratch = ImageScratch << Ishift;         //shift the scratch pad by the shift amount             ImageScratch = ImageScratch >> 8;         //swap bytes to put the image data in the lower byte             ImageOut[IColumn] = ImageScratch; //move the shifted image data to the output array         }     } } void imageDraw(const char IMAGE[], char row, char column) {     char a, b, IRowIndex, height, width, shift;     row += 60;     shift = 7-(row & 0x07);     row = row >> 3;     //row += 4;     width = IMAGE[0];     height = IMAGE[1];     IRowIndex = 0; // Image Row Index, 0 = first row, 1 = middle rows, 2 = last row, or single row image.     for ( a = 0; a <= height; a++)     {         if (a == 0){IRowIndex = 0;} else {IRowIndex = 2;}         if (a == height - 1) {IRowIndex = 1;}         if (a>0){b=a-1;} else {b=0;}         imageShift((char *)IMAGE+b*width, (char *)scratchImage, shift, IRowIndex);         if (row+a < 16){             if (row+a >= 8){                 setAddress(row + a - 8, column);                 SSD1306SendData((char *)scratchImage, width);             }         }     } } [/update]

Ok everyone, very big news to all those who registered for giving this kit some TLC.
There was some mis-communication about the kits and TI came forward with free "Full Working($149)" kits for everyone who registered here!!. I have 13 kits for all those who offered some TLC for the kits.
 
I may need a little help on shipping as these boxes are a little big. 
 
Big thanks to Dang Dung and William Cooper, @@adrianF at TI. Thank you for helping us out.
 
@@chibiace  @@cubeberg @@JWoodrell @@Rubi @@Automate @@grahamf72 @@oPossum @@dubnet @@roadrunner84 @@abecedarian @@rockets4kids @@legailutin @@Rickta59