Wish there were an easier way to switch code from port A to port B...
Is there a way to just say DIR # and have the compiler decide if it's A or B?
It should be straightforward to have a generic Port mnemonic, that can auto-map to either of Port A or Port B.
Some uses would result in errors, if the user tried to span both ports.
Other MCUs allow you to name a Pin, and then later use of that name, auto-selects the correct opcode combinations.
There probably needs to be an operator to collect pin names into a pin mask, for mask/multi0le operations.
Once things are settled, maybe there needs to be an A9 build bypassing the on board LEDS and switches and bringing all the P2 pins out to headers as raw pins. At some point we'll be testing things beyond blinking LEDs. If that is even possible on the A9 board...I forget how it is wired up.
Once things are settled, maybe there needs to be an A9 build bypassing the on board LEDS and switches and bringing all the P2 pins out to headers as raw pins. At some point we'll be testing things beyond blinking LEDs. If that is even possible on the A9 board...I forget how it is wired up.
(Sorry for another custom build request, Chip! )
Actually, at this point (when I have a USB mouse and USB keyboard connected) I don't see much use for the buttons and LEDs on the P123 board... (Ok, well maybe buffered LED are fine, that's kinda fun to see what's what)
On the A9, the DIR/OUT[63:0] drive {P[63], fpga_tx, P[61:0], while IN is driven by {fpga_rx, P[62:60], PB[3:0], P[55:0]}. So, the only unexpected thing is the pushbutton set, sneaking in on IN[59:56].
One thing that's been kind of a headache is that the physical hub RAM map wraps around within the 1MB hub map. For example, a 32KB physical hub repeats 32 times in the hub space. If you write just beyond the physical RAM limit, you overwrite early addresses. This creates horrible failures that bring everything to a halt.
To fix this problem, I made the egg-beater qualify the addresses to the hub RAM slices before it enables them. If you remember, there are 64 bytes at the end of the hub ($FFFC0..$FFFFF) that hold 16 debug interrupt vectors. You really don't want to overwrite those accidentally.
So, now, if you read from the physical RAM top, minus 63, to $FFFBF, you get $0000_0000's. Writes to that nether region don't do anything.
Reads and writes, from $00000 to physical RAM top minus 64, access the RAMs, as well as reads and writes from $FFFC0..$FFFFF.
I wanted to get this in before the coming release, as it simplifies the development tools, as well.
On the A9, the DIR/OUT[63:0] drive {P[63], fpga_tx, P[61:0], while IN is driven by {fpga_rx, P[62:60], PB[3:0], P[55:0]}. So, the only unexpected thing is the pushbutton set, sneaking in on IN[59:56].
Is that special mapping of PB still required now ?
( Seems more useful in very early bring-up testing )
What is the setting of 'Live' Smart Pins, in the present test build, and the upcoming build ? At one stage some Smart Pins were removed to make it fit ?
... If you remember, there are 64 bytes at the end of the hub ($FFFC0..$FFFFF) that hold 16 debug interrupt vectors. You really don't want to overwrite those accidentally.
Should those still be mapped at 1M ? - is it easy to move them up, as the road map may include 1MB or even above devices.
Seems best to avoid placing a speed-bump right in the middle of what could become RAM ?
So, now, if you read from the physical RAM top, minus 63, to $FFFBF, you get $0000_0000's. Writes to that nether region don't do anything.
Reads and writes, from $00000 to physical RAM top minus 64, access the RAMs, as well as reads and writes from $FFFC0..$FFFFF.
Might it be wise to go further, have addressing range beyond 1MB, and qualify to full 32bit addressing so those 64 addresses then sit at $FFFFFFC0? I guess it adds more address lines but does add even more future proofing.
Comments
Trying to use P56..P59.
I read ~1.0 V there with both my cogs setting DIRB and OUTB to #0
This is A9 board...
If I rotate my test board 180 degrees to have it on P4..P7, then it works.
Can't get it to work on P56..P59...
It should be straightforward to have a generic Port mnemonic, that can auto-map to either of Port A or Port B.
Some uses would result in errors, if the user tried to span both ports.
Other MCUs allow you to name a Pin, and then later use of that name, auto-selects the correct opcode combinations.
There probably needs to be an operator to collect pin names into a pin mask, for mask/multi0le operations.
Did you check the binary opcode, to see if it matches the latest build ? Could maybe be tool-skew ?
P56..P59 inputs are connected to the pushbuttons on the P123 board.
P56..P59 outputs are connected to header.
What is safe to use on Port B?
P48 to P54 should be free.
I'm seeing that 1V on P54 and P55 too...
Actually, there's voltage on a lot of pins lower than P54 too...
Puts a damper on my idea of putting a lot of stuff on this board...
Not sure where that is in the mix now, with latest LUT changes?
http://forums.parallax.com/discussion/comment/1372466/#Comment_1372466
(Sorry for another custom build request, Chip! )
Actually, at this point (when I have a USB mouse and USB keyboard connected) I don't see much use for the buttons and LEDs on the P123 board... (Ok, well maybe buffered LED are fine, that's kinda fun to see what's what)
Much rather have PortB same as PortA...
Re: P32.. to P47 on P123 board.
A quick look at the schematic shows the leds are connected to separate FPGA pins so they should Ok on the header.
I can remove things from my board and move stuff to the lower 16 pins of Port B, but going to be a routing pain...
There's something strange about the pins with DIR/OUT=0:
With no load, they seem to read 1 V. But, they go to zero Volts with a load...
Strange... It's like they need a load current to pull themselves down...
That's fine, I'll just move things down the port...
To fix this problem, I made the egg-beater qualify the addresses to the hub RAM slices before it enables them. If you remember, there are 64 bytes at the end of the hub ($FFFC0..$FFFFF) that hold 16 debug interrupt vectors. You really don't want to overwrite those accidentally.
So, now, if you read from the physical RAM top, minus 63, to $FFFBF, you get $0000_0000's. Writes to that nether region don't do anything.
Reads and writes, from $00000 to physical RAM top minus 64, access the RAMs, as well as reads and writes from $FFFC0..$FFFFF.
I wanted to get this in before the coming release, as it simplifies the development tools, as well.
Is that special mapping of PB still required now ?
( Seems more useful in very early bring-up testing )
What is the setting of 'Live' Smart Pins, in the present test build, and the upcoming build ? At one stage some Smart Pins were removed to make it fit ?
Should those still be mapped at 1M ? - is it easy to move them up, as the road map may include 1MB or even above devices.
Seems best to avoid placing a speed-bump right in the middle of what could become RAM ?
Or is it? Guess I forget...
PS: The smaller parts could have a reduced implementation to save even more flops/gates.