SOMO-14D Embedded Audio-Sound Module

[goom]

I decided to look into the SOMO-14D Embedded Audio-Sound Module as an alternative to the ISD2560 sound recorder chip, which I have used successfully in the past for a sailboat race countdown start timer. It may also prove to be a useful unit for model sound effects, commanded by a spare RC receiver channel.
I am new to 2-wire serial communications, and am having some difficulty understanding it.
From the datasheet, http://www.4dsystems.com.au/downloads/Audio-Sound-Modules/SOMO-14D/Docs/SOMO-14D-DS-rev2.pdf, it appears to require a rather slow data transmission - a 2.5kHz clock frequency. It also reqires a minimum 2ms start and stop bit pulse width. I therefore conclude that using SPIOUT (or HSPIOUT) would be much too fast for the SOMO-14D. Is that correct?
How fast is SPIOUT? I could not find any mention in the manuals. Perhaps underclocking could make it slow enough?
I decided to try my hand at some bit-banged SPI code:

'Countdown timer using PICAXE-28X1 and SOMO-14D Embedded Audio-Sound Module
setfreq m8
Start:
W0=65527 '=%1111111111110111, set volume to max
gosub Send_Data
W0=500 '=%0000000111110100, play sound file 0500.ad4
gosub Send_Data
end
Send_Data:
  low 0
  pulsout 2,400  'Pause 2ms by pulsing dummy pin (needs >2ms start bit)
  for b4=1 to 16  'Loop through all 16 bits
  W0=W1&%1000000000000000  'Mask MSB
  pin1=bit15  'Set data to MSB
  if b4=16 then
   high 0  'Clock high (needs >2ms stop bit)
   else
   pulsout 0,40  'Clock high for 200us to latch data on pin0
   pulsout 2,40  'Pause 200us by pulsing dummy pin (low clock)
  endif
  W0=W0<<1  'Shift left to get next significant bit
  next b4
Return

I would appreciate it if someone could do a sanity check to see if I am on the right track. I can't try anything yet since I ordered the unit only today.

 

[inglewoodpete]

How fast is SPIOUT? I could not find any mention in the manuals. Perhaps underclocking could make it slow enough?

You don't need to underclock.

I don't know how fast SPIOut is in bits/second but when I was doing some development work transferring an application from 28x to 40x1, I found the SPIOut was about 5 times faster than the equivalent longhand code.

The code I originally wrote was similar to the code provided in Command Manual (2), under ShiftOut/SPIOut. You will see that chips other than the X1s and X2s need to use a multicommand routine (it differs slightly depending if you want the MSMit or LSBit sent first).

By using the longhand coding, it will naturally run slower. If that is not slow enough, add a couple of short pauses (eg Pause 1), one when the clock line is high and the other when low. If that still doesn't work, extend the delay right out until it does work (or until you discover and fix the real problem) The good thing about SPIOut/ShiftOut is that you can slow it down as much as you want during debugging - eg 1 second per clock pulse!!

Edit: and now I've just read your code example. The data line must be valid on the rising edge of the clock signal. Also, you can't assume that the clock line will be high at bootup: it won't be. So, set pin 0 high and pause a long time (Eg 500mS) before doing anything else at startup. Also, I think you need to preload the data into w1 in your code, not w0. Have a close look at w0: you keep loading nothing into it!

 

[westaust55]

wrt to data rates, from some tests I did about 1 years ago
http://www.picaxeforum.co.uk/newreply.php?do=newreply&p=81360

and some recent tests with bit-bashed SPI data transfer here is my approx results on speed:

- 4 MHz bit-bashed SPI (using 08M and as per manual 2 thru three 74HC595) ==> 250 data bits/sec
- 4 MHz SPIOUT (using 40X1 thru four 74HC595) ==> 540 data bits/sec
- 4 MHz i2c comms (using 40X1 thru two MCP23017) ==> 780 data bits/sec (start/stop/ack/addr/etc are extra bits)

In each case I was transferring 3 or 4 bytes of data in rapid succession with overheads to create a loop to send the required data.
SP actual data transfer clock speeds will be higher that the above but these possibly represent typically long term data throughput.

 

[goom]

Many thanks for the responses.
Yes, I did have WO and W1 mixed up. I now realise that only one word variable is required, so have been able to simplify the code. W0 will be corrupted, but I do not need to use it elsewhere.

'Countdown timer using PICAXE-28X1 and SOMO-14D Embedded Audio-Sound Module
setfreq m8
Start:
W0=65527 '=%1111111111110111, set volume to max
gosub Send_Data
W0=500 '=%0000000111110100, play sound file 0500.ad4
gosub Send_Data
end
Send_Data:
  low 0
  pulsout 2,400 'Pause 2ms by pulsing dummy pin (needs >2ms low start clock pulse)
  for b4=1 to 16 'Loop through all 16 bits
 pin1=bit15  'Set data to MSB
 if b4=16 then
   high 0  'Clock high (needs >2ms stop clock pulse)
   else
   pulsout 0,40 'Clock high for 200us to latch data on pin1
   pulsout 2,40 'Pause 200us by pulsing dummy pin (low clock)
 endif
 W0=W0<<1  'Shift left to get next significant bit
  next b4
Return

I'm not sure that it matters whether the clock line defaults high or low on startup. I set it low for 2ms before beginning to transmit data (as required by the datasheet), so subsequent pulsouts will clock the data on a rising edge.
It does look like spiout may be slow enough EXCEPT for the requirement of an initial 2ms low clock, and a final 2ms high clock. I'll give it a try anyway once I get the module.

 

[westaust55]

4D systems SOMO 14D audio module

Did some rough maths working backwards from the data in the link I previously gave you.

Excluding the time for the for next loop and just considering the SHIFTOUT (SPIOUT) command time increase to send 4 bytes 50,000 times it took 377 seconds. If my maths are right, then that equates to around 4244 bits per second which is faster than the 2.5 kHz max clock speed of the SOMO 14D module.

But since the bit-bashed method runs slower from some of my data that suggests around 1964 bits/sec and Inglewoodpete’s comment suggests maybe even half of that.

So definitely start with the bit-bash method. You could then try the SPIOUT command once you have a knowing working situation, but seems like the SPIOUT will be too fast.

 

[goom]

Many thanks for the additional information. I will try just what you suggested once I have the hardware, and will post my findings.