I want to thank everyone on the Propeller Live Forum for the kind words about this project and the Propeller powered light show I have at the house.
During the live forum, I tested a use case that worked before I made the changes to the pin output and levels, where the Ethernet status would update when unplugged. On the live forum, it didn't work as expected. The ethernet status did not turn yellow, then red when I unplugged the cable.
So what I found was, the E1.31 cog is now much more aggressive in checking out the lock for the W6100 ethernet. To the point that unless there is E1.31 data flowing into the controller, the other cogs that communicate with the ethernet (The Watchdog and httpd server) might be in a state where they don't get a bite at the apple. This was a problem I anticipated, but it never materialized. Well, here it is I am unsure why I am just now seeing it and cannot be 100% sure it is related to the pin configuration changes.
I am not using the interrupt line on the W6100 (but it is wired on my board). This means that the webserver and E1.31 cogs just hammer away checking the registers to see if they have data available in the W6100. I have a small delay for the httpd and watchdog cogs, to deprioritize them.
I believe the solution to properly prioritize E1.31 is to configure the interrupt so that it will fire only if there is data available on the E1.31 socket. In addition, have the E1.31 cog attempt to checkout a lock only when there is data to service. This will give the http and watchdog cogs the ability to service any requests when no E1.31 data is being received. The problem currently manifests itself only when there is no E1.31 data to service. When I send data, the webserver and watchdog work appropriately. Servicing the E1.31 data should always be the priority.
test.spin2 has been renamed to Blitzen24.spin2. It is the Topfile.
Previous versions would set pingroup pixel count based on the first pin of the pingroup. ie pins 1,9, and17. Now pixel count for the pingroup is based on the highest individual port pixel count in the group.
You ever had a bug in a piece of code and when you look at the code you wrote, your mind is completely devoid of any recollection as to how it works? I really should have put more comments in here.
pub e131post() | output, ei, eti, u , uascii
longfill(@tE131CONFIG,0,432) ' Clean up the tmp space
eutmp[0] := 0
pcnt[0] := 0
output := str2dec(@READBUFFER + str.instr(@READBUFFER,string("output="))+ 7, 2)
u := 1
ei := 0
eti := 0
repeat until (E131CONFIG[ei] == output) or (E131CONFIG[ei] == 0) 'Do this until you get to the current e131 config
longmove(@tE131CONFIG+(ei*4),@E131CONFIG+(ei*4),4)
ei := ei + 4
eti := ei
str.append_str(@eutmp,string("U"))
str.append_str(@eutmp,str.dec(u,1))
str.append_str(@eutmp,string("="))
str.append_str(@pcnt,string("P"))
str.append_str(@pcnt,str.dec(u,1))
str.append_str(@pcnt,string("="))
repeat until str2dec(@READBUFFER + str.instr(@READBUFFER,@eutmp)+ 3, 6) == 0
tE131CONFIG[ei] := output
tE131CONFIG[ei+1] := str2dec(@READBUFFER + str.instr(@READBUFFER,@eutmp)+ 3, 6)
tE131CONFIG[ei+2] := str2dec(@READBUFFER + str.instr(@READBUFFER,@pcnt)+ 3, 3)
'vid.dec(str2dec(@READBUFFER + str.instr(@READBUFFER,@eutmp)+ 3, 6))
'vid.dec(str2dec(@READBUFFER + str.instr(@READBUFFER,@pcnt)+ 3, 3))
u := u + 1
eutmp[0] := 0
pcnt[0] := 0
str.append_str(@eutmp,string("U"))
str.append_str(@eutmp,str.dec(u,1))
str.append_str(@eutmp,string("="))
str.append_str(@pcnt,string("P"))
str.append_str(@pcnt,str.dec(u,1))
str.append_str(@pcnt,string("="))
ei := ei + 4
'waitms(3000)
repeat until (E131CONFIG[eti] <> output) or (E131CONFIG[eti] == 0) or eti >= 432
eti := eti + 4
' ei := ei - 4
repeat until (E131CONFIG[eti] == 0) or eti >= 432
longmove(@tE131CONFIG+(ei*4),@E131CONFIG+(eti*4),4)
eti := eti + 4
ei := ei + 4
longmove(@E131CONFIG,@tE131CONFIG,432)
ConfigPixels()
StopPixels()
StartPixels()
W6100.stopfastrx()
W6100.startfastrx(W6100.IDM_BSR_Socket3_Register,@pixelbuffer,@TXBUFFER,@E131CONFIG)
Comments.........help....so......much. Took me an hour and a half to walk this code manually and write comments as to what it is doing. I needed to do this to get my mind "right" again.
Basically, it copies the records in E131CONFIG structure to a temporary structure (tE131CONFIG) until it reaches the current output pin record. It then populates the records for the data that was posted to the webserver for the current pin in the tE131CONFIG structure. It must enumerate the Universe/Pixelcount pairs submitted on the form, as you can configure more than one universe for an output pin. Once that is complete, it copies the rest of the records from the E131CONFIG structure to the temporary structure (tE131CONFIG) until all records have been copied. It then copies all of the tE131CONFIG to E131CONFIG, re-runs the pixelconfig to setup where the pixel buffers will land, and restarts all affected cogs.
I remember writing this overnight after having a nap one weekend. That whole process congealed in my brain for a few hours. Then I never looked back until now. Now I need to actually see what causes the whole controller to lockup when an E1.31 config is removed or added when there are configurations on pins below or above it. The problem may also reside in PixelConfig. I can't recall if every pin is required to be in the E131CONFIG structure and with an E1.31 universe of 0 if not configured. It may be that I also need to clear the contents of the E131CONFIG before overwriting it with tE131CONFIG. That would make sense if we are removing records from the structure.
I look forward to killing this bug over Christmas!
pub e131post() | output, ei, eti, u , uascii
longfill(@tE131CONFIG,0,432) ' Clean up the tmp space
eutmp[0] := 0
pcnt[0] := 0
' Get the output Pin this E1.31 config is associated with
output := str2dec(@READBUFFER + str.instr(@READBUFFER,string("output="))+ 7, 2)
' Initialize the variables to be used.
u := 1
ei := 0
eti := 0
'Populate tE131CONFIG with configured pin/universe/pixelcount/pixelbuffer records in the E131CONFIG structure until we come to the current output.
repeat until (E131CONFIG[ei] == output) or (E131CONFIG[ei] == 0)
'Move 4 longs from the E1.31 config structure to the temp structure, before the output is found or end of structure is detected.
'No idea why I am doing ei*4, maybe because longs?
longmove(@tE131CONFIG+(ei*4),@E131CONFIG+(ei*4),4)
ei := ei + 4
eti := ei
' Populate eutemp with "U1="
str.append_str(@eutmp,string("U"))
str.append_str(@eutmp,str.dec(u,1))
str.append_str(@eutmp,string("="))
' Populate pcnt (pixelcount) with "P1="
str.append_str(@pcnt,string("P"))
str.append_str(@pcnt,str.dec(u,1))
str.append_str(@pcnt,string("="))
'Look in the read buffer until the location of the current eutmp (ie "U1=", "U2=", etc) is found and repeat the code block. Stop if it cannot be found.
repeat until str2dec(@READBUFFER + str.instr(@READBUFFER,@eutmp)+ 3, 6) == 0
' Set the output pin in the current location (ei) of tE131CONFIG. This is a many to one relationship with the pin in the pixelbuffer.
tE131CONFIG[ei] := output
' Set the value of the eutmp (ie "U1=", "U2=", etc) universe associated with this pin.
tE131CONFIG[ei+1] := str2dec(@READBUFFER + str.instr(@READBUFFER,@eutmp)+ 3, 6)
' Set the value of the pcnt (pixelcount ie "P1=", "P2=", etc ) of this universe assocaited with this pin.
tE131CONFIG[ei+2] := str2dec(@READBUFFER + str.instr(@READBUFFER,@pcnt)+ 3, 3)
'vid.dec(str2dec(@READBUFFER + str.instr(@READBUFFER,@eutmp)+ 3, 6))
'vid.dec(str2dec(@READBUFFER + str.instr(@READBUFFER,@pcnt)+ 3, 3))
' Increment the universe and pixelcount to the next that may have been posted to the page.
u := u + 1
' clear eutmp
eutmp[0] := 0
' clear pcnt
pcnt[0] := 0
' Populate eutemp with the next universe of this pin to look for.
str.append_str(@eutmp,string("U"))
str.append_str(@eutmp,str.dec(u,1))
str.append_str(@eutmp,string("="))
' Populate pcnt with the next pixelcount of this pin to look for.
str.append_str(@pcnt,string("P"))
str.append_str(@pcnt,str.dec(u,1))
str.append_str(@pcnt,string("="))
' Move to the next pin/universe/pixelcount/pixelbuffer in the structure.
ei := ei + 4
'waitms(3000)
' Increment et1 until we are past the currently configured output pin or the end of configured pin/universe/pixelcount/pixelbuffer records in the structure or the end of the structure.
repeat until (E131CONFIG[eti] <> output) or (E131CONFIG[eti] == 0) or eti >= 432
eti := eti + 4
' ei := ei - 4
' Copy any remaining records in the E1.31 structure to @tE131CONFIG
repeat until (E131CONFIG[eti] == 0) or eti >= 432
longmove(@tE131CONFIG+(ei*4),@E131CONFIG+(eti*4),4)
eti := eti + 4
ei := ei + 4
' Overwrite the E131CONFIG with tE131CONFIG
longmove(@E131CONFIG,@tE131CONFIG,432)
' Rebuild the Pixel/E1.31 relationship
ConfigPixels()
' Stop and restart the pixel drivers
StopPixels()
StartPixels()
' Restart the E1.31 ethernet driver
W6100.stopfastrx()
W6100.startfastrx(W6100.IDM_BSR_Socket3_Register,@pixelbuffer,@TXBUFFER,@E131CONFIG)
@ke4pjw said:
Comments.........help....so......much. Took me an hour and a half to walk this code manually and write comments as to what it is doing. I needed to do this to get my mind "right" again.
I remember writing this overnight after having a nap one weekend. That whole process congealed in my brain for a few hours. Then I never looked back until now. ....
This is soooo true!!! I've been there more times than I would like to admit. Good luck!
I also know this very well. The common error is to think "I'll do the documentation when I'm finished coding". But after it's halfway done I receive a phone call from a customer who urgently needs a fix for a problem. Then I come back two weeks later and have no clue what part was actually working, already, and what still needs to be fixed and how it was supposed to be implemented.
One possible solution is to document as much as possible before starting to code. At least the interface specifications and purpose of every variable and function can be written down ahead of the code. If you have new ideas while programming write them down immediately.
The other solution is to lock the door and switch the phone to flight mode until you're finished.
Glad I am not alone in forgeting how your own code works! @ManAtWork I think I am going to document the interface spec for passing the variables from the webserver, as well as document the data structures for the pixel and E1.31 configs. I have comments, but a graphic showing the one to many relationship of those two will be helpful.
More updates! Lots of work done over the holidays.
New Features!
Test mode for outputs. You can blink your LEDS Red, Green, Blue, or White via the Outputs tab. That allows you to ensure that the outputs are wired correctly and also is a way for you to determine if your pixel order is RGB and adjust it so that it is RGB.
Quad DMX outputs are working! You can now map up to four E1.31 universes to output to DMX. No more USB needed to control your DMX devices. Just use your network! Walk around with your laptop controlling your fixtures via WiFi.
Selectable Speed and Duplex. Ethernet was hard coded to 10BaseT Full. It is now selectable between 10/half/full, 100/half/full and Auto Negotiate. There can be a performance penalty at 100 Full, and that's why this was added. Additionally, some enterprise level switches will not auto negotiate correctly, or properly negotiate 10/Full unless the port specifies it.
DNS was added to the network configuration. DNS can be assigned via DHCP. I need to write a resolver. Once that is done, I will add a feature to allow these controllers to update their firmware via the Internet.
Improvements
The watchdog was updated to reflect more accurate E1.31 statistics.
The E1.31 indicator on the OLED display blinks Yellow when in outputs are in Test Mode.
All HDMI code has been removed and the driver unloaded from memory. All former diagnostic information, such as https logs, are now visible via debug. Just enable debug and load it into RAM. The freed up HDMI cog allowed for the Quad DMX to be implemented.
There is room for improvement, but this is starting to feel close to solid. I will test all of these features and most likely release this as Release Candidate 2.
This code is currently available in the Main Branch.
I hope everyone had a Merry Christmas, A Happy Hanukkah, a joyous Festivus, and will have a happy and prosperous 2023!
Found a major bug in the DMX output. The baudticks variable was not copied from hubram to the DMX cog. I had just checked the data with an analyzer, but didn't actually look at the timings. The timings look good now. I will test with actual DMX fixtures later this evening.
Found another major bug in the DMX output. Testing on generic Chinese DMX fixtures worked just fine. Testing on my own Rudolph 16's failed. They would indicate that DMX was being received, but would not accept any data from the Blitzen 24. After a couple of hours looking at the beautiful, perfectly timed waveforms generated by my modified version @JonnyMac 's jm_dmx_tx object, and banging my head against the table, I hooked up my old DMX USB dongle that I built based on the P1 to do a side by side. After a couple of minutes banging my head on the desk again, I saw it. The null start code on the DMX dongle. I had accidentally set the start code to a value of "1". Complete brain fart. The Rudolph 16 actually followed the current spec (at the time it was made) and ignored any packets with a start code other than 0.
Code has been updated in the main branch in the repo.
--Terry
"We do these things not because they are hard, but because we thought they would be easy."
Remote updates are getting closer to being a thing.
I can prepare the filesystem for downloads.
Get a copy of the update manifest.
Download the files from the manifest.
Having trouble enumerating files in the root directory and am stuck there at the moment.
So I upgraded to PropellerTool 2.9.2 and basically, the webserver no longer works. All of my builds are on PropellerTool 2.6.2.
I will take some time this evening/weekend to find what the issues are. The timings on the locks has changed and I think that may be affecting the performance.
To be clear, this is not an issue with PropellerTool, it is a problem where I did not use the beta releases to correct my code.
I found the "stupid" in my code in the W6100 ethernet driver. It now works properly with PropellerTool 2.9.2.
PUB readreg(REGISTER,BS,BLEN,RB) : r | i , LADDRL, LADDRH, tmpdata, tmpptr, datapin
repeat until locktry(EthernetLock) < 0
waitus(0) ' I removed this stupid thing in 3 places. All works correctly now.
Version 1.1 is also in the works. I have been able to add a real-time view of over-the-air upgrades using Javascript's EventSource. This has been tested in Edge (Chrome) and Firefox, and should work on any modern browser. In addition, I will add MD5 checksums to downloads and upgrade abort/rollback features to the 1.1 release.
When you get your controller, if you have it configured to boot from SD, (flash off) it should give you the option to upgrade over the air from the config page. I am curious to know if it works for someone that's not me .
When you get your controller, if you have it configured to boot from SD, (flash off) it should give you the option to upgrade over the air from the config page. I am curious to know if it works for someone that's not me .
Got it on friday. Very exciting! Hope to turn on the switch this week.
Comments
Cool👍
Awesome!!!
I want to thank everyone on the Propeller Live Forum for the kind words about this project and the Propeller powered light show I have at the house.
During the live forum, I tested a use case that worked before I made the changes to the pin output and levels, where the Ethernet status would update when unplugged. On the live forum, it didn't work as expected. The ethernet status did not turn yellow, then red when I unplugged the cable.
So what I found was, the E1.31 cog is now much more aggressive in checking out the lock for the W6100 ethernet. To the point that unless there is E1.31 data flowing into the controller, the other cogs that communicate with the ethernet (The Watchdog and httpd server) might be in a state where they don't get a bite at the apple. This was a problem I anticipated, but it never materialized. Well, here it is
I am unsure why I am just now seeing it and cannot be 100% sure it is related to the pin configuration changes.
I am not using the interrupt line on the W6100 (but it is wired on my board). This means that the webserver and E1.31 cogs just hammer away checking the registers to see if they have data available in the W6100. I have a small delay for the httpd and watchdog cogs, to deprioritize them.
I believe the solution to properly prioritize E1.31 is to configure the interrupt so that it will fire only if there is data available on the E1.31 socket. In addition, have the E1.31 cog attempt to checkout a lock only when there is data to service. This will give the http and watchdog cogs the ability to service any requests when no E1.31 data is being received. The problem currently manifests itself only when there is no E1.31 data to service. When I send data, the webserver and watchdog work appropriately. Servicing the E1.31 data should always be the priority.
I will keep you all posted.
I decided to try something less complicated, and it works, somehow.
Not sure what waitms(0) gets translated to, but it allows all of the cogs to get a bite at the lock. I will take it. Less complexity the better.
test.spin2 has been renamed to Blitzen24.spin2. It is the Topfile.
Previous versions would set pingroup pixel count based on the first pin of the pingroup. ie pins 1,9, and17. Now pixel count for the pingroup is based on the highest individual port pixel count in the group.
https://griswoldfx.visualstudio.com/_git/Blitzen 24?path=/&version=GBmain
You ever had a bug in a piece of code and when you look at the code you wrote, your mind is completely devoid of any recollection as to how it works? I really should have put more comments in here.
pub e131post() | output, ei, eti, u , uascii longfill(@tE131CONFIG,0,432) ' Clean up the tmp space eutmp[0] := 0 pcnt[0] := 0 output := str2dec(@READBUFFER + str.instr(@READBUFFER,string("output="))+ 7, 2) u := 1 ei := 0 eti := 0 repeat until (E131CONFIG[ei] == output) or (E131CONFIG[ei] == 0) 'Do this until you get to the current e131 config longmove(@tE131CONFIG+(ei*4),@E131CONFIG+(ei*4),4) ei := ei + 4 eti := ei str.append_str(@eutmp,string("U")) str.append_str(@eutmp,str.dec(u,1)) str.append_str(@eutmp,string("=")) str.append_str(@pcnt,string("P")) str.append_str(@pcnt,str.dec(u,1)) str.append_str(@pcnt,string("=")) repeat until str2dec(@READBUFFER + str.instr(@READBUFFER,@eutmp)+ 3, 6) == 0 tE131CONFIG[ei] := output tE131CONFIG[ei+1] := str2dec(@READBUFFER + str.instr(@READBUFFER,@eutmp)+ 3, 6) tE131CONFIG[ei+2] := str2dec(@READBUFFER + str.instr(@READBUFFER,@pcnt)+ 3, 3) 'vid.dec(str2dec(@READBUFFER + str.instr(@READBUFFER,@eutmp)+ 3, 6)) 'vid.dec(str2dec(@READBUFFER + str.instr(@READBUFFER,@pcnt)+ 3, 3)) u := u + 1 eutmp[0] := 0 pcnt[0] := 0 str.append_str(@eutmp,string("U")) str.append_str(@eutmp,str.dec(u,1)) str.append_str(@eutmp,string("=")) str.append_str(@pcnt,string("P")) str.append_str(@pcnt,str.dec(u,1)) str.append_str(@pcnt,string("=")) ei := ei + 4 'waitms(3000) repeat until (E131CONFIG[eti] <> output) or (E131CONFIG[eti] == 0) or eti >= 432 eti := eti + 4 ' ei := ei - 4 repeat until (E131CONFIG[eti] == 0) or eti >= 432 longmove(@tE131CONFIG+(ei*4),@E131CONFIG+(eti*4),4) eti := eti + 4 ei := ei + 4 longmove(@E131CONFIG,@tE131CONFIG,432) ConfigPixels() StopPixels() StartPixels() W6100.stopfastrx() W6100.startfastrx(W6100.IDM_BSR_Socket3_Register,@pixelbuffer,@TXBUFFER,@E131CONFIG)Comments.........help....so......much. Took me an hour and a half to walk this code manually and write comments as to what it is doing. I needed to do this to get my mind "right" again.
Basically, it copies the records in E131CONFIG structure to a temporary structure (tE131CONFIG) until it reaches the current output pin record. It then populates the records for the data that was posted to the webserver for the current pin in the tE131CONFIG structure. It must enumerate the Universe/Pixelcount pairs submitted on the form, as you can configure more than one universe for an output pin. Once that is complete, it copies the rest of the records from the E131CONFIG structure to the temporary structure (tE131CONFIG) until all records have been copied. It then copies all of the tE131CONFIG to E131CONFIG, re-runs the pixelconfig to setup where the pixel buffers will land, and restarts all affected cogs.
I remember writing this overnight after having a nap one weekend. That whole process congealed in my brain for a few hours. Then I never looked back until now. Now I need to actually see what causes the whole controller to lockup when an E1.31 config is removed or added when there are configurations on pins below or above it. The problem may also reside in PixelConfig. I can't recall if every pin is required to be in the E131CONFIG structure and with an E1.31 universe of 0 if not configured. It may be that I also need to clear the contents of the E131CONFIG before overwriting it with tE131CONFIG. That would make sense if we are removing records from the structure.
I look forward to killing this bug over Christmas!
pub e131post() | output, ei, eti, u , uascii longfill(@tE131CONFIG,0,432) ' Clean up the tmp space eutmp[0] := 0 pcnt[0] := 0 ' Get the output Pin this E1.31 config is associated with output := str2dec(@READBUFFER + str.instr(@READBUFFER,string("output="))+ 7, 2) ' Initialize the variables to be used. u := 1 ei := 0 eti := 0 'Populate tE131CONFIG with configured pin/universe/pixelcount/pixelbuffer records in the E131CONFIG structure until we come to the current output. repeat until (E131CONFIG[ei] == output) or (E131CONFIG[ei] == 0) 'Move 4 longs from the E1.31 config structure to the temp structure, before the output is found or end of structure is detected. 'No idea why I am doing ei*4, maybe because longs? longmove(@tE131CONFIG+(ei*4),@E131CONFIG+(ei*4),4) ei := ei + 4 eti := ei ' Populate eutemp with "U1=" str.append_str(@eutmp,string("U")) str.append_str(@eutmp,str.dec(u,1)) str.append_str(@eutmp,string("=")) ' Populate pcnt (pixelcount) with "P1=" str.append_str(@pcnt,string("P")) str.append_str(@pcnt,str.dec(u,1)) str.append_str(@pcnt,string("=")) 'Look in the read buffer until the location of the current eutmp (ie "U1=", "U2=", etc) is found and repeat the code block. Stop if it cannot be found. repeat until str2dec(@READBUFFER + str.instr(@READBUFFER,@eutmp)+ 3, 6) == 0 ' Set the output pin in the current location (ei) of tE131CONFIG. This is a many to one relationship with the pin in the pixelbuffer. tE131CONFIG[ei] := output ' Set the value of the eutmp (ie "U1=", "U2=", etc) universe associated with this pin. tE131CONFIG[ei+1] := str2dec(@READBUFFER + str.instr(@READBUFFER,@eutmp)+ 3, 6) ' Set the value of the pcnt (pixelcount ie "P1=", "P2=", etc ) of this universe assocaited with this pin. tE131CONFIG[ei+2] := str2dec(@READBUFFER + str.instr(@READBUFFER,@pcnt)+ 3, 3) 'vid.dec(str2dec(@READBUFFER + str.instr(@READBUFFER,@eutmp)+ 3, 6)) 'vid.dec(str2dec(@READBUFFER + str.instr(@READBUFFER,@pcnt)+ 3, 3)) ' Increment the universe and pixelcount to the next that may have been posted to the page. u := u + 1 ' clear eutmp eutmp[0] := 0 ' clear pcnt pcnt[0] := 0 ' Populate eutemp with the next universe of this pin to look for. str.append_str(@eutmp,string("U")) str.append_str(@eutmp,str.dec(u,1)) str.append_str(@eutmp,string("=")) ' Populate pcnt with the next pixelcount of this pin to look for. str.append_str(@pcnt,string("P")) str.append_str(@pcnt,str.dec(u,1)) str.append_str(@pcnt,string("=")) ' Move to the next pin/universe/pixelcount/pixelbuffer in the structure. ei := ei + 4 'waitms(3000) ' Increment et1 until we are past the currently configured output pin or the end of configured pin/universe/pixelcount/pixelbuffer records in the structure or the end of the structure. repeat until (E131CONFIG[eti] <> output) or (E131CONFIG[eti] == 0) or eti >= 432 eti := eti + 4 ' ei := ei - 4 ' Copy any remaining records in the E1.31 structure to @tE131CONFIG repeat until (E131CONFIG[eti] == 0) or eti >= 432 longmove(@tE131CONFIG+(ei*4),@E131CONFIG+(eti*4),4) eti := eti + 4 ei := ei + 4 ' Overwrite the E131CONFIG with tE131CONFIG longmove(@E131CONFIG,@tE131CONFIG,432) ' Rebuild the Pixel/E1.31 relationship ConfigPixels() ' Stop and restart the pixel drivers StopPixels() StartPixels() ' Restart the E1.31 ethernet driver W6100.stopfastrx() W6100.startfastrx(W6100.IDM_BSR_Socket3_Register,@pixelbuffer,@TXBUFFER,@E131CONFIG)This is soooo true!!! I've been there more times than I would like to admit. Good luck!
I also know this very well. The common error is to think "I'll do the documentation when I'm finished coding". But after it's halfway done I receive a phone call from a customer who urgently needs a fix for a problem. Then I come back two weeks later and have no clue what part was actually working, already, and what still needs to be fixed and how it was supposed to be implemented.
One possible solution is to document as much as possible before starting to code. At least the interface specifications and purpose of every variable and function can be written down ahead of the code. If you have new ideas while programming write them down immediately.
The other solution is to lock the door and switch the phone to flight mode until you're finished.
Comments have been added to the code.
Bug was found and dispatched.
New version of Blitzen24.spin2 is in the repo.
Glad I am not alone in forgeting how your own code works! @ManAtWork I think I am going to document the interface spec for passing the variables from the webserver, as well as document the data structures for the pixel and E1.31 configs. I have comments, but a graphic showing the one to many relationship of those two will be helpful.
Blitzen 24 Edge Pre-Release_1 is available in the repo.
I am ramping up to have boards available for sale, for those that are interested.
Also, here is a quick video I made when it started snowing before Christmas. It doesn't snow very often in Middle Tennessee.
Every light in this video is controlled by either a P1 (Rudolph 16 - A.C. dimmer) or P2 (Blitzen 24 - pixel controller).
Great!
More updates! Lots of work done over the holidays.
New Features!
Improvements
There is room for improvement, but this is starting to feel close to solid. I will test all of these features and most likely release this as Release Candidate 2.
This code is currently available in the Main Branch.
I hope everyone had a Merry Christmas, A Happy Hanukkah, a joyous Festivus, and will have a happy and prosperous 2023!
--Terry
Found a major bug in the DMX output. The baudticks variable was not copied from hubram to the DMX cog. I had just checked the data with an analyzer, but didn't actually look at the timings. The timings look good now. I will test with actual DMX fixtures later this evening.
Found another major bug in the DMX output. Testing on generic Chinese DMX fixtures worked just fine. Testing on my own Rudolph 16's failed. They would indicate that DMX was being received, but would not accept any data from the Blitzen 24. After a couple of hours looking at the beautiful, perfectly timed waveforms generated by my modified version @JonnyMac 's jm_dmx_tx object, and banging my head against the table, I hooked up my old DMX USB dongle that I built based on the P1 to do a side by side. After a couple of minutes banging my head on the desk again, I saw it. The null start code on the DMX dongle. I had accidentally set the start code to a value of "1". Complete brain fart. The Rudolph 16 actually followed the current spec (at the time it was made) and ignored any packets with a start code other than 0.
Code has been updated in the main branch in the repo.
--Terry
"We do these things not because they are hard, but because we thought they would be easy."
"We do these things not because they are hard, but because we thought they would be easy."
that's a nice one
Mike
Remote updates are getting closer to being a thing.
I can prepare the filesystem for downloads.
Get a copy of the update manifest.
Download the files from the manifest.
Having trouble enumerating files in the root directory and am stuck there at the moment.
Over the air updates are working! I do a walk through of the new features in the latest pre-release in the video below.
Nice
Binary distribution of Pre-Release 4 is here.
Pre-Release 4's Source is here.
So I upgraded to PropellerTool 2.9.2 and basically, the webserver no longer works. All of my builds are on PropellerTool 2.6.2.
I will take some time this evening/weekend to find what the issues are. The timings on the locks has changed and I think that may be affecting the performance.
To be clear, this is not an issue with PropellerTool, it is a problem where I did not use the beta releases to correct my code.
I found the "stupid" in my code in the W6100 ethernet driver. It now works properly with PropellerTool 2.9.2.
The bug has been fixed in both Pre-Release 4 and the Main branch.
Version and Uptime have been added to the Config screen. Once this has been regression tested, I will make it a full 1.0 release.
PR4 was promoted to the full 1.0 release, named Music City.
Binary Release is here.
Source is here.
Version 1.1 is also in the works. I have been able to add a real-time view of over-the-air upgrades using Javascript's EventSource. This has been tested in Edge (Chrome) and Firefox, and should work on any modern browser. In addition, I will add MD5 checksums to downloads and upgrade abort/rollback features to the 1.1 release.
Great!
When you get your controller, if you have it configured to boot from SD, (flash off) it should give you the option to upgrade over the air from the config page. I am curious to know if it works for someone that's not me .
Got it on friday. Very exciting! Hope to turn on the switch this week.
For those that would like to buy boards, it's available in the GriswoldFX store:
https://store.griswoldfx.com/blitzen-24-edge/
Excellent! I DM'd you.
Hi Terry!
Did you post the details, dims & BOM for building and connecting that giant LED strip display somewhere ?
I'm thinking with your board now available, that would be a neat summer project for me to hand a "lucky" student