Thanks @pillo79,

Yes it helps! It is great to not have all of those conflicts show up, let along the time it takes to upload/download all of these files!

But I am guessing that this tool will only help sync up, if/when I sync up to the https://www.github.com/arduino/ArduinoCore-zephyr
arduino branch? That is I am guessing that if I check in something to my own fork/branch, like WIP changes for a PR, and then
go to a different machine of mine (or my Windows copy), and sync up, to my current changes, the zephyr-sync-artifacts tools
will not grab new binaries for my fork/branch.

Likewise, I assume, it will not work, if I sync up to the USB fixes PR, it won't bring down the artifacts for this?

git fetch upstream pull/96/head:usb_fixes
git checkout usb_fixes

Although, maybe it does? if the github checks builds the variants and keeps the artifacts.

Side note: I appreciate how the build_all.sh now automatically builds all of the current variant!
But at times I miss the old simple scripts in that, it was easy to look up the arguments to pass to build.sh to build for
a specific board. Some reason I have a hard time remembering to build for the giga it is:

./extra/build.sh arduino_giga_r1//m7 --shield giga_display_shield
Each time I end up needing to look into boards.txt for the two lines:

giga.build.zephyr_target=arduino_giga_r1//m7
giga.build.zephyr_args=--shield giga_display_shield

Although it is probably just me 😆

You are correct, this will no longer work for the two cases you mentioned:

• when moving locally from devel machine to test machine
• when pushing to forks and PRs in Github

However,

• in the first case you can manually create a tarball after the build with extra/package_core.sh and copy/extract that to the test machine's core folder. Bonus: there are no extra files on the test machine, so no confusion of what is used where.
• in the second case the artifacts get built but they are not downloaded - we will need to look into supporting this situation.

Re/ the side note, I agree! Just pushed an update allowing build.sh to understand Arduino board names. So you can simply run extra/build.sh giga and it will pick the proper command as defined in the boards.txt entry with that name 😉

Thanks @pillo79 - Yep, the side note makes it a lot easier to remember... Will try out the stuff that you mentioned that @mjs513
is trying out.

Currently I am doing it with a set of rsync commands between the ubuntu FS and windows FS.

As a different side note, trying to figure out why some of our test sketches where we are trying out things on the display, work on the
0.3.1 release, but not on the current stuff. And in fact just changing the bootloader shows it...
I included it here in case anyone is interested, should probably instead add it to the issue about the display...

zephyr_GIGA_shield_touchpaint-250429a.zip

I added simple fill the screen with 4 colors directly into our SDRAM buffer and then tell it display. This was just a check to make
sure our quick and dirty GFX wrapper was not totally screwing up.
image
And it pauses waiting for input from user to continue...
On current code, the full screen display look like they might work, but this display, sort of momentarily shows something like our image and then goes to full red screen...

Debugged it into stm32_ltdc_write call: where I added prints for passed in stuff:

static int stm32_ltdc_write(const struct device *dev, const uint16_t x,
				const uint16_t y,
				const struct display_buffer_descriptor *desc,
				const void *buf)
{
...
	printk("stm32_ltdc_write(%p %u %u %p %p):", dev, x, y, desc, buf);
	if ((x == 0) && (y == 0) &&
...
	} else {
...
		pend_buf = dst;
		printk("pend_buf: %p\n", pend_buf);

And the prints show:

Display::write8(0 0 0xc000000c) 0x806351c 804d6e5
stm32_ltdc_write(0x8062e1c 0 0 0xa 0xc000000c):pend_buf: 0xc0000080
Display::write8(0 0 0xc000000c) 0x806351c 804d6e5
stm32_ltdc_write(0x8062e1c 0 0 0xa 0xc000000c):pend_buf: 0xc0000080
Display::write8(0 0 0xc000000c) 0x806351c 804d6e5
stm32_ltdc_write(0x8062e1c 0 0 0xa 0xc000000c):pend_buf: 0xc0000080

So looks like the memory we allocated for our frame buffer in SDRAM
0xc000000c from above:

void GigaDisplay_GFX::begin() {
 display = new Display();
 display->begin();
 SDRAM.begin();
 buffer = (uint16_t*)SDRAM.malloc(this->width() * this-> height() * sizeof(uint16_t));
 sizeof_framebuffer = this->width() * this-> height();

Overlaps the memory for the pending buffer; 0xc0000080

So something not in place for the shared memory pool or ??? ... Investigating

quick update: if I hack it up to use the shared memory allocator, it appears to fix it:

#ifdef CONFIG_SHARED_MULTI_HEAP
#include <zephyr/kernel.h>
#include <zephyr/devicetree.h>
#include <zephyr/multi_heap/shared_multi_heap.h>
#endif
void GigaDisplay_GFX::begin() {
 display = new Display();
 display->begin();
#ifdef CONFIG_SHARED_MULTI_HEAP
 buffer = (uint16_t*)shared_multi_heap_aligned_alloc(SMH_REG_ATTR_EXTERNAL, 16, (this->width() * this-> height() * sizeof(uint16_t)));
#else
 SDRAM.begin();
 buffer = (uint16_t*)SDRAM.malloc(this->width() * this-> height() * sizeof(uint16_t));
#endif 
 sizeof_framebuffer = this->width() * this-> height();
 this->display->setFrameDesc(this->width(), this-> height(), this-> height(), sizeof_framebuffer);
 Serial.print("Buffer: 0x"); Serial.println((uint32_t)buffer, HEX);

Not sure why the difference between builds... but..
Or if this is the needed fix

@KurtE
Just updated the couple of test sketches I have as well - graphicstest etc. and using SMH seems to have fixed the issue.
Looks like new PR issued #117

as you said not sure why specifing using sdram for full screen does not work.

Error handling can definitely be improved 🤣 the current syntax is:

sync-zephyr-artifacts <path-to-repo> [<sha-id>]

so the simplest call is sync-zephyr-artifacts . (with the dot as "current directory") and it will figure out the sha from the Git information. For debug purposes you can also give a sha and it will download that (if it is available).
Note that only branch "heads" are built, so when multiple commits are pushed at once, only the most recent one is available. In practice it should not be an issue because you either just want "the latest" (which is always available) or you are interested in developing with the core further and thus will install Zephyr and build your own cores.

Just tried it with a fresh copy of the core:

root@DESKTOP-5R9LQSU:/home/my_new_zephyr_folder/ArduinoCore-zephyr# ./extra/sync-zephyr-artifacts/syn
c-zephyr-artifacts.sh ./home/my_new_zephyr_folder/ArduinoCore-zephyr
Git SHA: 9bfd899
Download URL: http://downloads.arduino.cc/cores/zephyr/ArduinoCore-zephyr-9bfd899.tar.bz2
Error downloading archive: bad status: 404 Not Found

learning process for me - @KurtE is more familar with this.