I was unable to bootload my Artemis readboards using 2.0.1 SDK (on osx) and had to spend quite a bit of time downgrading to 1.2.
I am unable to even see the mac serial port now too - even after restart so artemis_svl fail too.
I tried this even with a fresh Artemis readboard
so I have two Artemis readboards that wont show up as a /dev/cu.usbserial-xxxx and one that does. It seems that whatever the bootloader did broke the serial upload. In the meantime I overnight ordered a few more boards. I dont dare touch the only onw I have that works and i HIGHLY DO NOT RECOMMEND ANYONE TO USE THE V2 SDK. until it is reliable.
OK so here is my question… HOW do I restore my Artemis redboards so that they can be programmed by the bootloader…
remember I am on osx?
Ok so the after reinstalling the 1.2 SDK I was able to get the old artemis_svl to run by installing the CH34X drivers.
sigh… I would have loved to use the v2 SDK… but it’s really not ready yet.
keep working on it folks
I also noticed that the 2.0 SDK compile is a bit more picky, thats always good, but its much slower now.
Just an FYI, we don’t actually develop the AmbiqSDK. That comes directly from the chipset manufacturer: https://ambiq.com/
I realize that … I was talking about the Ambiq Apollo3 Arduino Core not the AmbiqSuite SDK
the one found at https://github.com/sparkfun/Arduino_Apollo3
I just used the 2.1.1 release of the Arduino core, it seems to work a lot faster when “reloading” previously compiled code (i.e. uploading a second time w/ no changes).
The V2.X version from Sparkfun (NOT the AmbiqSuite SDK) is slower in compilation and provides indeed a (much) larger binary than the V1 version. The size of the binary also means a longer upload time. The reason is that V2.X is built on top of MBED which results in a larger code. The big advantage with V2.x is Bluetooth support, but it had its issues and many have been solved in the meantime.