RE: SDIO MMCSD card is not writing/reading files anymore it does mount CMD24 -5 error

[disruptivesolutionsnl]

Update:

I think I have found it. it has to do with 1-bit and 4-bit:

The SDIO Card Specification Version 2.0 is also supported with two different
databus modes: 1-bit (default) and 4-bit.

 

Nuttx has default 4-bit and that's why I was thrown of.

 

I tried to change the SDIO Clock (DIV) and wanted to "talk" in 4-bit databus
mode. But then the error stays. In 1-bit the STM32F407VE seems to do the
job.

 

Ben

 

Van: disruptivesolution...@gmail.com  
Verzonden: maandag 13 april 2020 20:55
Aan: dev@nuttx.apache.org
Onderwerp: RE: SDIO MMCSD card is not writing/reading files anymore it does
mount CMD24 -5 error

 

Update:

My purpose is to write data to a file in a thread. With append. Writing once
works.

 

int nbytesi;

nbytesi = write(fd_mmcsd, g_testmsg, strlen(g_testmsg));

 

if (nbytesi < 0)

{

   printf("write_test_file: ERROR failed to write to %s, errno=%d\n",

   "/dev/mmcsd0", errno);

}

 else

   {

  printf("write_test_file: wrote %d bytes to %s\n", nbytesi,
"/dev/mmcsd0");

}

   close(fd_mmcsd);

 

sleep(2); <-- when putting in a sleep it all breaks 

 

nbytesi;

nbytesi = write(fd_mmcsd, g_testmsg, strlen(g_testmsg));

 

if (nbytesi < 0)

{

   printf("write_test_file: ERROR failed to write to %s, errno=%d\n",

   "/dev/mmcsd0", errno);

}

 else

   {

  printf("write_test_file: wrote %d bytes to %s\n", nbytesi,
"/dev/mmcsd0");

}

 

   close(fd_mmcsd);

 

 

 

Van: disruptivesolution...@gmail.com
  mailto:disruptivesolution...@gmail.com> > 
Verzonden: maandag 13 april 2020 12:06
Aan: dev@nuttx.apache.org  
Onderwerp: SDIO MMCSD card is not writing/reading files anymore it does
mount CMD24 -5 error

 

Hi All,

 

I had the SD card written with using Nuttx, but then it stopt writing and
reading to and from the SD card. I get a CMD24 error:

mmcsd_eventwait: ERROR: Awakened with 14


mmcsd_writesingle: ERROR: CMD24 transfer failed: -5

 

It seems to think it wrote bytes, but no file there. What am I doing wrong?
Where could I find more info?

 

Debug log:

mmcsd_open: Entry


mmcsd_geometry: Entry


mmcsd_geometry: available: true mediachanged: true writeenabled: true


mmcsd_geometry: nsectors: 248320 sectorsize: 512


mmcsd_read: startsector: 0 nsectors: 1 sectorsize: 512


mmcsd_readsingle: startblock=0


mmcsd_readsingle: offset=0


fat_checkbootrecord: WARNING: Signature: aa55 FS sectorsize: 0 HW
sectorsize: 512

fat_mount: Partition 0, offset 446, type 6


mmcsd_read: startsector: 97 nsectors: 1 sectorsize: 512


mmcsd_readsingle: startblock=97


mmcsd_readsingle: offset=49664


fat_mount: FBR found in partition 0


fat_mount: FAT16:


fat_mount:  HW  sector size: 512


fat_mount:  sectors: 248320


fat_mount:  FAT reserved:1


fat_mount:  sectors: 248223


fat_mount:  start sector:98


fat_mount:  root sector: 160


fat_mount:  root entries:512


fat_mount:  data sector: 192


fat_mount:  FSINFO sector:   0


fat_mount:  Num FATs:2


fat_mount:  FAT sectors: 31


fat_mount:  sectors/cluster: 32


fat_mount:  max clusters:7754


fat_mount:  FSI free count   -1


fat_mount:  next free0


succes mount!


mmcsd_geometry: Entry


mmcsd_geometry: available: true mediachanged: false writeenabled: true


mmcsd_geometry: nsectors: 248320 sectorsize: 512


mmcsd_read: startsector: 160 nsectors: 1 sectorsize: 512


mmcsd_readsingle: startblock=160


mmcsd_readsingle: offset=81920


mmcsd_writing_daemon started


 

mmcsd_geometry: Entry


mmcsd_geometry: available: true mediachanged: false writeenabled: true


mmcsd_geometry: nsectors: 248320 sectorsize: 512


