Your new topic does not fit any of the above??? Check first. Then post here. Thanks.

Moderator: igrr

User avatar
By andrew melvin
#16590 I'm not sure I understand your second bit? Are you saying that the do while causes a block in operations until it is time to update based on clock count?

The implementation I have just uses timers, so every x mills the strip is updated, which means i don't have any flickering, its pretty smooth actually. I can actually run it whilst having two instances of the PID lib, the MQTT lib, web server lib... and it still worked just fine. I got MQTT to publish the number of iterations though my loop... per second, and it was >10,000 with all that.
User avatar
By Makuna
#16591 I was simply asking why did you put a "do while" around the asm in the define

Code: Select all#define STORE_CYCLES(r) do { \
  __asm__ __volatile__("rsr %0, CCOUNT \n\t" : "=a" (r)); \
} while (0);


could just be...

Code: Select all#define STORE_CYCLES(r)  __asm__ __volatile__("rsr %0, CCOUNT " : "=a" (r))
User avatar
By Jason Stapels
#16613
Makuna wrote:Two things...
1) have you tried this while WiFi is active and you are "animating" the strip? This seems to be where things break down for me.

I did a quick test and found that the first LED does go wonky sometimes when the WiFi is running. I wonder if this is a voltage issue more than anything, I'll have to hook up the level-shifter again and try it with that.

Makuna wrote:2) In the code I quoted, why the "do while" around the asm?

That's just a habit from when I want to do multiple commands in a macro. As you noted it's not necessary and will be compiled out obviously.
User avatar
By Makuna
#16645 MORE PROGRESS!

I was suspecting interrupts were the issue, and I spotted evidence in that my usbasp light would flicker at the same time I would see anomalies in the pixels being displayed.

The interrupt system on this chip is more advanced that AVRs, and it looks like the Arduino IDE implementation for noInterrupts, Interrupts just calls in a ROM method that I suspect just disables all level 0 interrupts leaving the level 14 (a lot of the WiFi stuff) alone. I dug in and found a way to disable even these. I DO NOT RECOMMEND DOING THIS FOR A LONG STRIP OF LIGHTS.

But it has cleaned up most of the glitches (except a few just shortly after startup).

GitHub Makuna/NeoPixelBus

Code: Select all// Read Set Interrupt Level
#define RSIL(r)  __asm__ __volatile__("rsil %0,15 ; esync":"=a" (r))
// Write Register Processor State
#define WSR_PS(w)  __asm__ __volatile__("wsr %0,ps ; esync"::"a" (w): "memory")


static inline uint32_t esp8266_enter_critical()
{
    uint32_t state;
    RSIL(state);
    return state;
}

static inline void esp8266_leave_critical(uint32_t state)
{
    WSR_PS(state);
}


then just wrap your code like...

Code: Select all    uint32_t state = esp8266_enter_critical();
// time critical code
    esp8266_leave_critical(state);