You’re a bit of a genius when it comes to graphics and display stuff. That’s much appreciated! Feels important to mention that.
AFAIK that was a host driver for a non-standard UVC (it used bulk endpoints rather than isochronous), rather than having the Teensy act as a UVC device.
The boson camera project is not about making a device that looks like a UVC device to a host. It is the development of a Teensy Host driver to read data from an actual FLIR Boson camera connected to the T4.1 host USB port. The driver is possible since the Boson, unlike most web cams, uses USB Bulk endpoints, rather than Isochronous endpoints. The driver is under NDA, but I don't consider that too much of a problem since Boson cameras retail in the $3K to $4K region. They are also subject ITAR export controls. Those factors probably mean a limited demand in the Teensy community. I'm still looking for a less expensive camera with bulk endpoints. If I find one, I'll try to develop an open-source driver.
github.com
Prior work to assure alignment just over allocated by the alignment bytes needed then set the usable address masked upwards to that alignment boundary - perhaps that is what you did?
if (b) {
// First see if we need to allocate buffer
if (_pfbtft == NULL) {
// Hack to start frame buffer on 32 byte boundary
_we_allocated_buffer = (uint8_t *)malloc(CBALLOC+32);
if (_we_allocated_buffer == NULL)
return 0; // failed
_pfbtft = (RAFB*) (((uintptr_t)_we_allocated_buffer + 32) & ~ ((uintptr_t) (31)));
memset(_pfbtft, 0, CBALLOC);
}
DMAMEM uint16_t pixels[320 * 240] __attribute__ ((aligned(32)));SDRAM.begin();
Serial.println("Before camera start"); Serial.flush();
if (!cam.begin(CAMERA_R640x480 /*CAMERA_R320x240 */, IMAGE_MODE, 10)) {
blinkLED();
}
uint8_t *fb_mem = (uint8_t *)SDRAM.malloc(640 * 480 * 2 + 32);
fb.setBuffer((uint8_t *)ALIGN_PTR((uintptr_t)fb_mem, 32));#define ALIGN_PTR(p,a) ((p & (a-1)) ?(((uintptr_t)p + a) & ~(uintptr_t)(a-1)) : p)Not really sure what you mean, any pointer returned by an allocation function has to be able to be directly passed to the equivalent release function (the same ways pointers returned by aligned_alloc() can be passed to free() when using stdlib). The simplest way to do it with smalloc would involve increasing the size of smalloc_hdr by 4 bytes, which would also make the default alignment 16 (a power of 2, as it should be) instead of the bad value it currently uses (returned pointers are always multiples of 12). The extra field would hold the amount of padding preceding the header of the allocated block.
FWIW - I believe we should use the KISS strategy and in this case change as few system things as possible.
malloc() already guarantees 8 byte alignment. It's defined this way in the C standard - any dynamically allocated memory must have alignment suitable for any native datatype e.g. 8 bytes for a double. smalloc is deficient in this regard.
And that's why I'm saying the changes should be in smalloc, so there is no possible confusion on the user side about which pointer is the aligned space and which is the allocated space. GNU C has had aligned allocation functions for decades, it shouldn't be up to the user to manually overallocate and align pointers (which btw isn't completely safe from a cache point-of-view - the size must also be 32-byte aligned to ensure the allocated space will not share its final cacheline with a separate memory allocation).
Sounds good,
Just popped back on line for a few minutes - I agree - its going to Paul;s call to change sm_alloc.
Working on the 7675 next
Go for it. I believe we gave links to all of the cameras you can order from Arduino, like the 7675Would be cool to see this on @Rezo 5" with 24bit and LCDIF.
store.arduino.cc