2019-07-31 (W) PillarGame

Eliminating memory problems became a priority. I tried dividing the LEDs into three different strips, so the memory would not have to be assigned in a single array. This also helped with the division of rows since the top, bottom, and middle rows were separate entities. Nothing changed with the redistribution of LEDs and three strips of 300 overloaded the memory. Fortunately, while testing the different lines, I found that it was possible to remove power from the LEDs and calling a show() command restored all the colors, so there was no need to keep an extra register with those numbers.

Startup sequence of three strips

A few special functions were written to test communication. It was possible to assign LEDs a unique color one at a time, but turning on each LED was laborious. A test() function was written which turned on the first eight lights on all three rows, then changed their colors and left them on. The next task was AllOff() which turned off all of the LEDs and SlowOff() which turned them off sequentially. A show() function refreshed all three rows and could be useful after losing power. Some of the algorithms had delays programmed into them and talking to 900 addresses slowed things downs, so feedback was added, which sent a message about starting a long process and a message when it was complete. During these operations, the onboard indicator showing connection would turn off until completion.
Running "test" command

The rest of the posts for this project have been arranged by date.

First time here?

Completed projects from year 1
Completed projects from year 2
Completed projects from year 3
Completed projects from year 4
Completed projects from year 5
Completed projects from year 6

Disclaimer for http://24hourengineer.blogspot.com and 24HourEngineer.com

This disclaimer must be intact and whole. This disclaimer must be included if a project is distributed.

All information in this blog, or linked by this blog, is not to be taken as advice or solicitation. Anyone attempting to replicate, in whole or in part, is responsible for the outcome and procedure. Any loss of functionality, money, property, or similar, is the responsibility of those involved in the replication.

All digital communication regarding the email address 24hourengineer@gmail.com becomes the intellectual property of Brian McEvoy. Any information contained within these messages may be distributed or retained at the discretion of Brian McEvoy. Any email sent to this address, or any email account owned by  Brian McEvoy, cannot be used to claim property or assets.

Comments to the blog may be utilized or erased at the discretion of the owner. No one posting may claim property or assets based on their post.

This blog, including pictures and text, is copyright to Brian McEvoy.