On Wed, 1 Dec 2010 11:50:46 +0000 Jack Keegan <whatsjacksem...@gmail.com> wrote: > Hi Antoine, > > On Wed, Dec 1, 2010 at 9:24 AM, Antoine Pitrou <solip...@pitrou.net> wrote: > > > > > > The main question IMO: the I2C bus operates at 400kHz, but how much > > received data can it buffer? That will give you a hint as to how much > > latency you can tolerate. > > > I'm not sure on buffering, but I have to ask the device on the I2C bus for a > sample each time I want one. This is done by sending out the address of the > device on the I2C bus, waiting for a reply, then addressing the registers I > want to read data from, then read the data. Therefore, I would need to make > the request at the rate I require.
Sounds like you want to do this part in raw C and in a separate process, IMO. > > I don't think soft threads would work at all, since they wouldn't allow > > overlapping between frame reading and other ops. If frame reading > > releases the GIL (as any properly implemented IO primitive in Python > > should), then at least you can try using OS threads. > > > It's actually a separate piece of hardware that does the frame > reading/encoding. I then interface to this via a DLL so I'm not sure how it > handles things in the background. Unless I am mistaken, I have to allocate a > chunk of memory for it to read the frames into, while I read from there. Well, if you are the one writing the CPython interface against the DLL, you are responsible for releasing the GIL properly. > It's probably some sort of ring buffer implementation so I'd have to read > the frames out and store them to disk before the next run through the buffer > overwrites the old frames. You have to evaluate the latency requirements there too. I have to point out that I have no experience on embedded software, so the advice I'm giving is out of pure common sense :) Regards Antoine. -- http://mail.python.org/mailman/listinfo/python-list
