Shop OBEX P1 Docs P2 Docs Learn Events
Port B and Counters, Video Generators and FSRW — Parallax Forums

Port B and Counters, Video Generators and FSRW

65816581 Posts: 132
edited 2014-10-28 22:44 in Propeller 1
Hello,

I collected various P1V code modifications from the forums and integrated them into my git[1] repository.
So far it includes:
- PORTB (additional 32-bit output, usable with BST / Propeller Tool)
- Non-tested counters and video generator on portb (testers needed)

Pin Mapping:
- PORTA 0-31: As the original release (Edit: P28/29 are on-board EEPROM now).
- PORTB 0-27: On left (P2) header as 3.3V LVTTL
- PORTB 28-31: Mapped to internal SD-Card slot.

Now I am trying to port the SD-Card Driver (FSRW) to PORTB to use the the on-board
SD-Card - so far without success. I replaces all ina/outa/dira with the dirb/outb/dirb statements
and have some trouble now with the ctra/ctrb registers and the PINB setup - maybe somebody would
like to try this out or help me with the syntax? I am a bit confused by the SPIN shift statements.


Update: Working version at:

https://git.no-route.org/syso/p8x32a_emulation/repository/archive.zip?ref=v0.4a-PORTB-Counters-Working


--
1. https://git.no-route.org/syso/p8x32a_emulation/commits/v0.4-PORTB (ZIP-Download at https://git.no-route.org/syso/p8x32a_emulation/repository/archive.zip?ref=v0.4-PORTB)

