There is the circuit in the attachment to explain my idea; I assume you're viewing that circuit while reading this report.
When Input Format attribute of LED Matrix is "Select Rows/Columns" and Light Persistence more than 0, Matrix actually behaves as an asynchronous memory device. For the case shown in my circuit, we can accept input, which define row number, is an "address" and input, which sets pixels in a row, is a "data". As an asynchronous memory device, a Matrix updates its state as soon as new value is received from inputs. Usually, data and address don't update simultaneously, so it's common case when memory device receives new address while data isn't updated yet; new value will overwrite old one. But in case of our Matrix, new data doesn't overwrite old one: it OVERLAPS (or mixes with) it - "1" eliminates "0" but "0" doesn't eliminate "1" (actually, AND operation performs). I see the obstacle to fix this: there is no definition "who is who": whether row number is an "address" or column number is. The simple solution is to define: row number is an "address", and every new value should overwrite a row if corresponding row number bit is "1". More complex solution is to add an attribute defining "who" is an "address". There is another solution (I guess it's bad): to add clock input to LED Matrix component. Actually, two "working correctly" solutions in my circuit are the attempt to "add" clock input.
Carl, I'm sorry I didn't find this bug when you just added "Light Persistence" feature this summer. It was my job to check this situation. I would to know you decision about this bug soon, since my workbook contains the lab with this sort of using LED Matrix and I have to know whether I have to add this terrible "register solution" or to wait until you will implement good solution.
Log in to post a comment.