advice please hippy

Hippy, I've been working with the ISD 4004 audio recorded. It is controlled via the SPI interface on the 40X1. I can controll most of the functions. I know that at least some of comms are working because with my CRO and bench top power supply I can see current consumption go up or down when for example I issue the powerup or powerdown com.


I cannot get the record or play com to work. I believe the problem is in the way Im expressing the address to record to or to play from part of the command. The address is given in hex.

The datat sheet is here:
http://www.chipdip.ru/library/DOC000057135.pdf

Page 6 of the data sheet has the Opcode summary.

Page 62 of the new picaxe basic commands manual has the hspiout command info.

I have pasted in part of the code Im using below. As I say everything seems to be working except the record and play lines. How should I write the hex address part of the code? As it is below is the only way the editor will take it but it doesnt seem to work.

I have discovered it is important to high low chip select output between eachk command.

I've kinda hit the wall, any advice will be much appreciated. If you need more info please ask and I'll respond.

main:
low 0 'enable slave select

init: hspisetup spimode10e,spislow 'spi mode 1,1 the ISD4004 responds to this

high 0

low 0 'enable slave select
hspiout (%00100) 'POWERUP com
high 0
pause 35 'power up delay
low 0
hspiout (%00100) 'POWERUP com
high 0
low 0
hspiout (%10100,$00,$00) 'SETREC com
high 0

low 0
hspiout (%10110) 'REC com
high 0

pause 3000


hspiout (%00110000) 'STOP com



low 0
hspiout (%0001) 'STOPPWRDN com
high 0


stop

 

Edited by - BrendanP on 23/06/2007 09:10:38

Edited by - BrendanP on 23/06/2007 09:15:58

Page 18, figure 5 of the ISD4004 datasheet:
- Clock idle looks to be low.

- SlaveIn data is sampled on high going clock but it requires 200 ns hold time so it's prolly a good idea to have the Picaxe clocking the data out on the low going edge.

- The SlaveOut data is clocked out on the low going edge. So it should be safest for the Picaxe, being master, to sample on the low going clock.

I'd change your setup to: hspisetup spimode00e,spislow ' CKP=0, CKE=1, SMP=1

(The ISD4004 is good for the full 1 MHz clockrate btw but I assume you will do that once it is running.)

Next problem is likely the bit ordering. SPI defacto bit order is big endian but there is always exceptions and the ISD4004 is one such exception. It's not too hard to correct this, all you have to do is swap all the command bit patterns end-for-end.

And any data/addresses you send/receive will need massaged also.

To give you a bit of a hint, you fluked your powerup command for two reasons:
- You incorrectly formatted the command without the bottom 3 unused bits. So the top 3 unused bits are shifted out first on the big endian Picaxe which are received as the bottom 3 unused bits of the command in the little endian ISD4004.
- The remaining 5 bits are a symmetrical pattern so just happens to be the same command in both formats.



Edited by - evanh on 23/06/2007 13:03:43

I'm not familiar with the ISD nor using HSPIOUT commands, but looking at the datasheet you linked to, Figure 7 shows the address being sent before the command rather the the way you have it. That would require ...<code><pre><font size=2 face='Courier'> hspiout ($00,$00,%10100) 'SETREC com </font></pre></code> However ... Figure 13-2 in the 16F886 datasheet shows the MSSP port sends data msb first, whereas the ISD expects lsb first, which would mean using ...<code><pre><font size=2 face='Courier'> hspiout ($00,$00,%00101) 'SETREC com </font></pre></code> And all other commands would need to be reversed as well. You'll have to reverse all address bits as well if using anything other than address $0000

Also, comparing Figure 13-2 in the 16F886 datasheet with the required SPI signals in the ISD datasheet, it appears that, for the 16F886, you'd want CKP=0/CKE=1 mode of clocking, which is spimode00 or spimode00e for HSPISETUP, not the spimode10e you have.

No guarantees I've got it right because I haven't sat down and studied the datasheets in depth, but this is where I'd start.

