im trying to interface a winbond chipcorder isd1700 via spi, i have it working with standalone buttons right now so i know it works, i have the spi lines hooked to the arduino, and this is sorta what i have so far.
can i use the opcodes like i am? do i need to do anything special for the hex codes, should i convert them to decimal? any hints on something im doing blatantly wrong?
i couldn't find a spi speed in the manual so i assumed the lowest
the datasheet specified
PU then CLR_INT then PLAY as a sample execution sequence
each of these command bytes is to be followed by a 0x00 value
the code doesn't work as is, but i don't exactly expect it to either. looking for some advice so i can work on it some more tommorrow thanks!
The hardware SPI, which you are attempting to work, only works on specific pins: SS is pin 10, MOSI is pin 11, MISO is pin 12, SCK is 13. That's a start, at least!
My hangup was this: SPI has four modes determined by two parameters, clock polarity (CPOL) and clock phase (CPHA). The standard doesn't really specify which to use, so different vendors come up with different ways of doing it. Of course #4 was the one that finally worked for my device.
As A_square pointed out, you've got to use the specified pins for MOSI, MISO, and CLK. SPI is a bus, so if the peripherals are well behaved you can put multiple devices on these three lines (each will need its own slave select, of course).
regarding how to read status registers on the chipcorder, and im assuming other spi devices....
alright i think i have an idea of how it works miso goes in SPDR after each SPDR load so you put a byte into spdr and it outputs a byte into spdr from the spi device now... lets say the spi device puts 3 bytes into spdr for a command spdr only appears to hold a single byte, so how do we read all 3 bytes? the spi commands im noticing have 0x00 bytes beyond the command byte the number of these 0x00 bytes seem to conform to how many miso bytes the command returns so at first glance the extra 0x00 for each command seem like nonsense because they are null values however what it does is give you seperate spi_transfer calls, each returning a byte so while RD_STATUS is 0x05,0x00,0x00 its 3 different spi_transfers, and 3 different MISO states so you read each miso value after each spi transfer, then you can put them together to get the full miso stream so for my chip corder, when i send a play command, then continue checking the 3rd returned byte of the rd_status spi command while the chip is playing, the 3rd bit of the 3rd byte (last 0x00 transfer of RD_STATUS) will be 1, it will go to 0 when the chip is done (actually it will go from 00100000 to 10000000 as the first bit is the ready flag .. what you should be looking for anyways).
two things don't help figuring this out, serial.print's deletion of leading zeros, and serial.prints erratic behaviour while the circuit is playing the speaker (need to track this down) i assume its either power draw or noise. bitwise math is what youll need to do to check status ... for instance you dont want to start another spi command until the play command has completed which you don't know unless you check the regsiter... so you have to keep cycling through RD_STATUS spi commands until the 3rd byte is what you want.
to put multiple spi devices on the same bus wouldn't they need to all use the same SPCR settings?
Nope, since (if they are well-behaved SPI devices) their MISO pins are all in a high impedance state except for the one with its chip select active. Just change to the appropriate control register settings before selecting the device you want to talk to - theoretically anyway; I haven't done this myself. My multiple device scenario consisted of identical devices.
There are some devices (e.g. Dallas has a few) that do not go hi-Z on MISO like they're supposed to. These would break the bus.
i fixed my erratic arduino behavior with a 100uf bypass cap after the arduino, i just looked at the demo board and it has 4 extra 10uf caps on each of the different vcc segments, the datasheet showed these as optional and didnt even list values so ill give that a shot first.
im not sure if its a noise or peak power problem the 100uf is solving, technically the speaker should not be doing more than 670mW according to the spec sheet so its probably noise.
Hello. So finally you done? Solve your problem? Can you send me the full code? I'm so new to this chip and just start to learn it. Have no idea at all about SPI.