Seeking an uber-short, single cog, color bar video test, + a linking question.
epmoyer
Posts: 314
Greetings folks,
I'm in the process of putting together the production test software for my Coyote-1 device (www.openstomp.com) and I find myself wanting to embed the production test code into the shipping firmware image. That means that the production test code will need to be code-efficient to leave as much room as possible for the operational code. In order to verify the video in production I'm going to have the manufacturer connect the video output to a display and verify a color bar pattern. I'm looking to write the shortest possible single-cog routine to display some basic color bars. I know there are a lot of renderer tinkerers in the Hydra community so I thought I'd toss it out there and not reinvent the wheel if someone's already got something that would do the trick. Any takers?
On another subject, I use a good chunk of RAM (6K+) for various data buffers in the firmware. It would be possible to "reclaim" the code space used for the diagnostic code and use it for those buffers, since the two will never be used concurrently. I haven't gone poking around yet to figure out how the Propeller Tool orders code assets in a compile. I'd like to locate the diagnostic code so that it appears last, and as one contiguous block, in the "Program" section and abuts the beginning of the "Variable" section. Can anyone shed any light on the order in which modules are stored in EEPROM/RAM during a compile? I am guessing/hoping that linking is performed in the order declared and that declaring the diagnostic objects last in the top file will ensure that they are last in the EEPROM/RAM image. Is there any way to get the equivalent of a memory map out of the Propeller Tool to verify where things are being stored?
Thanks!
-Eric
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The World's First Open Source Guitar Pedal:··http://www.OpenStomp.com
I'm in the process of putting together the production test software for my Coyote-1 device (www.openstomp.com) and I find myself wanting to embed the production test code into the shipping firmware image. That means that the production test code will need to be code-efficient to leave as much room as possible for the operational code. In order to verify the video in production I'm going to have the manufacturer connect the video output to a display and verify a color bar pattern. I'm looking to write the shortest possible single-cog routine to display some basic color bars. I know there are a lot of renderer tinkerers in the Hydra community so I thought I'd toss it out there and not reinvent the wheel if someone's already got something that would do the trick. Any takers?
On another subject, I use a good chunk of RAM (6K+) for various data buffers in the firmware. It would be possible to "reclaim" the code space used for the diagnostic code and use it for those buffers, since the two will never be used concurrently. I haven't gone poking around yet to figure out how the Propeller Tool orders code assets in a compile. I'd like to locate the diagnostic code so that it appears last, and as one contiguous block, in the "Program" section and abuts the beginning of the "Variable" section. Can anyone shed any light on the order in which modules are stored in EEPROM/RAM during a compile? I am guessing/hoping that linking is performed in the order declared and that declaring the diagnostic objects last in the top file will ensure that they are last in the EEPROM/RAM image. Is there any way to get the equivalent of a memory map out of the Propeller Tool to verify where things are being stored?
Thanks!
-Eric
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The World's First Open Source Guitar Pedal:··http://www.OpenStomp.com
Comments
Re your question on reclaiming memory, I'm afraid the news is not very good. See this thread:
http://forums.parallax.com/showthread.php?p=670353
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Michael Park
PS, BTW, and FYI:
To search the forum, use search.parallax.com (do not use the Search button).
Check out the Propeller Wiki: propeller.wikispaces.com/
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The World's First Open Source Guitar Pedal:··http://www.OpenStomp.com
I've just reread the above-referenced thread and have posted some additional comments. I don't know if it will help in your case, but it might.
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Still some PropSTICK Kit bare PCBs left!
Bamse's little 50 line driver is probably the best bet, also, I posted something that will do the same called the "HEL" demo a while ago, very short. However, you might want to not put the test code into the firmware and have it be a separate step. The reason being you might want a more elaborate (or need a more elaborate test then you have now) in the future. Typically, you have the test code firmware, green light, then the production app which tests something again (at least the functionality of what it does at least). This way, if you find yourself needing a more complex test program you don't have to split it out from the application firmware, and its just easier actually for the manufacturing in the long run since they are used to running the test suite then loading the final firmware, running, a quick functional test.
Andre'
As far as I know, that even works in the text only drivers, and character spaces are a good size to make color bars with.