So I am trying to interface with the MAX7219. I can get it working fine using SPI, however I don't want to be limited to the hardware SPI pins so I am trying to use the shiftOut function instead of the SPI but I cannot get it to work.
This code works - however I am limited to using the hardware SPI pins.
byte modeReg = 0x0f;
byte testModeOn = 1;
//Turn on test mode
digitalWrite(csPin, LOW);
SPI.transfer(modeReg);
SPI.transfer(testModeOn );
digitalWrite(csPin, HIGH);
I don't want to be limited to the pins I use so I unsuccessfully tried to do:
If you're trying to use shiftOut to talk to the SPI slave on the MAX, that won't work. Read up on how SPI works - there's a lot more to it than simply shifting out 8 data bits. It is entirely possible to make (low-speed) SPI work using almost any I/O pins, but you MUST implement the SPI protocol, which is non-trivial.
Delta_G:
What is the aversion to using the SPI pins? What do you need on those pins that you can't do with other pins?
I just wanted the flexibility of being able to add a display (the MAX7219) to an existing setup and not have to worry about modifying the SPI bus or anything else that was already on the SPI pins.
CrossRoads:
Can use any pins as long as you define them first - I usually make them global - so define before setup() :
All AVR serial ports are capable of full speed master mode SPI.
The Mega2560 has 4 hardware serial ports and a Bobuino has 2.
If you don't use the USB link, the 1 serial port of small Arduinos will do too.
Perfect for hanging dedicated devices you don't want to open/close/open/close on.
If you want to copy files between 2 SD cards, 2 SPI buses can speed that up incredibly.
Delta_G:
The MAX7219 uses SPI, so it wouldn't matter if you had something else on the SPI bus. You can have several things sharing the SPI bus at the same time. They only need separate CS pins. That's the point of having the dedicated bus, so many things can share the same pins. If you try to create a "software SPI" for one of them then you are needlessly giving up 3 pins on your Arduino that could be doing something else.
that's true but if I have an SD card on that bus and wanted to shovel SD data through the MAX7219, the very act of switching the SD off to switch the MAX on means the SD has to reinitialize, open the file and set the seek whereas if they are on different SPI buses there is no need to do that every time the buffer gets full.
Do you remember copying files between floppy disks with only one FD, no HD, and 64K or less RAM?
Compare to the same operation with 2 FD's. That's why more than one SPI bus can make a big difference.
Delta_G:
So an SD card closes the file if I pull the SS pin to HIGH? I figured it would just sit until I pulled SS low and started talking to it again.
My understanding from the docs is that the card turns off when it's deselected.
I would not count on the card closing the file for me. My code should do that before deselect if I've been writing to file to ensure that the FAT is updated.
Perhaps a test is in order but I'm past bedtime already.
No. Have a look at the code for any of the small TFT screens that come with an SD card on the shield. They all have an example sketch which loads a BMP image from the SD card onto the screen. There isn't enough memory on an Arduino to hold the whole image, so it has to work in small chunks. Raising the CS for the SD card doesn't break the file that's currently open.
MorganS:
No. Have a look at the code for any of the small TFT screens that come with an SD card on the shield. They all have an example sketch which loads a BMP image from the SD card onto the screen. There isn't enough memory on an Arduino to hold the whole image, so it has to work in small chunks. Raising the CS for the SD card doesn't break the file that's currently open.
Are you saying that because the buffer is smaller than the image that therefore the SD card stays on point?
I need to see code, not assumptions. I spent too many years learning that lesson.
So I modified a modified SD example to deselect and select with a delay between and I found out that yes, the SD card does "hold position" which is great news to me!
I must have been really tired last night. I was thinking I'd have to do a bunch of cut and splice to hang two devices on the bus (got the SD module on jumpers) to test and then this morning I see there's no need for that.