Skip to content

Commit

Permalink
Updated FW with productName as protected field and ImageManip behavio…
Browse files Browse the repository at this point in the history
…r revert
  • Loading branch information
themarpe committed Nov 8, 2022
1 parent 76e2b2b commit 7f284dc
Show file tree
Hide file tree
Showing 3 changed files with 5 additions and 1 deletion.
2 changes: 1 addition & 1 deletion cmake/Depthai/DepthaiDeviceSideConfig.cmake
Original file line number Diff line number Diff line change
Expand Up @@ -2,7 +2,7 @@
set(DEPTHAI_DEVICE_SIDE_MATURITY "snapshot")

# "full commit hash of device side binary"
set(DEPTHAI_DEVICE_SIDE_COMMIT "b3aeaf23ff5857fc8f79d412ceefc08da23e7aad")
set(DEPTHAI_DEVICE_SIDE_COMMIT "dd3f378864da91f09a9da6e364c5ec7f032dd18f")

# "version if applicable"
set(DEPTHAI_DEVICE_SIDE_VERSION "")
3 changes: 3 additions & 0 deletions examples/ColorCamera/rgb_preview.cpp
Original file line number Diff line number Diff line change
Expand Up @@ -41,6 +41,9 @@ int main() {
cout << "Bootloader version: " << device.getBootloaderVersion()->toString() << endl;
}

// Device name
cout << "Device name: " << device.getDeviceName() << endl;

// Output queue will be used to get the rgb frames from the output defined above
auto qRgb = device.getOutputQueue("rgb", 4, false);

Expand Down
1 change: 1 addition & 0 deletions include/depthai/device/CalibrationHandler.hpp
Original file line number Diff line number Diff line change
Expand Up @@ -19,6 +19,7 @@ namespace dai {
* - batchName
* - batchTime
* - boardOptions
* - productName
*/
class CalibrationHandler {
public:
Expand Down

6 comments on commit 7f284dc

@chengguizi
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any reason why productName also become protected? I am currently relying on it to inject keyword FFC to enable CAM_D port.

@themarpe
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It started to represent a device name / part name and useful to match against in case needed (eg: OAK-D-LITE or OAK-D, ...)

@chengguizi what kind of a device are you using at the moment? We'll expose such things through BoardConfig - let us know (feel free to open an issue for it)

@chengguizi
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@themarpe I am currently using OAK-SoM-Pro modules. Some of them do not come with a meaningful Board Name (some come with wrong one in fact). So I have to rely on configurable Product name to make sure port support is proper.

I am happy to open an issue on this, if needed!

@themarpe
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@chengguizi do you mind sharing output of this som by using the calibration dump script? Bare soms should not come pre-flashed out of factory. If a field is empty you should be able to flash it even if its protected.

@chengguizi
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@themarpe I agree that most som comes with empty boardNames and productNames. But I do have a few units come with filled boardNames. I am not sure if I accidently falshed them with other .json files from off-the-shelf product like OAK-D.

Anyway, for such cases, I currently have no means on 2.19.1 version to change boardName and productName. Is there a way to force it? Or perhaps allow me to clear the names.

Otherwise, i can stick to old versions, just for flashing productName task. Inconvenience though.

@themarpe
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is a way to force, though unpreferred. Might rather rely on older version for such specific operation.

I assume those units were flashed later on. The main issues is that we cannot ONLY rely on USER area of EEPROM as some older devices do not come with FACTORY yet flashed.
Though we could allow complete flashing of USER area (including protected fields) if FACTORY was present... TBD, but would have to be paired with factory flashed SoMs in this case

Please sign in to comment.