On Thu, May 14, 2020 at 5:21 PM Nathan Hartman wrote:
> It is now time to open a PR and start the review process.
The PR is #1051:
https://github.com/apache/incubator-nuttx/pull/1051
Alan and David, whenever you get the chance, I'll be standing by to
address any issues you find...
Thanks!
Natha
BIG UPDATE: The board boots NuttX to a working NSH prompt!
This means that a whole lot of things went right.
It is now time to open a PR and start the review process.
I'm going to title the PR [DO NOT MERGE] until we go through it...
Greg, thanks for your help. David and Alan, thanks for volunt
Hi
I would be happy to review this, but I will need some time as I am swapped.
David
-Original Message-
From: Gregory Nutt [mailto:spudan...@gmail.com]
Sent: Wednesday, May 13, 2020 9:27 AM
To: dev@nuttx.apache.org
Subject: Re: Adding support for STM32G474RET6
> If all goes w
On Wed, May 13, 2020 at 12:26 PM Gregory Nutt wrote:
>
> > If all goes well, there will be a big pull request coming soon. Wish me
> luck!
>
> I think we should consider getting a review team together. This will be
> more than a single person can review (especially if that single person
> is me
If all goes well, there will be a big pull request coming soon. Wish me luck!
I think we should consider getting a review team together. This will be
more than a single person can review (especially if that single person
is me since I am completely out of touch with with STM32 these days).
I with you good luck! Welcome STM32G4!
On 5/13/20, Nathan Hartman wrote:
> Update: It builds! It links! After much work, it's time to begin testing...
>
> https://github.com/hartmannathan/incubator-nuttx/tree/stm32g474
>
> If all goes well, there will be a big pull request coming soon. Wish me
>
Update: It builds! It links! After much work, it's time to begin testing...
https://github.com/hartmannathan/incubator-nuttx/tree/stm32g474
If all goes well, there will be a big pull request coming soon. Wish me luck!
Nathan
Progress report on this port: I'm getting closer... Not quite
compiling yet, still some errors with a few undefined register
definitions here and there. But I'm definitely getting closer...
As before, my work is in my fork under stm32g474 branch [1], if anyone
wants a sneak preview. :-)
[1] https
On Thu, May 7, 2020 at 1:18 PM raiden00pl . wrote:
> A new branch is a good idea, but I think we should squash as many commits
> as possible before PRs to
> avoid noise in the git history. Especially when it comes to new chip
> specific files.
Agreed. I was thinking to squash the chip support int
> STM32L4R also has DMAMUX with two DMAx controllers. Maybe it is closer
match for STM32G4 than H7.
Yes, you are right. STM32L4R is definitely a better choice.
> Can we put my stm32g474 branch into the main NuttX repository (as a
> branch, not in master) and split the work? I have ~50 commits and
On Thu, May 7, 2020 at 1:25 AM raiden00pl . wrote:
> I got my NUCLEO-G431RB so I can help.
How shall we proceed?
Can we put my stm32g474 branch into the main NuttX repository (as a
branch, not in master) and split the work? I have ~50 commits and
~7000 lines so far. I think it will be better to
Hello,
STM32L4R also has DMAMUX with two DMAx controllers. Maybe it is closer match
for STM32G4 than H7.
Check:
https://github.com/apache/incubator-nuttx/blob/master/arch/arm/src/stm32l4/stm32l4xrxx_dma.c
https://github.com/apache/incubator-nuttx/blob/master/arch/arm/src/stm32l4/hardware/stm
You can look how DMAMUX is implemented for stm32h7.
It's more complicated than in G4 and H7 is based on DMA IPv2 but the
concept should be the same.
I got my NUCLEO-G431RB so I can help.
czw., 7 maj 2020 o 00:15 Nathan Hartman
napisał(a):
> On Wed, May 6, 2020 at 6:10 PM Nathan Hartman
> wrote:
On Wed, May 6, 2020 at 6:10 PM Nathan Hartman wrote:
> On Wed, May 6, 2020 at 4:56 PM Gregory Nutt wrote:
> > > In arch/arm/src/stm32/hardware/stm32_dma_v1.h, I have to add DMA
> > > channel mappings of the form:
> > >
> > > # define DMACHAN_ADC1STM32_DMA1_CHAN1
> > >
> > > for the (
On Wed, May 6, 2020 at 4:56 PM Gregory Nutt wrote:
> > In arch/arm/src/stm32/hardware/stm32_dma_v1.h, I have to add DMA
> > channel mappings of the form:
> >
> > # define DMACHAN_ADC1STM32_DMA1_CHAN1
> >
> > for the (new) case of CONFIG_STM32_STM32G47XX.
> >
> > How / where can I find
In arch/arm/src/stm32/hardware/stm32_dma_v1.h, I have to add DMA
channel mappings of the form:
# define DMACHAN_ADC1STM32_DMA1_CHAN1
for the (new) case of CONFIG_STM32_STM32G47XX.
How / where can I find the names and values that should be defined?
Probably in the data sheet rat
In arch/arm/src/stm32/hardware/stm32_dma_v1.h, I have to add DMA
channel mappings of the form:
# define DMACHAN_ADC1STM32_DMA1_CHAN1
for the (new) case of CONFIG_STM32_STM32G47XX.
How / where can I find the names and values that should be defined?
Thanks,
Nathan
On Sun, Apr 19, 2020 at 12:03 AM Nathan Hartman
wrote:
> I've begun work on supporting the STM32G474RET6, and also the
> B-G474E-DPOW1 Discovery board.
Just FYI, I've been working on adding support for the STM32G474 family
and B-G474E-DPOW1 development board. So far, I have cranked out quite
a bi
I've begun work on supporting the STM32G474RET6, and also the
B-G474E-DPOW1 Discovery board.
So far I don't have much to show, but hopefully there will be much
more in the coming days. What I have so far is in my fork, in a branch
called stm32g474:
https://github.com/hartmannathan/incubator-nuttx
the
last quality guard.
> -Original Message-
> From: Xiang Xiao [mailto:xiaoxiang781...@gmail.com]
> Sent: Thursday, April 16, 2020 7:47 PM
> To: dev@nuttx.apache.org
> Subject: Re: Adding support for STM32G474RET6
>
> On Fri, Apr 17, 2020 at 5:54 AM David Sidrane
> wr
How about in the commit hooks?
-Original Message-
From: Xiang Xiao [mailto:xiaoxiang781...@gmail.com]
Sent: Thursday, April 16, 2020 7:47 PM
To: dev@nuttx.apache.org
Subject: Re: Adding support for STM32G474RET6
On Fri, Apr 17, 2020 at 5:54 AM David Sidrane
wrote:
>
> Thank y
On Fri, Apr 17, 2020 at 12:04 PM Xiang Xiao wrote:
>
> On Fri, Apr 17, 2020 at 11:17 AM Nathan Hartman
> wrote:
> >
> > On Thu, Apr 16, 2020 at 10:47 PM Xiang Xiao
> > wrote:
> >
> > > On Fri, Apr 17, 2020 at 5:54 AM David Sidrane
> > > wrote:
> > > >
> > > > Thank you for fixing the typos. I a
On Fri, Apr 17, 2020 at 11:17 AM Nathan Hartman
wrote:
>
> On Thu, Apr 16, 2020 at 10:47 PM Xiang Xiao
> wrote:
>
> > On Fri, Apr 17, 2020 at 5:54 AM David Sidrane
> > wrote:
> > >
> > > Thank you for fixing the typos. I am sure I can make them faster than you
> > > can fix them. :)
> > >
> >
>
On Thu, Apr 16, 2020 at 10:47 PM Xiang Xiao
wrote:
> On Fri, Apr 17, 2020 at 5:54 AM David Sidrane
> wrote:
> >
> > Thank you for fixing the typos. I am sure I can make them faster than you
> > can fix them. :)
> >
>
> Actually, checkpatch.sh support -c option which do the spell check by
> invok
athan Hartman [mailto:hartman.nat...@gmail.com]
> Sent: Thursday, April 16, 2020 12:39 PM
> To: dev@nuttx.apache.org
> Subject: Re: Adding support for STM32G474RET6
>
> On Thu, Apr 16, 2020 at 1:00 PM David Sidrane
> wrote:
> > If you look at the Kinetis,
> > https://
PM
To: dev@nuttx.apache.org
Subject: Re: Adding support for STM32G474RET6
On Thu, Apr 16, 2020 at 1:00 PM David Sidrane
wrote:
> If you look at the Kinetis,
> https://github.com/apache/incubator-nuttx/blob/master/arch/arm/include/kinetis/kinetis_pmc.h#L50-L63
>
> You can see the gist
On Thu, Apr 16, 2020 at 1:00 PM David Sidrane wrote:
> If you look at the Kinetis,
> https://github.com/apache/incubator-nuttx/blob/master/arch/arm/include/kinetis/kinetis_pmc.h#L50-L63
>
> You can see the gist of that approach.
>
> It idea was as developers on the outside of the MFG, we only see
chip
level and not litter the code with partnumber.
David
-Original Message-
From: Gregory Nutt [mailto:spudan...@gmail.com]
Sent: Thursday, April 16, 2020 7:47 AM
To: dev@nuttx.apache.org
Subject: Re: Adding support for STM32G474RET6
> One thing you can do to keep prevent the runaway de
On Thu, Apr 16, 2020 at 10:41 AM Gregory Nutt wrote:
> One thing you can do to keep prevent the runaway dependencies on
> specific chips is to parameterized the features. For example, if
> STM32abc, STM32def, and STM32ghi and have FEATURE_X, then instead of
> conditioning the implementation of FE
One thing you can do to keep prevent the runaway dependencies on
specific chips is to parameterized the features. For example, if
STM32abc, STM32def, and STM32ghi and have FEATURE_X, then instead of
conditioning the implementation of FEATURE_X on all of those MCUs, you
could minimize the ch
So what's the deciding factor? Should this be in 'stm32' directory
because most peripherals have compatibility? Or a different directory
because RCC is different?
The deciding factor should be maintainability.
I have not heard any reason why the support should not go under stm32/.
Mu only c
On Thu, Apr 16, 2020 at 1:16 AM raiden00pl . wrote:
> > 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.
On Thu, Apr 16, 2020 at 12:44 AM raiden00pl . wrote:
> Yes,
> 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,
>
> 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 periphera
>
> 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 Tri
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
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
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
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.
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 o
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 differen
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 t
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 w
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
mino
> Most STM32's, certainly F4, have HRTIM.
That's not true. Only F3 and H7 have HRTIM. HRTIM is a timer dedicated
to power electronics applications. You've probably confused advanced
timers (TIM1/TIM8) with HRTIM, but these are completely different
peripherals.
> The F3 is not a good point of comp
On Tue, Apr 14, 2020 at 9:11 PM Gregory Nutt wrote:
>
> > In reading about the STM32G4 family, someplace on the STmicro website,
> this
> > introductory page:
> >
> >
> https://www.st.com/en/microcontrollers-microprocessors/stm32g4-series.html
> >
> > suggests that there's a "high degree of compa
In reading about the STM32G4 family, someplace on the STmicro website, this
introductory page:
https://www.st.com/en/microcontrollers-microprocessors/stm32g4-series.html
suggests that there's a "high degree of compatibility" with the stm32f3
series.
I opened the datasheet for one of the stm3
On Tue, Apr 14, 2020 at 7:57 PM Gregory Nutt wrote:
>
> > So this sounds like a new stm32g4 subdirectory would be beneficial.
>
> You would have to know how pervasive the differences between the chips
> are. The STM32F0 cohabitates quite nicely with G0 and L0, for example.
>
> If, for example, a
So this sounds like a new stm32g4 subdirectory would be beneficial.
You would have to know how pervasive the differences between the chips
are. The STM32F0 cohabitates quite nicely with G0 and L0, for example.
If, for example, all of the peripherals are the same, but there is a
differenc
On Tue, Apr 14, 2020 at 6:21 PM David Sidrane wrote:
> I have not looked at the G part yet so I cannot say for certain, but I can
> share this:
>
> We learned many lessons from the coupling in the stm32 dirs. The take away
> was Avoid it!
>
> The F7 model is much better - the goal is to not have i
Hi Nathan,
I have not looked at the G part yet so I cannot say for certain, but I can
share this:
We learned many lessons from the coupling in the stm32 dirs. The take away
was Avoid it!
The F7 model is much better - the goal is to not have ifdef rash.
Layered includes bring it the correct head
51 matches
Mail list logo
