4253 A place to share, learn, and grow... en-US Fri, 22 Jan 2016 00:21:06 +0000 http://bbpress.org/?v=1.0.2 q http://forums.leaflabs.com/search.php http://forums.leaflabs.com/topic.php?id=1271#post-7915 Fri, 27 Jan 2012 10:27:53 +0000 samtal 7915@http://forums.leaflabs.com/ <p>RickRantilla</p> <p>Don't you feel you are left there alone with your pain. It is shared by many.<br /> The USB probalem you describe has been reported many times in the past, with no real cure from LeafLabs (except blaiming it on Windows, when I guess 90% of us use Winodws XP).<br /> I have several Maples r5, and occasunaly I struggle with it up to a level that I just want to give up the Maple, and use a proffesional development board.<br /> My problem is that I work remotely on the board, thus I can not press the reset.<br /> My solution is as follows:<br /> I use a SiLabs USB to serial board to convert from the 5V usb to the 3.3 V Maple.<br /> (I also have one Prolific USB to UART, and others use FTD or similar).<br /> That board has a RTS pin, which I connect to the Maple reset pin.<br /> Each time I upload program to the board, I close the port, and re-open it as soon as I see that the IDE starts to search for the DFU.<br /> This generates a pulse that resets the board and help loading the program.<br /> The drawback is that each time I open the port, the board will reset, but I can live with that.<br /> One more thing you should try -<br /> In the IDE 'File', 'Preferences' change (extend) the 'Delay after reset' parameter. This will give you larger time latitude in the reset.<br /> Good luck<br /> samtal </p> http://forums.leaflabs.com/topic.php?id=1262#post-7790 Thu, 19 Jan 2012 01:12:18 +0000 zecritic 7790@http://forums.leaflabs.com/ <p>Hi Rick,<br /> 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?</p> <p>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).</p> <p>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? </p> http://forums.leaflabs.com/topic.php?id=1271#post-7745 Tue, 17 Jan 2012 18:02:47 +0000 cyberia 7745@http://forums.leaflabs.com/ <p><a href="http://forums.leaflabs.com/topic.php?id=73" rel="nofollow">http://forums.leaflabs.com/topic.php?id=73</a></p> <p>this fixes windows 7 driver signing so that you can use maple on your better computer</p> <p>that may help </p> http://forums.leaflabs.com/topic.php?id=1271#post-7737 Tue, 17 Jan 2012 17:00:52 +0000 poslathian 7737@http://forums.leaflabs.com/ <p>Rick, we definitely feel your pain on the windows front. Using a single MCU to be both the processor you are programming as well as the programming interface turned out to be a very tricky setup, and while we have been able to smooth things over quite a bit in Mac and linux, Windows has always really really hated all the switching back and forth between "programming" mode and "serial port" mode. Not to mention all the naming issues and that crap. What is really needed is a custom windows driver to behave the right way and handle both the serial port and DFU modes in one driver. In our future products we are switching to a two-chip setup, where the programming interface chip is independent and always on, one permanent serial port. </p> <p>However, should definitely be able to power and program at the same time. Just switch the jumper to EXT power (or BAT) and plug in the USB anyway. </p> http://forums.leaflabs.com/topic.php?id=1262#post-7709 Tue, 17 Jan 2012 03:47:40 +0000 RickRantilla 7709@http://forums.leaflabs.com/ <p>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). </p> <p>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.</p> <p>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.</p> <p>Thanks in advance...</p> <pre><code>// Written by Rick Rantilla - January 2012 // with help from Nick Gammon char sketch[] = &quot;Maple_SPI_jan17q &quot;; // 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&#39;t need them // Hooked up to T&amp;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&#39;s find it&#39;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&#39;t working. Let&#39;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&amp;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 &lt;Servo.h&gt; // 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&#39;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&amp;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]&gt;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) &amp;&amp; (good_digit[g-6]==0) &amp;&amp; (good_digit[g-5]==0)) { // a valid userID starts with 4 zeroes - print the 4 least significant digits // don&#39;t care how long this takes, I won&#39;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(&quot;User ID = &quot;); 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&#39;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&#39;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 &quot;43&quot; in a valid user ID would register as &quot;413&quot; // since a &quot;4&quot; ends in &quot;192&quot; and the &quot;3&quot; starts with &quot;96&quot; // this looks like a &quot;1&quot; which is defined as a &quot;96&quot; &quot;192&quot; // also &quot;08&quot; since &quot;8&quot; begins with &quot;62&quot; and &quot;0&quot; ends with &quot;127&quot; // which would be &quot;008&quot; // although these bytes are not part of their &quot;unique&quot; 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> http://forums.leaflabs.com/topic.php?id=1271#post-7707 Tue, 17 Jan 2012 02:27:04 +0000 RickRantilla 7707@http://forums.leaflabs.com/ <p>Thanks, Larry. I'm using an old Dell portable with XP because I never could get the IDE running on my Windows 7 machines.</p> <p>A different limitation (defect) seems to have turned into a feature for me. It appears you can't power the Maple from an external power supply and program it at the same time. So I hooked up a switch to the jumpers for USB vs. External power. I can now flip this external switch at just the right time while I'm compiling and uploading a revised program and somehow Windows XP "usually" hooks up both com ports. On to the next problem... </p> http://forums.leaflabs.com/topic.php?id=1271#post-7636 Sat, 14 Jan 2012 00:22:06 +0000 LarryP 7636@http://forums.leaflabs.com/ <p>@RickRantilla, </p> <p>First off, I feel your pain -- and it shouldn't have to be so !@#$%^ hard! </p> <p>If memory serves, one of MicroSoft Windows "features" is that it's pretty *stupid* about USB devices, and give even less in terms of decode-able error messages. One manifestation of M$ USB "features" is that the same device (e.g. Maple + cable) is recognized differently, DEPENDING ON WHICH USB CONNECTOR ON THE WINDOWS HOST IT IS PLUGGED INTO. So, if you get it working again (good luck; honestly, that's what it takes), note exactly which physical connector you have the cable plugged into on your PC and *ALWAYS* use that same USB connector, whenever you work on your Maple board. (And if at all possible, don't use that connector for anything else.) This may not solve all of the problems (remember, we're talking about M$ here), but it may help to get M$'s excuse for operating systems to work more nearly sanely. </p> <p>My fingers are crossed for you! except when I'm typing ;-) </p> http://forums.leaflabs.com/topic.php?id=1271#post-7590 Thu, 12 Jan 2012 08:42:50 +0000 RickRantilla 7590@http://forums.leaflabs.com/ <p>Arrghhhh! I'm using IDE 0.0.12 on a Windows XP system connected via USB to a rev 5 Maple. The interface seems to change from day to day.</p> <p>I always select under "tools" "board" to "Flash" and "serial Port" "com3". The first few days I'd just hit "upload" and the program would upload as expected. When I press "Serial Monitor" I'd get a window on "com10" that would receive data from my application, as, for example in the "hello world" stub. If I went to "tools" "serial port" there would typically be this new port, com10, listed and checked.</p> <p>Then I started getting "Couldn't find the DFU device: [lEAF:0003]" error, so I would use the "reset" while uploading. This required hitting reset at the right time so I also use the "Perpetual bootloader" scheme (pressing reset and the "but" button on the board). This got more awkward as I installed the Maple board inside my device.</p> <p>Now I no longer get the second com10 port after a successful upload, so I can't see what my application is doing anymore. </p> <p>I just reloaded "hello world" and can't get any feedback (no com10). I also changed it to include "blink" (so I'm sure my new program is there). The only serial port is com3 and it doesn't work as a monitor.</p> <p>Any suggestions?<br /> thanks in advance... </p> http://forums.leaflabs.com/topic.php?id=1262#post-7583 Thu, 12 Jan 2012 03:00:51 +0000 zecritic 7583@http://forums.leaflabs.com/ <p>I've run into the exact same problem before - the Wirish library uses software select for SPI in both master and slave configurations.</p> <p>From section 25.3.1 of the reference manual:</p> <blockquote><p> Slave select (NSS) pin management<br /> Hardware or software slave select management can be set using the SSM bit in the<br /> SPI_CR1 register.<br /> ● Software NSS management (SSM = 1)<br /> The slave select information is driven internally by the value of the SSI bit in the<br /> SPI_CR1 register. The external NSS pin remains free for other application uses.<br /> ● Hardware NSS management (SSM = 0)<br /> Two configurations are possible depending on the NSS output configuration (SSOE bit<br /> in register SPI_CR1).<br /> – NSS output enabled (SSM = 0, SSOE = 1)<br /> This configuration is used only when the device operates in master mode. The<br /> NSS signal is driven low when the master starts the communication and is kept<br /> low until the SPI is disabled.<br /> – NSS output disabled (SSM = 0, SSOE = 0)<br /> This configuration allows multimaster capability for devices operating in master<br /> mode. For devices set as slave, the NSS pin acts as a classical NSS input: the<br /> slave is selected when NSS is low and deselected when NSS high. </p></blockquote> <p>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).</p> <p>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.</p> <p>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. </p> 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><p> 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. </p></blockquote> <p>RickRantilla -- good point; that's a bug. Feel like submitting a patch? ;) </p> http://forums.leaflabs.com/topic.php?id=1262#post-7547 Tue, 10 Jan 2012 18:08:13 +0000 gbulmer 7547@http://forums.leaflabs.com/ <p>RickRantilla -<br /> <blockquote>I think there might be a basic problem with the way spi and spi(2) are implemented on the Maple.</p></blockquote> <p> I think the normal way to access two SPI interfaces is to create two instances (objects) of HardwareSPI:</p> <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> http://forums.leaflabs.com/topic.php?id=1262#post-7546 Tue, 10 Jan 2012 18:02:59 +0000 bubulindo 7546@http://forums.leaflabs.com/ <p>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. ;) </p> <p>Good that you fixed it. </p> http://forums.leaflabs.com/topic.php?id=1262#post-7544 Tue, 10 Jan 2012 16:51:01 +0000 RickRantilla 7544@http://forums.leaflabs.com/ <p>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.</p> <p>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.</p> <p>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.</p> <p>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.</p> <p>Thanks again </p> http://forums.leaflabs.com/topic.php?id=1262#post-7540 Mon, 09 Jan 2012 20:25:37 +0000 gbulmer 7540@http://forums.leaflabs.com/ <p>RickRantilla - is it plausible that the SerialUSB.print is having an effect?<br /> Each call is potentially blocking, and consume a little bit of interrupt driven processing, which might cause bytes to be lost.</p> <p>Could you do something with lower overhead to test the setup?<br /> 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. </p> http://forums.leaflabs.com/topic.php?id=1262#post-7529 Sun, 08 Jan 2012 18:10:45 +0000 bubulindo 7529@http://forums.leaflabs.com/ <p>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. </p> <p>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. </p>