Re: Adding support for STM32G474RET6

[Juha Niskanen (Haltian)]

From: Nathan Hartman 
Sent: Wednesday, April 15, 2020 7:07 AM

>How do you know whether the IP is the same? By which, I mean: Is there a
> better way than to study both datasheets and manually look for differences?

Unfortunately that is the only really reliable way. Sometimes there are very 
minor differences like switching some bits in single peripheral register even 
when the IP blocks otherwise are the same.

>> STM32L1 is supported in that directory and, in that case, I think it was
>> a mistake.  The L1 is far too different from the other members supported
>> there (F1, F2, F3, F4).  If I had it to do over, I would put L1, F1+F3,
>> and L2+L4 in three directories.  That is, I admit, my fault.  I did all
>> of those ports (at least initially) except for the L1.
>
> It might be worthwhile to refactor that, if it will make supporting other
> P/Ns easier and simplify the code. I haven't studied it in detail yet but
> as I get further into this, I'll keep that possibility in mind.

I agree STM32L1 in stm32 directory is a mistake, but I think it is too late to 
really refactor it. Nobody is using it for new designs anymore, has not for 
many years , so it is only kept for existing users. I hope both F1 and L1 could 
be retired in say five to ten years. L2 does not exist and L0, L1 and L4 are 
too different  to really fit together (for any pair of the three). I assume 
F2+F4 was intended, don't know how compatible they are.

Best Regards,
   Juha

Re: Adding support for STM32G474RET6

[Juha Niskanen (Haltian)]

From: raiden00pl . 
Sent: Wednesday, April 15, 2020 8:49 AM

>L1, F1+F3 in a separate directory are a bad idea for me, but L1+F1
>separation looks better.

L1+F1 are not really that compatible. Only common thing is that both
are quite old and not really used for new projects. L1 is much newer, it was
a "prototype" low-power family until ST got the low-power stuff right with L4. 

I would not do any refactoring for the oldest families. Just not worth the 
hassle anymore.

F1 has stupid quirks and silicon bugs not in any other STM32 subarch.
Is anyone even using F1 for anything these days?

Best Regards,
  Juha

RE: Adding support for STM32G474RET6

[disruptivesolutionsnl]

Most of the "video's" and "learning material" for Nuttx is based on the
STM32F1. So that's validation enough?
And quirks? Which MCU does not have quirks? I benchmarked all kinds of MCU's
and every supplier/vendor has quirks and really annoying features and/or
other quirks. Documentation, support, etc etc.

ST(M32) is a really strong MCU family I think. And also very supportive in
any kind of solution. Also the STM32F1's. Even though its for learning
purposes right?

My 2 cents

Ben


-Oorspronkelijk bericht-
Van: Juha Niskanen (Haltian)  
Verzonden: woensdag 15 april 2020 11:00
Aan: dev@nuttx.apache.org
Onderwerp: Re: Adding support for STM32G474RET6

From: raiden00pl . 
Sent: Wednesday, April 15, 2020 8:49 AM

>L1, F1+F3 in a separate directory are a bad idea for me, but L1+F1 
>separation looks better.

L1+F1 are not really that compatible. Only common thing is that both
are quite old and not really used for new projects. L1 is much newer, it was
a "prototype" low-power family until ST got the low-power stuff right with
L4. 

I would not do any refactoring for the oldest families. Just not worth the
hassle anymore.

F1 has stupid quirks and silicon bugs not in any other STM32 subarch.
Is anyone even using F1 for anything these days?

Best Regards,
  Juha

Re: [DISCUSS] Release Notes

[Alin Jerpelea]

Looks good in my opinion
Thanks!

Alin


On Tue, Apr 14, 2020, 23:13 Abdelatif Guettouche <
abdelatif.guettou...@gmail.com> wrote:

