Hi all,
I am looking for developing an IP camera based system based on STMicroelectronics STM32. The way it is supposed to work is:
STM32F4 will have few IP cameras connected to it. It may have a web server running so it can be accessed from outside.
We will have a mobile app running on a mobile device / tablet. It should be able to connect to a particular IP camera through the web server (or any other mechanism).
End result expected is as a user if I run the app on my device, I should be able to connect to a particular site (say my home) and get the live feed of a camera.
I do not need to do any image processing.
Now the questions:
1. Is STM32F4 suitable for this application?
2. What other components I am missing in the overall system?
3. Using a storage media with STM, such as a SD card, I can record the video and then send it when requested. Does video recording need knowledge of the protocol used by the camera (say H.264 compression method etc.)?
4. Any pointers where I can start studying this?
Thanks a lot,
Gopal
Yes, it is going to be Cortex-M4F.
Ok, I never worked with DMA so missed this point of "out-of-order" packets.
Using camera as sensor is also good idea. Probably I can use that in addition to the motion sensors.
At the moment, the exploration is based on the need for having multiple cameras per CortexM4. But if that is *not* possible, then single camera is going to be a compromise.
But from the calculations, it looks feasible, doesn't it?
By the way, I superlike your saying
jensbauer wrote: (note: Such people don't always play by the rules - they are very clever; I just wish they would use their skills for developing ARM based gadgets instead).
jensbauer wrote:
(note: Such people don't always play by the rules - they are very clever; I just wish they would use their skills for developing ARM based gadgets instead).
The DMA is faithful, but the packets from Ethernet might come in any order, as they can be disturbed by a switch, a router and in general be lost, so they would need to be sent again. (IP protocol).
Due to that some packets will probably need re-transmission, it's good to have a little more bandwidth than the "exact match", so 12.5 MB/sec would probably be good for a 9MB/sec transfer.
-So yes, if not cutting things too close to the limits (keeping some free air / "breathing-room" around everything) should help taking such things into account.