No announcement yet.

NeoPixel possible?

  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    I see the comment about disabling the serial interrupt ("Comms Interrupts should also be disabled by the user, otherwise errors may occur."), but I'm unclear what you mean. If I need to call com_Reset then I'll have to synchronize the NP_Write calls with com_Empty() avoid losing serial data? I see a com_TXbufferHold, but nothing similar for holding off the RX interrupts.


    • #17
      The errors that will occur are on the NeoPixel side of things as a comms interrupt will change the timing of the NP write.

      The only way to stop serial comms interrupts, once started, is to use com_Reset. com_Empty() really has nothing to do with it, it's a new character coming in during the NP_Write that will cause the issue.

      Sorry, that may or not be helpful, since I don't know exactly how your system works I can't tell.

      I sort of assume you have a way to stop comms during an NP_Write, either by not seding anything to it at the time, or by com_Reset, or using some handshaking technique.

      If that's too hard maybe check com_Count() before and after the NP_Write and, if it changes, redo the NP_Write command?

      I'm reluctant to disable comms interrupts during NP_Write as, for a large NP array this may cause lost data.


      • #18
        I mentioned com_Empty because I'm uncertain what happens when I call com_Reset with pending data in the internal buffer. I assume there's no reliable way to recover such lost bytes and no way to call com_Init such that it would, afterwards, provide said bytes. Given that, I can't really call com_Reset until com_Empty return false without losing buffered data. On top of that there's always a little time between checking com_Empty and calling com_Reset that an interrupt could sneak into buffering new data.

        No chance of getting a com_IntHold(ON/OFF), or something similar, for solving this? I'm guessing your UART has a small 16 or 64 byte hardware buffer that could be buffering data while interrupts were disabled. This would let the implementor decide whether disabling interrupts was required/warranted or not.

        In my case retrying the write command would work (especially since I'm likely to be animating the lights) so long as the errors are rare. Any guidance on how to estimate the call time on NP_Write? Comparing that with my com character times should give me a way to estimate the frequency of collisions.


        • #19
          I'm reluctant to even think about com_IntHold(ON/OFF) as it could easily cause more problems that it could solve.

          I need to do some measurements on write times to do some calculations.

          Regardless the 'retry until com_Count() doesn't change' should be easy to implement and also foolproof. You could have a loop counter that increments and thus know the actual collisions that have occurred.


          • ESPsupport
            ESPsupport commented
            Editing a comment
            An 8 neopixel write takes about 0.247ms, 62 takes 1.95ms.

            The Retry code is really the best solution

        • #20
          I'll email you a new PmmC. Even though it appears to work for PA0-3 it's not quite right.


          • #21
            By the way, slow as we're going we are making some progress towards integrating these panels with the lights. Here's some pictures of the first prototype with the first pass at a bezel.
            Click image for larger version

Name:	20150108_180248.jpg
Views:	58
Size:	118.0 KB
ID:	42238 Click image for larger version

Name:	20150108_180158.jpg
Views:	48
Size:	181.2 KB
ID:	42239 Click image for larger version

Name:	20150108_180325.jpg
Views:	53
Size:	186.0 KB
ID:	42240


            • #22
              Looking Good