ESP8266 Community Forum

- Thu Feb 12, 2015 10:56 am #9552

Thanks for the advice I tried iot_demo but I just do not understand exactly how ...

I only presented the iot_demo as an example of how to add this code to some other code ... feel free to try it out with anything else ... following the method presented here ...

I just do not understand exactly how a iot_demo function can configure ESP through the web interface ?.

I am currently working on a custom version of the iot_demo that will handle the get/set functions using json calls (exactly how the iot_demo works now) ... then using a single html (js, css, images, sounds, etc ... all embedded within) file acting as a javascript app to interface/manipulate the device using json calls ... similar to the android (iot.apk) demo app floating around out there ... but from a crossplatform web app instead

My ideal firmware would not only be able to handle the json calls ... but also to be able to serve up (maybe gzipped) this single html file ... to clients that don't already have it but I'm not there yet ...

- Fri Feb 13, 2015 7:18 pm #9697 Yes, I understand that I added this code http://esp8266.ru/forum/threads/razrabo ... sp8266.56/ to your web interface and it works fine however I would like my control panel 16x32 it is 512 LEDs, I use software Jinx and when I set Channels and Chan / Block to 1466 income stream stops to think is there any solution for achieving control all 512 LEDs ?

- Fri Feb 13, 2015 8:19 pm #9701

Yes, I understand that I added this code http://esp8266.ru/forum/threads/razrabo ... sp8266.56/ to your web interface and it works fine however I would like my control panel 16x32 it is 512 LEDs, I use software Jinx and when I set Channels and Chan / Block to 1465 income stream stops to think is there any solution for achieving control all 512 LEDs ?

where does the income stream stop? is the problem with jinx ... or is the problem with this code? can you verify your setup with some other tpm2net controller to know if jinx is capable of doing this in the first place ... or verify it from other jinx users ... if so ... then lets jump into looking at this code and see if we can't fix it ...

-the code disables the wdt (no sure what difference this makes ... unless you need it)
-the code uses (as others have done) the disable/enable interrupts functions for the entire length of time it takes to send the data frame to the led strip.

(512x3x8=12288x1.25+50=15360µs) - maybe .01536 sec is too long to disable interrupts.
(pixels x leds x bits = totalbits x perbitµs + resetµs = totalcycleµs)

-the code bitbangs the gpio using the system api (crude)
-the code also uses while loops for timming the bitbang (blocking code)

the way I see it ... we need an interrupt freindly/non-blocking gpio bitbang routine ...

got one?

the longer the chain ... the longer the interrupt delay ... the looser the timing gets ... the least likely it will work.

I was hopeful that changes in the sdk_v0.9.5 or the rtos_sdk would bring some solutions ...
I also do not have a scope or 512 pixels ... so I am limited.

finally, if you had to split the display into two controllers ... you are still only out the cost of a second esp8266 ...

but, I too want to drive the full 512!!!!!

- Fri Feb 13, 2015 9:18 pm #9708 No matter how many LEDs you use for testing in channel settings for more than 1465 cease to illuminate all LEDs