> Are there any concerns or additions to the release notes?
> I did some re-organisation yesterday.  Mainly I put network related
> changes to their own section and moved some other points that were not
> where they belong.
> I don't know what we should put in the first item "What's New In This
> Release".  Maybe a word that this is the first Apache release and
> highlight some notable changes/additions like the x86_64 port.
> Is this ready for a PR?
>
> On Fri, Apr 10, 2020 at 4:42 PM Abdelatif Guettouche
>  wrote:
> >
> > > I don't need them anymore.
> >
> > Okay. I removed them.
> >
> > I also tried to re-organize a little bit.  Please refer to this
> > version of the document to have a look at the original organization:
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=148645728
> >
> > "Bug fixes" under "Major Changes to Core OS" should only contain bug
> > fixes to the OS not arch or drivers.
> > Similarly, "Security Issues Fixed in this Release" should contain only
> > security vulnerabilities.
> >
> >
> > On Fri, Apr 10, 2020 at 2:58 AM Nathan Hartman 
> wrote:
> > >
> > > On Thu, Apr 9, 2020 at 7:09 PM Abdelatif Guettouche <
> > > abdelatif.guettou...@gmail.com> wrote:
> > >
> > > > Also, I didn't want to remove the PRs number, maybe Nathan still
> needs
> > > > them.
> > >
> > >
> > > I don't need them anymore.
> > >
> > > Initially I thought that when writing the release notes, we could (in
> > > parenthesis) link to the corresponding PR and/or Issue number(s) for
> anyone
> > > reading the release notes who might be interested in seeing more about
> a
> > > particular change. But I forgot to mention that so we can go ahead and
> > > remove them.
> > >
> > > Cheers,
> > > Nathan
>

[PATCH] drivers/usbdev/usbmsc.c: fix build error with DEBUGASSERT

[Juha Niskanen (Haltian)]

Hi,

Another recent build failure.

Best Regards,
   Juha
From 0ed36626013fc72d25c533a950e6a2ee1100952a Mon Sep 17 00:00:00 2001
From: Juha Niskanen 
Date: Wed, 15 Apr 2020 17:11:53 +0300
Subject: [PATCH] drivers/usbdev/usbmsc.c: fix build error with DEBUGASSERT

---
 drivers/usbdev/usbmsc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usbdev/usbmsc.c b/drivers/usbdev/usbmsc.c
index a61a8b2..2d31a12 100644
--- a/drivers/usbdev/usbmsc.c
+++ b/drivers/usbdev/usbmsc.c
@@ -1856,7 +1856,7 @@ void usbmsc_uninitialize(FAR void *handle)
* have no option but to continue with the teardown.
*/
 
-  DEBUGASSERT(ret == OK || ret == -ECANCLED);
+  DEBUGASSERT(ret == OK || ret == -ECANCELED);
 }
   while (ret < 0);
 
-- 
2.7.4

Re: Start of the NuttX 9.0 release cycle

[Abdelatif Guettouche]

I created the branch, it's up to date with master.
>From now on, we only backport to the branch what we think is necessary
to the release.

> We should probably figure out how this patch would be represented in code
> and if we want to have 9.0.0-RC1 or whatever supported.
What do you mean in code?
A release will go through possibly multiple release candidates all
tagged as 9.0.0-rcX, the final tag will be the same as the last
accepted RC without the -rc suffix.
Patches will have to go through the same process. With the voting in
the incubator general list, etc.


On Mon, Apr 13, 2020 at 12:59 AM Brennan Ashton
 wrote:
>
> On Sun, Apr 12, 2020, 4:55 PM Gregory Nutt  wrote:
>
> >
> > > With this in mind and with the suggestion from Brennan, the branch
> > > would be "releases/9.0.0"
> >
> > There there would be tags on the branch to differentiate 9.0.1 from
> > 9.0.2? and from release candidates?
> >
> > So would the branch name releases/9.0 still be OK?  The tags on the
> > branch would pick up the 3rd digit?  I don't really care and I am trying
> > to leave the decisions in the hands of the people doing the work.  No
> > need for bossy spectators; no need for spectators period.  But I thought
> > I should mention that.
> >
> > Greg
> >
>
> This all seems very reasonable to me. No need to bikeshed too much, we can
> always learn from the release and refine as we go along.
>
> We should probably figure out how this patch would be represented in code
> and if we want to have 9.0.0-RC1 or whatever supported.
>
> >

Re: [DISCUSS] Release Notes

[Abdelatif Guettouche]

I created the PR with the release notes from Confluence. It's here:
https://github.com/apache/incubator-nuttx/pull/801
If there is anything to add/remove/replace let me know.


