25 Mhz Input ...
LustInBlack
Posts: 22
I'm currently trying to figure out how I could synchronize the cogs to sample a 25 Mhz signal in the Prop..
The signal is a digital camera.. I want to record the samples (YUV samples) to an external memory..
But right now, I would be satisfied if it could read 1 bit of that YUV signal..
The camera is clocked at 25 Mhz, and it is feeding me it's clock on one prop pin.
I could use waitpeq to wait for a change on the CAM-clock line. WaitPeq have a latency of 5 clock..
If I understand correctly, each cog gets a maximum of 80 mhz clock, I am currently set a 8mhz ext + PLL16x..
I believe I could wait for a clock transition, but would'nt have time to read the data in the short window it would be
available..
My question is, the update of the input (INA) memory value is done after a complete cycle of the hub, or is it made
between cog transition !? .. (If so, I should be able to synch many cogs to treat the value...)
?
*** OR, I could directly write the YUV data into memory with digital gates .... ***
The signal is a digital camera.. I want to record the samples (YUV samples) to an external memory..
But right now, I would be satisfied if it could read 1 bit of that YUV signal..
The camera is clocked at 25 Mhz, and it is feeding me it's clock on one prop pin.
I could use waitpeq to wait for a change on the CAM-clock line. WaitPeq have a latency of 5 clock..
If I understand correctly, each cog gets a maximum of 80 mhz clock, I am currently set a 8mhz ext + PLL16x..
I believe I could wait for a clock transition, but would'nt have time to read the data in the short window it would be
available..
My question is, the update of the input (INA) memory value is done after a complete cycle of the hub, or is it made
between cog transition !? .. (If so, I should be able to synch many cogs to treat the value...)
?
*** OR, I could directly write the YUV data into memory with digital gates .... ***
Comments
However cogs execute an instruction once every 4 cycles, this means cogs execute 20 MIPS. So sampling at 25 MHz in a cog isn't posible. To exacerbate things further the tightest store-to-cog-meory loop takes 3 instructions to execute (and the number of smaples is limited by cog memory) and 4 instructions for the store-to-hub-memory version (but actually acts like it takes 8 instructions because of hub synchronization), or sampling rates of 6.667 MHz and 2.5 MHz.
But there is a silver lining to the dark cloud, it is possible to scynchronize multiple cogs and offset them so they work in round robin to sample at higher frequencies. So if you used two cogs and synchronize them so that each takes sample halfway between the other cog's samples the datarate is doubled to 13.3MHz and 5 MHz. So with 4 cogs running you can get to 26.67 with 4 cogs.
Lastly, now that I think about it I'm afraid given you application it won't be possible. The above number doesn't take into account the need to move the data to hub memory, while it's doing this it can't sample, and I think you need to sample more than 2000 times which is the practical limit for store-in-cog.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
Are you really running at 128 Mhz!
You do not need "funny effects" when you are debugging COG syncs
As Pauls says you have to start with your data storage bandwidth!
So you most likely will need a "burst" technique: sampling 1k data -> storing it.
This is not even difficult:
Sync each HUB to X, X+1, X+2, X+3
Then you have to find a nice scheme that allows bit shift and local LONG storage. I think repeated code will do best:
Just multiply 32 loops as:
INA
RCL
DJNZ
This will input 1000 bits @150ns /bit
You should exchange the crystal so it will take 160 ns (or 120ns if very brave)
Post Edited (deSilva) : 3/8/2008 10:32:34 AM GMT
I didn't have any problem tho, but for keeping things in synch, I'll set the pll to 8x..
I thought about the problem, I believe I can do it externally, by storing the image in a framebuffer..
Using 8-bit binary counters (Probably three 74hc590 for 12 bit addressing) that increment the address of an external SRAM at each clock edge, and a buffer that will latch the 8-bit data from the camera for the SRAM ..
In fact, I would use 2 SRAM since I only have in my possession 70ns SRAM chips..
So, by using the bit 0 of the binary counters, I would select which SRAM to use, this would share the load between the
2 SRAM modules.. I will need another Buffer for each SRAM modules to store the temporary address received from the
binary counters..
I never did such a thing yet, I always worked with microcontrollers before, trying to keep the external part
count to a minimum... But I believe my idea will work...
To synch this with the prop, I would only have to use a cog to compare the 12th bit of that binary counter, when it reads high, I
reset the counter, then send the data in memory to my computer using an USB cable, wait for vertical synch of camera, then repeat...
This would free the MCU from the burden of loading the data, I would then have plenty of power left for other things, like,
video-overlay, or an artificial vision system..
I understand that the power of the propeller is it's internal ability of processing 32bit words in parallel, thus, I believe it's
quite capable of performing high speed computation on an image; I could use that for a robotic application . .
DeSilva, how do you keep the COGs in synch, when a condition appear in one COG, it will need to resynch, how do you do it
without wasting clock cycles?! .. I would rdlong a shared variable to keep the state of each COG, not unlike a COG state-machine,
but this sounds slow ..
You can then run at 100 Mhz and be synched.
Next, if the camera is an uncompressed video camera, you can use interlaced sampling
over as many frames as necessary to access the full Resolution image.
I was thinking of a "burst" mode, which means reading only a part of the data (1k Byte per COG), and then dumping it to HUB or PC
This "dumping" will take CONSIDERABLE time, so an external syncronisation will be needed anyhow.
If all the COGs are awaiting this external event, they will be perfectly synchronized again.
Another way is that one of the COGs (or a master COG) can define a specific CNT for the next wave.
COGx will then grab the signals starting at CNT+x , e.g.
Also: Have a look here: http://forums.parallax.com/showthread.php?p=689325
This describes a hardware system similar to your ideas ("external DMA")
Post Edited (deSilva) : 3/9/2008 7:20:40 AM GMT
For the moment, I'll continue my initial project, which is, a low resolution vision system..
I'm currently learning the propeller, and I see the potential now!
It's very pleasant to play with, I like the prop very much!
I conencted the prop to a VGA screen and now I can debug quite easily..
I'm still at 128MHz, and I don't see any "funnyness" yet.. What is it supposed to do!?
Any timing related problem or things like that?!
Btw, what I'm doing right now, is making a 4 bit ADC using capacitors and reading the value from
photoresistors, then displaying them to the VGA screen.
I have a question, I'm using the VGA screen in text mode.. I know that the character map is useful, but I don't
like it, the chars are too big, and I want a font similar to the one DOS use..
I changed the resolution of the screen to 640x480 (using the vga demo) and I'm trying to fiddle with the fonts
at $8000 .. well, it's not working, the memory must be read-only (most probably a ROM that isn't shadowed in RAM) ..
Anyways, I wondered if I could change that memory location with my own font format, but seems unlikely...
I'll code a new VGA driver with external font support..
You can display any character as long as its 32x32, just set it's address in the tile..
There are also some activities by Steven and me to beef-up GRAPHICS, but it will take to Easter at least for me...
I am having some results using the vga_512_384 demo . ..
Post Edited (LustInBlack) : 3/9/2008 8:56:41 PM GMT
I have this setup, DOSFont is an array of 8x8 fonts..
Ptr is supposed to be a pointer to DOSFont, I'm playing with Ptr to point to the font I want ...
So, Ptr++ etc..
I tried all this :
mov ptr, DOSFont ' Nein!
mov ptr, @DOSFont 'Nein !
mov ptr, #DosFont 'Nein ! .. I thought this one would work, but NO !
So I tried :
mov ptr, #@DosFont ' NOO it doesn't work!
Then, I decided to do it in spin, and bingo, it's working..
I took me all day long to figure out this one.. Damn ..
Post Edited (LustInBlack) : 3/10/2008 1:37:53 AM GMT
The section of the Propeller manual t about the '@' operator discusses some of this. One option would be to include a bit of spin code like this before you start the cog.
This is my DAT section, for the moment, my rendering is pretty dumb and slow..
I'll optimize that in time, for the instant, I'm plotting in X and Y by parameter..
The PTR is loaded with the address of DOSFont, which does only work when I do as you said..
I want to do the same inside the Asm Code!
I also tried this :
in Spin :
FontBackUpPtr := @DOSFont
Ptr := @DOSFont
in asm :
mov Ptr, FontBackUpPtr
'WRONG, it doesn't work !!!! ??????
I must miss something quite obvious...
[noparse][[/noparse]I'm used to code for AVR, this is quite different, but I like it alot!!!]
DAT ORG 0 DrawGlyph mov nY, #0 mov yFont, #8 LoopW rdbyte tmp, ptr shl tmp, #24 mov bCnt, #8 mov nX, #0 BLoop shl tmp, #1 wc call #XYPlot add nX, #1 djnz bCnt, #BLoop add nY, #1 add ptr, #1 djnz yfont, #LoopW mov nTmp1, cnt add nTmp1, nDelay waitcnt nTmp1, nDelay jmp DrawGlyph DrawGlyph_RET ret DOSFont long byte $00,$00,$00,$00,$00,$00,$00,$00 byte $30,$78,$78,$30,$30,$00,$30,$00 byte $6C,$6C,$6C,$00,$00,$00,$00,$00 byte $6C,$6C,$FE,$6C,$FE,$6C,$6C,$00 byte $30,$7C,$C0,$78,$0C,$F8,$30,$00 byte $00,$C6,$CC,$18,$30,$66,$C6,$00 byte $38,$6C,$38,$76,$DC,$CC,$76,$00 byte $60,$60,$C0,$00,$00,$00,$00,$00 byte $18,$30,$60,$60,$60,$30,$18,$00 byte $60,$30,$18,$18,$18,$30,$60,$00 byte $00,$66,$3C,$FF,$3C,$66,$00,$00 byte $00,$30,$30,$FC,$30,$30,$00,$00 byte $00,$00,$00,$00,$00,$30,$30,$60 byte $00,$00,$00,$FC,$00,$00,$00,$00 byte $00,$00,$00,$00,$00,$30,$30,$00 byte $06,$0C,$18,$30,$60,$C0,$80,$00 byte $7C,$C6,$CE,$DE,$F6,$E6,$7C,$00 byte $30,$70,$30,$30,$30,$30,$FC,$00 byte $78,$CC,$0C,$38,$60,$CC,$FC,$00 byte $78,$CC,$0C,$38,$0C,$CC,$78,$00 byte $1C,$3C,$6C,$CC,$FE,$0C,$1E,$00 byte $FC,$C0,$F8,$0C,$0C,$CC,$78,$00 byte $38,$60,$C0,$F8,$CC,$CC,$78,$00 byte $FC,$CC,$0C,$18,$30,$30,$30,$00 byte $78,$CC,$CC,$78,$CC,$CC,$78,$00 byte $78,$CC,$CC,$7C,$0C,$18,$70,$00 byte $00,$30,$30,$00,$00,$30,$30,$00 byte $00,$30,$30,$00,$00,$30,$30,$60 byte $18,$30,$60,$C0,$60,$30,$18,$00 byte $00,$00,$FC,$00,$00,$FC,$00,$00 byte $60,$30,$18,$0C,$18,$30,$60,$00 byte $78,$CC,$0C,$18,$30,$00,$30,$00 byte $7C,$C6,$DE,$DE,$DE,$C0,$78,$00 byte $30,$78,$CC,$CC,$FC,$CC,$CC,$00 byte $FC,$66,$66,$7C,$66,$66,$FC,$00 byte $3C,$66,$C0,$C0,$C0,$66,$3C,$00 byte $F8,$6C,$66,$66,$66,$6C,$F8,$00 byte $FE,$62,$68,$78,$68,$62,$FE,$00 byte $FE,$62,$68,$78,$68,$60,$F0,$00 byte $3C,$66,$C0,$C0,$CE,$66,$3E,$00 byte $CC,$CC,$CC,$FC,$CC,$CC,$CC,$00 byte $78,$30,$30,$30,$30,$30,$78,$00 byte $1E,$0C,$0C,$0C,$CC,$CC,$78,$00 byte $E6,$66,$6C,$78,$6C,$66,$E6,$00 byte $F0,$60,$60,$60,$62,$66,$FE,$00 byte $C6,$EE,$FE,$FE,$D6,$C6,$C6,$00 byte $C6,$E6,$F6,$DE,$CE,$C6,$C6,$00 byte $38,$6C,$C6,$C6,$C6,$6C,$38,$00 byte $FC,$66,$66,$7C,$60,$60,$F0,$00 byte $78,$CC,$CC,$CC,$DC,$78,$1C,$00 byte $FC,$66,$66,$7C,$6C,$66,$E6,$00 byte $78,$CC,$E0,$70,$1C,$CC,$78,$00 byte $FC,$B4,$30,$30,$30,$30,$78,$00 byte $CC,$CC,$CC,$CC,$CC,$CC,$FC,$00 byte $CC,$CC,$CC,$CC,$CC,$78,$30,$00 byte $C6,$C6,$C6,$D6,$FE,$EE,$C6,$00 byte $C6,$C6,$6C,$38,$38,$6C,$C6,$00 byte $CC,$CC,$CC,$78,$30,$30,$78,$00 byte $FE,$C6,$8C,$18,$32,$66,$FE,$00 byte $78,$60,$60,$60,$60,$60,$78,$00 byte $C0,$60,$30,$18,$0C,$06,$02,$00 byte $78,$18,$18,$18,$18,$18,$78,$00 byte $10,$38,$6C,$C6,$00,$00,$00,$00 byte $00,$00,$00,$00,$00,$00,$00,$FF byte $30,$30,$18,$00,$00,$00,$00,$00 byte $00,$00,$78,$0C,$7C,$CC,$76,$00 byte $E0,$60,$60,$7C,$66,$66,$DC,$00 byte $00,$00,$78,$CC,$C0,$CC,$78,$00 byte $1C,$0C,$0C,$7C,$CC,$CC,$76,$00 byte $00,$00,$78,$CC,$FC,$C0,$78,$00 byte $38,$6C,$60,$F0,$60,$60,$F0,$00 byte $00,$00,$76,$CC,$CC,$7C,$0C,$F8 byte $E0,$60,$6C,$76,$66,$66,$E6,$00 byte $30,$00,$70,$30,$30,$30,$78,$00 byte $0C,$00,$0C,$0C,$0C,$CC,$CC,$78 byte $E0,$60,$66,$6C,$78,$6C,$E6,$00 byte $70,$30,$30,$30,$30,$30,$78,$00 byte $00,$00,$CC,$FE,$FE,$D6,$C6,$00 byte $00,$00,$F8,$CC,$CC,$CC,$CC,$00 byte $00,$00,$78,$CC,$CC,$CC,$78,$00 byte $00,$00,$DC,$66,$66,$7C,$60,$F0 byte $00,$00,$76,$CC,$CC,$7C,$0C,$1E byte $00,$00,$DC,$76,$66,$60,$F0,$00 byte $00,$00,$7C,$C0,$78,$0C,$F8,$00 byte $10,$30,$7C,$30,$30,$34,$18,$00 byte $00,$00,$CC,$CC,$CC,$CC,$76,$00 byte $00,$00,$CC,$CC,$CC,$78,$30,$00 byte $00,$00,$C6,$D6,$FE,$FE,$6C,$00 byte $00,$00,$C6,$6C,$38,$6C,$C6,$00 byte $00,$00,$CC,$CC,$CC,$7C,$0C,$F8 byte $00,$00,$FC,$98,$30,$64,$FC,$00 byte $1C,$30,$30,$E0,$30,$30,$1C,$00 byte $18,$18,$18,$00,$18,$18,$18,$00 byte $E0,$30,$30,$1C,$30,$30,$E0,$00 byte $76,$DC,$00,$00,$00,$00,$00,$00 byte $00,$00,$00,$00,$00,$00,$00,$00 fit 496Your right, with that code the DOSFont will get copied into the cog. The pointer to DOSFont is used like this
I think the problem is elsewhere. Have a look at the comments in the code below.
DAT ORG 0 DrawGlyph mov nY, #0 mov yFont, #8 LoopW rdbyte tmp, ptr shl tmp, #24 'this will result in 0 in tmp! Just leave it out 'rdbyte reads into the first 8 bits (rightmost) of the register mov bCnt, #8 mov nX, #0 BLoop shl tmp, #1 wc call #XYPlot 'I don't see this anywhere... add nX, #1 djnz bCnt, #BLoop add nY, #1 add ptr, #1 djnz yfont, #LoopW mov nTmp1, cnt add nTmp1, nDelay waitcnt nTmp1, nDelay 'do you mean to add the delay in twice? jmp DrawGlyph DrawGlyph_RET ret 'I added these in cause I couldn't see them in your code nX long 0 ny long 0 yFont long 0 tmp long 0 ptr long 0 'do you put the start address in here? how do you reset it back to the start? bCnt lont 0 DOSFont long 'everything that I didn't copyThis code actually works, the problem is when I remove the line ptr := @DOSFont and replace it in assembly
at Draw label with : mov Ptr, #DOSFont
It then send garbage to the screen..
The pointer is invalid for some reason .. .
CON _clkmode = xtal1 + pll8x _xinfreq = 8_000_000 tiles = vga#xtiles * vga#ytiles tiles32 = tiles * 32 OBJ vga : "vga_512x384_bitmap" VAR long sync, pixels[noparse][[/noparse]tiles32] word colors[noparse][[/noparse]tiles] PUB start | h, i, j, k, x, y screen := @pixels 'start vga vga.start(16, @colors, @pixels, @sync) 'init colors to cyan on blue repeat i from 0 to tiles - 1 colors[i] := $2804 'draw some lines ' repeat y from 1 to 80 ' repeat x from 0 to 32 ' plot(x, y) FrameBuffer := @pixels ' Ptr := @DOSFont ' FontPtr := @DOSFont ' DOSFont[noparse][[/noparse]0] := @DOSFont+4 Ptr := @DOSFont nScreenSize := Tiles32 cognew(@Draw, 0) PRI plot(x,y) | i if x => 0 and x < 512 and y => 0 and y < 384 pixels[noparse][[/noparse](y << 4) + (x >> 5)] |= |< x DAT ORG 0 Begin Draw mov nX, #0 mov nY, #0 mov nParam1, #0 DrawGlyph mov nY, #0 mov yFont, #8 LoopW rdbyte tmp, ptr shl tmp, #24 ' <<<<<<< I do this because, the pixel bits of my font are left MSB .. I should reverse the loop counter ' instead, that would be more efficient... >>>>>>>>>>> mov bCnt, #8 mov nX, #0 BLoop shl tmp, #1 wc ' Carry flag will contain the data to render on the screen, see XYPlot call #XYPlot add nX, #1 djnz bCnt, #BLoop add nY, #1 add ptr, #1 djnz yfont, #LoopW mov nTmp1, cnt ' Agreed, that this delay sucks, but it's just for testing purpose, it's not usefull add nTmp1, nDelay waitcnt nTmp1, nDelay jmp DrawGlyph DrawGlyph_RET ret ' This is in progress.. PrintStr mov nTmp3, #4 :ReadStr 'rdbyte nTmp2, #nParamStr mov nTmp2, "1" mov Ptr, FontPtr shl nTmp2, #3 add Ptr, nTmp2 mov nParam1, nX mov nY, 0 call #DrawGlyph add nParamStr, #1 djnz nTmp3,#:ReadStr PrintStr_RET ret ClearScreen mov Val, #0 mov nTmp1, nScreenSize :ClrLoop wrlong Val, screen add screen, #4 djnz nTmp1, #:ClrLoop ClearScreen_RET ret ' This routine is for plotting at (X,Y) the bit of the font.. ' This is testing code, it's not optimized in any way XYPlot mov screen, FrameBuffer mov nTmp1, nY mov nTmp2, nX shl nTmp1, #4 shr nTmp2, #5 add nTmp1, nTmp2 shl nTmp1, #2 add screen, nTmp1 rdlong Val, screen mov nTmp1, #1 rol nTmp1, nX IF_C or Val, nTmp1 IF_NC xor nTmp1, #$FF IF_NC and Val, nTmp1 wrlong Val, screen XYPlot_RET ret FrameBuffer long 0 Val long 0 yfont long 0 bCnt long 0 nY long 0 nX long 0 tmp long 0 FontPtr long 0 screen long 0 nTmp1 long 0 nTmp2 long 0 nTmp3 long 0 jRet long 0 Ptr long 0 nScreenSize long 0 nDelay long 50_000_000 nParam1 long 0 nParamStr long $20322020 DOSFont byte $00,$00,$00,$00,$00,$00,$00,$00 byte $30,$78,$78,$30,$30,$00,$30,$00 ' About 96 other fonts... fit 496 [/i]at LoopW Tis reading from the hub. You want to change it to read from the cog like this
Than if you do the
at draw it should work.
And a note, if you post some code and some of it is in italics than the forum has eaten the [noparse][[/noparse] i ] (without spaces) from your code. Just put a space after the opening bracket and this won't happen or else use Phil's code formatter.
I retried to be sure, and it doesn't work !
I had to change my logic, as the SHL 24 was on a byte, now it's on a dword..
I simply removed the shl and replaced shl in the loop with a shr..
Do not work either way..
I am out of guess!
I had a bug in the incrementation of PTR
I did this:
PtrChg: mov tmp, ptr
and when I inc Ptr I do :
add PtrChg, #1
Then I'll have to change the affection of tmp so it points on a byte...
I think it will work that way, since I can almost distinguish the characters on screen now !
Thanks ! ..
However, I'm trying to implement a String routine, and when I rol the CharPtr, it gets to a null value!
However, it's supposed to contains "ABCD"
I can print the A, then .. it's equal to 0 !
How come ?!
I supposed it would do it :
"ABCD"
"BCDA"
"CDAB"
"DABC"
I know it's not DrawGlyph,I've put it in comment and it's still doing it..
PrintStr PSLoopChar ' movs :IncPtr, PrintStr_Param ' :IncPtr ' mov CharPtr, 0-0 mov CharPtr, TESTCHAR add PrintStr_Param, #1 mov nBackChar, CharPtr mov PSBCount, #4 PSBitLoop mov CharPtr, nBackChar <<<<< rol nBackChar, #8 <<<<<<<<< and CharPtr, #$FF <<<<<<<<<<<<<<< test CharPtr, CharPtr wz <<<<<<<<<<<<< IF_Z jmp #PrintStr_RET <<<<<<<<<<<<<<<<< call #DrawGlyph add nX, #8 mov nTmp1, cnt add nTmp1, nDelay waitcnt nTmp1, nDelay djnz PSBCount, #PSBitLoop jmp #PSLoopChar PrintStr_RET ret PrintStr_Param long 0 PSBCount long 0 nBackChar long 0 TESTCHAR long "ABCD"Post Edited (LustInBlack) : 3/11/2008 5:00:34 AM GMT
TESTCHAR long "A"
long "B"
long "C"
long "D"
Try doing
TESTCHAR long byte "ABCD"
The long makes it byte aligned and the byte tells the compiler to only allocate a byte instead of a long for each character.
Easy to do and hard to find
("SIZE OVERRIDE MUST BE LARGER")
There is the well known work-around to split sizer and alignement
LONG testchar BYTE "ABCDEFG.."It works as expected though if you put it on the next line. Either like deSilva has or like this.
TESTCHAR long byte "ABCD"You can actually put in as many longs, words and bytes in between like this and it doesn't change the size.
All very strange to confuse those who haven't met it before. Well thats my new thing for the day
Most people are not even aware of the difference between sizer and alignment
Will be one of the surprises for Fletch
I thought the compiler would take care of alignment.. That's good to know !!!
Back to the original subject..
What about using CTRA and CTRB to detect a Positive Edge of the Clock line of the camera!?
Wouldn't that be extremely fast and work at clock speed (or selected speed of the PLL) !?
Is the VCO adjustable!? What is the VCO exactly and how is it configured!? ..
This chip ROCKS I completely love it! I am almost throwing my avr stuff away !!!! ... (Just kidding... But seriously!) 8]
Now back to your question about using the counters. The counters can detect the positive edge but all they can do is add FRQx into PHSx which is not useful for this. The best way would be to use a waitpeq or waitpne. I think that these only have a delay of 1 clock cycle between a change in pin state and the cog resuming. So you will have a delay of 1 clock cycle between receiving the input and doing something about it. Try to do that using interrupts on an AVR.
Now for the VCO. The propeller has several VCOs but you can't get directly at any of them. They are all parts of the PLLs so there are two in each cog and one for the main system timer. What you are probably more interested in is the PLL modes for the timers. Using these it is possible to get almost any frequency you want between 64MHz and 128MHz out of the propeller. However, because of the way the counters work you will sometimes get a glitch. There have been a couple of threads about this recently and they shouldn't be hard to find. Again, have a look in the AN001 notes. Also, the data sheet has some info on the counters and so does the hydra book.