drivers: video: hm01b0 - reset/pwdn more formats

[KurtE]

Now that the @NinoSc PR has been merged:

Adding some of the missing pieces to the HM01b0 video class.

Note: not maybe necessary, but changed the VIDEO define to match all of the other video drivers that I have tried:
That is CONFIG_VIDEO_HIMAX_HM01B0 to
CONFIG_VIDEO_HM01B0

Also keep wondering if the default data-bits should be 8 as to be more likely compatible with more camera drivers. But
left it as 1.

Added PWDN and RESET pins, to yaml, plus code.

Added a few more format sizes: 326x326 to 326x244 match the spec. Verified again from earlier
tests, and Logic Analyzer.

I have also added some of the other components that are in other related drivers, like the
ctrl for HFLIP/VFlip

Added 4 bit mode using the format @avolmat-st suggested in the related issue.

Added format for cameras with Bayer filter.

Questions are:
Should I remove the current resolutions like: 320x320 as the camera does not actually return that?

The images are not as good as I would like or saw from the cameras on other setups. I believe a lot of
this is the other setups (Arducam, Linux, Teensy) do a lot settings of the registers than this currently does.
Things like Auto Exposure and the like.

Main question is: what granularity of change would you prefer to see?
Continue on to refine the images? Or incremental steps? Should I squash all of these?
Do you agree with the cahnge from CONFIG_VIDEO_HIMAX_HM01B0 -> CONFIG_VIDEO_HM01B0 or should I revert it?

Thanks
Kurt

[josuah]

Thanks for these improvements!

Here are a few suggestions to try to reduce the code size and some help for implementing frame rate control.

Let me know if you have questions!

[KurtE]

I just pushed up, changes that initializes a lot more of the registers using tables that was common
to several other setups, like Arduino MBED, Teensy, Arducam.

Getting better images and it fixed that we are getting 326 is now 324 as expected.

There are issues on how many rows are generated, which I am working through. May have been the same on the other
platforms as they only take one frame at a time, and then sync back up start of frame.

But with these updated changes, My Zephyr example sketch(sample) where I added quick and dirty BAYER to rgb565 output
is showing a lot more data now: It is scrolling on each frame, which is indicative of the issue.

Going to mark back to in progress, but pushed up to let other try if the desire.

[KurtE]

@josuah @mjs513 - What my gut tells me, is there are some wrong settings for 324x324 versus 244x324
Earlier picture showed when I set for 324x324, Note: my Bayer buffer processing eats 4 rows and columns. It is doing the real
basic...
But: my startup code printed:

ERROR: dcmi@48020000 device is not ready
[00:00:05.634,000] <err> video_common: failed to write-read to I2C register
                                       00 00                                            |..
[00:00:05.653,000] <err> video_common: Failed to read from register 0x0
[00:00:05.663,000] <err> hm01b0: Error reading id reg (-5)
[00:00:05.681,000] <err> video_common: failed to write-read to I2C register
                                       00 00                                            |..
[00:00:05.700,000] <err> video_common: Failed to read from register 0x0
[00:00:05.709,000] <err> hm01b0: Error reading id reg (-5)
[00:00:05.728,000] <err> video_common: failed to write-read to I2C register
                                       00 00                                            |..
[00:00:05.747,000] <err> video_common: Failed to read from register 0x0
[00:00:05.756,000] <err> hm01b0: Error reading id reg (-5)
[00:00:05.775,000] <err> video_common: failed to write-read to I2C register
                                       00 00                                            |..
[00:00:05.794,000] <err> video_common: Failed to read from register 0x0
[00:00:05.803,000] <err> hm01b0: Error reading id reg (-5)
[00:00:05.822,000] <err> video_common: failed to write-read to I2C register
                                       00 00                                            |..
[00:00:05.841,000] <err> video_common: Failed to read from register 0x0
[00:00:05.850,000] <err> hm01b0: Error reading id reg (-5)
[00:00:05.869,000] <err> video_common: failed to write-read to I2C register
                                       00 00                                            |..
[00:00:05.888,000] <err> video_common: Failed to read from register 0x0
[00:00:05.897,000] <err> hm01b0: Error reading id reg (-5)
[00:00:05.915,000] <err> video_common: failed to write-read to I2C register
                                       00 00                                            |..
[00:00:05.934,000] <err> video_common: Failed to read from register 0x0
[00:00:05.944,000] <err> hm01b0: Error reading id reg (-5)
[00:00:05.962,000] <err> video_common: failed to write-read to I2C register
                                       00 00                                            |..
[00:00:05.981,000] <err> video_common: Failed to read from register 0x0
[00:00:05.991,000] <err> hm01b0: Error reading id reg (-5)
[00:00:06.009,000] <err> video_common: failed to write-read to I2C register
                                       00 00                                            |..
[00:00:06.028,000] <err> video_common: Failed to read from register 0x0
[00:00:06.038,000] <err> hm01b0: Error reading id reg (-5)
[00:00:06.056,000] <inf> hm01b0: Reset/pwdn pins valid:3
[00:00:06.064,000] <inf> hm01b0: hm01b0_init check connection
INFO: - Device name: dcmi@48020000
[00:00:06.087,000] <inf> main: - Capabilities: min buf:2
INFO:   GREY width [160; 160; 0] height [120; 120; 0]
INFO:   GREY width [320; 320; 0] height [240; 240; 0]
INFO:   GREY width [320; 320; 0] height [320; 320; 0]
INFO:   GREY width [164; 164; 0] height [122; 122; 0]
INFO:   GREY width [324; 324; 0] height [244; 244; 0]
INFO:   GREY width [324; 324; 0] height [324; 324; 0]
INFO:   Y04  width [164; 164; 0] height [122; 122; 0]
INFO:   Y04  width [324; 324; 0] height [324; 324; 0]
INFO:   Y04  width [324; 324; 0] height [244; 244; 0]
INFO:   BA81 width [164; 164; 0] height [122; 122; 0]
INFO:   BA81 width [324; 324; 0] height [324; 324; 0]
INFO:   BA81 width [324; 324; 0] height [244; 244; 0]
video_get_format returned: 160 120 59455247
updated to: 324 324 31384142
INFO: - Format: BA81 324x324 324
After call video_get_format: - Format: BA81 324x324 324
Initialze video buffer list cnt:2 size:104976 104976
  0:24003d5c
  1:24003d7c
Starting  capture
Get Video Selection:
ERROR: -88
Starting main loop

So it showed the 324x324, however if I look at the Logic Analyzer output It shows 244 rows output:

and for one Row, it shows:

But if I configure by 324x244:
Output shows:

video_get_format returned: 160 120 59455247
updated to: 324 244 31384142
INFO: - Format: BA81 324x244 324
After call video_get_format: - Format: BA81 324x244 324
Initialze video buffer list cnt:2 size:79056 79056
  0:24003d5c
  1:24003d7c
Starting  capture
Get Video Selection:
ERROR: -88
Starting main loop

But logic analyzer output shows:

Like the settings got reversed at some point... And maybe many of us all copied from the place that was off..

[KurtE]

Quick note: with the help of @mjs513 found the format issue and fixed.

I am going to mark as ready for review again. Also unless I hear otherwise, I will
Squash all of the commits into one. (maybe two if change of driver name should be it's own)

[mjs513]

@KurtE

Just by way of confirmation that things are working with the HM01B0 I ran your changes on the GIGA with the display shield and now getting a perfect video feed.

[avolmat-st]

@KurtE, thanks for the check. So, should I understand that with DCMI fix applied behavior is now correct regarding the error you raised previously ?
However I do not understand why 45fps would be working now ? What has changed compared to before ? I recall you mentioned before that 45fps was not working with this sensor anyway.

[mjs513]

@avolmat-st - @KurtE
Just incorporated your changes to DCMI and seems like it resolved the issue>

1. Input 20 rounded to 15.
2. Input 40 rounded to 30.
   So looks like that resolved the issues.

[KurtE]

@KurtE, thanks for the check. So, should I understand that with DCMI fix applied behavior is now correct regarding the error you raised previously ? However I do not understand why 45fps would be working now ? What has changed compared to before ? I recall you mentioned before that 45fps was not working with this sensor anyway.

What I have seen with these cameras on different processors and the like, is they feel very temperamental.
Things like the connections or maybe how exact clock speeds (4bit data requires twice the clock speed) for the BPS
Or maybe power requirements? 45/60 takes about twice as much current as 22/30 or ???

Back earlier when @mjs513 and I were trying them out on Teensy Micromod, I felt like the HM0360 was more stable.
Ditto for example between OV7670 and OV7675 I had more luck with 75... But that may just be my gut...

But the 45fps at 324x324 on the Vision shield with 8 bit data bus I have now received about 4000 * 32 frames and
not sure how many I missed as only have 2 frame buffers and it checks for USB Serial character available and if not
return and requeue and every 32 frames prints out to USB... So maybe some were tossed.

[KurtE]

I decided to follow through on my thought that the get_frmival should compute the actual current value from the
register that the set_frmival modifies, instead of storing the actual values into a frmival data structure, which is only
used for the get. This also removed the need for the init code to precompute it.

[avolmat-st]

Thanks. Looks good to me. Only had few last very minor points.
Also could you rebase on latest head since currently the branch is not mergable ?

[avolmat-st]

Just a guess but, I feel like this extra delay is only meaningful if there there is either a reset or powerdown gpio involved, otherwise it is adding an extra delay on a device which has already been in that state for already a while probably, in which case it should be done within the

#if DT_ANY_INST_HAS_PROP_STATUS_OKAY(pwdn_gpios) || DT_ANY_INST_HAS_PROP_STATUS_OKAY(reset_gpios)

[KurtE]

@avolmat-st
Rebased - fixed merge errors
Remove extra blank line, added blank line, moved the delay to only happen if at least one of the two pins are defined

[avolmat-st]

Thanks @KurtE, sorry (again), one last small wording in the migration-guide tp integrate it better in the generated documentation.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
5.8% Duplication on New Code

See analysis details on SonarQube Cloud

[avolmat-st]

Thanks a lot @KurtE. LGTM.