I tried the code in these threads. I used the code of thread (1) for the header and sample program, and thread (2) for the definition of ISD1700 class.
I fixed the code a little.
//#include "WProgram.h" #include "Arduino.h"
But it wouldn't work. All I got were "Not_RDY".
In push button mode it works well. I can record with the on board mic. and I can play them, and the forward function also works well.
I upload the photo of my trying system. Is there anyone who help me?
And any suggestion welcomes.
Well - that's great, but etiquette suggests that you post what you did to fix the problem here, so that others who may have this problem in the future may learn from your example...
Sorry for being too late to upload my codes. I hadn't noticed above message.
How did I fix the problem:
The document said "It needs at least 500 nsec between the SS pin is set LOW and transmitting the clock." So I added "delay(WAIT_TIME)" after "digitalWrite(SLAVESELECT, LOW). I think WAIT_TIME=1(ms) is OK, because it is greater than 500ns.
How to connect the audio line:
Connect PC's audio output to the Arduino's AnaIn and Gnd pins. The stereo mini plug must convert into the monoral mini plug.
How to control:
Control Arduino by the Arduino 1.0's serial montor.
0 - initialize.
1 - erasing test with specifying the address.
2 - recording test with specifying the address.
3 - playback test with specifying the address.
l - clear interupt.
y - play
r - rocord
f - forward
z - erase all
e - erase
s - reset
a - set the apc resister as "mic in".
b - set the apc resister as "analog in".
How to record:
1)Firstly, erase whole memories by "z" key.
2)Switch to line input by "b" key. You will hear sound.
3)Start recording by "r" key. Stop recording by "p" key.
4)Playback it by "y" key.
How to "set-record":
1)Firstly, erase whole memories by "z" key.
2) "1" key - erase memories from start_address to end_address.
3) "2" key - record on the memories from start_address to end_address.
4) "3" key - playback between start_address and end_address.
I know this is an old thread but thought I'd share my experience and unique solution in case anyone is considering using the ISD17xx.
After battling with the SPI for more time than I care to admit, I had an important realization.
SPI operation seems at best intermittent. Some commands work all of the time (DEVID), some work some of the time (RD_PTR). The device seems to work fine in manual mode, with the switches.
Since the switch inputs are just looking for logic levels, I thought about driving them directly with the Arduino. There already was a common ground. I rewired my board, putting in 10k resistors in series for a bit of isolation/protection and ran digital lines to the switch inputs. I chose 10k since the inputs have 600k pullups, and 10k should have negligible effect on a logic low. I have not tried it but am confident that no resistors are required.
The system now works perfectly!
No bit bashing or SPI library/SPI configuration/time delays/flag checking required. I wrote simple functions that sends logic low for 100 ms to appropriate switch inputs to activate each desired function.
The only functionality lost with this approach is that my message handling structure needs to know how many messages are recorded in the circular memory array after power is applied. I plan on using a dedicated location in FLASH to store this value.
Asserting the RESET line gets you to a known condition (PLAY & REC PTRS at last message) so you can then use FWD to advance through the circular array.
I've also found that many boards are available with this chip on it at very affordable prices so it is a good option for adding voice output to any system.
Save yourself a lot of frustration by ignoring the SPI interface and just wire into the switch inputs. The internal pullups and debouncing make it virtually foolproof.
bradski58:
I know this is an old thread but thought I'd share my experience... in case anyone is considering using the ISD17xx.
...
Couldn't have put it better myself, so I didn't.
I posted on "programming questions" as it was sorta a compiler thing of general interest maybe, but my point can be reiterated harmlessly here I hope.
BTW I love and approve of hijacking buttons if it can do what you need. But I think the fear people might have of SPI should be overcome.
The "ready_play_wait()" routine from above is flawed. It has a certain chance of failing to wait at all. byte3 is tested before it is received from the chip. All you needa do is change the while to a do/while.
I think this might have caused some heads to ache.
Here's a general ready_wait that works. No need for any delay(), but it does just waste time waiting.
I'm trying to build a simple DIY sampler from an ISD1760.
I spent an hour going through the forum to find a good solution, I found your idea and it makes total sense!
Did you implement your idea to use a dedicated location in Flash?
Thanks!
Izhar
bradski58:
I know this is an old thread but thought I'd share my experience and unique solution in case anyone is considering using the ISD17xx.
After battling with the SPI for more time than I care to admit, I had an important realization.
SPI operation seems at best intermittent. Some commands work all of the time (DEVID), some work some of the time (RD_PTR). The device seems to work fine in manual mode, with the switches.
The system now works perfectly!
The only functionality lost with this approach is that my message handling structure needs to know how many messages are recorded in the circular memory array after power is applied. I plan on using a dedicated location in FLASH to store this value.
Yes, I did get that working by using an EEPROM location.
It been awhile, (i've been retired for over a year now) but near as I can tell from looking at (many versions) of the source code, it went something like this:
#include <EEPROM.h>
// in setup() include the following
//EEPROM.write(500,whateverv_value); // only executed once to write the value permanently. //comment out after one execution
max_msg = EEPROM.read(500); // read every time the program starts to get the stored value
I don't remember why I used location 500
I had a pretty bad source code version control system back then consisting of many dated folders.
I believe this code was functional.
Perhaps you could check out the EEPROM library... I've also seen references to EEPROM.get & EEPROM.put. Not sure why I used read & write.