Double whammy! Actually, they are quite complementary replies. Needs stickied.

A massive thank you to both of you. The generosity of people on this forum always amazes me.

&#160;

Edited by - BrendanP on 23/06/2007 13:51:55

Your write up of the question went along way to helping with the answer. The description of behaviour (which paired up nicely with the code), the link to datasheet, and the example code all made the answering way easier.

The only other thing's that I referenced was the updated picaxe basic manual (Never used the X1 commands before) and a PIC16F874A datasheet (Dunno what parts the newer Picaxes are using but figured the SPI ports are all the same).

I'll agree with evanh, the datasheet link was the real key for me. I wasn't aware of 'standard SPI bit ordering' and was surprised that wasn't mentioned in the PICAXE Manual, so had to go to the PICmicro datasheet.

Having not done ISD or HSPI I was happy to learn more, and your comment on addressing was a lucky break which did identify a problem, even if it wasn't the main issue. That's usually how debugging goes !

Why datasheets cannot clearly state everything without having to go through and compare waveform diagrams with text descriptions and quite often code from people who have finally got things working I'll never know.

Well guys, in the words of Dr. Frankenstein &quot;ITS ALIVE&quot;. I made the changes you guys suggested and away it went. I've been on this thing for all this week so its great to get a result.

Evan, if you want a 40X1 to work with let me know and Ill post one to you for free. Let me know your local post office in NZ. I'm in Melbourne. I presume you have some Hippy?

I think the problem with the poor info delivery of most data sheets can be traced back to the a basic fact of human behaviour. When we oursleves are extremely conversant with a piece of information or in this case technology there is a very strong subconscious tendencey to start thinking everyone else has that same knowledge. So when the enginnering team who designed the ISD4004 sat down to write the data sheet they omit all sort of information, why? because after working in the field for years they themsleves are totally familiar with that info so think surely every one else is too.

&#160;

Edited by - BrendanP on 24/06/2007 02:36:19

Thanks for the offer but like hippy I also got some more knowledge under my belt and glad to of been a help. And work uses Picaxes from time to time so I'll get to play with an X1 part before long.

I'm not sure why little endian format is used for such a device. One idea that comes to mind is maybe AC97 is defined little endian. Don't really know and AC97 will be much higher clockrate anyway.

Researching an answer led me to think; why can't SPI be used to churn out 8 pixels worth of video data ? I can't see why not and that gives video generating code on a PICmicro some time to determine the next 8 pixels while the hardware sorts out sending the last 8.

Another idea now is to use the AUSART for pixels out as that's double-buffered and use SPI for data input.

So do you thank me or I thank you <img src="smile.gif" width=15 height=15 align=middle>

I am interested in your project with the ISD4004, I don't have one but I have tried using a picaxe to control a ISD 25000 series. The 25000 series does not have a SPI port just used the picaxe to control the pushbutton command inputs. My problem was the speed of response between playing the recorded sounds. I see from ISD data sheet &quot;The ISD4000 SPI Control Port&quot; that you can jump &quot;seamlessly&quot; to another address while the chip is playing, but it always plays to the end of the memory row before stopping or changing ??. Except a stop is sent and you have to wait for the time Stop/pause before next message. I was wondering is this correct, have you experimented.?? According to the data sheet the 4004 rows are 400 milliseconds long, whis is a long time. I thought maybe the SPI chips would be faster. Would welcome your thoughts. ...... Thanks..

As I understand it each row of the ISD4004 is divided into 200 milli sec increments. Therefore worse case senario is that you would have a 199 millisec gap between segments if you were 'building' a message out of discrete segments. I don't think that would be an issue in a practical application. I'm still sorting the thing out. I'm getting very poor sound reproduction at the moment. I have to try other mikes. I was happy just to be able to control the beast. Now that I have that under control I'll try things like building messages. Ill post gain as I advance.

&#160;

Edited by - BrendanP on 26/06/2007 13:23:15