Crash with < 14 LEDs (CDEVICES value) prevents small numbers of LEDs from working #1
Comments
|
No help here except to commiserate- I also ran into that problem for the On Sunday, November 23, 2014, Brian Schmalz notifications@github.com
-Larissa |
|
Dang… this is why I sometime hate contributed code that is done on a weekend; then you have to support it L When I get a chance I will take a look and try to see what the deal is. Off of the top of my head… I don’t know why 14 would have any significates. KeithV From: Brian Schmalz [mailto:notifications@github.com] It turns out that if you have CDEVICES set less than 14 then updateLEDs() will never return true. To test this out, take LBling example and set CDEVICES to 13 (and comment out an appropriate number of initializes in rgGRB[]) and run. No LED data will be output and the state will be stuck in LOADPAT forever. Interestingly this is not as simple as it seams. You CAN use CDEVICES < 14, but the cDevices parameter to the begin() call must be less than the cbPatternBuffer parameter (not equal, as they normally are). Why 14 is the magic number where these things can be equal, I have no idea. For example, if CDEVICES = 4, I have tried parsing the code to figure out why this happens, but I haven't figure out exactly how the DMA an pattern buffers work yet, so I can't see the forest for the trees at this point. *Brian — |
|
KeithV-- chipKIT needed WS2812 libraries-- ESP for christmas! It's a weird glitch I would be interested to find out what is causing it, On Sun, Nov 23, 2014 at 7:49 PM, KeithV notifications@github.com wrote:
-Larissa |
|
It should just work…. I will look at it. KeithV From: Larissa Swanland [mailto:notifications@github.com] KeithV-- chipKIT needed WS2812 libraries-- ESP for christmas! It's a weird glitch I would be interested to find out what is causing it, On Sun, Nov 23, 2014 at 7:49 PM, KeithV notifications@github.com wrote:
-Larissa — |
|
I tried this on both a WF32 and MAX32 exactly as Brian suggests and down to CDEVICES == 3 and it just works for me. I do not have an SD, so I couldn't check that. |
|
Keith, Drat. That may mean that it's something about the MX250's DMA that's Can you confirm that the latest files in Gihub are the versions that you *Brian On Wed, Nov 26, 2014 at 4:25 PM, KeithV notifications@github.com wrote:
|
|
Hi Brian, I actually downloaded the .zip file from github, it works fine for the WF32 and MAX32 KeithV From: Brian Schmalz [mailto:notifications@github.com] Keith, Drat. That may mean that it's something about the MX250's DMA that's Can you confirm that the latest files in Gihub are the versions that you *Brian On Wed, Nov 26, 2014 at 4:25 PM, KeithV notifications@github.com wrote:
— |
|
Keith, good thinking! OK, I'll try it on some of my other boards and see if *Brian On Wed, Nov 26, 2014 at 9:44 PM, KeithV notifications@github.com wrote:
|
|
Well I found one problem with the GitHub version….. The blinking LED in the loop is on LED1, that is a bad LED to use as that is PIN 13 which is also the SCK for the SPI… do not use LED1 on any UNO form factor board as that will hose up SCK. This will not affect the MAX32, but will the WF32 and may affect the SD, don’t know. But… I think Rick changed this to LED1. KeithV From: Brian Schmalz [mailto:notifications@github.com] Keith, good thinking! OK, I'll try it on some of my other boards and see if *Brian On Wed, Nov 26, 2014 at 9:44 PM, KeithV notifications@github.com wrote:
— |
|
Sorry Brian, The only SDs I have here are you MX4 variations. So I can’t try and debug what is wrong with the 1.5 SD; as the spi controller is not fully supported on the MX4. Ah, I noticed really high PIN numbers for the SPI in the variant file….??? KeithV From: Brian Schmalz [mailto:notifications@github.com] Keith, good thinking! OK, I'll try it on some of my other boards and see if *Brian On Wed, Nov 26, 2014 at 9:44 PM, KeithV notifications@github.com wrote:
— |
|
Brian, Oddly enough though… I do have one of your SDMZ, not sure how I got that… you must have sent me one. From: Brian Schmalz [mailto:notifications@github.com] Keith, good thinking! OK, I'll try it on some of my other boards and see if *Brian On Wed, Nov 26, 2014 at 9:44 PM, KeithV notifications@github.com wrote:
— |
|
Like I said, it looks like Rick put everything to LED1 and that will create a conflict with SCK on Uno style type form factor boards like the WF32. From: Brian Schmalz [mailto:notifications@github.com] Keith, Drat. That may mean that it's something about the MX250's DMA that's Can you confirm that the latest files in Gihub are the versions that you *Brian On Wed, Nov 26, 2014 at 4:25 PM, KeithV notifications@github.com wrote:
— |
|
Hi Brian, I fixed up the project to work with the Mini (dev) and got it to work with CDEVICES == 13. However I did NOT do any mapping of the SPI pins, so I am just running the controller without mapping anything out to the pins. But I do get past LOADPAT. I had to fix up the DMA controller priority… I bet you just commented out the priority level for the MX250 and thus the DMA had zero priority and never ran. Not sure how it would work for more than 14 devices though. Anyway look at the attached project… but remember you must add pps mappings to the SPI, and make sure the LED does not conflict (I just removed the LED). I used the latest build of MPIDE. Good Luck KeithV From: Brian Schmalz [mailto:notifications@github.com] Keith, Drat. That may mean that it's something about the MX250's DMA that's Can you confirm that the latest files in Gihub are the versions that you *Brian On Wed, Nov 26, 2014 at 4:25 PM, KeithV notifications@github.com wrote:
— |
|
Keith, Thanks, I'll take a look at the changes you made. Important note: all of my work was done on a Fubarino Mini, not a Fubarino I'll let you know what I find- *Brian On Thu, Nov 27, 2014 at 12:28 AM, KeithV notifications@github.com wrote:
|
|
Thanks Brian, I saw in the GitHub version that Rick put the Furburino SD in there and it did not compile for me because the MX4 does not support the SPI features, so I assumed Rick put it in there for the MX7 version. Then I read your mail and realized it was the MX250 you had the problems with; so I got an old dev Mini, but I didn’t want to fool with the 50MHz bootloader, so I just checked it out at 40MHz. I don’t think that will make a difference…. But who knows? Hope you had a great Thanksgiving! Keith From: Brian Schmalz [mailto:notifications@github.com] Keith, Thanks, I'll take a look at the changes you made. Important note: all of my work was done on a Fubarino Mini, not a Fubarino I'll let you know what I find- *Brian On Thu, Nov 27, 2014 at 12:28 AM, KeithV notifications@github.com wrote:
— |
|
Happy Thanks Giving. Just trying to catch up to this. I think I just added stuff so it would -_Rick On Fri, Nov 28, 2014 at 1:21 AM, KeithV notifications@github.com wrote:
Co-founder |
It turns out that if you have CDEVICES set less than 14 then updateLEDs() will never return true.
To test this out, take LBling example and set CDEVICES to 13 (and comment out an appropriate number of initializes in rgGRB[]) and run. No LED data will be output and the state will be stuck in LOADPAT forever.
Interestingly this is not as simple as it seams. You CAN use CDEVICES < 14, but the cDevices parameter to the begin() call must be less than the cbPatternBuffer parameter (not equal, as they normally are). Why 14 is the magic number where these things can be equal, I have no idea.
For example, if CDEVICES = 4,
ws2812.begin(3, rgbPatternBuffer, sizeof(rgbPatternBuffer), false)
will work but
ws2812.begin(4, rgbPatternBuffer, sizeof(rgbPatternBuffer), false)
will not work.
I have tried parsing the code to figure out why this happens, but I haven't figure out exactly how the DMA an pattern buffers work yet, so I can't see the forest for the trees at this point.
*Brian
The text was updated successfully, but these errors were encountered: