Shop OBEX P1 Docs P2 Docs Learn Events
Can I do this? — Parallax Forums

Can I do this?

KyeKye Posts: 2,200
edited 2010-08-20 17:45 in Propeller 1
I need to do very high speed 8 bit parallel input.

I want to do (wrbyte ina, phsa)... and have phsa increment in tune to a clock.

However, I believe I cannot use ina as a destination. So what will happen?

Comments

  • ke4pjwke4pjw Posts: 1,173
    edited 2010-08-19 10:20
    Kye wrote: »
    I need to do very high speed 8 bit parallel input.

    I want to do (wrbyte ina, phsa)... and have phsa increment in tune to a clock.

    However, I believe I cannot use ina as a destination. So what will happen?

    Depends on how you have your parallel inputs. I have done it this way before..... 
    mov      rxdata, ina             ' Read pins set for input
shr       rxdata, datapin       ' Shift data so that the LSB corresponds with D0
wrbyte  rxdata,t2               ' Write byte from the rxdata into the address located at t2's value
  • jazzedjazzed Posts: 11,803
    edited 2010-08-19 10:25
    Kye wrote: »
    I need to do very high speed 8 bit parallel input.

    I want to do (wrbyte ina, phsa)... and have phsa increment in tune to a clock.

    However, I believe I cannot use ina as a destination. So what will happen?

    The instruction (if compilable) would probably write the ina "shadow register" value to the address.
  • KyeKye Posts: 2,200
    edited 2010-08-19 10:39
    And that won't be ina right? Shame...
  • ke4pjwke4pjw Posts: 1,173
    edited 2010-08-19 12:02
    Ah, the phsa counter. Couldn't you just trim ina with an intermediate variable and mov it to phsa?
  • KyeKye Posts: 2,200
    edited 2010-08-19 13:04
    I need it to go to main memory. I'm doing video capture at high speeds.
  • ke4pjwke4pjw Posts: 1,173
    edited 2010-08-19 13:14
    (This is a learning experience for me, so please forgive me if my question is ignorant.)

    Aren't the phsa and phsb counters directly readable and writable from each cog? It appears so to me, according to page 285 of the manual. I have no experience with those counters, so tell me if I am just being ignorant. :)
  • jazzedjazzed Posts: 11,803
    edited 2010-08-19 13:48
    ke4pjw wrote: »
    Aren't the phsa and phsb counters directly readable and writable from each cog?

    Yes, they are and can be used as an index for wrbyte data, phsa for example and Kye is probably doing something like that.

    You can set up something like this code fragment to read pins and send data to a buffer.
    mov ctra, _nco
mov frqa, _200ns
mov phsa, hubptr
:loop
mov data, ina
wrbyte data, phsa
djnz count,#:loop

    There are optimizations for short bursts or specific behaviors on P0-8.

    Cheers.
    --Steve

    BIG Caveat! I knew there was a problem but forgot what it was:) As a good friend reminds me, this would write a byte to every fourth address because PHSA increments every clock tick regardless of FRQA. So any data read would use 4x memory space and would have to be reassembled into a contiguous stream.
  • ke4pjwke4pjw Posts: 1,173
    edited 2010-08-19 13:56
    Oh wow! OK, I get it. (I think) So you use the phsa counter as an index of addresses in main memory. This provides a very quick method of incrementing the pointer at a specific point in time, correct?
  • KyeKye Posts: 2,200
    edited 2010-08-19 13:59
    Yep. That's right.
  • Jack BuffingtonJack Buffington Posts: 115
    edited 2010-08-20 07:56
    That's pretty clever using phsa. An indirect register would be awesome...

    What is the source of the video that you are trying to capture? I worked on a project a few months ago where I was capturing from a 640x480x60Hz VGA signal. I couldn't capture the whole signal because of RAM issues and the 496 long limitation but if I recall correctly, I could capture three sections of video per scan line totaling about 80 pixels per line. My application required that each scan line could have a different capturable area so that took up a lot of code space but if you had an always defined region, you could capture more pixels.

    I needed to capture every pixel in the regions that I was capturing so what I ended up doing was making two chunks of code. The first grabbed the pixels and stored them in COG RAM in successive locations. I'm already fuzzy on the pneumonics of parallax assembly after not using it for a few months but that code looked roughly like this:

    mov storeLocation+0,ina
    mov storeLocation+1,ina
    mov storeLocation+2,ina
    ...

    The other chunk of code wrote them to HUB RAM in the proper location:

    wrword hubLocation, storeLocation+0
    add hubLocaion, #2
    wrword hubLocation, storeLocation+1
    add hubLocation, #2
    ..

    The main flow of the program was made possible through self-modifying code so I would be backing up the mov instruction from the first section and replacing it with a jump back to the main routine at the point that I needed to stop capturing. The instruction would then be restored. The second routine would simply have the add instruction replaced with the new hub address that was needed. At the end of the scan line, it would restore that location too.
  • KyeKye Posts: 2,200
    edited 2010-08-20 10:47
    I'm capturing data from an ominvision camera. There's a pixel clock so I have to lock onto the clock and sample the I/O lines after that.
  • StefanL38StefanL38 Posts: 2,292
    edited 2010-08-20 11:31
    If I remember right,

    Linus Akesson used 8 IO-Ports for fast intercog-communication in the turbulence demo.

    I did not analyse this in detail. But maybe his code gives some new ideas.

    best regards

    Stefan
  • Clock LoopClock Loop Posts: 2,069
    edited 2010-08-20 16:13
    The prop diagram for cog interaction via the hub and ram, would be slower than two cogs talking to each other directly using pins, if they are running code that uses cog ram only. The diagram shows that pin access does not go through the hub.

    Quote from the manual

    "After boot up, any I/O pins can be used by any cogs at any time since I/O pins are one of the common resources. It is up to the application developer to ensure that no two cogs try to use the same I/O pin for conflicting purposes during run-time."

    Kye wrote: »
    I need to do very high speed 8 bit parallel input.

    What about using good old 4c4007 (data sheet it). 1Meg x 4 dram.

    I would make an entire prop be a dram controller.

    Using two of these dram chips would give you a 8 bit bus. After the first dram chip, the addressing/read/write is parallel-able.

    8 bit bus 1 meg. using 2 chips from a edo 72 pin simm.
    pin no hub.jpg
    800 x 794 - 84K
  • ke4pjwke4pjw Posts: 1,173
    edited 2010-08-20 16:23
    jazzed wrote: »
    BIG Caveat! I knew there was a problem but forgot what it was:) As a good friend reminds me, this would write a byte to every fourth address because PHSA increments every clock tick regardless of FRQA. So any data read would use 4x memory space and would have to be reassembled into a contiguous stream.

    Is this the reason the font characters are interleaved in the ROMs memory?
  • Clock LoopClock Loop Posts: 2,069
    edited 2010-08-20 17:05
    Kye wrote: »
    I need to do very high speed 8 bit parallel input.


    See attached pdf schematic.
    pdf
    pdf
    dram.pdf
    12K
  • KyeKye Posts: 2,200
    edited 2010-08-20 17:28
    Nice but, I don't want to use external componets and I don't need to store all the data I input. Only a small bit of it.
  • jazzedjazzed Posts: 11,803
    edited 2010-08-20 17:45
    ke4pjw wrote: »
    Is this the reason the font characters are interleaved in the ROMs memory?
    Fonts are interleaved so you can use half a character if you like for making 3D buttons.
Sign In or Register to comment.