Just one last question, will the memory access be at a fixed distance to a hubop (e.g. rdbyte)? If that's the case we don't have to worry about misalignment.
Just one last question, will the memory access be at a fixed distance to a hubop (e.g. rdbyte)? If that's the case we don't have to worry about misalignment.
It will be 4n system clocks from a hubop for sure as there are no waitpne or waitcnt between the hub op and the SQI code. I can make it fixed if needed.
There are actually no waitxxx at all unless we end up needing waitvid at all.
This cog polls a mailbox (the emulated system bus) in a loop and when it sees a memory request it does a lookup to map between emulated high order address and real high order address and then accesses the SQI device as needed and writes the result back to the hub.
Hopefully we can do clock sync code on cog startup and then be good to go.
[h=2] Re: Looking for methods for fast SDI or SQI[/h]
What comes in mind is:
1 color VGA mode using regular PLL single-ended, instead of PLL internal (video mode)
Color is shifted out on falling edge of PLL.
If that clock edge is not good, use PLL differential mode.
Hello Tony,
We can use regular PLL single-ended to clock the video generator instead of special PLL internal(video mode). Is it sure ?
* If Yes, it will be great because in this way for non video usage of the video generator , the video generator clock can be send out ( a copy!) of the prop.
Where do you find that color is shifted out on falling edge of PLL ? and what about pixel clock shifting?
Have you experimented this?
Using video generator for sending out informations is my obsession.
Once, i have planned to send out address for an LMM external memory at more than propeller system clock. But video generator seem not to be one shot.
Thanks tony,
I have also found your original thread with Kuruneko.
Do you know if it is possible to force the video generator to send one frame only? or do you know someone who has yet done that?
Thus it will probably better for my planned application to stop the video generator just after (?!!) the waitvid instruction (using Vmode Vcfg, is it true?). Does it stop at the end of the current frame? and what about the restart time?
Why don't you tell us a bit more about what exactly you want to do? Sending stuff out isn't usually the issue, getting it back in is. To answer your question(s), if you stop the video h/w it stops, the current frame is not completed. Restart behaviour depends on a lot of things, most notably when it's stopped. PLL clock to system clock ratio is another factor. Knowing what we're up against (i.e. what are your plans) will increase the chances of finding a solution.
Comments
It will be 4n system clocks from a hubop for sure as there are no waitpne or waitcnt between the hub op and the SQI code. I can make it fixed if needed.
There are actually no waitxxx at all unless we end up needing waitvid at all.
This cog polls a mailbox (the emulated system bus) in a loop and when it sees a memory request it does a lookup to map between emulated high order address and real high order address and then accesses the SQI device as needed and writes the result back to the hub.
Hopefully we can do clock sync code on cog startup and then be good to go.
C.W.
1 color VGA mode using regular PLL single-ended, instead of PLL internal (video mode)
Color is shifted out on falling edge of PLL.
If that clock edge is not good, use PLL differential mode.
Hello Tony,
We can use regular PLL single-ended to clock the video generator instead of special PLL internal(video mode). Is it sure ?
* If Yes, it will be great because in this way for non video usage of the video generator , the video generator clock can be send out ( a copy!) of the prop.
Where do you find that color is shifted out on falling edge of PLL ? and what about pixel clock shifting?
Have you experimented this?
Using video generator for sending out informations is my obsession.
Once, i have planned to send out address for an LMM external memory at more than propeller system clock. But video generator seem not to be one shot.
Q: Is the colors shifted out on falling or rising edge of a PLL clock?
Kuroneko
A:Falling edge.
So the data-out would be "most valid" on the rising edge.
I have also found your original thread with Kuruneko.
Do you know if it is possible to force the video generator to send one frame only? or do you know someone who has yet done that?
Do you know if it is possible to force the video generator to send one frame only?
It's simple, once you run out of frame clocks (vscl[11..0]) it reloads. So either you keep feeding it or you switch it off.
Thanks Kuruneko,
I imagine that if the frame clock is very fast (ie more than 80MHz) it will be difficult to continously feed the video g
Or write a low to DIRA pinx to set it to a input (have 10k pulldown on trace)
But if change state on the 3rd clock of the instruction, maybe hard to get sync with actual data?