On Wed, Apr 15, 2020 at 12:49 PM Alin Jerpelea  wrote:
>
> Looks good in my opinion
> Thanks!
>
> Alin
>
>
> On Tue, Apr 14, 2020, 23:13 Abdelatif Guettouche <
> abdelatif.guettou...@gmail.com> wrote:
>
> > Are there any concerns or additions to the release notes?
> > I did some re-organisation yesterday.  Mainly I put network related
> > changes to their own section and moved some other points that were not
> > where they belong.
> > I don't know what we should put in the first item "What's New In This
> > Release".  Maybe a word that this is the first Apache release and
> > highlight some notable changes/additions like the x86_64 port.
> > Is this ready for a PR?
> >
> > On Fri, Apr 10, 2020 at 4:42 PM Abdelatif Guettouche
> >  wrote:
> > >
> > > > I don't need them anymore.
> > >
> > > Okay. I removed them.
> > >
> > > I also tried to re-organize a little bit.  Please refer to this
> > > version of the document to have a look at the original organization:
> > >
> > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=148645728
> > >
> > > "Bug fixes" under "Major Changes to Core OS" should only contain bug
> > > fixes to the OS not arch or drivers.
> > > Similarly, "Security Issues Fixed in this Release" should contain only
> > > security vulnerabilities.
> > >
> > >
> > > On Fri, Apr 10, 2020 at 2:58 AM Nathan Hartman 
> > wrote:
> > > >
> > > > On Thu, Apr 9, 2020 at 7:09 PM Abdelatif Guettouche <
> > > > abdelatif.guettou...@gmail.com> wrote:
> > > >
> > > > > Also, I didn't want to remove the PRs number, maybe Nathan still
> > needs
> > > > > them.
> > > >
> > > >
> > > > I don't need them anymore.
> > > >
> > > > Initially I thought that when writing the release notes, we could (in
> > > > parenthesis) link to the corresponding PR and/or Issue number(s) for
> > anyone
> > > > reading the release notes who might be interested in seeing more about
> > a
> > > > particular change. But I forgot to mention that so we can go ahead and
> > > > remove them.
> > > >
> > > > Cheers,
> > > > Nathan
> >

Re: Start of the NuttX 9.0 release cycle

[Brennan Ashton]

On Wed, Apr 15, 2020, 9:29 AM Abdelatif Guettouche <
abdelatif.guettou...@gmail.com> wrote:

> > We should probably figure out how this patch would be represented in code
> > and if we want to have 9.0.0-RC1 or whatever supported.
> What do you mean in code?
> A release will go through possibly multiple release candidates all
> tagged as 9.0.0-rcX, the final tag will be the same as the last
> accepted RC without the -rc suffix.
> Patches will have to go through the same process. With the voting in
> the incubator general list, etc.
>

There is a version file that is generated but it only exposes major, minor,
and build hash as defines for code to use. Do we need to extend the code to
support a patch version? And should the RC be exposed to the code as well
somehow (probably less important).

>

Re: Adding support for STM32G474RET6

[Nathan Hartman]

On Wed, Apr 15, 2020 at 1:50 AM raiden00pl .  wrote:
> > The F3 is not a good point of comparison.  It is like the F1 with a
> > Cortex-M4.  There will be a lot of differences compared to any
> > contemporary parts.  Compare instead with one of the F4's.  I bet you
> > find they are not so different.
>
> I can't agree with this. G4 is basically F3 on steroids with more
> peripherals and
> some additional improvements that we can also find in new families (eg.
> DMAMUX).
>
> When the first manuals for G4 came out I did a comparison and from what
> I remember adding support to the existing arch/arm/src/stm32 looked easy.
> The main differences are in DMAMUX, RCC and PWR but these can be
> ported from G0/H7.
> If I can get B-G474E-DPOW1 discovery board, I'll try to help.
>
> I also don't think that comparing F3 with F1 is good. F3 was released after
> F4
> and many peripherals were upgraded to newer revisions. For this reason,
> if we look at supported peripherals we can find more similarities between
> F1 and F4 than F1 and F3 (UART, I2C, PWM, ADC and more).
>
> L1, F1+F3 in a separate directory are a bad idea for me, but L1+F1
> separation looks better.

What I can say is that the numbering sure is confusing!!

I'm studying various F3 and G4 part data sheets right now to learn the
similarities and differences.

Nathan

Re: Adding support for STM32G474RET6

[Gregory Nutt]

This helps clarify the families: https://en.wikipedia.org/wiki/STM32

"The STM32 F3-series is the second group of STM32 microcontrollers based 
on the ARM Cortex-M4F core. The F3 is almost pin-to-pin compatible with 
the STM32 F1-series. ...


"The STM32 F2-series of STM32 microcontrollers based on the ARM 
Cortex-M3 core. It is the most recent and fastest Cortex-M3 series. The 
F2 is pin-to-pin compatible with the STM32 F4-series "

Re: Adding support for STM32G474RET6

[Gregory Nutt]

