Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

mega1284 issues #121

Closed
focalintent opened this issue Jan 15, 2015 · 17 comments

Comments

Projects
None yet
3 participants
@focalintent
Copy link
Member

commented Jan 15, 2015

From @jar10623:

i have a Problem with fastLED since i changed from Arduino nanoV3 (all OK) to
https://github.com/JChristensen/mini1284

i build two to test but this is only a Problem with fastLED!

with https://github.com/cpldcpu/light_ws2812 is no problem, Timing ist well

see the Data Timing with m1284p & fastLED
m1284p_timing

with 33µs (m1284p) für one LED the ws2812b dosn't work, the 30µs is from m328p

focalintent added a commit that referenced this issue Jan 15, 2015

Attempt at a fix for #121 - base the cycle for a pin on the port that…
… the pin is attached to, vs. the arbitrary pin numbers used by arduino.
@focalintent

This comment has been minimized.

Copy link
Member Author

commented Jan 15, 2015

I don't have an mega1284p here to test with, but I just did some tweaks to better deal with the different i/o timings that m1284p and put them on the FastLED3.1 branch, so you should grab that and try it out and let me know if that helps at all.

@focalintent

This comment has been minimized.

Copy link
Member Author

commented Jan 16, 2015

Re: the comments by @jar10623 on b4bbd5c#commitcomment-9311582 -

There have been a large number of changes, are you using the FastLED3.1 branch or did you just apply the patch for that change? As I mentioned in the ticket, this is on the FastLED3.1 branch which has a lot of other changes, you should be using that branch for this testing.

In the meantime, without having any m1284p based hardware to test with there isn't a whole lot else I can do at the moment, I'd need a dev environment to get into more accurate timings for individual instructions as well as what the compiler is doing with my assembler. Also - please keep conversation about this on the page for issue #121 - #121 it's better to have all this tracked in one place rather than in comments spread across commits and issues.

If you have a pointer for where I can buy a working dev board to work with I can look into getting one to do more direct debugging with this.

@focalintent focalintent added the MCUs label Jan 16, 2015

@focalintent

This comment has been minimized.

Copy link
Member Author

commented Jan 16, 2015

but where is your problem to look at the bitbang code from tim cpldcpu
https://github.com/cpldcpu/light_ws2812 it works perfekt with m328p and m1284p

That code is not useful for what FastLED does. FastLED does a lot more when writing data out than just the bit banging, it is also performing color and brightness correction as well as doing dithering. As a result, there's a lot more going on between the pin toggles than just nop's, and as such, things are a bit trickier when the CPU is changed from m328p and m1284p.

a arduino working device based on m1284p?
there are many in the internet and with use breadboard too

I have nearly a half dozen boards here with different CPUs and environments to work on support for - I don't have time to breadboard up a system to do one shot testing - and of all the links you supplied, only one is to an actual board that I can buy, and that's $50 once shipping is included. (I have a full time job, a contract job that eats up much of the rest of my time, and a backlog of work on the library for a variety of widely available boards/systems out there, so at the moment I'm mostly only putting time into finished hardware that I can get cheaply/easily or that someone gives me).

i have buy 6 pcb from osh park an build it by my own

If you are willing to send me a board for a short amount of time so that I can do the testing and debugging here with real hardware, I can then send it back to you once I'm finished with it.

Again, please - keep discussion about the 1284P on this page.

@jar10623

This comment has been minimized.

Copy link

commented Jan 16, 2015

FastLED does a lot more when writing data out than just the bit banging, it is also performing color and brightness correction as well as doing dithering.

yes i believe, but there must be one point to send out the new builded DATA to the LED, there it is,
i can not understand why some can hold the timing for a m1284p perfekt by send out, thats only bitbanging!

if i can understand cpp i would change the send out for the m1284p

If you are willing to send me a board for a short amount of time so that I can do the testing and debugging here with real hardware, I can then send it back to you once I'm finished with it.

i must think, my time is small too and i must build a new one time&money and without your address i'm unable to send you one

CPLD

That code is not useful for what FastLED does.

can you explain why send data to ws2812b in 2 LIB must be different?
if i look at the datasheet from ws2812b there ist only the DATA Pin toggeling in the right way for a 0 and a 1.
Before send the Data must be prepaired in a Data Array and send out, for my understanding it is not a big problem to change the outsending bitbang with a define wich AVR is use

@jar10623

This comment has been minimized.

Copy link

commented Jan 16, 2015

so i fixed it:

#if defined(AVR_ATmega1284P)
#undef F_CPU
#define F_CPU 14400000
#endif

works ..............

if Timing is 10 percent to slow for a m1284p, i made it faster :-)

