LeafLabs Garden » Topic: SPI beginSlave doesn't pay attention to Slave Select line

LeafLabs Garden » Topic: SPI beginSlave doesn't pay attention to Slave Select line http://forums.leaflabs.com/topic.php?id=1262 A place to share, learn, and grow... en-US Fri, 22 Jan 2016 00:20:38 +0000 http://bbpress.org/?v=1.0.2 <![CDATA[Search]]> q http://forums.leaflabs.com/search.php zecritic on "SPI beginSlave doesn't pay attention to Slave Select line" http://forums.leaflabs.com/topic.php?id=1262#post-7790 Thu, 19 Jan 2012 01:12:18 +0000 zecritic 7790@http://forums.leaflabs.com/ Hi Rick, It's a bit hard for me to read your code to understand which versions work and which alternate commented out versions don't. Could you clean up your code a little bit and post the two different versions on some site like pastebin that has syntax highlighting and link them here, instead? I'm not entirely sure what's going on here. From my reading of the manual, I got the impression that since HardwareSPI sets the Software Slave Management (SSM) bit, the only way to toggle the internal slave select status is by changing the SSI bit in control register 1. Since wirish makes no provisions for setting the SSI bit, I would expect that the maple's SPI is never selected, and that RXNE is never set and thus since HardwareSPI::read() blocks unti RXNE is set, that HardwareSPI::read() should never return. (Obviously it does, though usually not with the correct answer). Can someone with a better understanding of SPI shed some light here? What would be the expected behavior if one were to try to receive data on the SPI without ever selecting it? RickRantilla on "SPI beginSlave doesn't pay attention to Slave Select line" http://forums.leaflabs.com/topic.php?id=1262#post-7709 Tue, 17 Jan 2012 03:47:40 +0000 RickRantilla 7709@http://forums.leaflabs.com/ Since I've got your attention, I've run into another glitch that may or may not be related. When I move the spi.read() statement into any function except the main loop it either stops working (or can't keep up with the data). Specifically, I'm receiving data at 1 byte every 4 microseconds, so the 72 megaHz Maple processor should be able to run 288 assembly instructions before the next byte arrives. My code (in c) does at most 1) an spi.read, 2) a lookup in a 256 bit table, 3) a function that does two reassigns, then an if... switch to another reassign and a return and 4) one more conditional after the return. I don't know what this maps to in assembly but when I put in a timer it measured this cycle at 2 microseconds. I need to move the spi.read out of the main loop so I can do other functions but it stops working. Here is all the relevant code which works fine as is. In loop I've commented out the 3 simple OPTIONS I've tired. With each I never get a successful userID. With OPTION 3, I don't think the overhead of simply going to a function is sufficient to use up my 288 cycles so maybe there is some other problem I can't think of. Thanks in advance... <pre><code>// Written by Rick Rantilla - January 2012 // with help from Nick Gammon char sketch[] = "Maple_SPI_jan17q "; // Rick a // rev q - clean up code - simplify calls to servos // rev m - removed interrupts - fussing with raw2work table and getDigit() sequence // rev k - learning interrupts - I didn't need them // Hooked up to T&A, which sends 1500 byte bursts at 2.25 megaHz (1 byte every 4 microsec) // 10% pass first filter, half those pass 2nd filter, then I analyze remainder for userID // so a 256 byte buffer seems adequate // rev f - IT WORKS! now let's find it's limits before integrating hw // rev e - testing pin 31 (slave select) // Rev d - corrected if raw2work loop // experimenting with SPI mode - unsure of Slave Select/Enable // Rev c - using HardwareSPI 2 - which is 5v tolerant // Rev b - isn't working. Let's try as a master in example // OK got spi.beginSlave() going // Rev a - goal is to get basic SPI running on Maple // then hook it to T&A and see if dropped % and junk % are better // currently have an Arduino 2009 with SPI master connected // also have logic analyzer connected // global includes, variables, etc. // Use SPI port number 2 - which is 5 volt tolerant HardwareSPI spi(2); // Rick a - this spi is on pins 31 - 34 #include <Servo.h> // Rick A // global variables byte g = 0; // Rick J byte i = 0; // Rick p byte j = 0; // Rick p byte k = 0; // Rick p byte p = 0; // Rick x - I've made all counters unique and global volatile byte c; volatile byte cp; volatile byte work_digit=9; // Rick n volatile byte good_digit[255]; // Rick d - need to initialize to something besides 0 volatile boolean raw2work[] = {0,1,0,0,0,0,0,0, 0,0,0,0,0,0,0,0, 0,0,0,1,0,0,0,0, 0,0,0,0,0,0,0,0, // 0-31 Rick w 0,1,0,1,0,0,0,0, 0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0, 0,0,0,0,1,0,1,1, // 32-63 0,0,0,1,0,0,0,1, 0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0, // 64-95 1,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0, 0,0,0,0,0,0,1,1, // 96-127 0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0, // 128-159 0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0, // 160-191 1,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0, // 192-223 0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0 };// 224-255 // Rick x - only bytes in this table pass thru to the next step of decoding // namely: 1,19,33,35,60,62,67,71,96,126,127,192 // Maple m - also letting in 63 to eliminate digit pairs creating false readings int userID = 0; // Rick B byte userDoor[255]; // Rick H - registerNewUser() uses to assign doors int keySwitch = 26; // external key positions CW = ClockWise position // note HardwareSPI on Maple uses pins 31, 32, 33, 34 byte SS = 31; // Maple e - test this SPI pin - Need to turn on for SPIslave to work!!! void setup() { pinMode (SS, INPUT); // Maple e - test SPI pins (also undocumented requirement for SPI) // Turn on the SPI port spi.beginSlave(MSBFIRST, SPI_MODE_2); // use this for T&A //spi.beginSlave(MSBFIRST, SPI_MODE_0); // use this for data from Arduino simulator //spi.begin(SPI_2_25MHZ, MSBFIRST, 0); // Maple d - if using as Master pinMode (keySwitch, INPUT_PULLUP); } // end setup void loop() { // if (digitalRead(keySwitch) == HIGH) {adultCare();} else {childCare();} // OPTION 1 - fail // also tried using interrupts OPTION 2 - fail // adultCare(); // with spi.read in adultCare function it stops working OPTION 3 - fail //} // end loop //void adultCare() { work_digit = spi.read(); // get something on MOSI at 1 byte every 4 microsec in 1500 byte bursts // goal is to extract 8 digit userID from each burst if (raw2work[work_digit]>0) // Rick f - check against the valid bit map table - only about 10% should pass { getDigit(); // Rick x - converts only valid digits, less than half make it through this filter // returns with a new good_digit[] at g, or with g unchanged if (good_digit[g-8] == 0) // is it getting within range? { if((good_digit[g-7]==0) && (good_digit[g-6]==0) && (good_digit[g-5]==0)) { // a valid userID starts with 4 zeroes - print the 4 least significant digits // don't care how long this takes, I won't get another userID for a few billion cycles userID = 1000 * good_digit[g-4] + 100 * good_digit[g-3] + 10 * good_digit[g-2] + good_digit[g-1]; SerialUSB.print("User ID = "); SerialUSB.println(userID); // debug // do a bunch of other stuff here } // end if good_digit(-7) } // end if good_digit(-8) } // end if raw2work - most of the time loop does nothing but check inpoint/outpoint } // end adultCare() void childCare() { // a completely different set of stuff that doesn't require spi.read() } // end childCare void getDigit() // Rick p { cp = c; // Rick n - store previous digit needed to distinguish a 1, 3 or 8 c = work_digit; // still the raw byte as SPI found it, but only those in raw2work lookup table switch (c) // Rick n - each graphic bitmap has 16 bytes per digit displayed (plus 6 command digits) // Among the digits, each digit has a unique byte (or byte pair) // 96, 192, 62, 126 and 127 may also appear in other digits, but unique pairings finalize the selection // So whenever I find this unique byte (pair) in a field of digits, I've got a good digit // regardless of what else is in that digit // I might also get what appears to be a digit in a field of commands or letters or the clock, // but I will later throw them out unless they are immediately following 4 zeroes in a row // Increment g only if a valid digit found { case 127: break; // Maple m - dispense with these in a hurry, there are a lot of them case 126: break; //case 192: break; case 71: good_digit [g++] = 0; // Rick e break; case 96: // original 127 remapped to 11 if cp was 0 if (cp == 192) {good_digit [g++] = 1; }// Rick t break; case 67: good_digit [g++] = 2; // Rick d break; case 62: // original 32 remapped to 5 if cp was 0 if (cp == 127) {good_digit [g++] = 8; }// Rick t if (cp == 126) {good_digit [g++] = 3; } // Rick t // Note: there is a bug where sequence "43" in a valid user ID would register as "413" // since a "4" ends in "192" and the "3" starts with "96" // this looks like a "1" which is defined as a "96" "192" // also "08" since "8" begins with "62" and "0" ends with "127" // which would be "008" // although these bytes are not part of their "unique" byte pairs break; case 19: good_digit [g++] = 4; // Rick d break; case 33: good_digit [g++] = 5; // Rick e break; case 60: good_digit [g++] = 6; // Rick d break; case 1: good_digit [g++] = 7; // Rick d break; case 35: good_digit [g++] = 9; // Rick d break; default: //time = micros() - time; Serial.println (time, DEC); delay(100); // debug break; } // end of switch } // end of getDigit</code></pre> zecritic on "SPI beginSlave doesn't pay attention to Slave Select line" http://forums.leaflabs.com/topic.php?id=1262#post-7583 Thu, 12 Jan 2012 03:00:51 +0000 zecritic 7583@http://forums.leaflabs.com/ I've run into the exact same problem before - the Wirish library uses software select for SPI in both master and slave configurations. From section 25.3.1 of the reference manual: <blockquote> Slave select (NSS) pin management Hardware or software slave select management can be set using the SSM bit in the SPI_CR1 register. ● Software NSS management (SSM = 1) The slave select information is driven internally by the value of the SSI bit in the SPI_CR1 register. The external NSS pin remains free for other application uses. ● Hardware NSS management (SSM = 0) Two configurations are possible depending on the NSS output configuration (SSOE bit in register SPI_CR1). – NSS output enabled (SSM = 0, SSOE = 1) This configuration is used only when the device operates in master mode. The NSS signal is driven low when the master starts the communication and is kept low until the SPI is disabled. – NSS output disabled (SSM = 0, SSOE = 0) This configuration allows multimaster capability for devices operating in master mode. For devices set as slave, the NSS pin acts as a classical NSS input: the slave is selected when NSS is low and deselected when NSS high. </blockquote> This is fine for a master configuration, since you know when you're sending/receiving, but for slave configurations, you would need to setup an interrupt to toggle the <code>SSI</code> bit, which is a hassle (I tried doing that, but I couldn't get it to work). The cleanest solution is to just enable hardware NSS for slave mode, which gives the behavior that I suppose most people would expect, namely that it "just works" without needing to setup an interrupt. This can be done by modifying <code>HardwareSPI::enable_device</code> to only include the <code>SPI_SW_SLAVE</code> flag if it's being configured as a master, which has worked for me. mbolivar on "SPI beginSlave doesn't pay attention to Slave Select line" http://forums.leaflabs.com/topic.php?id=1262#post-7569 Wed, 11 Jan 2012 12:41:34 +0000 mbolivar 7569@http://forums.leaflabs.com/ <blockquote> I can't imagine any other function for this pin in this context so I don't know why spi.beginSlave doesn't handle it. </blockquote> RickRantilla -- good point; that's a bug. Feel like submitting a patch? ;) gbulmer on "SPI beginSlave doesn't pay attention to Slave Select line" http://forums.leaflabs.com/topic.php?id=1262#post-7547 Tue, 10 Jan 2012 18:08:13 +0000 gbulmer 7547@http://forums.leaflabs.com/ RickRantilla - <blockquote>I think there might be a basic problem with the way spi and spi(2) are implemented on the Maple.</blockquote> I think the normal way to access two SPI interfaces is to create two instances (objects) of HardwareSPI: <pre><code>HardwareSPI spiA(1); HardwareSPI spiB(2); void setup() { pinMode(..., OUTPUT); // set up the any selects pinMode(..., OUTPUT); spiA.begin(...); spiB.beginSlave(...); } void loop() { d = spiB.read(); ... spiA.write(...); }</code></pre> bubulindo on "SPI beginSlave doesn't pay attention to Slave Select line" http://forums.leaflabs.com/topic.php?id=1262#post-7546 Tue, 10 Jan 2012 18:02:59 +0000 bubulindo 7546@http://forums.leaflabs.com/ Portuguese actually. bubulindo is freshman years nickname. I know it sounds silly, but there aren't a lot of people using it so I have no problem registering in sites with it. ;) Good that you fixed it. RickRantilla on "SPI beginSlave doesn't pay attention to Slave Select line" http://forums.leaflabs.com/topic.php?id=1262#post-7544 Tue, 10 Jan 2012 16:51:01 +0000 RickRantilla 7544@http://forums.leaflabs.com/ Bubulindo (pretty clown?... are you Brazilian?), thanks. I finally got it working. It seems that even though the identified slave select pin for SPI2 is pin 31, the spi.beginSlave function appears to leave it as an output or undefined. When I assigned pinMode(31,INPUT) it solved the problem. I can't imagine any other function for this pin in this context so I don't know why spi.beginSlave doesn't handle it. gbulmer, thanks. The SerialUSB.print lines were just for debugging, but weren't part of that problem. Once I integrate it back into my full application with servos and everything timing and interrupts might come up again, but that will take a few more days. I think there might be a basic problem with the way spi and spi(2) are implemented on the Maple. Since the functions don't include which SPI port is being used, you would have to constantly switch HardwareSPI spi(1); and HardwareSPI spi(2) before every spi command. Excellent chances of deep bugs there. Anyway it looks like I'm on my way. The Arduino shield doesn't cover the Maple pins 22 to 35 so I have a bunch of rewiring to do. Thanks again gbulmer on "SPI beginSlave doesn't pay attention to Slave Select line" http://forums.leaflabs.com/topic.php?id=1262#post-7540 Mon, 09 Jan 2012 20:25:37 +0000 gbulmer 7540@http://forums.leaflabs.com/ RickRantilla - is it plausible that the SerialUSB.print is having an effect? Each call is potentially blocking, and consume a little bit of interrupt driven processing, which might cause bytes to be lost. Could you do something with lower overhead to test the setup? For example, could you send a known sequence of bytes (e.g. decimal 32 to 96) from the SPI master, and have the SPI slave simply validate that the byte is as expected. It could signal an error by toggling an LED on. A digitalWrite (to turn a LED on) should be *much* faster than those three SerialUSB.print calls. bubulindo on "SPI beginSlave doesn't pay attention to Slave Select line" http://forums.leaflabs.com/topic.php?id=1262#post-7529 Sun, 08 Jan 2012 18:10:45 +0000 bubulindo 7529@http://forums.leaflabs.com/ I had a quick look at the spi.c /.h and HardwareSPI.cpp files and it seems like there isn't any interrupt defined to receive data. That way, the hardware will receive bytes as they come along but I suspect that they'll be overwritten depending on when you read from the SPI. I'm not very used to Maple or ARM environment, I've done most of my stuff in AVR (or Arduino-like), and I've just received my Maple two weeks ago, but it seems like this is what is happening. RickRantilla on "SPI beginSlave doesn't pay attention to Slave Select line" http://forums.leaflabs.com/topic.php?id=1262#post-7528 Sun, 08 Jan 2012 16:48:46 +0000 RickRantilla 7528@http://forums.leaflabs.com/ I was developing a Time and Attendance application using an Arduino as a slave to grab 1500 byte bursts of data at 2.25 megaHz. At that speed the Arduino was marginal and occasionally dropping bytes. I was getting too deep into the code and decided to try to work my way out of it with a faster processor, namely a Maple, which might be several times faster for this application. I ported the code over to Maple and once in a while it worked, but most of the time it didn't work at all. It seems the Maple gets "out of sync" most of the time. I'm to the point in my checking where it seems that the Maple in slave mode SPI simply doesn't pay attention to the slave select line. My Seleae logic analyzer shows good clear data going into the Maple on all the right pins. For testing I'm using an Arduino 2009 as an SPI master to generate data, and have been slowing it down trying to find what is going wrong. For example, this code will usually start off with the input data shifted one or more bits. If it happens to start on the right bit it works ok. <pre><code>// Use SPI port number 2 - which is 5 volt tolerant HardwareSPI spi(2); // Rick a - this spi is on pins 31 - 34 #include <Servo.h> // Once I get this debugged I'll be using servos byte d; // this is the digit I read void setup() { //spi.beginSlave(MSBFIRST, SPI_MODE_2); // use this for T&A Master spi.beginSlave(MSBFIRST, SPI_MODE_0); // use this for Arduino Master } // end setup void loop() { d = spi.read(); // get something on MOSI SerialUSB.print(d,BIN); SerialUSB.print(" ");SerialUSB.println(d); // debug } // end loop</code></pre> I can't find anything in the HardwareSPI docs that shows how to manipulate the spi.beginSlave function, other that Most Significant Bit and clock sync. I'm using HardwareSPI 2 so I don't have to worry about the Maple being 3.3 volts. The Slave Select pin in SPI-2 is pin 31 and I've even tried just removing the wire from pin 31 and the behaviour is unchanged, that is, the Maple still reads data but starting at whatever bit it feels like.