This document address migration from F1 to F3 and addresses all major 
differences between F1 and F3:  AN4228, Application note, Migrating from 
STM32F1 Series to STM32F3 Series microcontrollers. Table 6 address every 
peripheral.

Re: Adding support for STM32G474RET6

[Gregory Nutt]

On 4/15/2020 1:51 PM, Gregory Nutt wrote:

This helps clarify the families: https://en.wikipedia.org/wiki/STM32

"The STM32 F3-series is the second group of STM32 microcontrollers 
based on the ARM Cortex-M4F core. The F3 is almost pin-to-pin 
compatible with the STM32 F1-series. ...


"The STM32 F2-series of STM32 microcontrollers based on the ARM 
Cortex-M3 core. It is the most recent and fastest Cortex-M3 series. 
The F2 is pin-to-pin compatible with the STM32 F4-series "


The original F3's (2012) were little more than F1's with a Cortex-M4.  
Some peripherals were upgraded, but most were not. The early STM32F205 
and STM32F207 were identical to the STM32F405 and STM32F407, except with 
the Cortex-M3.   What has happened over the years is that the Cortex-M4 
platforms have evolved and advanced, but the the Cortex-M3 platforms 
have not advanced so much.  I did the ports and most of the drivers for 
all initial versions of these parts and feel confident in saying these 
things, but I am not so familiar with the more recent variations.  It 
appears to me that the F3 has taken its own path.

Re: Adding support for STM32G474RET6

[Nathan Hartman]

On Wed, Apr 15, 2020 at 4:08 PM Gregory Nutt  wrote:
> This document address migration from F1 to F3 and addresses all major
> differences between F1 and F3:  AN4228, Application note, Migrating from
> STM32F1 Series to STM32F3 Series microcontrollers. Table 6 address every
> peripheral.

Ok, I'll look at that.

Meanwhile... So I've been studying, toward making a decision, whether
to try implementing this in the stm32 directory or create a new one
for stm32g4... I probably won't know which is better and which is less
(or more!) work until I actually start writing code.

As I'm looking at STM32F3 parts we support and compare to STM32G474,
it seems the STM32F334 has the most similarities to this new part.

Comparison:

(At least what I know so far...)

Both have GPIO ports ABCF. STM32G474CxT adds port G but only for
PG10-NRST. That is, the reset pin can be used as a GPIO.

Analog: the STM32G474Cxt is heavy on analog features with much more
ADC, DAC, COMP, and OPAMP peripherals and pins than the STM32F3. These
features are obviously new IP as the ADC adds Hardware Oversampling,
IO Voltage Booster, Gain Compensation, Bulb Sampling, Sampling Time
Control Trigger, Dual Interleaved Sampling, new Analog Watchdog
features. The DAC adds Sample and Hold, and also Internal DACs that
can be connected to other internal peripherals, e.g., to a COMP or
OPAMP. And there's much more. [1]

Timers: Both have HRTIM, but the STM32F334 has HRTIM IP version 1.0
while STM32G474Cxt has HRTIM IP version 2.0. This adds various
features and capabilities, described in [2]. Also, the G4 more of the
regular resolution timers.

Communication: STM32F334 has CAN. STM32G474CxT has FDCAN1, FDCAN2,
FDCAN3. STM32G474CxT has LPTIM, LPUART, SAI, USB. Also, more I2C and
SPI.

Side-by-side comparison of Ports, Pins, and Peripherals:

Ports:
===
STM32G474CxTx  | STM32F334CxTx
===
PORT_A | PORT_A
PORT_B | PORT_B
PORT_C | PORT_C
PORT_F | PORT_F
PORT_G | - x -
---


Pins:
===
STM32G474CxTx  | STM32F334CxTx
===
PA0| PA0
PA1| PA1
PA2| PA2
PA3| PA3
PA4| PA4
PA5| PA5
PA6| PA6
PA7| PA7
PA8| PA8
PA9| PA9
PA10   | PA10
PA11   | PA11
PA12   | PA12
PA13   | PA13
PA14   | PA14
PA15   | PA15
---
PB0| PB0
PB1| PB1
PB2| PB2
PB3| PB3
PB4| PB4
PB5| PB5
PB6| PB6
PB7| PB7
PB8-BOOT0  | PB8
PB9| PB9
PB10   | PB10
PB11   | PB11
PB12   | PB12
PB13   | PB13
PB14   | PB14
PB15   | PB15
---
PC13   | PC13
PC14-OSC32_IN  | PC14-OSC32_IN
PC15-OSC32_OUT | PC15-OSC32_OUT
---
PF0-OSC_IN | PF0-OSC_IN
PF1-OSC_OUT| PF1-OSC_OUT
---
PG10-NRST  | - x -
---