@jar10623

This comment has been minimized.

Copy link

commented Jan 17, 2015

this ist only a temporary FIX, i hope for a real FIX in FastLED

@focalintent

This comment has been minimized.

Copy link
Member Author

commented Jan 18, 2015

yes i believe, but there must be one point to send out the new builded DATA to the LED, there it is,
i can not understand why some can hold the timing for a m1284p perfekt by send out, thats only
bitbanging!

Once again, it is because in FastLED it is not just bitbanging. Interleaved between the setting of the pins high and low is a lot of hand cycle counted assembly code to work in the brightness scaling and dithering support.

if i can understand cpp i would change the send out for the m1284p

Understanding cpp won't be enough - as all that code is written directly in AVR assembler.

i must think, my time is small too and i must build a new one time&money and without your address i'm > unable to send you one

If you're willing to send me one - email me at danielgarcia at gmail dot com so that I can send you my shipping address. I understand that your time is small, however, when it comes to my time on this library you are not the only person asking for support, and the atmega1284p is not the only platform I need to add support for. You are, however, only the second person who has asked me for atmega1284p support while I have dozens, if not more, waiting on RFDuino and SparkCore support.

As it is, the time that I have spent attempting a fix and reading through the atmega1284p datasheet to try and find obvious differences is time that has been taken away from other work that I need to do.

Add to that the fact that the atmega1284p is unlikely to ever be a chip that I use in my own personal projects I'm wary of spending money and time on hardware for what will basically be a one time bug fix.

can you explain why send data to ws2812b in 2 LIB must be different?
if i look at the datasheet from ws2812b there ist only the DATA Pin toggeling in the right way for a 0 and a 1.
Before send the Data must be prepaired in a Data Array and send out, for my understanding it is not a
big problem to change the outsending bitbang with a define wich AVR is use

See my explanation above in this comment. Once again, FastLED does a lot more when writing out the led data than just the bit banging. The interleaved code is complex, and very carefully timed based on the instruction timing of the atmega328p/atmega32u4/atmega2560. If something is coming out differently on the atmega1284p it is because of a difference in timing/instruction that I haven't been able to find just from reading the data sheet. To track down what that is and account for it correctly and in a way that doesn't break the code for the far more frequently used atmega328p/32u4 I need hardware to test and do timing with for a real fix.

@jar10623

This comment has been minimized.

Copy link

commented Jan 18, 2015

I need hardware to test and do timing with for a real fix.

ok that i do understand with my low english,

if i find out to biuld a test m1284p arduino i send you one, but now, it is easyer for me to use my FIX
#if defined(AVR_ATmega1284P)
#undef F_CPU
#define F_CPU 14400000
#endif

the only things i must do now is to correct my F_CPU based +10% or + 1600000 wenn i use the m1284p with my FIX

thank you

@jar10623

This comment has been minimized.

Copy link

commented Jan 24, 2015

i subscribe this thread, please would you be so kindly to replay here if you fixed the fastLED LIB in this case?

thanks a lot.....

@focalintent focalintent added this to the Future backlog milestone Feb 17, 2015

@focalintent

