Chat freely about anything...

User avatar
By folny82
#9756
sfranzyshen wrote:
folny82 wrote:You can try to do the 16x32 matrix at Jinx and to know whether the LEDs will light up ?.


I do not use windows and I can not get Jinx to run properly on my linux ...


So that might be a problem I use Windows, I asked in what could be the problem of software authors and Jinx wrote that your code does not have support for multi blocks can you please try to add this feature to your code.
User avatar
By sfranzyshen
#9779
folny82 wrote:So that might be a problem I use Windows, I asked in what could be the problem of software authors and Jinx wrote that your code does not have support for multi blocks can you please try to add this feature to your code.

I dought the problem lies with windows (as much as I would love to see it to be :D ) I knew that there was a fragmentation possible ...
If your channel count + protocol overhead exceeds the network mtu size, you will run into trouble with fragmented network packets.
So it's back to the drawing board to see what we can come up with ...

I am now insearch of tpm2net "client" code ... from ANY source ... any language
or server side code will also help ...
User avatar
By folny82
#9789 It will be necessary to add support Block for the code because under Windows will not be able to control 512 LEDs any restriction MTU and also the other devices have limited MTU only 1500.
User avatar
By sfranzyshen
#9861 after looking around I have not found a controller (client) code (except assembly sedu code ...) that supports multiple packets. the pixelcontroller's arduino code does have an offset ... but never checks to see if the current packetnumber = totalpackets+1 before it writes the data out to the strip ... maybe because it splits the display into multiple strips and uses a seperate gpio to drive a second strips ... I don't know ... I didn't dig that deep.

anyway onto our code ... I can understand why frans-willem (the author of the tpm2net code used here in this project ... not me!) choose to write the code the way he did ... he has chosen to uses a pointer to the already memory allocated espconn's data to avoid setting up an array and copying the data over to said array before sending it to the strip. This also avoids needing to initialize or know anything about the strip before hand ...

However it does ignore mutiple packets ... it assumes that all of the frame's data is in this one packet and so on ... either increase the mtu of the host ... or define the frame array ahead of time ... copying the data with each recieved packet into that array ... until the total number of packets have been recieved. then fire off the ws2812 code with our new frame array.

Current Code
Code: Select alltpm2net_recv(void *arg, char *pusrdata, unsigned short length) {

   unsigned char *data =(unsigned char *)pusrdata; //pointer to espconn's returned data

   if (data && length >= 6 && data[0]==0x9C) { // header identifier (packet start)

      uint8_t blocktype = data[1]; // command type

      uint16_t framelength = ((uint16_t)data[2] << 8) | (uint16_t)data[3]; // data length

      uint8_t packagenum = data[4]; // packet number

      uint8_t numpackages = data[5]; // total packets

      if (length >= framelength + 7 && data[6+framelength]==0x36) { // header end (packet stop)

         unsigned char *frame = &data[6]; // pointer 'frame' to espconn's data (start of data)

         if (blocktype == 0xDA) { // data command ...

            ws2812_out(frame,framelength); // send data to strip
         }


      } else {
         //Invalid length or invalid end byte
      }
   } else {
      //Not a valid header
   }
}


I will updade the code ... but it will require knowing the size of the matrix ahead of time ... we will either need to add a way to configure this ... or hard code it into the firmware. OR if we hard code an array size of 512 pixels max and then keep a running tally on the number of pixels actually recieved (in multiple packets or single) and only tell the ws2812 code to update the size of matrix recieved and not the full defined 512 pixel array ...

cup of coffee in hand and a cold sunday afternoon ... I will see what I can come up with ;)