mmcsd_write: sector: 160 nsectors: 1 sectorsize: 512


mmcsd_writesingle: startblock=160


mmcsd_writesingle: offset=81920


mmcsd_eventwait: ERROR: Awakened with 14


mmcsd_writesingle: ERROR: CMD24 transfer failed: -5


fat_currentsector: position=0 currentsector=-22 sectorsincluster=32


write_test_file: wrote 15 bytes to /dev/mmcsd0


 

mmcsd_geometry: available: true mediachanged: false writeenabled: true


mmcsd_geometry: nsectors: 248320 sectorsize: 512


mmcsd_write: sector: 4294967274 nsectors: 1 sectorsize: 512


mmcsd_writesingle: startblock=-22


mmcsd_writesingle: offset=-11264


mmcsd_eventwait: ERROR: Awakened with 14


mmcsd_writesingle: ERROR: CMD24 transfer failed: -5

[PATCH] arch/arm/src/stm32l4/stm32l4_spi.c: add missing ret

[Juha Niskanen (Haltian)]

Hi Greg,

Trivial build error corrected.

Best Regards,
   Juha
From 402bdadb6f51ce8879931fa0067fa82bcf3c0677 Mon Sep 17 00:00:00 2001
From: Juha Niskanen 
Date: Tue, 14 Apr 2020 16:42:09 +0300
Subject: [PATCH] arch/arm/src/stm32l4/stm32l4_spi.c: add missing ret

---
 arch/arm/src/stm32l4/stm32l4_spi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/src/stm32l4/stm32l4_spi.c b/arch/arm/src/stm32l4/stm32l4_spi.c
