Understanding pins better (or at all)
cheezus
Posts: 295
With all the new tricks like the streamer, registered io (almost completely lost here) and whatnot I'm looking at different ways of rewriting P1 code. Simple bit-bashing like done on p1 would probably be the easiest to get working. I've also been going the OTHER route aka converting all ASM to Spin for fastspin.
The p1 asm engine is working (quite well) on the but it's going to require an entire rewrite to be compatible with P2. There's quite a few things that will need to change but for now i'm just trying to understand the bulk transfer loop, ie
Since these are all word transfers having the streamer handle hub -> pins makes sense but I'm drawing a blank on how to sync toggling clock pins with the streamer. What I'd really WANT to do isn't possible afaik since the streamer can't output it's clock but SW might be able to handle this?
My spin code for hubtodisplay needs to be cleaned up and clock pins handled better but currently testing on P1 with fastspin.
I really haven't done anything on the p2 with the new hardware since I'm trying to understand the pins still. What is really confusing me is the P2 Doc talks about pin delays but I thought this only applies to registered IO? I guess some expansion on registered IO and such would be nice. I should probably grab an updated version of the Instructions and Documentation.
*edit - fixed formatting in code
* slightly OT
I'm currently trying to find a SD card driver. I guess fsrw would work, I guess it's time to start learning fourth!
The p1 asm engine is working (quite well) on the but it's going to require an entire rewrite to be compatible with P2. There's quite a few things that will need to change but for now i'm just trying to understand the bulk transfer loop, ie
ramtohub_loop mov data_16,ina ' get the data
wrword data_16,hubaddr ' move data to hub
andn outa,maskP20 ' clock 161 low
or outa,maskP20 ' clock 161 high
add hubaddr,#2 ' increment the hub address
djnz len,#ramtohub_loop '
or outa,maskP16 ' memory /rd high
jmp #done ' ' tristate pins and listen for command
hubtoram_loop and outa,maskP16P31 '%11111111_11111111_00000000_00000000
rdword data_16,hubaddr ' get the word from hub
or outa,data_16 ' send out the byte to P0-P15
andn outa,maskP17 ' set mem write low
add hubaddr,#2 ' increment by 2 bytes = 1 word. Put this here for small delay while writes
or outa,maskP17 ' mem write high
andn outa,maskP20 ' clock 161 low
or outa,maskP20 ' clock 161 high
djnz len,#hubtoram_loop ' loop this many times
jmp #done ' tristate pins and listen for command
hubtodisplay_loop and outa,maskP16P31 '%11111111_11111111_00000000_00000000
rdword data_16,hubaddr ' get the word from hub
or outa,data_16 ' send out the byte to P0-P15
andn outa,maskP18P19 ' ILI write low
or outa,maskP18P19 ' ILI write high
add hubaddr,#2 ' one word
djnz len,#hubtodisplay_loop ' do this many times
or outa,maskP19 ' CS high
jmp #done
Since these are all word transfers having the streamer handle hub -> pins makes sense but I'm drawing a blank on how to sync toggling clock pins with the streamer. What I'd really WANT to do isn't possible afaik since the streamer can't output it's clock but SW might be able to handle this?
My spin code for hubtodisplay needs to be cleaned up and clock pins handled better but currently testing on P1 with fastspin.
PRI LCD_Writ_Bus(LCDLong)
LCDLong &= $0000_FFFF
OUTA &= %11111111_11111111_00000000_00000000 ' set P0-P15 to zero ready to OR
OUTA |= LCDLong ' merge with the word to output
' send out the data
LCD_CS_Low
LCD_WR_Low
LCD_WR_High
LCD_CS_High
PRI LCD_WR_Low
OUTA &= !LCD_WR
PRI LCD_WR_High
OUTA |= LCD_WR
PRI LCD_CS_Low
OUTA &= !LCD_CS
PRI LCD_CS_High
OUTA |= LCD_CS
I really haven't done anything on the p2 with the new hardware since I'm trying to understand the pins still. What is really confusing me is the P2 Doc talks about pin delays but I thought this only applies to registered IO? I guess some expansion on registered IO and such would be nice. I should probably grab an updated version of the Instructions and Documentation.
*edit - fixed formatting in code
* slightly OT
I'm currently trying to find a SD card driver. I guess fsrw would work, I guess it's time to start learning fourth!
Comments
I think the intended approach on P2, is to generate CLKs on one smart pin, and attach the streamer to that clock.
Chip was going to look into getting a CLK out at SysCLK speeds, because right now a smart pin cannot export at SysCLK (only /2,/3..) but the streamer can run at SysCLK, so there is a blindspot there.
Not sure of the status of that fix ?
I am going to talk to Wendy about this.
While being able to output @ sysclock using the streamer would be nice, I don't think it's really necessary for what I want to do. The devices on the bus have max clock < 20mhz so even bit-bashing @ 160mhz will probably be sufficient to get maximum bandwith on the bus. I was thinking that having the streamer handle hub -> pins would free up the cog for pre-processing the hub data before the streamer did it's thing, I'm not sure how much this would really improve things. The biggest bottleneck is, was and will always be the SD card!
From what I understand, it should be possible to setup a smartpin as a clock and then setup the streamer with the same period. Then you'd phase align the NCOs, enable streamer and then enable the clock output. Maybe the streamer would need a "dummy clock" or two to allow time to enable the smartpin? I guess I should go through the smartpin docs again because the more I think about it there's got to be a mode for "output x number of clocks". If this is possible for sysclock/2 or /4 or even /16 or something I might try it at some point. Am I even close??? LOL
eg the DOCs say this
%00100 = pulse/cycle output
This mode overrides OUT to control the pin output state.
X[15:0] establishes a base period in clock cycles which forms the empirical high-time and low-time units.
X[31:16] establishes a value to which the base period counter will be compared to on each clock cycle, as it counts from X[15:0] down to 1, before starting over at X[15:0] if decremented Y > 0. On each clock, if the base period counter > X[31:16] and Y > 0, the output will be high (else low).
Whenever Y[31:0] is written with a non-zero value, the pin will begin outputting a high pulse or cycles, starting at the next base period.
Some examples:
If X[31:16] is set to 0, the output will be high for the duration of Y > 0.
If X[15:0] is set to 3 and X[31:16] is set to 2, the output will be 0-0-1 (repeat) for the duration of Y > 0.
IN will be raised when the pulse or cycles complete, with the pin reverting to low output.
During reset (DIR=0), IN is low, the output is low, and Y is set to zero.
I think that translates to mean this
Cycles Generated = Y[31:0] Zero disables/stops
Period = SysCLK/X[15:0] (but 0,1 are illegal ?)
DutyCycle = X[31:16]/X[15:0]
The above mode should be valid for SysCLK/2../2^15 in steps of 1, with odd numbers not having 50% clock duty cycles.
Do you mean adding external components ? Yes, that is possible, but requires the user design the PCB with that in advance, and rather defeats the 'Smart Pins' moniker.
Those external parts also add a delay to the clock.