To ORGH or not to ORGH?
rjo__
Posts: 2,114
I am using P123(A9), and I'm wondering if this occurs just on the A9 or whether it also occurs in silicon.
While updating my PropCam code from P2v14, which worked fine, I ran into a hiccup using coginit and cogstop.
To illustrate, I have taken Chip's 640x480 8bpp example and added my coginit after his hubset instruction.
and then after his code added:
I get various results depending upon the first instruction after PropCam_Acq. as explained in the code.
While updating my PropCam code from P2v14, which worked fine, I ran into a hiccup using coginit and cogstop.
To illustrate, I have taken Chip's 640x480 8bpp example and added my coginit after his hubset instruction.
DAT org ' ' Setup hubset #$FF 'set clock to 80MHz coginit #2,##@PropCam_Acq
and then after his code added:
org
PropCam_Acq
'nop 'if this is first instruction everything fine
'waitx ##80_000_000 'if this is first instruction ... no display
'cogid camera_number 'if this is first instruction ... bad lut
'cogstop #2 'if this is first instruction ... bad lut
temploop jmp #temploop
camera_number res 1
I get various results depending upon the first instruction after PropCam_Acq. as explained in the code.
Comments
Try using an ORGH in your section...
You need an ORG too...
org $400 gives me … "cog origin exceeds limit"
I tried moving my coginit after the lut had loaded, but it made no difference.
I don't see anything in your code that looks wrong. I will try this out later when I'm at my computer.
Do you see anywhere in the code where maybe some RAM is being used for workspace that might overwrite your tiny program that goes into cog 2?
I don't see anything. Maybe v32i didn't load correctly. I'll trying the PX route again.
just guessing,
Mike
Pnut does not.
Mike
DAT 'Start of HyperRAM test code orgh 0 org 0I think orgh puts it over $400
As for the P2-ES, any time you need to start the PLL (or change its frequency) the WAITX interval is mandatory; PLL needs to stabilize, before it can be allowed to drive Sysclk.
Using the following code snippet, extracted form from RJSM's Hyperram code, as an example:
hubset #0 ' set 20MHz+ mode hubset ##_SETFREQ ' setup oscillator waitx ##20_000_000/100 ' ~10ms hubset ##_ENAFREQ ' enable oscillatorA procedure like the one above is of general usage, and no one has reported any bug related to it.
Since you are not using any debug facilities, if some lazy slug did found its way under the doors, it can be seating at the wrong place, unnoticed.
Seems I just waste the first $400, so don't have to think about it...
My code starts out like this:
DAT 'Start of HyperRAM test code orgh 0 org 0 '+-------[ Set Xtal ]----------------------------------------------------------+ ' RJA: New for real P2 hubset #0 ' set 20MHz+ mode hubset ##_SETFREQ ' setup oscillator waitx ##20_000_000/100 ' ~10ms hubset ##_ENAFREQ ' enable oscillator '+-----------------------------------------------------------------------------+ coginit #Serial_Cog,##@SerialStart coginit #HyperRam_Cog,##@HyperInit coginit #VGA_Cog,##@VGA_Driver 'this one has to be last as overwrites this cog endStart jmp #endStartThen, the other cog code just starts with this:
That was it... in addition to the fact that I used # rather than ## in the coginit... had changed it while I was messing around and then forgot I changed it.
Thanks everyone...
wow... a day of worrying about absolutely nothing:)
Maybe it could be trained, to wander at your monitor's screen, searching for missing #s, then filling the blanks, with their tracks.
Given the actual stage of my sight capabilities, its 8"-long body will help me to don't foot-step on its head.
https://nationalgeographic.com.au/australia/new-hot-pink-slug-found-in-australia.aspx
Henrique
Then we would have one slug correcting another slug.
I don't get why we have single #'s. Doesn't a ## work whenever a # does?
And about this orgh business... what?
I didn't need orgh before and I was pounding my P2v... up til v14 after which I really did get distracted for a while.
(These are mostly rhetorical question, since I probably won't understand the answers:)
SO.... originally I fixed my problem by using an Org only instruction and then inserting a NOP instruction at the beginning of my code section... thinking that there was a timing issue.
This worked fine, but it bothered me.
Then I tried inserting a waitx instead of a NOP at the beginning of the code section and it failed (no matter how large or small I made the wait period.)
Why does inserting a NOP solve the problem if the problem is that I wasn't using ORGH?
See what I mean?
EDIT: Err, loadp2 only fills 3 of the 4 allotted longwords, so COGINIT would be safe. I'll have a look at your code ...
You're not alone. I'm all for the slugs and snails. Let the spins for the Props; I'm just a "linear" wandering being.
Sure, we do understand the answers; each one has its own share of responsibility, by letting computers get where they are, now.
Five++ decades doing hardware, four++++ coding, and I always feel amissed, dealing with the several syntaxes I've passed by.
Many times I get myself wondering why and when I did lose sight of my first 400 Series Compucorp programmable calculator (4 kB of memory, 56-bit mantissa, 8-bit exponent, both signed), where I did learn, with a lot of fun, and also a ton of limitations concerning code&data organization, almost 80% of what I can do with the right processor.
Propellers are my best bets, to recover all the time and joy I did lost, so far.
So, I commented out everything having to do with VGA and images and toggled PNUT into PASM view.
It is pretty clear... that without the ORGH, the fact that my code was not interfering with the VGA code was accidental.
I am the luckiest person I know, but this would be a new record for me.
And with the RESs, ORGH $400 isn't specifically needed either, $100 works too, for example.
I've always been wary of using RES in the past. I must have bumped into this before but didn't understand it at the time. Still don't really.
That finding might be of interest to you guys. It would be good to understand if we're coding wrong or if there is a common bug in the tools.