This comment has been minimized.

Copy link
Member Author

commented Apr 5, 2015

Closing this thread as I am not going to be doing any more AVR platform work for more platforms beyond the 32u4, mega328p, and mega 2560.

@focalintent focalintent closed this Apr 5, 2015

@aphelps

This comment has been minimized.

Copy link
Contributor

commented Oct 15, 2015

@jar10623 Did you ever get this working with the WS2812s?

I've been working on some atmega1284p based boards as an upgrade for an atmega328p project I have using FastLED to run a WS2801 based LEDs. I've verified the hardware works using Adafruit's 2801 library, but haven't been able to get it to work with FastLED. @focalintent I'm also willing to try out making what changes would be necessary to get FastLED working on my environment if you have some pointers on where to start looking in the FastLED code.

@focalintent

This comment has been minimized.

Copy link
Member Author

commented Oct 15, 2015

You'd have to throw a scope on the output of the library to see how the timing for the WS2812 is off compared to what it should be, and what changes would need to be made depend on what happens there. The asm code for WS2812 output is in platforms/avr/clockless_trinket.h

@jar10623

This comment has been minimized.

Copy link

commented Oct 15, 2015

@jar10623 Did you ever get this working with the WS2812s?

i don't use the WS2812s but i don't know because i order Stripes and i do not know what ist used.

I use a old version off fastLED maybe v2 with Arduino arduino-1.0.5-r2-windows not v3/3,1 that dosn't work (i try Arduino 1,65 too)

My last change in delay.h was:

// Some timing related macros/definitions

// Macro to convert from nano-seconds to clocks and clocks to nano-seconds

// 14400000
// #define NS(_NS) (_NS / (1000 / (F_CPU / 1000000L)))
#if F_CPU < 96000000
#if defined(AVR_ATmega1284P)
#define NS(_NS) ( (_NS * ( (F_CPU_9L/10L) / 1000000L))) / 1000
#define CLKS_TO_MICROS(_CLKS) ((long)(_CLKS)) / ((F_CPU_9L/10L) / 1000000L)
#else
#define NS(_NS) ( (_NS * (F_CPU / 1000000L))) / 1000
#define CLKS_TO_MICROS(_CLKS) ((long)(_CLKS)) / (F_CPU / 1000000L)
#endif
#else
#define NS(_NS) ( (_NS * (F_CPU / 2000000L))) / 1000
#define CLKS_TO_MICROS(_CLKS) ((long)(_CLKS)) / (F_CPU / 2000000L)
#endif

// Macro for making sure there's enough time available

@aphelps

This comment has been minimized.

Copy link
Contributor

commented Nov 9, 2015

Sorry, I failed to set notifications on here and only got back to this project this week.

I'm actually working with older/cheaper WS2801 LEDs, which I don't think should have the same timing issues as the WS2812's. Any pointers on what might be preventing those from working?

@focalintent

This comment has been minimized.

Copy link
Member Author

commented Nov 9, 2015

@aphelps what pins are you trying this on? Do you know if it is using the hardware SPI pins or if you are using software SPI? Also - since this ticket is primarily about the 1284 and 2812's, if you're still having issues, open up a new ticket to track things with the ws2801.

@aphelps

This comment has been minimized.

Copy link
Contributor

commented Nov 18, 2015

@focalintent Thanks for the response, looks like I was running using software SPI, so perhaps the problem is with that not properly supporting the 1284 (I know the SoftwareSerial library doesn't support it properly so I wouldn't be surprised if the SPI one didn't either). I'm going to go back to the drawing board and put together a test setup using the the hardware SPI. If that doesn't work out I'll open a new ticket for this specific issue.

@aphelps

This comment has been minimized.

Copy link
Contributor

commented Nov 19, 2015

FYI, I think I've fixed the problems I was having with this PR: #227

I also tested with a strip of WS2812B's and those appear to work fine now as well (@jar10623)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.