-
-
Notifications
You must be signed in to change notification settings - Fork 34
-
Sorry, not sure if this is off topic or not.
Wondering if any of you has a repository or the like of example zephyr projects, that you are using
that might help some of us who are starting out on the Arduino side, to better understand how zephyr works?
For example, when you were starting to add Giga Shield support to zephyr, did you have an example sketch to test it
out? Was it LVGL based? Did you test the touch screen... We have some Arduino sketches where, we have some of
the display working with the display using an Adafruit GFX subclassing. But so far I don't think we have a working
touchscreen... (Details about this are in the issue #92)
Examples for your Wi-Fi or BT support?
I am also curious, as to again get a better handle on the usage of Zephyr. I am currently trying Zephyr on some Teensy boards
just to understand the state of it. (Also doing a PR to add Teensy Micromod support to the current support for T4 and T4.1),
but that is a side story...
Thanks
Beta Was this translation helpful? Give feedback.
All reactions
-
👍 1
Replies: 3 comments 2 replies
-
Quick note: as I mentioned in new discussion about building on Windows. We have been playing some using Zephyr directly and
I pushed up a github project with some really rough semi working sketches (applications).
But it would still be great if there are others that are more applicable to the ArduinoCores-zephyr project. Again things like using the GIGA display shield, or using Bluetooth or USB ... And if you are using samples under the zephyr project, which ones? Any special changes needed...
Thanks
Beta Was this translation helpful? Give feedback.
All reactions
-
👍 1
-
@facchinm @pillo79 @iabdalkader @josuah and everyone else:
Sorry, I keep wondering what some of you do when you are making changes to the underlying zephyr system, Such that
it allows others to test those changes out and also make it easier for yourself to test the next changes to that system?
For example, I have a draft pr: zephyrproject-rtos/zephyr#93797
That soon I will probably mark as no longer draft. In this PR, I have updated GC2145 camera library as well as the video_stm32_dcmi code
to allow you to, setup different sizes of output and the ability to use a "SNAPHOT" mode instead of continuous updates.
More details are up on the actual PR.
But the actual question here, is how would you actually test changes such as this? In particular testing it within Zephyr for
Arduino hardware like the GIGA or Portenta H7?
Currently I do not believe there are any of the samples under (zephyr\samples) that are setup for the
GIGA or any Portenta.
Under the samples/drivers/video example I the only sketch that was setup for any Arduino board
was Nicla Vision under capture. And it really did not do anything with the image...
I ended up purchasing one of these and have my own example that then sends the image over USB (Arducam format) to
display it... Which was fun as with the snaphot mode I was able to set the image to 480x320 which is not possible with
released code due to memory constraints. i.e. you are limited to 320x240 (.0768 mega pixel).
Whereas if you had examples setup for Portenta or GIGA outputting to SDRam you can test larger sizes. Also you can test
the stability of the code when you are reading in image onto SDRAM and also processing them at the same time.
Currently I have my own test setup where on Portenta H7, I can output the images to an ST7796 or ILI9341 display.
Which helps test the code as well as demonstrates the issues.
But I keep wondering what others are doing. For example would you test out the impacts of different Pull requests such as this?
Thanks
Beta Was this translation helpful? Give feedback.
All reactions
-
👍 1
-
It seems like Zephyr is slowly becoming an OS split from the application ecosystem, such as Arduino which is built on top, not inside Zephyr.
So submitting a patch for the underlying features needed, and re-integrating that in Arduino, like done currently, seems like the way to go.
The Arduino maintainers probably have plans for how to handle Zephyr runtime/build-time config schism (i.e deferred-init workaround)... At my level I can only propose and see how it's received on either side.
Beta Was this translation helpful? Give feedback.
All reactions
-
👍 1
-
Thanks @josuah
I understand what you are saying and very true, with lots of the features. However for me, it cuts both ways.
That is, each time I sync up to the latest in the zephyr changes, I find things that change that often times breaks the
Arduino builds/functionality. For example over these last several syncing up, I have run into, SPI code no longer built as
the CS pins data relies on the order of definitions on at least some STM32 boards. Since been fixed, DMA numbers 1 based instead
of 0 based, SDRAM 2 sections... It might be nice if some of the stuff were caught in the Pull Requests...
And for me, it is a lot easier to test a lot of the basic things using code run directly on Zephyr versus trying to run it on Arduino.
Especially when I do most of my work on Windows. There is no currently no Native setup to build the Arduino Logical Firmwares
on Windows. @mjs513 and I have setup to do it, by setting up to do the builds on WSL, then copy all of the appropriate stuff out
of the Linux FS area into the appropriate place on the Windows Filesystem, then we can burn the firmware and build the sketch.
Which I am about to do again with the Camera stuff, to try out my HM01b0 changes on Window with the GIGA using 4 bit
data path as well as trying out the 8 bit Bayer camera I have from Sparkfun.
The other reason it would be great to have additional native Arduino GIGA/Portenta/... support is it would help ones like me to
learn what I need to do: For example I have updated some of my Zephyr test sketches to use USB_NEXT, mostly by trial and
error: My reasonably current stuff is up at:
https://github.com/KurtE/zephyr_test_sketches/tree/usb_next/camera_capture_to_usb_common
Which this app outputs data over USB from the camera I have configured into it. It is setup to talk to either the Processing sketch
that Arduino has an extra in Camera library, which the processing code does not appear to work well on windows for this, or it
also talks to the Arducam viewer which work on windows. This is from current run with update HM01b0 code
Arduino Portenta H7 on their vision shield HM01b0 version (8 bits)
image
Still more work to be done on getting the brightness... But at least it is talking at 326x244.
But each of my sketches that work now on USB, have to do things like:
https://github.com/KurtE/zephyr_test_sketches/blob/usb_next/camera_capture_to_usb_common/boards/arduino_portenta_h7_stm32h747xx_m7.overlay#L1-L4
And in my common directory I have things like:
https://github.com/KurtE/zephyr_test_sketches/blob/usb_next/common/src/usb_device_descriptor.c
and a quick and dirty setup for Serial objects and USB Serial object.
I probably should take some time to figure out how to make some of my code in this project easier to use. Things like:
all of the common code, which I have in common, I hack up each of the sketches to tell them to look there for ,c ,cpp ,h
files... Might be good to figure out how to tell it to look there and easier and maybe include .conf and .overlay files
by boards such that I don't duplicate all of those setting... Maybe some day.
And as side not: would also like to get more of this working with Teensy boards (PJRC), but so far except for the real simple tests,
they crash or the like...
Thanks again
Beta Was this translation helpful? Give feedback.
All reactions
-
👍 1
-
It might be nice if some of the stuff were caught in the Pull Requests...
I wonder how https://github.com/zephyrproject-rtos/arduino-core-zephyr will come to play in that.
For the video area, keeping API compatibility too much would make it evolve too slowly for the needs of Arduino and other projects, so paradoxically, some breakages are needed too in the mix.
One way to handle this: have the arduino core target a particular version of Zephyr, and have a CI that re-tests everything whenever upgrading. It can be the same CI system as Zephyr use, and I suppose Arduino will have plans for it too.
additional native Arduino GIGA/Portenta/... support
Do you mean as a Zephyr board or as Arduino port?
USB_NEXT
Nice work! Looks like it works smoothly. Good future-proofing.
make some of my code in this project easier to use
I would really try to discover what Arduino/Qualcomm plan, as they probably already have their own plan for integration and this might be completely unaware of this discussion. They will face the same problem where Devicetree is compile-time config and they want quick runtime updates of the code.
Beta Was this translation helpful? Give feedback.
All reactions
-
👍 1