I am pretty sure that is not the case... # is absolute address, @ is relative address.
Correct!
Typing+thinking while eating breakfast is awkward.
I'm not as good at multi-tasking as the P2!
Post Edit: Now I remember where I was going with JMP @ and JMP #.
I have been using the two different types of JMP to distinguish the difference between HUB and COG mode code.
As PNUT is not colorized yet it helps me tell the difference between to the two modes.
Hopefully in the final IDE ORGH and ORG will have their own background colors.
I was trying to build ozpropdev's test tool and PNUT told me there was no longer an ENCOD instruction! Its not in the latest instruction list and I haven't found its replacement in the blog thread. Anybody know what it became?
Brian, do you have an update for your tool you'd like to share? Please??
Thanks, all!
It's been renamed to BLSIZE, as it's the complement to BLMASK.
Bill, you could always run a monitor on another COG too. That's what I do with a second prop plug.
I think Chip fixed the list output from Pnut to work as a copy paste too. If he has, you can also leave the thing running, and use a monitor to upload the image, then launch it with the monitor in another COG.
Good point, I will have to hook up a second serial port.
Oh! I forgot about the list feature of PNut. Is there a cheat-sheet for all the options, pseoudo-ops and command keys for PNut? I know it is quite powerful, but I have to get to that power
Right now I am making the tools... to make tools... to port my earlier P2 code to the new improved P2.
I am looking for something like ".ALIGN 4" that I can stick before BYTE or WORD declarations to make sure they are long aligned (for use with LOC*)
BYTE 0[4-($ mod 4)] or some variation should work. Will test and report.
Bill, you could always run a monitor on another COG too. That's what I do with a second prop plug.
I think Chip fixed the list output from Pnut to work as a copy paste too. If he has, you can also leave the thing running, and use a monitor to upload the image, then launch it with the monitor in another COG.
...and if he hasn't, you can always edit the list a little. Remember you only need one address line, colons for the others, unless you want to break up data and put it in various places in RAM.
Just tried it. PNut acceps orgw and orgl, however orgl does not force long alignment.
The good news is that if a locptra refers to a non-long aligned label, PNut says so - opening a dialog "Address is not long" so it is easy to manually pad! (Thanks Chip!)
I just made a cog-only version. ptra gets the correct hub address, yet garbage is printed.
Could the problem be with the uart?
Update2:
Dropping the baud rate on the p2 to 9600 made no difference.
This problem is officially driving me nuts.
Bill, when you do a JMP #address, you need to do JMP #address>>2, since the JMP needs the top 16 bits of the address, and not the bottom two bits. This is a semantics issue with the assembler that needs some rethinking. One way to avoid this issues is to just do JMP @address. I'm surprised you were getting anything to work, at all.
I just looked at the assembler and I had already made provisions for handling these 16-bit address automatically, so the above was wrong. It should already work.
Just tried it. PNut acceps orgw and orgl, however orgl does not force long alignment.
The good news is that if a locptra refers to a non-long aligned label, PNut says so - opening a dialog "Address is not long" so it is easy to manually pad! (Thanks Chip!)
Within a DAT section, you can do a LONG without any data following, in order to pad $00 bytes to the next long address.
You can also do an ORGW to pad to the next wide address, both within a cog section (ORG) and a hub section (ORGH).
I'll try that; however I thought that jmp/call would do the >>2 when dealing with addresses >512 automagically... I guess I was thinking a bit ahead of the game
I was trying both @ / # 16bit hub addresses, in order to eliminate one or the other as being the issue. I just never thought to >>2 ... duh. I'll try it with the >>2 when I am back upstairs
What I don't understand is how it managed to work sometimes!!!
OH!
If all the hub is cleared to 0, and if 0 is effectively a NOP, could it have been running "around" the whole hub?
(I am in my lab right now, working on RoboPi, as wifey is napping - but I moved the DE2 upstairs last nite so I could sneak in some quality P2 time on the weekend, it will be moving back to the lab on Monday)
Bill, when you do a JMP #address, you need to do JMP #address>>2, since the JMP needs the top 16 bits of the address, and not the bottom two bits. This is a semantics issue with the assembler that needs some rethinking. One way to avoid this issues is to just do JMP @address. I'm surprised you were getting anything to work, at all.
Bill, when you do a JMP #address, you need to do JMP #address>>2, since the JMP needs the top 16 bits of the address, and not the bottom two bits. This is a semantics issue with the assembler that needs some rethinking. One way to avoid this issues is to just do JMP @address. I'm surprised you were getting anything to work, at all.
I'll try that; however I thought that jmp/call would do the >>2 when dealing with addresses >512 automagically... I guess I was thinking a bit ahead of the game
Bill,
I went back to the FPGA Build (6 Feb 2014) and loaded your code.
Very mixed results this time!
Using F11 did not work every time. The LEDs worked but serial data was garbage.
Retrying multiple times worked sometimes, seems random the successful loads.
The plot thickens...
Cheers
Brian
Comments
Thanks! Worked like a charm.
Found a better way:
locptra #hello_world+$380
I am pretty sure that is not the case... # is absolute address, @ is relative address.
Both forms worked for me, and the print string loop now works in both hub and cog mode.
Even
locptra @hello_world+$380
works!
Looks like Chip forgot to offset the locptra (and probably locptrb) addresses by the hub offset of $E000 in PNut...
I remember that $E00 offset from previous binaries, however I remember reading that Chip got rid of the need for it.
$E00 >> 2 = $380 which can be added at assembly time instead of runtime with an ADDPTRA with an AUGS (saving two longs)
I wonder if the other LOC* instructions?
Correct!
Typing+thinking while eating breakfast is awkward.
I'm not as good at multi-tasking as the P2!
Post Edit: Now I remember where I was going with JMP @ and JMP #.
I have been using the two different types of JMP to distinguish the difference between HUB and COG mode code.
As PNUT is not colorized yet it helps me tell the difference between to the two modes.
Hopefully in the final IDE ORGH and ORG will have their own background colors.
locptr @hello_world
should not need the +$380 offset, as it is supposed to be a relative offset.
Looks like PNut is not computing the relative address correctly for LOCPTR (and probably all LOC* instructions)
Hmmm, that might explain a weird bug I'm trying to chase. A BUG in my DEBUGGER!
It's been renamed to BLSIZE, as it's the complement to BLMASK.
If you make a program that used F11 to download, where you must start your program with an ORGH $380, the addresses will be in the proper places.
I tried what you suggested, and it did not work. Here is my test program, with comments as to what worked and what did not.
I'm still looking into it some more.
Idea for the next FPGA image:
If key0 is held down when the reset button is pressed (on the adapter board) the chip resets into the monitor... but does not clear the hub memory
This would allow for post-mortem analysis.
I think Chip fixed the list output from Pnut to work as a copy paste too. If he has, you can also leave the thing running, and use a monitor to upload the image, then launch it with the monitor in another COG.
Oh! I forgot about the list feature of PNut. Is there a cheat-sheet for all the options, pseoudo-ops and command keys for PNut? I know it is quite powerful, but I have to get to that power
Right now I am making the tools... to make tools... to port my earlier P2 code to the new improved P2.
I am looking for something like ".ALIGN 4" that I can stick before BYTE or WORD declarations to make sure they are long aligned (for use with LOC*)
BYTE 0[4-($ mod 4)] or some variation should work. Will test and report.
I think those keys are in the menus.
Yeah, early on when I was writing the monitor document, I just left it on and sent code back and forth. Spiffy!
It complained about lack of a pub, so I added 'pub dummy' at the end of the file.
DUH. I can't belive I missed those keys in the menu!!!! I am getting old.
$1000 will contain $F0
And of course, the other thing to do is launch the monitor right away, then let the program run. Either way, you can get to the data after the fact.
Bill,
Chip used this in his multi-thread example:
There may be similar for word and long alignment?
Good point!
Rick,
Just tried it. PNut acceps orgw and orgl, however orgl does not force long alignment.
The good news is that if a locptra refers to a non-long aligned label, PNut says so - opening a dialog "Address is not long" so it is easy to manually pad! (Thanks Chip!)
Use Ctrl-M for PASM programs. It won't demand a PUB.
Unfortunately I have to report that either my DE2-115 is defective, or there are some issues with the FPGA image.
Problem #1:
I have to hit F11 twice for the download to work if I do not power cycle the DE2 - by work I mean the LED's showing the hub address
This is 100% repeatable.
Problem #2:
There is something wonky with hubexec or locptra or FPGA emulation state being preserved over prop resets.
LED's are set to getptra result, before send text loop.
Counting longs the string is at long address $393, getptra returns %111001001100 which is correct. CTRL-M listing confirms string is at $E4C ($393)
On a freshly powered up DE2-115, I have a small chance of the code working correctly (defined as "Hello World!" being sent over the serial port)
If the code happens to work, and I re-download again (no changes), it prints garbage.
If I power down the DE2, wait some time, power up, program the same unchanged code, there is maybe a 1:10 chance of it working correctly.
I tried to see if it was the issue Ale reported re/ 6th instruction in hubexec mode, it did not seem to make a difference.
I tried disabling the icache, no difference.
I dropped the clock multiplier to 12 for 60Mhz.
download #1 - no LED's as usual
download #2 - printed garbage
download #4 - no LED's
download #5 - worked @ 60Mhz
download #6 - no LED's as usual
download #7 - printed garbage
download #8 - no LED's as usual
download #9 - printed garbage
download #10 - no LED's as usual
download #11 - printed garbage
powered off for about 30 sec
download #1 - LED's OK, correct output
download #2 - no LED's as usual
download #3 - printed garbage
powered off for about 30 sec
download #1 - printed garbage
download #2 - no LED's as usual
download #3 - printed garbage
download #4 - no LED's as usual
download #3 - printed garbage
Put clock back to 80MHz... problem persists
Test code:
CON _rx = 91 _tx = 90 DAT orgh $380 start org clkset #$FF 'set 80MHz setsera ser_parms, bit_time clrp #_tx ' Enable _tx pin mov dirb,leds mov outb,#1 ' if we don't get to another outb, we jumped to never-never land jmp #hubexec ser_parms long %10 << 16 + _rx << 9 + %10 << 7 + _tx bit_time long 80_000_000 / 115200 ch long 0 leds long $FFF '---------------------------------------------------------------- orgh nop nop ' nop ' nop ' nop ' nop hubexec locptra #hello_world ' orgh, F10 download works $38A Put ' mov outb,##hubexec ' $38B/C ' mov outb,##hello_world getptra outb nop loop rdbyte ch, ptra++ wz ' $38D if_nz serouta ch ' $38E if_nz jmp #loop ' $38F jmp @hubexec ' $390 hello_world byte "Hello World!",13,10,0 ' $391 bub serouta #64 jmp #bubEveryone: I'd appreciate it if you guys with DE2-115's could replicate the issue.
Update:
I just made a cog-only version. ptra gets the correct hub address, yet garbage is printed.
Could the problem be with the uart?
Update2:
Dropping the baud rate on the p2 to 9600 made no difference.
This problem is officially driving me nuts.
Bill, when you do a JMP #address, you need to do JMP #address>>2, since the JMP needs the top 16 bits of the address, and not the bottom two bits. This is a semantics issue with the assembler that needs some rethinking. One way to avoid this issues is to just do JMP @address. I'm surprised you were getting anything to work, at all.
I just looked at the assembler and I had already made provisions for handling these 16-bit address automatically, so the above was wrong. It should already work.
Within a DAT section, you can do a LONG without any data following, in order to pad $00 bytes to the next long address.
You can also do an ORGW to pad to the next wide address, both within a cog section (ORG) and a hub section (ORGH).
I'll try that; however I thought that jmp/call would do the >>2 when dealing with addresses >512 automagically... I guess I was thinking a bit ahead of the game
I was trying both @ / # 16bit hub addresses, in order to eliminate one or the other as being the issue. I just never thought to >>2 ... duh. I'll try it with the >>2 when I am back upstairs
What I don't understand is how it managed to work sometimes!!!
OH!
If all the hub is cleared to 0, and if 0 is effectively a NOP, could it have been running "around" the whole hub?
(I am in my lab right now, working on RoboPi, as wifey is napping - but I moved the DE2 upstairs last nite so I could sneak in some quality P2 time on the weekend, it will be moving back to the lab on Monday)
from the cog code, jmp #hubexec>>2 went off to never never land, while jmp @hubexec and jmp #hubexec went to the right place.
Garbage output most of the time.
I'll put in a bit-banged serial output, if that works, than the issue pretty much has to be in serouta.
If the bit-banged serial does not work, I'll just go to the wall and bang my head against it.
FYI Bull, I tried your code "as is" on my DE2 and it loads with F11 everytime and "Hello world" transmits OK everytime.
I think you might have figured out the solution.
I went back to the FPGA Build (6 Feb 2014) and loaded your code.
Very mixed results this time!
Using F11 did not work every time. The LEDs worked but serial data was garbage.
Retrying multiple times worked sometimes, seems random the successful loads.
The plot thickens...
Cheers
Brian
I think I have it figured out.
While I cannot discount the possibility that some of my testing issues were due to the issue found by Brian, I found an even more basic issue.
The problem turns out to serialouta being too fast for PropPlugs.
I am not kidding.
Once I got my bit-banged output routine running, attached below, I had the same bad behavior.
Then the proverbial coin dropped, and I came up with a testable theory:
The P2, with serouta AND bitbanged serial output was transmitting bytes back to back, with stop bits right up against start bits!
I added four extra stop bit periods, and it works fine now with the software serial output.
I will test and determine how many stop bits are needed to male the PropPlug happy.
I *STRONGLY* recommend adding variable number of stop bits to serouta/b, or an optional inter-character delay (in bit periods).
Now I'll run some tests to see how many stop bits I need on my specific PropPlug.
Stay tuned...
Bill, I just discovered the same thing by adding a 10 second delay to give me enough time to start PST.
Cheers
Brian