Peripherals:
===
STM32G474CxTx  | STM32F334CxTx
===
ADC1   | ADC1
ADC2   | ADC2
ADC3   | - x -
ADC4   | - x -
ADC5   | - x -
- x -  | CAN
COMP1  | - x -
COMP2  | COMP2
COMP3  | - x -
COMP4  | COMP4
COMP5  | - x -
COMP6  | COMP6
COMP7  | - x -
CRS| - x -
DAC1   | DAC1
DAC2   | DAC2
DAC3   | - x -
DAC4   | - x -
FDCAN1 | - x -
FDCAN2 | - x -
FDCAN3 | - x -
HRTIM1 | HRTIM1
I2C1   | I2C1
I2C2   | - x -
I2C3   | - x -
I2C4   | - x -
I2S| - x -
I2S2   | - x -
I2S3   | - x -
IR | IR
LPTIM1 | - x -
LPUART1| - x -
OPAMP1 | - x -
OPAMP2 | OPAMP2
OPAMP3 | - x -
OPAMP4 | - x -
OPAMP5 | - x -
OPAMP6 | - x -
QUADSPI1   | - x -
RCC| RCC
RTC| RTC
SAI1   | - x -
SPI1   | SPI1
SPI2   | - x -
SPI3   | - x -
SYS| SYS
TIM1   | TIM1
TIM15  | TIM15
TIM16  | TIM16
TIM17  | TIM17
TIM2   | TIM2
TIM20  | - x -
TIM3   | TIM3
TIM4   | - x -
TIM5   | - x -
TIM8   | - x -
- x -  | TSC
UCPD1  | - x -
USART1 | USART1
USART2 | USART2
USART3 | USART3
USB| - x -
---

References:

[1] STM32F3 vs STM32G4 Analog: AN5310:

https://www.st.com/content/ccc/resource/technical/document/application_note/group1/0e/97/a6/8e/6b/bd/49/40/DM00607955/files/DM00607955.pdf/jcr:content/translations/en.DM00607955.pdf

[2] HRTIM differenc

Re: Start of the NuttX 9.0 release cycle

[Abdelatif Guettouche]

I don't think we need to expose the RC, it's not the one that's going
to be released.
The patch, however, could be an option.  Some files will need to adapt
to that though, not only the version.sh script.


On Wed, Apr 15, 2020 at 5:33 PM Brennan Ashton
 wrote:
>
> On Wed, Apr 15, 2020, 9:29 AM Abdelatif Guettouche <
> abdelatif.guettou...@gmail.com> wrote:
>
> > > We should probably figure out how this patch would be represented in code
> > > and if we want to have 9.0.0-RC1 or whatever supported.
> > What do you mean in code?
> > A release will go through possibly multiple release candidates all
> > tagged as 9.0.0-rcX, the final tag will be the same as the last
> > accepted RC without the -rc suffix.
> > Patches will have to go through the same process. With the voting in
> > the incubator general list, etc.
> >
>
> There is a version file that is generated but it only exposes major, minor,
> and build hash as defines for code to use. Do we need to extend the code to
> support a patch version? And should the RC be exposed to the code as well
> somehow (probably less important).
>
> >

Re: [PATCH] drivers/usbdev/usbmsc.c: fix build error with DEBUGASSERT

[Nathan Hartman]

On Wed, Apr 15, 2020 at 10:22 AM Juha Niskanen (Haltian)
 wrote:
> Another recent build failure.

Has this been converted to a PR? If so, if I may ask, would the person
who converts a patch to a PR, please reply to the dev@ email and tell
the list that it has been done, with the PR number? Hopefully that
will help so patches don't slip through the cracks.

Thanks everyone and thanks to Juha for the patch.

Cheers,
Nathan

Re: Adding support for STM32G474RET6

[David Sidrane]

How does the RCC (clock tree) compare?

On Wed, Apr 15, 2020, 5:11 PM Nathan Hartman 
wrote:

> On Wed, Apr 15, 2020 at 4:08 PM Gregory Nutt  wrote:
> > This document address migration from F1 to F3 and addresses all major
> > differences between F1 and F3:  AN4228, Application note, Migrating from
> > STM32F1 Series to STM32F3 Series microcontrollers. Table 6 address every
> > peripheral.
>
> Ok, I'll look at that.
>
> Meanwhile... So I've been studying, toward making a decision, whether
> to try implementing this in the stm32 directory or create a new one
> for stm32g4... I probably won't know which is better and which is less
> (or more!) work until I actually start writing code.
>
> As I'm looking at STM32F3 parts we support and compare to STM32G474,
> it seems the STM32F334 has the most similarities to this new part.
>
> Comparison:
>
> (At least what I know so far...)
>
> Both have GPIO ports ABCF. STM32G474CxT adds port G but only for
> PG10-NRST. That is, the reset pin can be used as a GPIO.
>
> Analog: the STM32G474Cxt is heavy on analog features with much more
> ADC, DAC, COMP, and OPAMP peripherals and pins than the STM32F3. These
> features are obviously new IP as the ADC adds Hardware Oversampling,
> IO Voltage Booster, Gain Compensation, Bulb Sampling, Sampling Time
> Control Trigger, Dual Interleaved Sampling, new Analog Watchdog
> features. The DAC adds Sample and Hold, and also Internal DACs that
> can be connected to other internal peripherals, e.g., to a COMP or
> OPAMP. And there's much more. [1]
>
> Timers: Both have HRTIM, but the STM32F334 has HRTIM IP version 1.0
> while STM32G474Cxt has HRTIM IP version 2.0. This adds various
> features and capabilities, described in [2]. Also, the G4 more of the
> regular resolution timers.
>
> Communication: STM32F334 has CAN. STM32G474CxT has FDCAN1, FDCAN2,
> FDCAN3. STM32G474CxT has LPTIM, LPUART, SAI, USB. Also, more I2C and
> SPI.
>
> Side-by-side comparison of Ports, Pins, and Peripherals:
>
> Ports:
> ===
> STM32G474CxTx  | STM32F334CxTx
> ===
> PORT_A | PORT_A
> PORT_B | PORT_B
> PORT_C | PORT_C
> PORT_F | PORT_F
> PORT_G | - x -
> ---
>
>
> Pins:
> ===
> STM32G474CxTx  | STM32F334CxTx
> ===
> PA0| PA0
> PA1| PA1
> PA2| PA2
> PA3| PA3
> PA4| PA4
> PA5| PA5
> PA6| PA6
> PA7| PA7
> PA8| PA8
> PA9| PA9
> PA10   | PA10
> PA11   | PA11
> PA12   | PA12
> PA13   | PA13
> PA14   | PA14
> PA15   | PA15
> ---
> PB0| PB0
> PB1| PB1
> PB2| PB2
> PB3| PB3
> PB4| PB4
> PB5| PB5
> PB6| PB6
> PB7| PB7
> PB8-BOOT0  | PB8
> PB9| PB9
> PB10   | PB10
> PB11   | PB11
> PB12   | PB12
> PB13   | PB13
> PB14   | PB14
> PB15   | PB15
> ---
> PC13   | PC13
> PC14-OSC32_IN  | PC14-OSC32_IN
> PC15-OSC32_OUT | PC15-OSC32_OUT
> ---
> PF0-OSC_IN | PF0-OSC_IN
> PF1-OSC_OUT| PF1-OSC_OUT
> ---
> PG10-NRST  | - x -
> ---
>
>
> Peripherals:
> ===
> STM32G474CxTx  | STM32F334CxTx
> ===
> ADC1   | ADC1
> ADC2   | ADC2
> ADC3   | - x -
> ADC4   | - x -
> ADC5   | - x -
> - x -  | CAN
> COMP1  | - x -
> COMP2  | COMP2
> COMP3  | - x -
> COMP4  | COMP4
> COMP5  | - x -
> COMP6  | COMP6
> COMP7  | - x -
> CRS| - x -
> DAC1   | DAC1
> DAC2   | DAC2
> DAC3   | - x -
> DAC4   | - x -
> FDCAN1 | - x -
> FDCAN2 | - x -
> FDCAN3 | - x -
> HRTIM1 | HRTIM1
> I2C1   | I2C1
> I2C2   | - x -
> I2C3   | - x -
> I2C4   | - x -
> I2S| - x -
> I2S2   | - x -
> I2S3   | - x -
> IR | IR
> LPTIM1 | - x -
> LPUART1| - x -
> OPAMP1 | - x -
> OPAMP2 | OPAMP2
> OPAMP3 | - x -
> OPAMP4 | - x -
> OPAMP5 | - x -
> OPAMP6 | - x -
> QUADSPI1   | - x -
> RCC| RCC
> RTC| RTC
> SAI1   | - x -
> SPI1   | SPI1
> SPI2   | - x -
> SPI3   | - x -
> SYS| SYS
> TIM1   | TIM1
> TIM15  | TIM15
> TIM16  | TIM16
> TIM17  | TIM17
> TIM2   | TIM2
> TIM20  | - x -
> TIM3   | TIM3
> TIM4   | - x -
> TIM5   | - x -
> TIM8   | - x -
> - x -  | TSC
>

