Experimenting with PICs

In order to experiment with PICS I used a PIC16F684 and wrote a flashing led program. However for our actual design we need a PIC with more pins (PIC16F684 has 14 pins) to handle the LCD that will be part of the front end of our system. We decided to use a PIC18F4331, but ran into some problems with programing resulting in a message "Programming failed at Program Memory address 0x000000." After much work we realized that AVDD and AVSS must be connected since they provide a reference voltage for the A/D converter. After fixing this we were finally able to write to the PIC.

Bridge PCB -> Bridge PCBA

Here's the assembled I2C<->RS232 bridge in its fully-assembled glory.

Yes, I know, the leftover flux looks kinda nasty, but it works!* All that's left hardware-wise (we hope) is the front-end assembly, which will be done on a breadboard.

edit: I went ahead and ported the SFBP state-machine I whipped up for the back-end SIM utility to the PIC and everything functions as expected. I used the Advanced Serial Port Terminal by Eltima Software to do some preliminary tests. Once all the commands are implemented (so much as to return dummy values), I'll go forward and try it with the test utility that the front-end team made.

*It works, but with a few hacks. In the schematic, I flipped the PGD and PGC ICSP programming pins, which was easily fixed by exchanging the wires on the cable. I also would've preferred the power traces to be wider and should've laid-out some space for the RS-232 connector. Coulda' woulda' shoulda'.

Serial Port Communication Version 2

This is the second version...

Source Code and Demo

I2C <-> RS-232 Bridge PCB arrived!

Hey everyone! As you can see, the PCB came in. Hopefully I don't screw it up while I solder the parts on.

Serial Port Communicator

In order to test the functionality of our project while it’s under construction, we've decided that we need a method to test the back end and front end portions separately (As we might have mentioned the front end comprises mostly of the user interface and controls while the back end consists of the DSP and audio hardware). Since the two will communicate with each other through a serial port interface, we wrote a program that runs in Windows and allows the sending of characters and data through the serial port. This will allow us to test the functionality of the front end and back end separately without both the need for both systems to be completed. Included are a mini presentation on using this program and as well as copy of the software with source code (Please use at your own discretion as it has not been thoroughly tested although we plan to soon).

Presentation

Serial Port Communicator (*.exe)

Source Code
(This program is written by Win32, Please select NO SET for Character Set in Property in order to run it if you use Visual C++ 2005 or higher)

hack #1?

Hi all. I've begun setting up the serial comm setup for the back-end. As expected, I've come across a few hangups while designing it.First the good news: the CON1 header provides me with a nice interface to the various GPIO pins. A section is connected to the LEDs, and another is connected to the switches. There are also 4 unconnected pins connected to solder pads on the reverse side.

Unfortunately, the DSP36761 does NOT have a UART, which would require me to bit-bang the RS232 interface. This is achievable, but not as elegant as I would like. Once the real DSP stuff gets running on the chip, I can foresee some communication problems (missed bytes, corrupt data, etc.) Therefore, I opted to use the SHI peripherals that the DSP36761 provides: SPI and I2C. As mentioned earlier, the CON1 header has connections to the GPIO pins, but NOT to the SHI pins... but remember what I said about the open solder pads on the reverse side? In the manual, it suggests that these pads be used as endpoints for jumpers to the I2C pins that are underneath one of the switches.

Now that that's done, I still need to somehow convert the I2C protocol stuff to RS232. Well I thought about it for a bit, looked around my shoebox, and realized I could use my leftover dsPIC to handle the comm with the front-end (implementing the protocol state machine) and convert the I2C bytes to RS-232 bytes. The MAX232 would be connected to the dsPIC's UART pins for some level-translating action.

edit: I just finished whipping up the schematic and layout for the I2C <-> RS-232 board. I'll put in an order to BatchPCB.com and get this thing spun in a jiffy.

edit 2: I just realized that since the I2C bus is essentially visible through the RS-232 serial port, it'll be possible for the EEPROM (where the code is stored for the DSP) to be updated through the serial port. Field updatability perhaps?
- Marc

Schweet! The DSP board came in!

Hey ya'll. Our DSP dev kit came in recently. As you can see from the picture, it's from Freescale semi'. It's called the "Symphony SoundBite" and it basically is a DSP platform designed for audio signal processing. It features the DSP56371, a codec, and some GPIO pins. Another cool feature is the built-in debugger with a USB interface.

We've already whipped up some code, based on some example stuff from Freescale, that passes-through a signal directly from the inputs to the outputs. Unfortunately for us, the GNU C compiler that targets this DSP is crap. The IDE, which is based on Eclipse, is nice, but also still very immature. From what I've seen on the Freescale forums, they don't seem to be supporting this board as much (GCC 1.37.1 anyone?) as their more expensive offerings, which is kind of understandable considering the board's target audience: hobbyists and cash-strapped university students. There's another tool chain, Altium TASKING for DSP53xxx, that provides nice DSP intrinsics for maximizing the special features of the chip, and a mature optimizing C compiler, but the 15-day trial and it's $500 price tag is much too prohibitive. Therefore, for us to get performance out of the chip, it looks like we'll be coding the computationally intensive stuff in ASM. On the upside, learning how to program this thing at the machine code level will definitely be a fulfilling experience because we'll be exposed to inherent architectural differences a DSP has between a regular general-purpose CPU. Besides, no one said the project was gonna be easy.

Aside from our previous little pet-peeve, we think this platform is a great enabler for what we plan to do, and it'll definitely provide us with some valuable real-world experience.

As for the front-end, Andy ordered some 40-pin DIP micro-controller samples from Microchip, as well as a programmer/debugger. We already came up with the command protocol for the application layer of the serial I/O. The preliminary command set can be found on our wiki.

We think we're off to a pretty good start. After speaking with Professor Jenks about our project, we now have to start making progress with our spec document. Anyway, we look forward to a very fun year and hopefully we'll be able to show something interesting for demo day!

First post

Welcome to the spkrtwkr blog!

The following is the location for the team wiki, which should be publicly viewable shortly...

http://hyperintense.com/wiki/index.php?title=Main_Page