index 0771a1b..0ce5ef0 100644
--- a/arch/arm/src/stm32l4/stm32l4_spi.c
+++ b/arch/arm/src/stm32l4/stm32l4_spi.c
@@ -1450,6 +1450,7 @@ static void spi_exchange(FAR struct spi_dev_s *dev, FAR const void *txbuffer,
  FAR void *rxbuffer, size_t nwords)
 {
   FAR struct stm32l4_spidev_s *priv = (FAR struct stm32l4_spidev_s *)dev;
+  int ret;
 
 #ifdef CONFIG_STM32L4_DMACAPABLE
   if ((txbuffer &&
-- 
2.7.4

[PATCH] arch/arm/src/stm32l4/stm32l4_1wire.c: fix build error, fix typo

[Juha Niskanen (Haltian)]

Hi,

Yet another trivial build error.

Best Regards,
  Juha
From 7756b0d3f401e8fc16740f2f13c57a9d76a353c0 Mon Sep 17 00:00:00 2001
From: Juha Niskanen 
Date: Tue, 14 Apr 2020 18:20:33 +0300
Subject: [PATCH] arch/arm/src/stm32l4/stm32l4_1wire.c: fix build error, fix
 typo

---
 arch/arm/src/lc823450/lc823450_i2c.c | 2 +-
 arch/arm/src/stm32/stm32_1wire.c | 2 +-
 arch/arm/src/stm32/stm32_i2c.c   | 2 +-
 arch/arm/src/stm32/stm32_i2c_alt.c   | 2 +-
 arch/arm/src/stm32/stm32f40xxx_i2c.c | 2 +-
 arch/arm/src/stm32h7/stm32_i2c.c | 2 +-
 arch/arm/src/stm32l4/stm32l4_1wire.c | 4 ++--
 7 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/arch/arm/src/lc823450/lc823450_i2c.c b/arch/arm/src/lc823450/lc823450_i2c.c
index a6d5831..8716903 100644
--- a/arch/arm/src/lc823450/lc823450_i2c.c
+++ b/arch/arm/src/lc823450/lc823450_i2c.c
@@ -134,7 +134,7 @@ struct lc823450_i2c_priv_s
 
   FAR const struct lc823450_i2c_config_s *config;
 
-  int   refs;  /* Referernce count */
+  int   refs;  /* Reference count */
   sem_t sem_excl;  /* Mutual exclusion semaphore */
 #ifndef CONFIG_I2C_POLLED
   sem_t sem_isr;   /* Interrupt wait semaphore */
diff --git a/arch/arm/src/stm32/stm32_1wire.c b/arch/arm/src/stm32/stm32_1wire.c
index 98c98c3..e6691d3 100644
--- a/arch/arm/src/stm32/stm32_1wire.c
+++ b/arch/arm/src/stm32/stm32_1wire.c
@@ -129,7 +129,7 @@ struct stm32_1wire_config_s
 struct stm32_1wire_priv_s
 {
   const struct stm32_1wire_config_s *config; /* Port configuration */
-  volatile int refs; /* Referernce count */
+  volatile int refs; /* Reference count */
   sem_tsem_excl; /* Mutual exclusion semaphore */
   sem_tsem_isr;  /* Interrupt wait semaphore */
   int  baud; /* Baud rate */
diff --git a/arch/arm/src/stm32/stm32_i2c.c b/arch/arm/src/stm32/stm32_i2c.c
index 9320daf..a82f6eb 100644
--- a/arch/arm/src/stm32/stm32_i2c.c
+++ b/arch/arm/src/stm32/stm32_i2c.c
@@ -250,7 +250,7 @@ struct stm32_i2c_priv_s
 
   const struct stm32_i2c_config_s *config;
 
-  int refs;/* Referernce count */
+  int refs;/* Reference count */
   sem_t sem_excl;  /* Mutual exclusion semaphore */
 #ifndef CONFIG_I2C_POLLED
   sem_t sem_isr;   /* Interrupt wait semaphore */
diff --git a/arch/arm/src/stm32/stm32_i2c_alt.c b/arch/arm/src/stm32/stm32_i2c_alt.c
index d3e61b5..239d79d 100644
--- a/arch/arm/src/stm32/stm32_i2c_alt.c
+++ b/arch/arm/src/stm32/stm32_i2c_alt.c
@@ -278,7 +278,7 @@ struct stm32_i2c_priv_s
 
   const struct stm32_i2c_config_s *config;
 
-  int refs;/* Referernce count */
+  int refs;/* Reference count */
   sem_t sem_excl;  /* Mutual exclusion semaphore */
 #ifndef CONFIG_I2C_POLLED
   sem_t sem_isr;   /* Interrupt wait semaphore */
diff --git a/arch/arm/src/stm32/stm32f40xxx_i2c.c b/arch/arm/src/stm32/stm32f40xxx_i2c.c
index b783d40..302124b 100644
--- a/arch/arm/src/stm32/stm32f40xxx_i2c.c
+++ b/arch/arm/src/stm32/stm32f40xxx_i2c.c
@@ -265,7 +265,7 @@ struct stm32_i2c_priv_s
 
   const struct stm32_i2c_config_s *config;
 
-  int refs;/* Referernce count */
+  int refs;/* Reference count */
   sem_t sem_excl;  /* Mutual exclusion semaphore */
 #ifndef CONFIG_I2C_POLLED
   sem_t sem_isr;   /* Interrupt wait semaphore */
diff --git a/arch/arm/src/stm32h7/stm32_i2c.c b/arch/arm/src/stm32h7/stm32_i2c.c
index a588e0e..5fc7155 100644
--- a/arch/arm/src/stm32h7/stm32_i2c.c
+++ b/arch/arm/src/stm32h7/stm32_i2c.c
@@ -384,7 +384,7 @@ struct stm32_i2c_priv_s
 
   const struct stm32_i2c_config_s *config;
 
-  int refs;/* Referernce count */
+  int refs;/* Reference count */
   sem_t sem_excl;  /* Mutual exclusion semaphore */
 #ifndef CONFIG_I2C_POLLED
   sem_t sem_isr;   /* Interrupt wait semaphore */
diff --git a/arch/arm/src/stm32l4/stm32l4_1wire.c b/arch/arm/src/stm32l4/stm32l4_1wire.c
index d615e57..82ecf63 100644
--- a/arch/arm/src/stm32l4/stm32l4_1wire.c
+++ b/arch/arm/src/stm32l4/stm32l4_1wire.c
@@ -122,7 +122,7 @@ struct stm32_1wire_config_s
 struct stm32_1wire_priv_s
 {
   const struct stm32_1wire_config_s *config; /* Port configuration */
-  volatile int refs; /* Referernce count */
+  volatile int refs; /* Reference count */
   sem_tsem_excl; /* Mutual exclusion semaphore */
   sem_tsem_isr;  /* Interrupt wait semaphore */
   int  baud; /* Baud rate */
@@ -681,7 +681,7 @@ static inline void stm32_1wire_sem_destroy(
  *
  /
 
-static int void st

[PATCH] arch/arm/src/stm32f7/stm32_flash.c: fix return value of stm32_flash_lock

[Juha Niskanen (Haltian)]

Hi,

Yet another one

Best Regards,
   Juha
From 251c978ef83589ee3ab31b367f538692ecc77bf2 Mon Sep 17 00:00:00 2001
From: Juha Niskanen 
Date: Tue, 14 Apr 2020 18:25:56 +0300
Subject: [PATCH] arch/arm/src/stm32f7/stm32_flash.c: fix return value of
 stm32_flash_lock

---
 arch/arm/src/stm32f7/stm32_flash.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/src/stm32f7/stm32_flash.c b/arch/arm/src/stm32f7/stm32_flash.c
index 6268ecf..2b8fdbc 100644
--- a/arch/arm/src/stm32f7/stm32_flash.c
+++ b/arch/arm/src/stm32f7/stm32_flash.c
@@ -138,7 +138,7 @@ int stm32_flash_unlock(void)
   return ret;
 }
 
-void stm32_flash_lock(void)
+int stm32_flash_lock(void)
 {
   int ret;
 
-- 
2.7.4

SocketCAN Status

[Gregory Nutt]

Hi, Peter,

Has there been any clarification about the state of licensing on 
SocketCAN code?  I have been rebasing the SocketCAN branch against 
master periodically, so it is ready to retest and merge when we can 
resolve the licensing issues.  My understanding is:


1. We would have to include the dual license VW code with license 
headers as is, but


2. We would need some software grant from NXP for the NXP licensed code 
(I have dealt with this situation before and NXP just isn't very keen on 
granting software).


Is all of the above correct?  Couldn't we also just bring this in as 3rd 
party code with the VW and NXP copyrights in place?  What would it take 
to do that... I suppose that is a question for an ASF Mentor like Justin.


You have put a lot of effort into this NuttX port and it is sad to see 
it wilting on a branch.


Greg

Re: [DISCUSS] Release Notes

[Abdelatif Guettouche]

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: [DISCUSS] Release Notes

[Nathan Hartman]

On Tue, Apr 14, 2020 at 5:13 PM Abdelatif Guettouche
 wrote:
> Are there any concerns or additions to the release notes?

I just made some minor changes (most notably, describing the DNS Dual
Host support where there was previously a note "what is this? No PR
description").

> 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?

I added some text there. It's just a suggestion. Feel free to edit it
(or expand/remove/etc) !!! :-)

Cheers,
Nathan

Adding support for STM32G474RET6

[Nathan Hartman]

Regarding STM32 support, I'd like to add architectural and board
support for the B-G474E-DPOW1 Discovery board and its STM32G474RET6
microcontroller:

https://www.st.com/en/evaluation-tools/b-g474e-dpow1.html

My first question is, which directory does this architecture belong in?

Looking at the directories under arch/arm/src or arch/arm/include, it
seems they go loosely by core type:

* stm32 - Mix of Cortex-M3 STM32F1, STM32F2 families, Cortex-M4
STM32F3, STM32F4 families

* stm32f0l0g0 - Cortex-M0, -M0+

* stm32f7 - Cortex-M7

* stm32h7 - Cortex-M4 and Dual Core -M4/-M7, in the STM32H7 family only

* stm32l4 - Cortex-M4, in the STM32L4 family only

The STM32G4 family is Cortex-M4 and seems to have similarities to the
STM32F4 family. Does this belong in the stm32 directory? Does it
require a new stm32g4 directory?

Thanks,
Nathan

RE: Adding support for STM32G474RET6

[David Sidrane]

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 headers. Not litter the headers or
code with
#if defined(STM32x) 


David

-Original Message-
From: Nathan Hartman [mailto:hartman.nat...@gmail.com]
Sent: Tuesday, April 14, 2020 2:51 PM
To: dev@nuttx.apache.org
Subject: Adding support for STM32G474RET6

Regarding STM32 support, I'd like to add architectural and board
support for the B-G474E-DPOW1 Discovery board and its STM32G474RET6
microcontroller:

https://www.st.com/en/evaluation-tools/b-g474e-dpow1.html

My first question is, which directory does this architecture belong in?

Looking at the directories under arch/arm/src or arch/arm/include, it
seems they go loosely by core type:

* stm32 - Mix of Cortex-M3 STM32F1, STM32F2 families, Cortex-M4
STM32F3, STM32F4 families

* stm32f0l0g0 - Cortex-M0, -M0+

* stm32f7 - Cortex-M7

* stm32h7 - Cortex-M4 and Dual Core -M4/-M7, in the STM32H7 family only

* stm32l4 - Cortex-M4, in the STM32L4 family only

The STM32G4 family is Cortex-M4 and seems to have similarities to the
STM32F4 family. Does this belong in the stm32 directory? Does it
require a new stm32g4 directory?

Thanks,
Nathan

Re: Adding support for STM32G474RET6

[Nathan Hartman]

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 ifdef rash.
>
> Layered includes bring it the correct headers. Not litter the headers or
> code with
> #if defined(STM32x) 

So this sounds like a new stm32g4 subdirectory would be beneficial.

Nathan

Re: Adding support for STM32G474RET6

[Gregory Nutt]

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 
difference in clocking or power management (which would be my 
suspicion), then those could be handled with separate .c file selected 
in the Make.defs file.


You don't want to clutter the code, but neither do you want to duplicate 
all of the drivers.  The first is ugly and effects usability; the second 
could be a LOT of work.  You can't make that decision without 
understanding the differences and making some trade-off (even if it is 
still mostly subjective).

Re: Adding support for STM32G474RET6

[Nathan Hartman]

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, all of the peripherals are the same, but there is a
> difference in clocking or power management (which would be my
> suspicion), then those could be handled with separate .c file selected
> in the Make.defs file.
>
> You don't want to clutter the code, but neither do you want to duplicate
> all of the drivers.  The first is ugly and effects usability; the second
> could be a LOT of work.  You can't make that decision without
> understanding the differences and making some trade-off (even if it is
> still mostly subjective).


Thanks for your thoughts.

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 stm32f3 parts we support side-by-side
with a datasheet for one of the stm32g4, and just scrolling through them,
it seems the g4 has a lot more in terms of peripherals, including a high
resolution timer (HRTIM), more analog, more communication, various math
accelerators...

It's certainly an important question whether to create a whole new
directory or build this support into the stm32 directory.

On the one hand, I don't like to have the code duplication of yet another
stm32 directory if I can avoid it.

Bottom line, you're right: I really need to understand both families and
see how different they are. Looks like I have a lot of homework

Nathan

Re: Adding support for STM32G474RET6

[Gregory Nutt]

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 stm32f3 parts we support side-by-side
with a datasheet for one of the stm32g4, and just scrolling through them,
it seems the g4 has a lot more in terms of peripherals, including a high
resolution timer (HRTIM), more analog, more communication, various math
accelerators...


Most STM32's, certainly F4, have HRTIM.  Large number of peripherals is 
not a big issue; the issue is if the IP is the same for a give instance 
of the peripheral.


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.


There are differences in STM32 peripherals already in 
arch/arm/src/stm32.  If only a couple of peripherals differ, then they 
can still cohabitate.


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.


If that were the case, my bet is the the G4 would belong with the F4.

Greg

Re: Adding support for STM32G474RET6

[Nathan Hartman]

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 compatibility" with the stm32f3
> > series.
> >
> > I opened the datasheet for one of the stm32f3 parts we support
> side-by-side
> > with a datasheet for one of the stm32g4, and just scrolling through them,
> > it seems the g4 has a lot more in terms of peripherals, including a high
> > resolution timer (HRTIM), more analog, more communication, various math
> > accelerators...
>
> Most STM32's, certainly F4, have HRTIM.  Large number of peripherals is
> not a big issue; the issue is if the IP is the same for a give instance
> of the peripheral.


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?

More below...

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'll look at that in the morning.

More below...

There are differences in STM32 peripherals already in
> arch/arm/src/stm32.  If only a couple of peripherals differ, then they
> can still cohabitate.
>
> 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.

Thanks,
Nathan

Jenkins build is back to normal : NuttX-Nightly-Build #96

[Apache Jenkins Server]

See 

Re: Adding support for STM32G474RET6

[raiden00pl .]

> 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 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.


śr., 15 kwi 2020 o 06:07 Nathan Hartman 
napisał(a):

> 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 compatibility" with the stm32f3
> > > series.
> > >
> > > I opened the datasheet for one of the stm32f3 parts we support
> > side-by-side
> > > with a datasheet for one of the stm32g4, and just scrolling through
> them,
> > > it seems the g4 has a lot more in terms of peripherals, including a
> high
> > > resolution timer (HRTIM), more analog, more communication, various math
> > > accelerators...
> >
> > Most STM32's, certainly F4, have HRTIM.  Large number of peripherals is
> > not a big issue; the issue is if the IP is the same for a give instance
> > of the peripheral.
>
>
> 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?
>
> More below...
>
> 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'll look at that in the morning.
>
> More below...
>
> There are differences in STM32 peripherals already in
> > arch/arm/src/stm32.  If only a couple of peripherals differ, then they
> > can still cohabitate.
> >
> > 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.
>
> Thanks,
> Nathan
>