Re: Adding support for STM32G474RET6

[raiden00pl .]

>
> Analog: the STM32G474Cxt is heavy on analog features with much more
> ADC, DAC, COMP, and OPAMP peripherals and pins than the STM32F3. These
> features are obviously new IP as the ADC adds Hardware Oversampling,
> IO Voltage Booster, Gain Compensation, Bulb Sampling, Sampling Time
> Control Trigger, Dual Interleaved Sampling, new Analog Watchdog
> features. The DAC adds Sample and Hold, and also Internal DACs that
> can be connected to other internal peripherals, e.g., to a COMP or
> OPAMP. And there's much more. [1]
>

Yes, there are some new features in analogs but if you look at registers
organization
and configuration bits, these looks the same as in F3.

Timers: Both have HRTIM, but the STM32F334 has HRTIM IP version 1.0
> while STM32G474Cxt has HRTIM IP version 2.0. This adds various
> features and capabilities, described in [2]. Also, the G4 more of the
> regular resolution timers.
>

As above, we have new features, but the basic structure is the same.
The question is when we can talk about completely new IP block and
when we can talk only about an extended old version.
In my opinion, when the registers are identical, we have backward
compatibility but some new functions added - we are dealing with the same
IP block.

With this approach, we can easily extend existing code with some #ifdefs.

Re: Adding support for STM32G474RET6

[raiden00pl .]

>
> This document address migration from F1 to F3 and addresses all major
> differences between F1 and F3:  AN4228, Application note, Migrating from
> STM32F1 Series to STM32F3 Series microcontrollers. Table 6 address every
> peripheral.


If we are looking at compatibility then yes, most peripherals from F3 are
at least partial
compatible with F1. But also almost all are upgraded in some way.
And the statement "partial compatibility" in this table can be a bit
confusing.
For example "partial compatibility" for ADC means that ADC is completely
new IP block
with completely different registers organization :)

If you look at similar document which discuss migration from F1 to F4, you
will
see full compatibility between peripherals except RCC

Re: Adding support for STM32G474RET6

[raiden00pl .]

> How does the RCC (clock tree) compare?

RCC looks like in G0 family, which is not registers compatible with older
versions. But clock tree is similar to those found in F4/F7.

czw., 16 kwi 2020 o 02:34 David Sidrane 
napisał(a):

