If you look at the datasheet, there's a control interface (I2C), various clocks and a data interface (DOUT0-7). The clock minimum is ~6 MHz, so no biggy and suited for embedded systems. Until you start to work out the details: you need to send commands, read in a hefty datastream and do something with it (like writing to storage). That means you either write out the pixels as they come in, or you buffer an entire picture (or large part) and then write it out.
The first solution means that you'll need an embedded system with a clock that has an integer amount times the minimum clock for the sensor (you need to do stuff between different moments when data comes in).
The second solution means a large amount of RAM (think order MBit).
Embedded systems never scale the way you'd like them to, typically everything scales in one go. You want more internal RAM? Well, we also scaled this and that even though you won't need it, and it's 32-bit now instead of 8- or 16-bit. You want external RAM? Well here's an IC with the extra pins and an FSMC but it also has more Flash than you'll need and it comes with USB hardware you won't need. Result: more $ per unit even though you'll only need 40% of its functionality.
There's also an additional problem: This type of control from one single-core system will mean that you're going to write very dense code loops that won't be very happy about exceptions (e.g. flash write delays).
What you need in this kind of systems is a parallel approach:
- 1 core to do the I2C (very low requirement)
- 1 core to check the timing for your output stream (straight forward logic)
- several cores to read/process/filter the incoming stream (follow the datasheet)
- several cores to store everything in temporary external RAM on the fly (lockstep)
- one or more arbiters to tie everything together (the challenging part)
An 144 core system like this would be severely underemployed for this type of camera sensor. You could scale up the sensor to very high performance cameras.
So true, especially for the hobbyist. If you're big enough the chip vendor will build a custom combination for you but everyone else has to pick from the available tiers. Luckily, if power not price is the main issue you can typically clock down or disable portions of most modern microcontrollers.
Take this straight forward camera sensor:
https://www.sparkfun.com/products/retired/8668
If you look at the datasheet, there's a control interface (I2C), various clocks and a data interface (DOUT0-7). The clock minimum is ~6 MHz, so no biggy and suited for embedded systems. Until you start to work out the details: you need to send commands, read in a hefty datastream and do something with it (like writing to storage). That means you either write out the pixels as they come in, or you buffer an entire picture (or large part) and then write it out.
The first solution means that you'll need an embedded system with a clock that has an integer amount times the minimum clock for the sensor (you need to do stuff between different moments when data comes in).
The second solution means a large amount of RAM (think order MBit).
Embedded systems never scale the way you'd like them to, typically everything scales in one go. You want more internal RAM? Well, we also scaled this and that even though you won't need it, and it's 32-bit now instead of 8- or 16-bit. You want external RAM? Well here's an IC with the extra pins and an FSMC but it also has more Flash than you'll need and it comes with USB hardware you won't need. Result: more $ per unit even though you'll only need 40% of its functionality.
There's also an additional problem: This type of control from one single-core system will mean that you're going to write very dense code loops that won't be very happy about exceptions (e.g. flash write delays).
What you need in this kind of systems is a parallel approach:
- 1 core to do the I2C (very low requirement)
- 1 core to check the timing for your output stream (straight forward logic)
- several cores to read/process/filter the incoming stream (follow the datasheet)
- several cores to store everything in temporary external RAM on the fly (lockstep)
- one or more arbiters to tie everything together (the challenging part)
An 144 core system like this would be severely underemployed for this type of camera sensor. You could scale up the sensor to very high performance cameras.