LED Cloning Problem
Humanoido
Posts: 5,770
Help, please.
I have one prop chip with 20 or more I/O pins available.
There are 128 multitasking threads running in each of the 8 cogs.
Each thread blinks 1 LED, to verify the thread is running correctly.
How set up all 1,024 LEDs, each blinking at their own thread rates?
Thank you in advance. Humanoido
I have one prop chip with 20 or more I/O pins available.
There are 128 multitasking threads running in each of the 8 cogs.
Each thread blinks 1 LED, to verify the thread is running correctly.
How set up all 1,024 LEDs, each blinking at their own thread rates?
Thank you in advance. Humanoido
Comments
Am I right?
I wonder if someone will contribute an idea about a cost-less virtual LED arrangement, but I'm at a loss as to its implementation.
Humanoido
A pixel monitor, (with black pixels in between white LED pixels) would draw considerably less power than 400 amps.
If adopting this approach, my question is how to make the specific connections 1024 times from each prop chip to the monitor, and all prop chips for 40,000 monitor connections without running into any bottlenecks?
I think the positions of each pixel LED will need to be calculated, stored, and reported to a master chip which is connected to a TV monitor. But how to do simultaneous interval flashing of pixels?
Humanoido
as for coding 128 threads, I would use Hub-RAM for your variables, and have code in a single thread that is called 128 times, for each entry, thus saving your thread coding, then decode which number you're using, to then select which pixel/LED it's turning off / on, which could be a bitmap for now.
then for your LED's you could use MAX chips? depends how much you want to spend on this mammoth 40k LEDs + supporting chips.
Well, if you do this you won't really be driving 128 LEDs per cog, because doing that presumes an actual hardware connection, voltage, current flow, etc.
One way to do what you're suggesting is to have each cog use some threads to run a simple serial driver, then the rest of the threads can manage virtual LEDs. On the PC, you could use VB to build the virtual LED display. Build a form programmatically*, perhaps putting the LEDs into a 2D array. The cogs can send coordinates+direction for the LED to blink. The VB program can receive the coordinates+direction and pass them to functions controlling the LEDs.
Another option would be to run a high throughput driver in a control cog, then use the other cogs just for LEDs. This would probably give you better performance, since you wouldn't need to open & close connections for each cog. It just depends on what you're really trying to accomplish.
40,000 Virtual LEDs would be probably be difficult to fit on screen, so I would just lay out a 8x16 matrix of leds, and cycle through them to test the threads. Put some form of indicator to show which cog is being tested, and adjust the matrix size accordingly for the actual number of threads needed.
* By this I mean don't lay out 40,000 little circles for LEDs on a VB form by hand. Build the form with code.
Each prop in the tower uses 32 longs to store the state of it's 1024 leds, and the 32 longs are shifted out to the FIFO when the boss prop allows it access.
Each prop in the tower is granted access in turn to shift out it's data to the FIFO and that data is shifted out as video for "x" number of scan lines. During the period when data is being shifted out to the FIFO black video scan lines are produced to separate the "led pixels". Black pixels are also generated between the "led pixels" of each scan line to create horizontal separation.
The details would be determined to a great extent by the resolution of the display and arrangement of the "led pixels" on that display.
It may also be possible to do this using only the additional prop without the FIFO.
I believe your only purpose in flashing 128 LEDs per cog is to prove all the cogs are in fact each running 128 threads as advertised. I mused about the same problem, and thought to have each thread embed a timed code in their flashing so as to confirm (identify) the thread. I have not yet done this, but I believe it to be the only practical approach without building a lot of hardware just to prove a point.
Now, to implement such an embedded coding scheme will complicate the otherwise simple thread flashing software, and easily run out of cog ram, but some scheme can surely be developed. I would then also time share in some identifyable manner the I/O group among each cog in the prop.
So if you used 16 LEDs for encoded displaying operation of 128 threads, and 3 to encode which one of 8 cogs is currently using the 16 LED's, then you still have one LED left over, and you can use that to indicate how busy the cog is, either by busy/free indication, or by PWM DAC output on that last pin. I have used the latter approach as is a very nice indication to show when things are getting too busy.
Cheers,
Peter (pjv)
Maybe the Demo Board will work with its 8 yellow LEDs already on the board (from the VGA circuilt) and 8 more from the sockets, then 4 ports from the TV circuit can be used as well.
I like the idea of a timed code. The banks of LEDs could be automatically switched from one to the next. There's another 4 pins on the TV circuit, 3 of which can use the encode technique you describe below and one pin for the activity LED. (BTW, can you point me to an Object or code that can do this, or an idea about how to program it?) Starting out, I can envision the cog driving threads from 1 to 128 by cycling through 8 banks of 16 lights.
I think this is the plan! But it's not going to be easy to change over the current pin numbers to the Demo Board because I don't know if there are pins coded in PASM. Any suggestions will help. Thanks sincerely.
Humanoido
Assuming you hope these threads will work together to do something useful, isn't that the real "proof of the pudding"?
Humanoido
Next, I tried different values of Led1Ticks, tickclocks and tickus but still cannot get the LED to show blinking. What values do you recommend changing?
Humanoido
What program are you running?
Could you post it so I can understand your questions?
Cheers,
Peter (pjv)
Did you have a posted thread somewhere about how to use the program and what to expect from the LED lights when run? It appears random but after a while P3 LED does a lot of flickering, dims, becomes brighter, switches off and on, .. What is the sequence of what should happen?
Humanoido
Humanoido
Oh, that was one of my demo programs I created for the contest entry. I loaded your attachment directly into my Prop Prof. Dev. Board, and it immediately ran perfectly as designed. LED0 shows the business/acivity of the kernel, and LED1 through LED8 each are steady flashers at an on/off speed of 50, 45, 40, 35, 30, 25, 20, 15 usec respectively. So you need an oscilloscope to see these pulses. To the human eye they will simply be of some average brightness.
If you go to the CON section in the listing, and change the value of Led1Ticks from 50/TickuS to 500_000/TickuS and Delta from 1 to 10_000, you will slow all the threads down by a factor of 10_000 so you will be able to eyeball them. The Led1 becomes 500 mSec, and Led8 becomes 150 mSec, and their on times will all drift past each other.
The fact that some leds change in brightness indicates something amiss with the kernel (or possibly your setup). I believe I spotted an occasional counter roll-over issue which could rear its head every 53 seconds, depending on the busy-ness state and exact lignup of the threads at the instant of roll-over.
I am currently writing a much higer performance "improved" kernel which has 1 uSec resolution, and have a similar issue there. So that will need to be routed out.
Cheers,
Peter (pjv)
Which LED goes on which pin? For example, is LED 1 on pin 1, or pin 0?
On my Demo Board, LEDs on pins 7 through 1 are now blinking at their proper slowed down rates. However, the LED on pin 0 has a steady glow. What is happening on p0?
Also, I tested the code running in each of the eight cogs and it works perfect, but I must put the statement in the code to tell it which 1 cog to load into. It would be nice to have one statement to load the same program into all cogs at the same time.
Humanoido
The left shifts are simply to set the proper bit in the outa register.
As I said, pin0 (outa pin0) indicates the "busy-ness" of the kernel. It ticks at the rate of the base period which for this case has been chosen to be 5 uSec. You need a scope to observe this. An LED on this pin would simply show a steady glow... brighter for less busy and dimmer for more busy. As I stated before, you can turn that pulsing into a (DAC output) voltage using a series resistor and capacitor to ground to indicate busy-ness. It is a very important point to observe as at times the kernel may appear to be running properly but the timings are such that it looses ticks.
If the system gets too busy, ie: you are asking the processor to do more work than it can, the kernel will back up the ticks, and executes those as quickly as it can. But if you have written your application poorly then it may back up for many ticks, and in severe cases where there is not enough processor time, it may not be able to recover.
You NEED as scope (even a USB scope will do) to confirm proper operation of the kernel.
Cheers,
Peter (pjv)
My scope is old as the hills and stopped working - I definitely need the USB scope for traveling. For now, I'd like to get the circuit working to visually show the activity on LED 0.
The DAC circuit only made the LED go out. I tried various values of resistance and capacitance but nothing would light the LED. I double checked the circuit with the book. See below.
P0 --------^^^^^----o---- LED0 R1 | | --- C1 --- | | o GNDWhen doe the system become too busy? Somewhere between 16 and 128 LED threads? What is the indicator that ticks are being backed up? How to observe this or know this? Where is the tick backup routine and how does it work?
I was thinking about doing this (is this too ambitious?):
1) Get the activity light LED 0 to visually show Kernal activity
2) Find a way to run the same program in all 8 cogs at the same time
3) Find a way to cycle the output (blinking LEDs) from cog 0 through cog 7
4) Add 3 LEDs to indicate which cog is being shown
5) Add 8 more LED threads for a total of 16
6) Have each thread to do a tiny calculation
7) Show the result on 3 LEDs
I agree about the oscilloscope! If the DAC does not work, maybe there's another circuit that will?
Humanoido
Your statement that the DAC is not working is incorrect. It is what you are doing with it that is incorrect. You cannot connect an LED to the DAC output. The LED is a diode to ground. Now, you could connect an LED through a relatively high resistor value (1K or 2K or bigger) to the activity pin0 in parallel with the DAC, but the LED would have not much purpose. As I have repeatedly said, you NEED an oscilloscope to observe 5 uSec pulses.
As far as the details of the kernel are concerned, I suspect you are not sufficiently advanced in ASM to grasp the nuances (no disrespect intended) and my efforts at explanation will not be a good use of my time. Study ASM, the code and comments, and eventually you should be able to figure it out.
Cheers,
Peter (pjv)
Humanoido
I personally used the DAC with an oscilloscope to get a feeling of an "average" state of activity. To suggest why I bothered is better answered when you have observed the pin with an oscilloscope. These are the kind of nuances I'm thinking of when I referred to your level of advancement.
Actually, the kernel is largely incompatible with SPIN. You need to keep very tight control over the code looping/repeat structures to a level that is not practical in SPIN. So I tout this as an "assembler only" product. So if your strength "is not or will not or wants to be in assembler", then this code is not suitable for you.
In the kernel rendition I'm currently developing, I have the activity pin simultaneuously tell me serially the number of unused clock cycles available...... really cool!
Cheers,
Peter (pjv)