You are reading a single comment by @Robin and its replies. Click here to read the full conversation.
  • Actually a remote control for a rc car, a Willy's MB (JJRC Q65). The original has 5 different light modes and a complex switch to control them. I'll to use Neopixels instead of LEDs to simulate the light modes, and could also simulate a broken light. I tested it already with a led strip, but finally I want to switch to SK6805-2427. This, however requires a pcb and reflow or hot air soldering, as these LEDs have tiny contacts.
    An ESP8266 with a web server will become the receiver, to control servos, ESC and neopixels. The car (driving and lights) will be controlled over wifi with a mobile phone as controller. Finally I'll build a PCB with the ESP8266 12-F with logical level converters to 5V (needed for neopixels), but without USB port (to make it small).

  • Mon 2019.08.12

    title    'neopixel crashing the the board?'

    Just had time to take a peek at this. Puzzled by the title. Is it accurate that connecting the Neopixels are causing the board to crash as is indicated, or is it speculation that the suggestion there is an overflow of that register, that might, and I add might, cause an issue with timing?



    An observation here. Many of us have used Neopixels successfully for around ~five years, and over the last two years since my introduction to the world of Espruino and observing forum posts, this would be an absolute first, if this were truly 'crashing' your board as you put it.


    If one takes a look at the function _getCycleCount() just the contents of that register are being returned.

    L197    asm volatile("rsr %0,ccount":"=a" (ccount));

    While I didn't create this, nor do I completely understand how the register is used elsewhere in the source, it doesn't even appear that it would be an issue. My guess is the original author is resetting that register prior to data output to the pin. I'll S.W.A.G. it and guess in the SPI write mechanism.



    Using this case:

    L210  uint8_t tOne = 90; // one bit, high typ 800ns

    The value of 't' is equal to 90 and has an equivalent duration of ~0.8msec

    L247   while (_getCycleCount()-start < t) ; // busy-wait

    Assigning a value to start, then immediately taking another reading will make the result of that comparison extremely small. Then we wait in the loop counting up towards 90 the 800nsec equivalent. Clocking at the speeds indicated, even if there were overflow (my guess what is being referred to, ref. max value), the interval to wait for that condition to clear won't even be perceptibly noticed. We are looking at an interval of one in one thousand! In fact, being close to an overflow condition should only add an additional loop or two, as when the overflow occurs, the equation approximately a ~zero count is evaluated and this is also less than the 90 or 800nsec comparison value. Hardly noticeable. Comment at L222 explains why the bits need to initially be set to zero. I don't see an issue.


    Have you looked at the bits being clocked out with a logic analyzer?

About

Avatar for Robin @Robin started