Is it me, or does this really work?
* granted it whines about all the libraries but it doesn’t fail to compile.

- arduino1_6_9.png (82.26 KiB) Viewed 1656 times
I will have to give it a try on Windows.
Edit.
1.6.8 seems to be the latest official release
I’ll try installing the nightly / hourly build for Windows and see if that works
But I’ve not had chance to upload and see if it runs.
I tried to see if any of the other examples compiled, and interestingly they have added more functions into the String class (probably a while ago), so we’ll need to update our String class with the latest file(s) to add the new functions.
I have not been keeping an eye on what the IDE have been adding to the core API, so there is probably other new API funcs that we will need to borrow ![]()
Re: Library warnings
This should not be too hard to fix, I think the IDE team just added some more parameters that need to be in the library properties files, so it should be fairly easy to get rid of most of those warnings
<…>
Re: Library warnings
This should not be too hard to fix, I think the IDE team just added some more parameters that need to be in the library properties files, so it should be fairly easy to get rid of most of those warnings
I’m not sure how add empty property to the libray.properies file effects the library manager.
I was just proposing a possible solution / hack to prevent the IDE showing those warnings
Edit.
It looks like it just needs
Category=Uncategorized
This warniong only seems to be shown for libraries that have a libraries.properies file e,g, the one I made for OneWireSTM
name=OneWireSTM
version=1.0
author=Various - updated for STM by Roger Clark
email=
sentence=Dallas One Wire for STM
paragraph=OneWire for STM32F1
url=
architectures=STM32F1
maintainer=
diff --git a/STM32F1/libraries/OneWireSTM/library.properties b/STM32F1/libraries/OneWireSTM/library.properties
index d11b2f9..fb2bc18 100644
--- a/STM32F1/libraries/OneWireSTM/library.properties
+++ b/STM32F1/libraries/OneWireSTM/library.properties
@@ -7,3 +7,4 @@ paragraph=OneWire for STM32F1
url=
architectures=STM32F1
maintainer=
+category=
diff --git a/STM32F1/libraries/RTClock/library.properties b/STM32F1/libraries/RTClock/library.properties
index 755d65e..186b03c 100644
--- a/STM32F1/libraries/RTClock/library.properties
+++ b/STM32F1/libraries/RTClock/library.properties
@@ -7,3 +7,5 @@ paragraph=Real Time Clock for STM32F1
url=
architectures=STM32F1
maintainer=
+category=Timing
+
diff --git a/STM32F1/libraries/SPI/library.properties b/STM32F1/libraries/SPI/library.properties
index d4b44fa..8995c96 100644
--- a/STM32F1/libraries/SPI/library.properties
+++ b/STM32F1/libraries/SPI/library.properties
@@ -6,4 +6,5 @@ sentence=Serial Peripheral Interface
paragraph=SPI for STM32F1
url=
architectures=STM32F1
-maintainer=
\ No newline at end of file
+maintainer=
+category=Communication
diff --git a/STM32F1/libraries/Serasidis_EtherCard_STM/library.properties b/STM32F1/libraries/Serasidis_EtherCard_STM/library.properties
index 7b539c5..ea73a1f 100644
--- a/STM32F1/libraries/Serasidis_EtherCard_STM/library.properties
+++ b/STM32F1/libraries/Serasidis_EtherCard_STM/library.properties
@@ -7,3 +7,4 @@ paragraph=Ethernet module library for STM32F1
url=https://github.com/Serasidis/STM32duino/tree/master/libraries/Serasidis_EtherCard_STM
architectures=STM32F1
maintainer=
+category=Communication
diff --git a/STM32F1/libraries/Serasidis_VS1003B_STM/library.properties b/STM32F1/libraries/Serasidis_VS1003B_STM/library.properties
index 00e3759..89be24a 100644
--- a/STM32F1/libraries/Serasidis_VS1003B_STM/library.properties
+++ b/STM32F1/libraries/Serasidis_VS1003B_STM/library.properties
@@ -7,3 +7,5 @@ paragraph=VS1003 and VS1053 MP3, MP3 player and recorder
url=
architectures=STM32F1
maintainer=
+category=Device Control
+
diff --git a/STM32F1/libraries/Serasidis_XPT2046_touch/library.properties b/STM32F1/libraries/Serasidis_XPT2046_touch/library.properties
index 7afd17e..9008996 100644
--- a/STM32F1/libraries/Serasidis_XPT2046_touch/library.properties
+++ b/STM32F1/libraries/Serasidis_XPT2046_touch/library.properties
@@ -6,3 +6,4 @@ sentence=A simple XPT2046 Touch screen driver
paragraph=A simple XPT2046 Touch screen driver
url=http://wwww.serasidis.gr
architectures=STM32F1
+category=OtherI tried changing the OneWireSTM to Category = Uncategorized but it didnt stop the whining, perhaps the category has to be in a defined list e.g. communication (as in your diff)
I can’t see a problem with making those changes, as its just to appease the IDE and stop it whining and as far as I can tell makes no functional or compilation difference to the operation of the library
category=Uncategorized
Odd.
I thought I’d tried that.
Perhaps I made a typo
I’ve pushed the changes for the libraries and also the changes for MISO to become const static vars to the development branch of the repo.
I’ve also updated the repo to include WCharacter.h which provides functions like isDigit and also updated the String class files, as they seemed to have been updated in the Arduino repo.
The IDE team have probably updated other stuff as well, in the last 6 to 9 months, since a lot of the core files were copied from the Arduino SAM core, but I’ll need to revisit this if anyone spots an omission.
If possible can you pull the development branch and let me know if it builds for your usual projects using your pre-release IDE build.
It works fine for me on the Nightly build, there is just one warning about the deprecated build pattern, and also its not happy with the empty library folders as I didnt to a recursive clone
But at least it compiles and the code seems to run on both my current test rigs (both use SPI, but for different peripherals)
If possible can you pull the development branch and let me know if it builds for your usual projects using your pre-release IDE build.
Thanks for the PR
i will pull it locally, and if Ok, merge into master and development.
I wil hold off merging development back into master for a day or two, to give other people chance to test the changes
So I’ve partially worked out where “Get Board Info” gets its data from, and have added xxx.vid.0 and xxx.pid.0 to each board in boards.txt for the STM32F1.
But as all boards have the same VID/PID number, it seems to report the board as “Maple Mini”
Anyway. I think I may as well add the pid and vid stuff to the boards.txt file, so at least this partially works.
I noticed this text as well, on the last line of the info box, “SN: Upload any sketch to obtain it”
But it appears that official Arduino boards now get a serial number from inside the USB descriptor returned by the board
See https://github.com/arduino/Arduino/blob … criptors.c
We could possibly read the unique device ID and us that.
But I don’t have time at the moment to implement this.
FYI.
I’ve added the GD32 board into the STM32 tree, as maintaining the GD32 as a different core is going to cause wasted time and effort.
I’ve tested with my GD32 and it seems to work OK
We could possibly read the unique device ID and us that.
This name comes from the driver, (actually when the driver was registered with Windows), so can’t be changed on a board to board basis unless we use different PIDs and install multiple drivers.
I dont know what happens on OSX or Linux.
I can get the new Get Board Info feature to detect the board, but it has the same issue as all boards use the same PID, so they are all reported as Maple mini.
I’ll download and try it on Windows.
Edit.
I downloaded the non-installer version, and it worked fine.
I’ll try replacing the installer version, just to confirm, but it does look as if the IDE team have decided not to force everyone to update their core, and just give a warning message.
Depending on how people feel, it may be time to think about removing support for 1.6.5 and moving to 1.6.9, i.e change the recipe to remove the warning
I’ll update the development branch of the repo with that change.
Remember that 1.6.6, 1.6.7 and 1.6.8 were there for months with known issues.
If it took 3 Official Releases to get something Rock Solid, I bet a fourth one can be expected …
No worries
I’ve updated the development branch, but the changes are just to make it compatible with 1.6.6 really.
I’ve updated the F4 branch as well.
Changes are really minor, some of them are just setting the “category” field in the libraries properties file.
I’m hoping 1.6.9 is finally what they should have done in 1.6.6, i.e. not force cores to update and be incompatible with existing users who are still on 1.6.5
Very nice!
-rick
What is needed for ARM? DFU Util, etc
You could try building from the sources in the repo for dfu, etc
<…> All it is waiting for is a port of stm32duino : )
-rick


