Group Actions
Engagement
  • Author Author: COMPACT
  • Date Created: Date Created
  • Views 780 views
  • Likes 2 likes
  • Comments 3 comments
Related
Recommended

Project "code name" PostScript 011

COMPACT

16th July

A Great Progress Day

I have been continuing SIT testing and today I have my project producing sound whilst responding to Wi-Fi datagrams.

Although this does not sound like much to most you will need to consider what is happening.

 

The Basic WiFi Demonstration uses a SPI port with interrupts to service the CC3000.

As not to interfere with this activity, I have connected the 256K FRAM buffer, DAC and LCD to the other SPI port.

 

The Basic Wi-Fi Demonstration also uses a Timer A for handling its events.

As not to interfere with this activity, I have used Timer B0 to generate a 8KHz Interrupt for sound and mouth articulation processing.

 

Sound is produced using a sample rate of 8kHz.

When the Interrupt Service Routine (ISR) for Timer B0 is invoked,

     It firstly checks to see if sound is to be produced by checking the sound enable flag

     If this flag is set then the following occurs

          The FRAM Buffer is taken out of its hold state

          The FRAM Buffer is accessed to obtain the next DAC value

          The FRAM Buffer is accessed to obtain the next mouth value

          The DAC is loaded with the new value

          The mouth is loaded with its new value

          The FRAM Buffer is put back into its hold state

     The Timer is reloaded.

 

Using the hold state enables the use of quicker FRAM buffer accesses by utilising its auto increment address feature.

 

For SIT testing, this ISR is even more complicated because I have given it the ability to produce a continuous sound by relooping through the FRAM buffer.

I may leave this feature in because I am finding it useful. I am currently generating sine waves of a nominated frequency.

This feature would be useful for creating Alarm sounds.

  • in reply to COMPACT

    I think that size is a carry over from the old ethernet specifications.  To make it easier to get qualified, the wifi group just set up the specs to be compatible so they could claim plug and play capability.  I am surprised the TI guys didn't take that into account, but it sounds like the limitation might be a side effect of their simply wifi software.  You might take a look there to see if it is hard coded or just limited for the more simple protocol.

     

    From my perspective, the simple protocol is a greater benefit for embedded devices.  If you really need that higher message size, you need to step up to a more capable connection technology.

     

    Have fun,

    DAB

  • Hi DAB,

    The buffer issues are only related to the CC3000 Buffer allocated and within the MSP430 used in the Basic Wi-Fi Demo and not the additional FRAM Buffer.

    What I have worked out thus far is the buffer needs to larger than the original value 5 and no greater than 256.

    I've been getting everything else working and have not had the opportunity to look further into the reasons why.

     

    I just looked up TI e2e forum and it mentions that the minimum buffer size for the current driver is 119 bytes.

     

    With a bit of effort I think I will be able to find the cause and expand the buffer as necessary up to Wi-FI's MTU of 7981 bytes.

    (I didn't realise Wi-Fi datagrams could be so big!)

     

     

    Cheers

    Very Compact

  • If you get some time, I think you can decouple these events to get a better control and a smoother transition between the various tasks.

     

    The MSP430 provides a great set of independently operable timers and event triggered ISR options.  By using the full device capabilities, you can decouple the events into a cleaner structure, which might also alleviate some of your buffer issues.

     

    Just a thought,

    DAB