I'm working on a USB-camera with an Aptina-sensor connected to the EZUSB on GPIF interface. After couple of issues at the begining, everything works quite fine sofar. There is however one more requirement I need to fullfil and after trying for some time now, I'm getting out of ideas...
I should maintain a sequence number, incremented with each frame sent to the host, and put the sequence number along each frame-data either as a header before or as a footer after the data.
I tried to put the sequence number to the FIFO before starting GPIF (starting wave once for each frame), which never succeeded. It always gets overwritten by the frame-data. I read in this forum, that GPIF normally starts filling the FIFO from the start. That would explain the behaviour... Is there any way to change this and prepend some header before the frame-data (make the GPIF to start filling the FIFO from some other position than the start) ?
As a second try, I'm trying to put the sequence number at the end of the frame-data (footer), before I call INPKTEND to commit the last packet of the pending frame after the GPIF finished. I'm not quite sure, how to find out the position, where to put the sequence number. I mean, where the FIFO pointer stands at the moment. I should add that the FIFO is in AutoIn mode.
Any ideas are greatly appreciated.
Filling of FIFO always starts from the start of the buffer.
EPxFIFOBCH:L should let you read the number of bytes in the FIFO buffer. You'll be using the 8051 to write data onto the FIFO and it is a slightly slower process. You'll have to calculate the number of instruction cycles this operation is going to consume.
Have you considered the option of using FX3? That is much better suited for this application especially the inserting header part.
thanks for the quick response.
I see now that EP2FIFOBCH and EP2FIFOBCL contain an index pointing to the current position in the fifo. Maybe this is too obvious, but when I write something at that position, how do I increment the pointer to make sure, that it will get sent together with the past packet of the payload.
Incrementing the values in the too registers doesn't seem to have any effect.
You'll be able to write to the buffer only in manual mode. After that when you commit it by writing to EPxBCH:L you'll have to account for the bytes added.
I'm sorry, but didn't understand your answer.
Should I switch to manual mode before adding the footer-bytes to the last packet?
When the GPIF gets idle, there are usually (depending on actual frame size) some bytes left uncommited in the fifo, which I commit by signaling INPKTEND. This produce a short (zero) packet on the USB.
Is there any way to add something (footer) to this packet?
When yes, can you please describe it in a little more detail to me?
Thanks in advance.
Only in manual mode you will be able to access the FIFO buffer from CPU. In AUTO mode you won't be able to write to be buffer from CPU. So to add footer you'll have to put it in manual mode.
When you're in manual mode you'll be committing the number of bytes that are there in the buffer. So you should be able to do it there. FYI using 8051 in the data path (for this operation) will reduce the speed of transfer.
thanks for the quick reply.
This is the sequence of values (from left) of
frame_sequence_number, poll_count, EP2FIFOBCH/L, EP2BCH/L
0648, 0588: 0064, 5bef
0649, 0587: 0064, ebfd
064a, 0588: 0064, eb12
064b, 0586: 0064, 80d0
064c, 0588: 0064, 5bef
064d, 0587: 0064, ebfd
064e, 0587: 0064, eb12
064f, 0588: 0064, 80d0
0650, 0588: 0064, 5bef
read from the camera (debug buffer). One line is recorded for each frame. The value of "frame_sequence_number" I would like to add to the frame. The value of "poll_count" is just for diagnostics. Each line is recorded just before "INPKTEND = 0x02" gets executed.
My question is, how do I calculate the offset in the EP2BUF from the EP2FIFOBCH/L and/or EP2BCH/L values, where to copy the footer bytes before calling INPKTEND ?
I'm aware of the performance penalty of this solution, but I don't see any other way to do this without making the hardware considerably more complex. For the required frame resolution/rate, there is enough blanking-time between the frames to execure quite many instruction by the CPU without compromising the data-flow from the sensor.