Comments

  • jac_goudsmitjac_goudsmit Posts: 418
    edited 2014-10-16 13:37
    6581 wrote: »
    Hello,

    I collected various P1V code modifications from the forums and integrated them into my git[1] repository.

    Great stuff, 6581!

    I see you cloned my Github repo, so it should be easy to pull your changes back in, once I figure out how to do that :-)

    I'm reviewing your changes now, the only minor problem I've noticed so far is that you added tabs back to the source.


    Screenshot 2014-10-16 16.32.54.png

    To get to this dialog, open a file in the Quartus editor, then click Tools>Options and go to the Text Editor item in the list on the left (if the Editor item isn't there, it means you don't have a file open in the editor). Make sure the "insert spaces on tab" checkbox is on.

    Further updates will follow.

    Thanks!

    ===Jac
  • Cluso99Cluso99 Posts: 18,069
    edited 2014-10-16 13:55
    Nice work 6581.

    Do you have the SD card working on Port A? That might be the best option to start with. I have a PropOS that works with Port A if that helps to ensure the SD card is working - I use Kye's SD driver.
  • pik33pik33 Posts: 2,366
    edited 2014-10-16 21:08
    I have tested SD card working on Port A using Kye's driver (a modified version with LFN reading) so this works OK with P1V. The kbm and Kye's HIDEngine works too, using a self-made PS2 Y cable I have a keyboard (tested with KBM driver, not Kye's) and mouse running.

    I am not trying to use a port B with video/counters because I use it for the system bus. All inb/outb bits are then data bits,
  • 65816581 Posts: 132
    edited 2014-10-17 00:55
    Cluso99 wrote: »
    Nice work 6581.

    Do you have the SD card working on Port A? That might be the best option to start with. I have a PropOS that works with Port A if that helps to ensure the SD card is working - I use Kye's SD driver.

    Thank you! Yes, Port A works perfectly with FSRW and SIDcog etc.
    It seems that I am just missing something when setting the CTRA register.

    Maybe somebody could write a test program which uses the counter on Port B?
  • 65816581 Posts: 132
    edited 2014-10-17 01:06
    Great stuff, 6581!

    I see you cloned my Github repo, so it should be easy to pull your changes back in, once I figure out how to do that :-)

    I'm reviewing your changes now, the only minor problem I've noticed so far is that you added tabs back to the source.


    Screenshot 2014-10-16 16.32.54.png

    To get to this dialog, open a file in the Quartus editor, then click Tools>Options and go to the Text Editor item in the list on the left (if the Editor item isn't there, it means you don't have a file open in the editor). Make sure the "insert spaces on tab" checkbox is on.

    Further updates will follow.

    Thanks!

    ===Jac

    Thanks Jac,
    I have now replaced the tabs with whitespaces and commited! Just pull from -master.
  • 65816581 Posts: 132
    edited 2014-10-21 02:31
    I still cannot get it running. It seems like the counters don't work at all.
    Maybe somebody could review my changes?

    https://git.no-route.org/syso/p8x32a_emulation/compare/327d0b911937162d9024533c3b6c6dace66bb169...9f51f0eea5535e0774d554eb59c643a1839167b3
    (scroll down to see changes)

    Test spin code:
    https://git.no-route.org/syso/p8x32a_emulation/raw/Altera/tests/test_counter_pinb.spin
  • jac_goudsmitjac_goudsmit Posts: 418
    edited 2014-10-21 09:34
    There are some problems with your changes that I'll discuss later, but the counters look pretty solid.

    If you change the mode from %00100 to %00101 and add statements to set dira[0] to 1, do you see pin 0 on outa blinking? In that mode, the two timer outputs are connected to PHSx[31] and !PHSx[31] so when one output is on, the other is off and vice versa.

    I know on the BeMicroCV the pins on the second pin header are supposed to be differential and may have some limitations to voltages and other stuff. I haven't looked at the (BeMicro and Altera) documentation closely enough yet, but from what I've seen, it kinda looked like they couldn't simply be configured as 3.3V outputs. I may be wrong.

    ===Jac
  • 65816581 Posts: 132
    edited 2014-10-21 09:47
    There are some problems with your changes that I'll discuss later, but the counters look pretty solid.

    If you change the mode from %00100 to %00101 and add statements to set dira[0] to 1, do you see pin 0 on outa blinking? In that mode, the two timer outputs are connected to PHSx[31] and !PHSx[31] so when one output is on, the other is off and vice versa.

    I know on the BeMicroCV the pins on the second pin header are supposed to be differential and may have some limitations to voltages and other stuff. I haven't looked at the (BeMicro and Altera) documentation closely enough yet, but from what I've seen, it kinda looked like they couldn't simply be configured as 3.3V outputs. I may be wrong.

    ===Jac

    I will try that just now. There is a jumper which sets 2.5V or 3.3V for the 2nd pin header (J2)
    and other I/O banks. I will try and let you know!

    Port A in general with counters works.

    Update: Port B counters non functional.

    i try:
    CON _clkmode = xtal1 + pll16x
    _xinfreq = 5_000_000
    ledPin = 32+22
    dimPercent = 40

    PUB main
    DIRB := $FFFF_FFFF
    CTRA := %0_0110<<26 + ledPin
    FRQA := $7FFF_FFFF/50 * dimPercent
    repeat

    Port B stays low when using counter.
  • jac_goudsmitjac_goudsmit Posts: 418
    edited 2014-10-21 19:26
    Did you try writing some simpler programs, e.g. to blink all outputs on port A and B at the same time, or to make all port B outputs reflect one input pin on port A? That way you can verify that your pin assignments, voltages, jumpers etc. are correct. As far as I can tell, the Verilog for the timers is correct (there's not much to it), but it's probably easier to write a simple Spin program to test with values that are sent directly to dirb and outb (and reading from inb too of course), and then when that works, test it with all the clock/counter logic.

    Sorry, I don't have time right now to test your code on my hardware. I'll try to merge your code back into the Github repo later this week, but I'm really busy at work...

    ===Jac
  • 65816581 Posts: 132
    edited 2014-10-22 00:13
    Did you try writing some simpler programs, e.g. to blink all outputs on port A and B at the same time, or to make all port B outputs reflect one input pin on port A? That way you can verify that your pin assignments, voltages, jumpers etc. are correct. As far as I can tell, the Verilog for the timers is correct (there's not much to it), but it's probably easier to write a simple Spin program to test with values that are sent directly to dirb and outb (and reading from inb too of course), and then when that works, test it with all the clock/counter logic.

    Sorry, I don't have time right now to test your code on my hardware. I'll try to merge your code back into the Github repo later this week, but I'm really busy at work...

    ===Jac

    Yes, Port B reading, writing and setting direction works all fine. Toggling pin in PASM works
    also as expected. I still somehow have the feeling like I missed some connection in my
    code or if the register settings are wrong. It should use portb when APIN is set to 32+BPIN,
    so I am a bit lost now.
  • ozpropdevozpropdev Posts: 2,792
    edited 2014-10-23 23:05
    @6581
    I have PortB working on my DE0-Nano with the counters and note the following area of difference in our code.

    In cog_ctr.v
    // output pins
    
    wire [31:0] mask_a = outa << ctr[4:0];
    wire [31:0] mask_b = outb << ctr[13:9];
    
    assign pin_out = !ctr[14] && !ctr[5] ? mask_a | mask_b 
                      :!ctr[14] && ctr[5] ? mask_b
                      :ctr[14] && !ctr[5] ? mask_a
                      :32'b0;
                      
    assign pin_outb = ctr[14] && ctr[5] ? mask_a | mask_b 
                      :ctr[14] && !ctr[5] ? mask_b
                      :!ctr[14] && ctr[5] ? mask_a
                      :32'b0;
                      
    
    
    

    Hope this helps. :)
    Cheers
    Brian

    Edit: I just pasted your code into mine and it still works. I will see what other differences I can find.
  • ozpropdevozpropdev Posts: 2,792
    edited 2014-10-24 02:32
    Here is my source code of a working PortB+counters for a DE0-Nano.
    For testing I have assigned the cog leds to be OUTB[7..0].
    Sample SPIN code is also included.
    Relevant PORTB code is marked with "<=-" characters.
    Still looking for differences in code. Maybe some fresh eyes might pick it. :)
  • ozpropdevozpropdev Posts: 2,792
    edited 2014-10-24 03:02
    @6581
    I ran your test program on the DE0-nano and it works Ok.
    I noticed your using the PLL in there.
    Do you have the bug fix for the PLL in your code?
    // pll simulator
    
    reg [35:0] pll_fake;
    
    always @(posedge clk_pll)
    //if ([color=red]~&[/color]ctr[30:28] && |ctr[27:26])
       if ([color=blue]~|[/color]ctr[30:28] && |ctr[27:26])   // pll bug fix
          pll_fake <= pll_fake + {4'b0, frq};
    
    wire [7:0] pll_taps  = pll_fake[35:28];
    
    assign pll  = pll_taps[~ctr[25:23]];
    
    
  • 65816581 Posts: 132
    edited 2014-10-24 03:56
    ozpropdev wrote: »
    @6581
    I ran your test program on the DE0-nano and it works Ok.
    I noticed your using the PLL in there.
    Do you have the bug fix for the PLL in your code?
    // pll simulator
    
    reg [35:0] pll_fake;
    
    always @(posedge clk_pll)
    //if ([color=red]~&[/color]ctr[30:28] && |ctr[27:26])
       if ([color=blue]~|[/color]ctr[30:28] && |ctr[27:26])   // pll bug fix
          pll_fake <= pll_fake + {4'b0, frq};
    
    wire [7:0] pll_taps  = pll_fake[35:28];
    
    assign pll  = pll_taps[~ctr[25:23]];
    
    

    My Code looks like this
    [PHP]reg [35:0] pll_fake;

    always @(posedge clk_pll)
    if (~|ctr[30:28] && |ctr[27:26])
    pll_fake <= pll_fake + {4'b0, frq};

    wire [7:0] pll_taps = pll_fake[35:28];

    assign pll = pll_taps[~ctr[25:23]];[/PHP]

    Edit: This is the only bigger difference in our code:
    https://git.no-route.org/syso/p8x32a_emulation/commit/e79e5a9d08e87917bd2dd21672399d84bbe7fa95
    I replaced it now and will see if it works, If I've got a board near me again.

    And it also seems like the "match" part in cog.v got not checked in while my commit, so I might
    have been working with an old version.
    here are now all my changes - and I guess it should work now:
    https://git.no-route.org/syso/p8x32a_emulation/compare/a49417e2e16e39ff42af5bc98dceb91db5c7d0f5...a58d489c532603b13c95939d58264ac9990889ec
  • ozpropdevozpropdev Posts: 2,792
    edited 2014-10-24 05:40
    I still can't see anything obvious that is causing your problem.
    I configured my Nano's cog leds to show both PortA and PortB bits 0 to 3.
    Your test spin program alternates two leds Ok. (dira added and ctrmode changed to %00101).
    //Changes made to dig.v to verify OUTtA/B activity.
    
    assign cog_led = {pin_outb[3:0] & pin_dirb[3:0],pin_out[3:0] & pin_dir[3:0]}; //cog_ena;
    
    

    A mystery??? :(
  • 65816581 Posts: 132
    edited 2014-10-25 12:47
    I just tested it! That was it! PortB with Counters works perfect now!
    I even got my version of fsrw running and playing siddumps on the sidcog from an sdcard.
    Will release it soon!
  • 65816581 Posts: 132
    edited 2014-10-27 01:05
  • jac_goudsmitjac_goudsmit Posts: 418
    edited 2014-10-27 09:45
    Hey 6581, I noticed you made some changes yesterday.

    One of the changes is that in cog_ctr.v, you removed the code that used the port B (input) pins to assign dly. Can you explain why you did that? I tried to follow the discussion above, but I can't see ozpropdev's code so I don't know if the e79e5a9d08e commit is on purpose, or a mistake.

    It seems to me that the old code was correct, and after e79e5a9d08e all the input-mode CTRMODEs (i.e. all modes 01000 to 11110 except 10000) that have APIN or BPIN set to a value higher than 31 aren't going to work anymore, because bits 14 and 5 (the high bit of each port) are ignored. What's up with that?

    ===Jac

    PS incidentally, I wonder if it would be easier to work port B into the counters by changing the original cog_ctr module so that pin_in and pin_out are 64 bits instead of 32, instead of adding pin_inb and pin_outb parameters; that way you wouldn't end up with a lot of conditionals to map things to port A or B.

    Something like this:
    module              cog_ctr
    (
    input               clk_cog,
    input               clk_pll,
    
    input               ena,
    
    input               setctr,
    input               setfrq,
    input               setphs,
    
    input       [31:0]  data,
    
    input       [63:0]  pin_in, // use { ctr_pin_inb, ctr_pin_ina } as parameter in cog.v
    
    output reg  [32:0]  phs,
    
    output      [63:0]  pin_out, // use a 64-bit wire as parameter, split it to pin_outb and pin_outa in cog.v
    
    output              pll
    );
    
    

    I didn't test this but it seems to make sense since basically the counters work with 6-bit pin numbers. It would also potentially be easier to use an `if/`endif to enable/disable port B.

    I'm still in the process of reviewing your code, but I pulled your current stuff into a new 6581_Altera branch in Github. After I convince myself that it all works as planned, and that it compiles into something that's completely P1 compatible by default, I'll actually merge it into my Altera branch.
  • 65816581 Posts: 132
    edited 2014-10-27 12:26
    @jac_goudsmit:
    Indeed those changes were done on purpose and I can confirm that Port B including counters works properly
    with those changes. The changes are from ozpropdev's code. So far I cannot see any issues (looked also with
    my saleae logic analyzer). Correct me please if I am wrong :)
  • jac_goudsmitjac_goudsmit Posts: 418
    edited 2014-10-28 19:15
    6581 wrote: »
    @jac_goudsmit:
    Indeed those changes were done on purpose and I can confirm that Port B including counters works properly
    with those changes. The changes are from ozpropdev's code. So far I cannot see any issues (looked also with
    my saleae logic analyzer). Correct me please if I am wrong :)

    I will do some tests when I have some time, but as I mentioned in my previous post, I think any counter mode that depends on an input pin is not going to work when using an input pin that's on port B.

    I think the original change (that added the dependency on ctr[14] and ctr[5] to select the input pin from pin_in or pin_inb was correct, and the reason that it wasn't working until you took that out, was something else.

    For example, did you notice in the schematic that the first two pins of the B header are connected to VDD via pull-up resistors? They're intended to be used for I2C.

    ===Jac

    (notice to those reading along: beware of confusion here: the CTRA/CTRB registers refer to an "A" PIN and "B" PIN but each of those can be either a PORT A or PORT B pin)
  • ozpropdevozpropdev Posts: 2,792
    edited 2014-10-28 22:44
    I did a test on my DE2 and found that using PortB as a input to the counters works fine with 6581's code.
    In cog.v
          match <= m[4] && (i[ol+1:ol] == 2'b01 ^ (i[ol+1] ? cnt : (c ? pin_inb : pin_in) & s) == d);
    
    In cog_ctr.v
          dly <= {ctr[30] ? (ctr[14] ? pin_inb[ctr[13:9]] : pin_in[ctr[13:9]]) : dly[0], (ctr[5] ? pin_inb[ctr[4:0]] : pin_in[ctr[4:0]])};
    
    
    
    +1 Jac. I believe it might be related to the BE's pin assignments. :)
Sign In or Register to comment.