Shop OBEX P1 Docs P2 Docs Learn Events
Prop2 FPGA files!!! - Updated 2 June 2018 - Final Version 32i - Page 71 — Parallax Forums

Prop2 FPGA files!!! - Updated 2 June 2018 - Final Version 32i

16869717374160

Comments

  • RaymanRayman Posts: 13,797
    edited 2017-01-09 21:12
    Was looking around and found this: DEV ATLAS SOC A9
    It's only ~$100 and there's a lot in stock.
    Any chance it would work?

    Maybe I should be brave and try to make my own P123 clone...
  • cgraceycgracey Posts: 14,133
    Rayman wrote: »
    Just called Parallax Sales to order another P123 board. Unfortunately, they are sold out.

    Not so happy with my options...
    DE2-115 costs more, doesn't give as much and is way too big.
    The BeMicro-A9 seems to have been out of stock for a year.

    Are there any small A9 boards with reasonable cost?
    Any plans to make more P123 boards?

    Wait! I believe there are more, but there's some MRP system disconnect. I will call them.
  • cgraceycgracey Posts: 14,133
    Rayman wrote: »
    Was looking around and found this: DEV ATLAS SOC A9
    It's only ~$100 and there's a lot in stock.
    Any chance it would work?

    Maybe I should be brave and try to make my own P123 clone...

    It looks like the "-A9" designates "ARM Cortex -A9", not a nice, big FPGA.
  • jmgjmg Posts: 15,140
    edited 2017-01-09 21:29
    Rayman wrote: »
    Was looking around and found this: DEV ATLAS SOC A9
    It's only ~$100 and there's a lot in stock.
    Any chance it would work?

    I think that has a smaller 40k FPGA, and the A9 here applies to the ARM variant, not the Altera FPGA Size ?
    It could still be of some use for P2 development, using the 5CSEMA4U23C6N ?
  • cgraceycgracey Posts: 14,133
    Rayman, we've got 8 in stock. In the system, the board is called "Propeller 1-2-3 vA9". The part number is 60065. If you call back and use that data, they will know what you want.
  • RaymanRayman Posts: 13,797
    Excellent! Good news.
  • RaymanRayman Posts: 13,797
    Just figured out that smartpin output still works even if DIR for that pin is low.

    I had commented out the DIRH command in garryj's USB code thinking that would disable serial output because I was using my own serial I/O code.

    When I started getting two characters sent every time I hit the keyboard, I figured it out...
  • David BetzDavid Betz Posts: 14,511
    edited 2017-01-16 23:12
    (deleted)
  • jmgjmg Posts: 15,140
    David Betz wrote: »
    Parallax is out of the new Prop123A9 boards? Maybe they still have some Prop123A7 boards.

    Above Chip said they have 8 on Jan 10th ?
    "we've got 8 in stock. In the system, the board is called "Propeller 1-2-3 vA9". The part number is 60065"
    Did you mean they have all sold since the 10th ?


  • David BetzDavid Betz Posts: 14,511
    edited 2017-01-17 00:20
    jmg wrote: »
    David Betz wrote: »
    Parallax is out of the new Prop123A9 boards? Maybe they still have some Prop123A7 boards.

    Above Chip said they have 8 on Jan 10th ?
    "we've got 8 in stock. In the system, the board is called "Propeller 1-2-3 vA9". The part number is 60065"
    Did you mean they have all sold since the 10th ?

    Sorry. I was responding to what turned out to be an old message. Please ignore my comment.

  • Rayman wrote: »
    Just figured out that smartpin output still works even if DIR for that pin is low.

    I had commented out the DIRH command in garryj's USB code thinking that would disable serial output because I was using my own serial I/O code.

    When I started getting two characters sent every time I hit the keyboard, I figured it out...
    Any WRPIN,WXPIN,WYPIN instruction will configure the smart pin.
    A rising edge on DIRx will initiate the smart pin, even from another cog.
    For example
    
    con
    
    	_pulse = %1_00100_0
    	pulse_pin = 32
    
    dat	org
    	coginit	#7,#@prog2 		'start another cog (7)
    	wrpin	#_pulse,#pulse_pin	'set smart pin mode
    	wxpin	##$ffff,#pulse_pin	'set smart pin parameter x
    	cogstop	#0			'and terminate cog.
    
    	org
    prog2	dirh	#pulse_pin		'initiate smart pin
    .loop	waitx	##80_000_000		'wait a sec
    	wypin	##1000,#pulse_pin	'send pulse
    	jmp	#.loop
    

  • cgraceycgracey Posts: 14,133
    Rayman, if the DIR bit is low, that smartpin is being held in reset. Are you sure you are seeing the opposite?
  • jmgjmg Posts: 15,140
    cgracey wrote: »
    Rayman, if the DIR bit is low, that smartpin is being held in reset. Are you sure you are seeing the opposite?
    ozpropdev wrote: »
    ....
    A rising edge on DIRx will initiate the smart pin, even from another cog.

    I think those are essentially the same, with the point I think Rayman was trying to make, in the example, that you can pre-configure a Smart Pin Cell, from one COG, and then release DIR to start, from ANY COG.



    Maybe that DIR action could better be called Apply Config, rather than Reset, as many may avoid loading config when DIR == RESET, thinking nothing would happen ?
    (in any other MCU, reset really does reset the SFRs and any configs)
  • Re: Smart pin reset (DIRx == low)

    If you raise DIRx and then lower it, the smart pin mode and X parameter remain as previously set.
    Any function currently running is terminated and output is cleared.
    Raising DIRx again just initiates the smart pin again.
    Issuing a new WYPIN instruction starts the smart pin again. WRPIN and WXPIN are not required again.
    con
    	_pulse = %1_00100_0
    	pulse_pin = 32
    dat	org
    	wrpin	#_pulse,#pulse_pin
    	wxpin	##$ffff,#pulse_pin
    	dirh	#pulse_pin		'initaite smart pin
    	dirl	#pulse_pin		'smart pin reset
    	dirh	#pulse_pin		'initiate smart pin again
    
    .loop	waitx	##80_000_000
    	wypin	##1000,#pulse_pin
    	jmp	#.loop
    

  • RaymanRayman Posts: 13,797
    edited 2017-01-17 11:57
    cgracey wrote: »
    Rayman, if the DIR bit is low, that smartpin is being held in reset. Are you sure you are seeing the opposite?

    Sorry, I wasn't clear enough...

    I've got two cogs with serial code.
    I thought I disabled one of them by commenting out the "DIRH" line.
    But, that wasn't enough... had to comment all the "w_pin" lines too...

    Obvious now, of course...

  • cgraceycgracey Posts: 14,133
    Rayman wrote: »
    cgracey wrote: »
    Rayman, if the DIR bit is low, that smartpin is being held in reset. Are you sure you are seeing the opposite?

    Sorry, I wasn't clear enough...

    I've got two cogs with serial code.
    I thought I disabled one of them by commenting out the "DIRH" line.
    But, that wasn't enough... had to comment all the "w_pin" lines too...

    Obvious now, of course...

    Ah, I got it. Thanks.
  • RaymanRayman Posts: 13,797
    edited 2017-01-21 00:16
    Just curious...

    A couple times, now I've tried to do something like this:

    mov       rx_char,ptrb++ 'pop from stack
    


    When the compiler complains, I remember that ptrb++ is just for hub reading and writing.
    Anyway, can this ptrb logic also be easily tied to mov instructions?

    I'm not even sure if this would be a good idea or not though...


    Wait a minute, that doesn't make any sense at all, never mind...

    I guess it's easier to keep a buffer in HUB than in COG RAM, right?
    Think I'd need self-modifying code to do receive buffer in cog ram...

    Actually, what I should do for this case is use LUT as a buffer...
  • RaymanRayman Posts: 13,797
    Still...

    Could there by something like MOVP and WRLUTP instructions that worked with the cog/lut address in PTRA/PTRB and also allowed PTRA++, etc.?

    Even if that made any sense, it's probably a big change now...

  • cgraceycgracey Posts: 14,133
    If you set up RDFAST or WRFAST, you can move data between cog and hub with a single instruction for each long. With the streamer, you can move data between pins and hub. And there are those SETQ/SETQ2-RDLONG/WRLONG combos that can move longs between cog/lut and hub on every clock.
  • AribaAriba Posts: 2,682
    Rayman

    Indirect addressing inside cogmemory is now done with the ALTS/D/R and ALTI instructions instead of self modifying code.
    ALTI allows also to modify the pointer, just like PTRB++.

    Andy
  • evanhevanh Posts: 15,126
    I imagine PNUT could gain new general use cases of the ALTx "prefix" instructions to provide these addressing modes as an assembly feature. Not unlike how ## prefixes a regular instruction with one or more AUGx instructions.
  • evanhevanh Posts: 15,126
    One just has to be wary of the hidden cost this incurs at binary level is all.
  • RaymanRayman Posts: 13,797
    edited 2017-01-21 13:53
    What I'm working on here is very trivial... Just a receive buffer for incoming serial bytes...

    Still, at 3 MBaud, I've got only ~26 clocks between bytes.
    A write to hub can take up to ~16 clocks and I need to do two separate writes.
    But, I just realized that if I combine these two writes, as Chip suggests, with WRFAST or SetQ, then it should be fine.

    Still, the code to do serial receive is tiny and there's all kind of space in this cog.
    I could do ALTx as Ariba and evanh suggest, but that just looks complicated.

    Anyway, I switched my code to use the LUT as buffer.
    Maybe that's the best way anyway.
    Another benefit is that (at least I think) I don't have to worry about the index rolling over the end of the LUT address space. I'm going to assume that the cog only looks at the lower bits of the address and ignores the upper bits that are outside address space.
  • RaymanRayman Posts: 13,797
    Wasn't clear in the docs, but think I've decided:

    1. setq only works with wr/rdlong and not wr/rdbyte
    2. when setq used with ptra, the value of ptra is not changed after wr/rdlong
    3. there can be no instructions between the setq and the wr/rdlong

    Is this right?
  • cgraceycgracey Posts: 14,133
    Rayman wrote: »
    Wasn't clear in the docs, but think I've decided:

    1. setq only works with wr/rdlong and not wr/rdbyte
    2. when setq used with ptra, the value of ptra is not changed after wr/rdlong
    3. there can be no instructions between the setq and the wr/rdlong

    Is this right?

    That's all correct.
  • Chip
    Are you close to releasing the new V15? FPGA images with the new FLTx and DRVx instructions?
  • cgraceycgracey Posts: 14,133
    ozpropdev wrote: »
    Chip
    Are you close to releasing the new V15? FPGA images with the new FLTx and DRVx instructions?

    I could do that on Monday.
  • Great!
    Glad to hear your making good progress with your recovery too!
    Well done! :)
  • RaymanRayman Posts: 13,797
    Question about docs on SHL, etc.

    It says: Shift D left by S with zero written to bit 0. If wc is specified the C will be set if the msb of the result = 1

    But, I think this is wrong. Doesn't the C flag get set by the last bit shifted out of MSB?
  • cgraceycgracey Posts: 14,133
    Rayman wrote: »
    Doesn't the C flag get set by the last bit shifted out of MSB?

    Yes. If D was $0001_0000 and you shifted left by 16, C would equal 1 if WC was used.
Sign In or Register to comment.