STM have sent me the Nucleo boards, which their code will eventually support.
These boards are
Nucleo L053
Nucleo F091
Nucleo F103
Nucleo F303
Nucleo F446
Nucleo L476
I already had a Nucleo F334, and I can’t remember whether that was on their list to be supported or not.
I also have a Discovery F4, but I don’t think STM intend to support the Discovery series at all – however I think a number of people on the forum have some form of Discovery F4, so I suspect we will end up supporting it in some way.
PS. The boards have taken a week by Fedex to get from France to Australia, because they were misslabled with the AT rather than AU country code, hence they have been from France to Austria and back 3 times before I rang Fedex to notify them that something was seriously wrong with the addressing of the package(s) – and managed to get them to update the labels
Its strange, as the delivery address was correct, so you;d imagine it would be all handled by bar codes, not by the country code printed on the box, but perhaps they still manually sort stuff!

And yes, Austria and Australia is the same destination for most parcel services

29/09/2016 - Thursday
13:49 Delivered VICTORIA AU
09:23 On FedEx vehicle for delivery DERRIMUT AU
08:21 At local FedEx facility DERRIMUT AU
08:21 In transit DERRIMUT AU
Package available for clearance
08:21 International shipment release - Import DERRIMUT AU
28/09/2016 - Wednesday
11:59 In transit SINGAPORE SG
08:31 In transit SINGAPORE SG
04:26 In transit GUANGZHOU CN
03:42 Departed FedEx location GUANGZHOU CN
27/09/2016 - Tuesday
22:11 Arrived at FedEx location GUANGZHOU CN
05:56 On FedEx vehicle for delivery LEOBENDORF AT
04:19 In transit ROISSY CHARLES DE GAULLE CEDEX FR
03:45 Departed FedEx location ROISSY CHARLES DE GAULLE CEDEX FR
03:11 In transit ROISSY CHARLES DE GAULLE CEDEX FR
00:29 Arrived at FedEx location ROISSY CHARLES DE GAULLE CEDEX FR
26/09/2016 - Monday
22:44 In transit WIEN AT
18:21 Arrived at FedEx location ROISSY CHARLES DE GAULLE CEDEX FR
13:24 In transit VIENNA AT
05:14 In transit VIENNA AT
Tendered to authorized agent for final delivery
05:00 In transit VIENNA AT
Package available for clearance
25/09/2016 - Sunday
00:33 In transit ROISSY CHARLES DE GAULLE CEDEX FR
24/09/2016 - Saturday
19:39 Departed FedEx location ROISSY CHARLES DE GAULLE CEDEX FR
18:35 Arrived at FedEx location ROISSY CHARLES DE GAULLE CEDEX FR
03:55 Arrived at FedEx location ROISSY CHARLES DE GAULLE CEDEX FR
23/09/2016 - Friday
20:01 In transit CORBAS FR
20:01 Left FedEx origin facility CORBAS FR
15:30 Picked up VOREPPE FR
08:34 Shipment information sent to FedEx

The most expensive boards ever

Also. I’ll need to open another thread, as the L476 seems to have some problem with clock speed.
It appears to be running at 64Mhz not 80 Mhz. (See viewtopic.php?f=3&t=76&start=70#p18464 )
I’ve emailed STM and Wi6 and asked them to investigate as its a problem in the original code produced by Wi6Labs (or its by design that they only run a 80Mhz board at 64Mhz)
Apart from that, things like Blink and PWM work and also SPI works
As we have said in our email reply we have chosen to run the L476 at 64MHz. You can change the clock configuration by setting the flag ENABLE_HIGH_SPEED (in hw_config.h) and recompile the library. The clock will be at 80MHz.
The L476 board does work, but I had an issue with the upload script, so I’ve pushed a totally new version of the nucleoflasher bat file to the tools repo
Could you explain us what issue did you have with the upload script? What Windows version are you using?
Thanks
As we have said in our email reply we have chosen to run the L476 at 64MHz. You can change the clock configuration by setting the flag ENABLE_HIGH_SPEED (in hw_config.h) and recompile the library. The clock will be at 80MHz.
The L476 board does work, but I had an issue with the upload script, so I’ve pushed a totally new version of the nucleoflasher bat file to the tools repo
Could you explain us what issue did you have with the upload script? What Windows version are you using?
Thanks
does it end up going to fast ?
I’ve posted an update to the Dhrystone thread, but the board is indeed defaulting to 64Mhz in the original library.
This makes it only marginally faster than the F103 @72Mz
I think we will need to add an errata page to the wiki, to say that the Nucleo L476 Arduino core runs at 64Mhz and not the published frequency (on the packaging of 80Mhz)
I guess I could build 2 different libs and allow the user to select between 64 and 80mhz but I think we have more important things to spend our time on.
does it end up going to fast ?
OK
So if the ENABLE_HIGH_SPEED macro was use in the I2C code, to adjust the settings, it could be made to work ?
Same thing for 400KHz, it will becomes 500KHz ?
For most devices, it should be a problem.
I’m not sure why Wi6Labs chose 1Mhz SPI when the AVR default is DIV_4 of 16Mhz = 4Mhz. I think it should probably be defaulted to the same as AVR for compatibility, but thats something for the SPI library not these PLL settings
Same thing with I2C really, except I’ve no idea what speed they chose, and I don’t know (without googling) what the default AVR I2C speed is.
I presume its 100kHz
I’m not sure why Wi6Labs chose 1Mhz SPI when the AVR default is DIV_4 of 16Mhz = 4Mhz. I think it should probably be defaulted to the same as AVR for compatibility, but thats something for the SPI library not these PLL settings
Same thing with I2C really, except I’ve no idea what speed they chose, and I don’t know (without googling) what the default AVR I2C speed is.
I presume its 100kHz
Actually no. The HAL is not that abstract there. For some device it seems that you can just pass in the speed that you want (and it calculates stuff behind your back for the right setup). For some how that are derived from the newer FMP+ I2C core, you need to pass in explicit timing parameters to make it work. Just as a fun side note, the values in the databook are highly questionable, and I found quite a bunch of I2C devices that would refuse to work. Perhaps that’s just a problem with higher APB clocks.
Indeed the I2C clock configuration for L4 doesn’t work like F1. You must calculated for each speed a specific parameter which depends on the system clock.
You can find more information inside the file “twi.h”.
I will check the mbed and Chibios how they solve this problem…..
I will check the mbed and Chibios how they solve this problem…..
So we could use mbed’s I2C values for 80MHz
A new release will be soon available with the new settings:
- system clock at 80MHz
- SPI default speed at 5MHz
- I2C clock settings updated
BR
Thanks