Reducing data frequency

Discussion in 'Embedded Systems and Microcontrollers' started by simeonz, Apr 16, 2013.

  1. simeonz

    Thread Starter Member

    Jan 26, 2013
    31
    0
    Lets say I would like to slow down DVI signal by a factor of 2, basicly elongate every signal variation by 2.

    All logic, syncs, clock (obviously)...

    Is there an IC that can do this, or I have a long FPGA puzzle ahead of me ?

    I was wondering, what is the correct electronics term of ''elongating'' signal variation time by factors of 2/4/8 etc... I am looking for a fancy name.
     
  2. WBahn

    Moderator

    Mar 31, 2012
    17,737
    4,789
    Think about what you are asking your system to do. You data comes in at a rate of R and you want to send that same data out at a rate of R/2. That means that it will take twice as long for your data to leave as it took to arrive. So if you are feeding this think data for an hour, the box has to have the last half hour of that data buffered so that it can finish sending it out. And that just keeps getting worse and worse.
     
  3. simeonz

    Thread Starter Member

    Jan 26, 2013
    31
    0
    I forgot to mention, yes this will be sampled not too often.

    4-5 times a second, rest will all be discarded, this will not be viewed or watched or used.
     
  4. WBahn

    Moderator

    Mar 31, 2012
    17,737
    4,789
    In that case, just buffer the frame you are sampling and read it out at the slower rate.

    I actually designed a frequency converting buffer that did this automatically. It had three buffers that ran around in a ring. The input wrote to a new buffer if one was available otherwise it just overwrote the data in the existing write buffer. The output read from a new buffer is one was available otherwise is just read the same buffer again. This worked very nicely for converting between the frame rate of the focal plane array and the NTSC output to the monitor.
     
  5. simeonz

    Thread Starter Member

    Jan 26, 2013
    31
    0
    your process, what is it called ?? I'm having a problem of actually writing the data at 100 mhz thats the problem.

    frequency buffering ? Basicly nothing of the above brings me to an google leads that make sense, a buffer to me is a high impedance repeater.

    I need, the ''official name''... googling purposes.

    No slang plz.
     
    Last edited: Apr 16, 2013
  6. simeonz

    Thread Starter Member

    Jan 26, 2013
    31
    0
    Believe it or not I'm having trouble finding a cheap solution to write data @ 100 mhz clock without running into problems with interrupt latency and without building an actual computer. I cannot even get to the point of writing down data so fast to then re transmit it, if I could store it I would simply process everything I need. I need basicly a faster xmos.

    I need basicly a hardwired logic solution genius flip flop circuit, I know theres a solution but the mental effort will be huge. I need something like an xmos, but faster.

    Unless somebody here knows something I dont.

    Wbahn, that actually makes sense, I see what you mean now, good idea but no my idea for getting a single chip solution is gone, simply writing the info without any instruction or work to do is fast. But I need 2.4 million pixels x 3 bytes of memory :( I thought this was gonna be easier than this.

    You see ghz on every box of every product I have to do karate to just process a measly 100 mhz operation
     
    Last edited: Apr 16, 2013
  7. WBahn

    Moderator

    Mar 31, 2012
    17,737
    4,789
    If your data is coming in at 100MHz, then no matter what you do you are going to have to process it, to some degree at least, at 100MHz.

    I think the buzz phrase you are looking for is "frame capture" or "frame grabber". A number of years ago I was looking for a flexible capture card that could capture data off of our chips and thought it would be easy to find one and it wasn't. But I think there are a lot more options (not necessarily cheap) out there now. I would also think that a solution for something as widespread as DVI would be easier to find.

    But while a frame grabber will allow you to capture frames of data and perhaps to selectively retransmit them, I doubt any would allow you to put out the signal with a clock rate that was different that what the DVI standard calls for.

    Why do you need the slower clock rate?
     
  8. simeonz

    Thread Starter Member

    Jan 26, 2013
    31
    0
    I'm trying to build an automaton, wich directly reads pixel data from a 1024x1280 or a 768x1024 display, wich reads color ''conditions'' and then decides what actions it will take based coordinates. But this is like troubles x 1000 since everything goes so fast there is no time to even do anything with device clock speed so close to process.

    I think I'm stupid here you were right Wbahn, there is no FPGA solution, basicly the first few pulses can be followed but then theres just a massive overflow of information... There is no pattern for my mind to wrap around, Ive found pretty complex solutions before but that was a long time ago, I thought there could be but really its an empty desert if you pause and think.

    Only solution is to have a very fast processor who can directly process the logic or a write fast/re-transmit slow type of device.
     
    Last edited: Apr 17, 2013
  9. WBahn

    Moderator

    Mar 31, 2012
    17,737
    4,789
    Is your automaton running on a PC or other processor? If so, then just use a frame grabber to capture every Nth frame where N is big enough to give you time to process the image.
     
  10. simeonz

    Thread Starter Member

    Jan 26, 2013
    31
    0
    its based on external hardware, whatever that may turn out to be, everything must be totally external , there already exists such software, but I find those lacking in many ways.
     
  11. WBahn

    Moderator

    Mar 31, 2012
    17,737
    4,789
    It's sounding increasingly like you are headed for a custom solution. But there are FPGA development boards that are tailored toward image processing, so you might look to see if one of those can eat a DVI data stream and give you access to the data for your own custom processing blocks.
     
  12. simeonz

    Thread Starter Member

    Jan 26, 2013
    31
    0
  13. WBahn

    Moderator

    Mar 31, 2012
    17,737
    4,789
    It does, indeed, look interesting. I tend to work in the weeds, but I really should (and would like to) become more familiar with working a bit higher in the stack.
     
  14. simeonz

    Thread Starter Member

    Jan 26, 2013
    31
    0
    Yeha those chips are a pain to work with I know.

    Its just so expensive, you cant just try things out.

    But a chip like that, if it has some good flash memory like 3 MB+ , its pretty much ultimate level performance, its like basicly a computer in a chip I dont think you can ask for more.

    I wonder how ashamed those PLC companies feel when these things come out ? Thay'll argue that its rugged thats what they'll do...
     
  15. WBahn

    Moderator

    Mar 31, 2012
    17,737
    4,789
    Expensive, but amazingly easy to get free samples of some really spendy parts (I have no idea if these chips fall in that mix). But even if you get a $300 part free (and I have on a few occasions), anymore it means high density BGA or similar and it costs a huge amount of time and fab to get a board that will let you do something (unless a decent development board is available and you are able to get THAT for free -- harder, but sometimes still doable).
     
  16. simeonz

    Thread Starter Member

    Jan 26, 2013
    31
    0
    I think I'm just gonna use this FIFO thin g, this company is jewing me out on a ready made chip, because they have features I dont even need...

    http://www.latticesemi.com/products/...ramebuffer.cfm

    http://www.ti.com/product/sn74v3640

    And I think I'll just use an PIC @ 70 mhz, I wished to try and learn ARM, but I dont think ill ever finish anything if every time I need the debud myself via the net to understand the chip....

    DVI cable splitted to TMDS 10b/8b receiver deserializer to FIFO to PIC.

    Now I just hope a cable splitter doesnt cause me reflections and problems with signal if I keep the wire real short...

    http://www.connectworld.net/41215.html

    Because an actual screen will be plugged in parallel, to see whats going on when I developp the automaton.
     
Loading...