Jump to content
43oh

Recommended Posts

So now that I have a little clearer view of the declarations on the pins, I can start diving into communication between peripherals. Prior to getting code going and digging through user guides, I was hoping to get an experienced perspective from anyone that had dealt with both forms of communication.

 

My goal is to pull pcm audio in hex off of an eeprom and send it through a dac.

 

From what i've read it seems that spi would be better to begin with since I have a dedicated in and out rather than a combo port. The Queston is am I correct in thinking that I would be able to talk to the eeprom's input using the msp430 and use the eeprom output to go directly to the dac input as long as the clocks are all synced? Or does the dac still require communication input from the msp430?

 

Basically this is a question of am I pointed in the right direction or will I face the same extra coding requirements that I2C calls for?

Link to post
Share on other sites

Go for SPI, much easier to implement and no overhead. The only drawback, you need one chip select pin per attached device, so you will need a total of 5 pins for EEPROM and DAC. MEMCS, DACCS, MOSI, MISO, SCLK.

MOSI, MISO, and SCLK are shared, other two are used to enable specific device.

Link to post
Share on other sites

SPI does require an additional GPIO for CS, but tends to support faster clock rates and is simpler (unless you already have working I2C code in which case it doesn't matter).  Which MCU are you using?  If you have two serial peripherals then you could use DMA to transfer from the EEPROM to the DAC without MCU intervention.  MCUs with USCI peripherals split each peripheral into one each A and B variants, where the A supports UART or SPI and B supports SPI or I2C.

 

If you're doing audio you might want  to use DMA anyway to get a constant output sample rate unless you plan to toggle between the devices on a per-sample basis.

Link to post
Share on other sites

I'm using the launchpad for dev (2452) but ultimately would like to lower real estate with an AFE251. I'll be pushing audio onto the dac, I just came up on an eeprom programmer to more easily burn the audio in, but it will definitely need a constant sample rate.

 

Thanks guys, time to hit the includes and books!

Link to post
Share on other sites

If you are looking for highest transfer rate, make the SPI/I2C benchmark by yourself, and numbers will tell you everything.

If regarding the size, audio file can fit to internal MSP430 flash memory, it can be used instead of external EEPROM chip.

Don't know on what are you working (and what DAC is used), but 16 MHz uC is to slow for doing something with simple I2S 44.1 kHz (clock rate 2.8 MHz) digital audio signal. Dealing with SPDIF is more complicated, with higher clock rate.

Link to post
Share on other sites

You could consider using SD instead of eeprom, this saves you another programmer. But if you'll be using FAT you have to buffer, for what the launchpad it's easy too slow.

I2C it's limited to standard speed (100kbps), fast mode (400kbps) and fast mode plus (1Mbps). SPI on the other hand can go up to much higher speeds. But you must use extra pins as stated before.

In many cases the peripherals are not always available in both I2C and SPI.

Link to post
Share on other sites

SPI is generally easier and better IF you have a system architecture that is Master/Slave.  I2C generally works in Master/Slave mode, as well, but it can also work as a Master/Master mode.  I2C is a good substitute for UART.

 

Also, a myth with I2C is that it is only 100, 400, 1000 kbps.  These are just standardized limits to improve interoperability. I2C is clocked, so if you are generating 348kbps (or whatever), it isn't a problem for 400kbps rated devices.

 

Anyway, I2C is a good substitute for UART.  If you want something similar to UART but better, that is the best usage of I2C.

Link to post
Share on other sites

Well yeah, the I2C speeds are maximum guaranteed speeds for devices. It is free to a designed to build I2C at 10Mbps, though I don't think you'd be happy with that.

Why do you say I2C is a better UART? There are many cases that are much more suited for UART than for I2C. The multi-master aspect of I2C is a huge benefit, nut it suffers a half-duplex where UART is full duplex. UART allows for per-byte parity checking, UART is much easier to shift over to a balanced line (like DMX).

Link to post
Share on other sites

On a slightly related side note, what is a good overall low-cost, low-power option for multi-master communication over the distances found in, say... a house?  I2C isn't really designed to work over that distance, UART could work with RS-485 with multiport/9-bit UART but I'm not sure what the costs & power draw associated with the RS-485 infrastructure does.  Is something like CAN or an LVDS implementation (with transceiver interfaced with MSP430 over SPI) a viable option?

 

I have used an I2C extender made by NXP, the P82B715 ... it's in my wife's car with a couple AVRs up front and some general I2C devices in the trunk all communicating, works quite well.  Never did a good investigation of the power consumption though.  That network setup also has a dallas 1-wire bus for DS18B20's which works quite well too (got one up behind the bumper with a long CAT5 cable snaking back through a hole in the firewall).

 

But those P82B715 chips cost more than the MSP430!

 

(Funny side note, if I'm not mistaken the P82B715's whole purpose is to provide extra drive strength for sinking current from what is necessarily a relatively low-impedance pullup resistor to support the slew rate at >400pF total bus impedance, and the AVR can sink up to 40mA per port so I'm betting I didn't need to use them for the AVR units in the project)

Link to post
Share on other sites

Also, a myth with I2C is that it is only 100, 400, 1000 kbps.  These are just standardized limits to improve interoperability. I2C is clocked, so if you are generating 348kbps (or whatever), it isn't a problem for 400kbps rated devices.

You can use clocks below the rated maximum, but 400 kHz is the max data rate supported by MSP430 USCI module in I2C mode (at least on the MCUs I checked).  SPI can go up to f_SYSTEM, as much as 25MHz.  I recall spending an hour or two discovering that an I2C part that supported 1MHz didn't work at 500 kHz on the MSP430F5438A.  Teach me to remember to read the data sheets....

Link to post
Share on other sites

Responding to the CAN portion of Spirilis's side note, the May and June issues of Circuit Cellar magazine had a two part article by Stefan Siegel on using CANOpen to fully automate his house.  It is a pretty interesting read.  Some links below to Stefan's website and the third link is an article preview (actually the entire second part of the article).

 

HA Overview:  http://www.siegels.us/Solarhaeusle.html

Home Automation details:  http://www.siegels.us/HomeAutomation/SH_Automation.html

June article preview (pp24-35):  http://read.uberflip.com/i/10757/36#

 

Also, NXP now has a low cost M0 chip with both the CAN transceiver and on-chip CANOpen drivers built into the chip:  http://www.nxp.com/documents/leaflet/75017050.pdf

 

The above chip is one I have been eyeing for awhile as a candidate for my next generation home automation system (anybody remember the HCS-II ?  :smile: )

Link to post
Share on other sites

The multi-master aspect of I2C is a huge benefit, nut it suffers a half-duplex where UART is full duplex. UART allows for per-byte parity checking, UART is much easier to shift over to a balanced line (like DMX).

In modern times, these are not real issues.  Full duplexing is pretty rare, and when it is needed, SPI is more suitable than UART is.

Link to post
Share on other sites

Hi everyone, thank you for the info and lively discussion  :thumbup:

 

So I will migrating over to MicroSD for this project because my eeprom simply isn't holding enough data and even the larger ones 2Mb will start to suffer when accessing quality audio. Additionally, the MicroSD card will enable quick sound loading and testing with the female mount that I will be able to use in the design. From what I read in John Davies' MSP430 Microcontroller Basics, it seems that the hook up would be MOSI of MSP430 to MOSI of the SD card (or whatever the naming convention of the SD card is), then MISO of the SD Card to the MOSI of the DAC, and the DAC does not require a slave out. (With individual chip selects for each device). It feels like I am missing some MISO to the MSP430, but is this fine due to SPI's lack of error checking? 

 

I have the female sockets on their way and haven't picked up any Micro cards yet if anyone has any suggestions. 

 

Same idea though here, from the MicroSD card to the DAC directly through the control of the MSP430 if possible. In digging into the example codes, I was unable to find anything with this implementation in the MSP430ware section. Perhaps I was missing something or there is a better example laying about?

 

If anyone is curious, I am using a Linear Technology LTC1655 16-Bit DAC. 

 

Thank you everyone that has been chiming in, I am learning exponentially with everyone's help and hope to have a cool project to post and share up here soon!

Link to post
Share on other sites

AFAIK the SP SPI mode is free to implement, though you'd better call it a "TransFlash" slot to avoid SD trademark infringements. As SD cards identify themselves (block size, card size, identifiers) to the SPI master, you should have MISO from SD to MISO on the MSP430, there is no problem in feeding this same line to the MOSI on the DAC, since you'd have one dedicated output line and two dedicated input lines on the net. If you get problems with fanout (too much load for one little pin) you can resolve the issue with a simple single or dual buffer.

I've never heard about the SD SPI mode requiring licencing fees, I'll look into it.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...