> How does the RCC (clock tree) compare?
>
> On Wed, Apr 15, 2020, 5:11 PM Nathan Hartman 
> wrote:
>
> > On Wed, Apr 15, 2020 at 4:08 PM Gregory Nutt 
> wrote:
> > > This document address migration from F1 to F3 and addresses all major
> > > differences between F1 and F3:  AN4228, Application note, Migrating
> from
> > > STM32F1 Series to STM32F3 Series microcontrollers. Table 6 address
> every
> > > peripheral.
> >
> > Ok, I'll look at that.
> >
> > Meanwhile... So I've been studying, toward making a decision, whether
> > to try implementing this in the stm32 directory or create a new one
> > for stm32g4... I probably won't know which is better and which is less
> > (or more!) work until I actually start writing code.
> >
> > As I'm looking at STM32F3 parts we support and compare to STM32G474,
> > it seems the STM32F334 has the most similarities to this new part.
> >
> > Comparison:
> >
> > (At least what I know so far...)
> >
> > Both have GPIO ports ABCF. STM32G474CxT adds port G but only for
> > PG10-NRST. That is, the reset pin can be used as a GPIO.
> >
> > Analog: the STM32G474Cxt is heavy on analog features with much more
> > ADC, DAC, COMP, and OPAMP peripherals and pins than the STM32F3. These
> > features are obviously new IP as the ADC adds Hardware Oversampling,
> > IO Voltage Booster, Gain Compensation, Bulb Sampling, Sampling Time
> > Control Trigger, Dual Interleaved Sampling, new Analog Watchdog
> > features. The DAC adds Sample and Hold, and also Internal DACs that
> > can be connected to other internal peripherals, e.g., to a COMP or
> > OPAMP. And there's much more. [1]
> >
> > Timers: Both have HRTIM, but the STM32F334 has HRTIM IP version 1.0
> > while STM32G474Cxt has HRTIM IP version 2.0. This adds various
> > features and capabilities, described in [2]. Also, the G4 more of the
> > regular resolution timers.
> >
> > Communication: STM32F334 has CAN. STM32G474CxT has FDCAN1, FDCAN2,
> > FDCAN3. STM32G474CxT has LPTIM, LPUART, SAI, USB. Also, more I2C and
> > SPI.
> >
> > Side-by-side comparison of Ports, Pins, and Peripherals:
> >
> > Ports:
> > ===
> > STM32G474CxTx  | STM32F334CxTx
> > ===
> > PORT_A | PORT_A
> > PORT_B | PORT_B
> > PORT_C | PORT_C
> > PORT_F | PORT_F
> > PORT_G | - x -
> > ---
> >
> >
> > Pins:
> > ===
> > STM32G474CxTx  | STM32F334CxTx
> > ===
> > PA0| PA0
> > PA1| PA1
> > PA2| PA2
> > PA3| PA3
> > PA4| PA4
> > PA5| PA5
> > PA6| PA6
> > PA7| PA7
> > PA8| PA8
> > PA9| PA9
> > PA10   | PA10
> > PA11   | PA11
> > PA12   | PA12
> > PA13   | PA13
> > PA14   | PA14
> > PA15   | PA15
> > ---
> > PB0| PB0
> > PB1| PB1
> > PB2| PB2
> > PB3| PB3
> > PB4| PB4
> > PB5| PB5
> > PB6| PB6
> > PB7| PB7
> > PB8-BOOT0  | PB8
> > PB9| PB9
> > PB10   | PB10
> > PB11   | PB11
> > PB12   | PB12
> > PB13   | PB13
> > PB14   | PB14
> > PB15   | PB15
> > ---
> > PC13   | PC13
> > PC14-OSC32_IN  | PC14-OSC32_IN
> > PC15-OSC32_OUT | PC15-OSC32_OUT
> > ---
> > PF0-OSC_IN | PF0-OSC_IN
> > PF1-OSC_OUT| PF1-OSC_OUT
> > ---
> > PG10-NRST  | - x -
> > ---
> >
> >
> > Peripherals:
> > ===
> > STM32G474CxTx  | STM32F334CxTx
> > ===
> > ADC1   | ADC1
> > ADC2   | ADC2
> > ADC3   | - x -
> > ADC4   | - x -
> > ADC5   | - x -
> > - x -  | CAN
> > COMP1  | - x -
> > COMP2  | COMP2
> > COMP3  | - x -
> > COMP4  | COMP4
> > COMP5  | - x -
> > COMP6  | COMP6
> > COMP7  | - x -
> > CRS| - x -
> > DAC1   | DAC1
> > DAC2   | DAC2
> > DAC3   | - x -
> > DAC4   | - x -
> > FDCAN1 | - x -
> > FDCAN2 | - x -
> > FDCAN3 | - x -
> > HRTIM1 | HRTIM1
> > I2C1   | I2C1
> > I2C2   | - x -
> > I2C3   | - x -
> > I2C4   | - x -
> > I2S| - x -
> > I2S2   | - x -
> > I2S3   | - x -
> > IR | IR
> > LPTIM1 | - x -
> > LPUART1| - x -
> > OPAMP1 | - x -
> > OPAMP2 | OPAMP2
> > OPAMP3 | - x -
> > OPA

Build failed in Jenkins: NuttX-Nightly-Build #97

[Apache Jenkins Server]

See 

Changes:


--
[...truncated 297.41 KB...]

Configuration/Tool: sim/sixlowpan

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...


Skipping: sim/cxxtest

Configuration/Tool: sim/nettest

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...


Skipping: sim/nxwm

Configuration/Tool: sim/ipforward

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...


Configuration/Tool: sim/nx

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...


Configuration/Tool: sim/ostest

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...


Configuration/Tool: sim/mount

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...


Configuration/Tool: sim/module

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...


Configuration/Tool: sim/minibasic

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...


Configuration/Tool: sim/tcpblaster

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...


Configuration/Tool: sim/touchscreen

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...


Configuration/Tool: sim/bas

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...


Configuration/Tool: sim/mtdpart

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=