Re: Raspberry pi 4 Support

[Frank-Christian Kruegel]

Am 19.07.2023 um 18:52 schrieb Joseph Gonzalez:

Hi, I wanted to try out the NuttX RTOS, but didn't saw support for the RPi 4, 
is this board supported if not is there a way to add support to it?


Raspberry Pi is a difficult target. It is not Open Hardware, and there 
is a bunch of critical closed-source system software. The Broadcom SOCs 
are not fully documented.


The RP2040 however is a complete different thing. There is no Broadcom 
involvement, and the chip seems to be fully documented, and there is a 
NuttX port.


Or have a look at ST Micro Nuleo boards. Check the documentation before 
buying.



fchk

Re: OpenFPGALoader

[Frank-Christian Kruegel]

Am 13.07.2023 um 18:52 schrieb Simon Filgis:


Indeed the ICE fpgas are loaded by SPI. Interesting.

But mine is loaded by JTAG.


What FPGA type do you use EXACTLY?

Frank-Christian

Re: Hardcoded Pin mux, pad control and Drive Strength (AKA Slew-rate and Frequency) Settings #1570

[Frank-Christian Kruegel]

Am 10.04.2023 um 14:51 schrieb David Sidrane:


If I attempt to rephrase the proposal: Starting from a commit in a
future, stm32h7 GPIO definitions will not include speed indications
anymore, and these will have to be added manually in board.h, but ONLY
if the LEGACY_PINMAP is not set?
[DBS] Yes. This is correct. But also previously non suffixed pin. E.G. Where
there were not ALT settings to choose which GPIO to use will contain a _0
suffix.


I've designed several custom boards where I can put in an STM32F4, 
STM32F7, or STM32H7 depending on chip availability and performance 
needs. I've got board support packages for each family and keep them in 
sync so I can deliver what is needed.


My main concern and my loudest plea is: Please keep stm32f4, stm32f7, 
and stm32h7 in sync. For me making changes that make sense and pay off 
in the future are ok, but please make them on all stm32 families (at 
least the big ones).


Frank-Christian Kruegel

Re: Sensor implementation

[Frank-Christian Kruegel]

My thoughts: simple things should be simple. Getting temperature or 
humidity values from a sensor only requires a few lines of code. A 
simple character driver fells just right for me.


More code brings more potential bugs with it. The character drivers 
should remain as an option for simple things.


Frank-Christian


Am 12.03.2023 um 12:44 schrieb Tim Hardisty:

I had a quick skip through the video. My initial thoughts are:

1) This seems to be aimed at multi-sensor, multi-message systems, using uORB; 
and, perhaps even, really and perhaps only intended for PX4?
2) is it a "generic" solution, that is a really good idea, and NuttX is right to be 
adopting it, or is it just "a" way of sensors interacting with higher level software?
3) was it discussed here before?

Part of me thinks that this should be a layer on top of the tried-and-tested 
character driver approach, and it shouldn't actually be replacing it?

In the absence of any documentation, and even looking at the LTR-308 sensor as 
an example, it seems to be geared towards a sensor that will take regular 
readings (CONFIG_SENSORS_x_POLL_INTERVAL) and report timestamped changes.

Does it cater properly for "occasional" sensors that rarely need to send data? I can see 
there is some kind of push event so I imagine "my" sensor driver could adopt this 
methodology and send a message if the light level changes or a near/far proximity event occurs, but 
it seems the(my) whole system has to adopt a more complex messaging system for no good reason: the 
traditional poll_notify works well for me!

So, in summary, if this is the official way that sensors should be implemented, I will 
revisit my working driver, pain though that is. If, however, it is just "a" way 
I would rather leave it alone and see it merged once checked. In the future someone - or 
I - can revisit it should there ever be a wish for the APDS-9922 to follow the uORB/rpmsg 
approach.

Discuss! Guide me!

On 11/03/2023, 23:31, "Alan C. Assis" mailto:acas...@gmail.com>> wrote:


On 3/11/23, Xiang Xiao mailto:xiaoxiang781...@gmail.com>> wrote:

On Sun, Mar 12, 2023 at 12:12 AM Tim Hardisty mailto:t...@hardisty.co.uk>> wrote:


I submitted a PR for a driver for the Broadcom APDS-9922 ambient light
and
proximity sensor, written with what one might call the "traditional"
method of setting up the device via ioctl, then reading data when
available
according to the device setup, via poll notify.

The reviewer (Hi Alan - I'm not complaining!!) has suggested it perhaps
ought to use the "new" sensor methodology with a sensor_lower_half_s etc.

Looking at sensors that use this I can't see any that have the range of
set-up options of this device and are just "there", in the main apart
from
calibration, for example. Nor any NuttX documentation I can see?

Is this following a Linux methodology, like the power devices now do?
When
I did a power supply device drive I was pointed in the direction of Linux
documentation that (after much reading and cogitation) helped explain
what
NuttX was essentially emulating and, with the addition of some more
members
to the regulator_desc_s struct it was then fine and I wrote it that way.

I am still not convinced that this ALS/Proximity sensor necessarily fits
the "new" sensor methodology but if someone can point me in the direction
of relevant documentation I will gladly take a look.



Here is an intro video: https://www.youtube.com/watch?v=ESpAE6wqy9o 





Thank you Xiang!


Since this subsystem is more complex than original char driver sensor,
is there plans for Documentation ?


Tim, I suggest you to take a look at LTR-308 sensoe (ltr308.c) is it
also an ALS. So you can use it as reference.


BR,


Alan

NuttX and Gigadevice ARM processors?

[Frank-Christian Kruegel]

Hi;

there is a global shortage of STM32 processors on the market. I've seen 
STM32F767 selling for 480U$.


Has anybody tried Gigadevice processors? They claim to be STM 
replacements. I've got a design ready for a 144 pin STM32 (either F767 
or F427/429), and it seems that the GD32F427 are replacements for those 
that you can actually buy in quantities for a normal price (8.74 U$ for 
an GD32F427ZGT6)


https://lcsc.com/product-detail/Microcontroller-Units-MCUs-MPUs-SOCs_GigaDevice-Semicon-Beijing-GD32F427ZGT6_C3029772.html

https://www.gigadevice.com/products/microcontrollers/gd32/arm-cortex-m4/high-performance-line/gd32f427-series/

Does it run NuttX?

Frank-Christian

Re: Alternatives to FAT for msd

[Frank-Christian Kruegel]

Am 19.01.2022 um 19:40 schrieb TimH:

- an external PC (ideally Linux, Windows and MAC) needs to be able "see" 
the data via USB (msd) and read/write to the memory (log data, config 
files, audio files, etc). Hence FAT.


There is MTP (https://en.wikipedia.org/wiki/Media_Transfer_Protocol), 
which operates on a file level, not a block level. Cameras and MP3 
players use this. When using MTP you are free to choose any suitable 
file system since this is never exported to the outside world, and file 
locking etc is never an issue.


Frank-Christian Krügel

Re: Lin

[Frank-Christian Kruegel]

Am 13.08.2021 um 16:50 schrieb Simon Filgis:

Dear all,

has anybody implemented a LIN driver for SAME70 USART? The SAME70 USART
peripheral is capable of. A SW implementation (sllin.c - Pavel Pisa) would
also be interesting!

Would you extend sma_lowputc.c and sam_serial.c or would you grep USARTx in
a separate file?

Have a good Weekend,

Simon


Do you need LIN Master or LIN Slave?

LIN Master is easy. It's standard serial. The only nonstandard item is 
the BREAK signal generation. For this, just insert an AND Gate into the 
LIN TX UART line and keep the other input of the gate high. When you 
need to send a break, flush the buffers, set the other input of the gate 
to low, send two bytes (any value will do), wait until all bits are out, 
and set the gate input high. Then you've sent a break with 20 bit times, 
which is perfectly within the LIN specification, and without the need 
for a timer etc.


LIN slave is much more complex, especially if you want to do autobauding 
by measuring the SYNC byte after the break. You might end up with a 
custom serial driver then. If a fixed bitrate is enough the only problem 
is detecting the BREAK signal. A received break signal is basically a 0 
byte with a framing error added. You only need to detect and clear the 
framing error.



Grüße

Frank-CHristian Krügel

Re: Creating our own driver in NUCLEO-H743ZI2 with Nuttx rtos

[Frank-Christian Kruegel]

Am 13.08.2021 um 10:43 schrieb rushi ghatkar:

Hi,

I have configured and installed Nuttx rtos on the Nucleo-H743zi2 board.

Now I want to create my own driver. How to create our own driver?

Has anyone created their own driver using Nuttx rtos on the STM32 board?

Could anybody please tell me how to start?


Been there, done that.

The best starting point is to look for a similar driver. I needed 
drivers for ADC and DAC chips with I2C interface, so I looked for those 
drivers, copied one and changed it according to my needs. Then I looked 
into Makefiles, Make.defs, and Kconfigs, how these drivers were included 
an included mine in the same manner.


The build system with make menuconfig, Makefiles and Kconfigs is the 
same as for the Linux kernel. Since your development platform is Linux 
anyways (this is the strongly recommended default platform) you should 
already have plenty of Linux experience and know how to customize an 
Linux kernel, how to use Makefiles and gcc and gdb and binutils. If you 
know Linux well the step to NuttX is not so big any more.


I started a year ago, and it took me two months to get started with own 
hardware and own drivers (ok, with Linux experience since 1993 and UNIX 
experience since 1989).



Frank-Christian

STM32F7/H7: DAC driver missing?

[Frank-Christian Kruegel]

Hi.

I'm wondering where the driver for the STM32F7/H7 DACOUT pins is. For 
STM32F7 I can select DACOUT1 and DACOUT2 in menuconfig, but I don't find 
any accompanying source code. For STM32H7 I find traces of DAC 
configuration, but work there seems to be still in progress.


For STM32F4 I do find a dac.c and dac.h.

I my assumption right that I need to port the F4 driver myself in order 
to get an F7/H7 driver?


Best regards
Frank-Christian

STM32H7: What happened with the CANFD driver?

[Frank-Christian Kruegel]

Hi!

Some months ago a member of this mailing list submitted a CANFD driver 
for STM32H7. What happened with this driver? Is it stuck in the review 
process? Is additional work to do?


Best regards

Frank-Christian

how to handle backwards compatibility?

[Frank-Christian Kruegel]

Hi.

I'm writing several drivers for my custom hardware. One is for a PCA9633 
LED driver. I can use the pca9635pw driver for this and modify it so it 
can be used with PCA9633 (4 outputs), PCA9634 (8 outputs), and PCA9635 
(16 outputs) by adding an additional parameter to the driver initalize 
function. However, this would break existing code.


Since I'd like to give my work back to the community I'd like to ask how 
I should handle this situation:


- clone the existing driver and modify it and keep the original driver 
for existing projects

- modify the existing driver and ignore the compatibility issues
- provide a new pca963x_register(..., type) and add something like
int pca9635pw_register(...)
{
  return pca963x_register(..., TYPE_PCA9635);
}

What is the preferred way?

Frank-Christian

Re: Dev environment

[Frank-Christian Kruegel]

Am 11.05.2021 um 18:41 schrieb Tim:

Mac is the machine I know least. I have no "full" Linux machine. No
experience of Cygwin and its ilk - just a minefield to me.


The best way would be a virtual machine using Virtualbox 
(https://www.virtualbox.org) (free) or VMWare Player
(https://www.vmware.com/de/products/workstation-player.html) (free for 
non-commercial use).


Install it, then download Ubuntu 20.04 Desktop 
(https://releases.ubuntu.com/20.04/), and you have everything you need. 
You can also reroute USB devices into your virtual machines, so using a 
JTAG/SWD debugger will work.


Caveat: Check your BIOS setting for something like "VT Virtualization 
support" and enable it. The virtualizers need the CPU hardware 
virtualization support to be enabled.


Frank-Christian

Has anyone written a driver for DS2482S?

[Frank-Christian Kruegel]

Hi.

Has anybody written a driver for I2C(Slave) to 1Wire (Master) 
DS2482S-100 or -800?


Best Regards

Frank-Christian

How to share code and Kconfig between different boards

[Frank-Christian Kruegel]

Hi.

I've created several board support packages, each in its own out-of-tree 
directory. Ive configured them as custom boards with a relative path 
like ...


+- nuttx
+- apps
+- company-boards
|  +- board1
|  +- board2
|  +- board3
+- company-apps
|  +- app1
|  +- app2
...

Works fine.

These boards have different microcontrollers from different 
architectures, but they all have common hardware and configuration 
items. It would be very helpful, it i could share code between the 
boards like...


+- company-boards
|  +- board1
| +-Kconfig
| +-src
|  +- board2
| +-Kconfig
| +-src
|  +- board3
| +-Kconfig
| +-src
|  +- board-common  <-- NEW SHARED DIRECTORY
| +-Kconfig
| +-src

so I can reference the common codefrom each board. The shared code is 
kernel code, custom drivers, driver initialisation etc, no application 
logic, and since it is very specific to my hardware the nuttx tree is 
not a good place for it.


How do I do it the correct way?

I've notices that the board Kconfig gets copied over to 
nuttx/boards/dummy, so a mere "source ../../board-common/Kconfig" 
doesn't work. I managed to make Kconfig work by using "source 
$TOPDIR/../company-boards/board-common/Kconfig". Now I'm stuck with 
makefiles.


Best regards

Frank-Christian

Re: How to use small I2C EEPROMs the NuttX way?

[Frank-Christian Kruegel]

Am 30.04.2021 um 15:06 schrieb Gregory Nutt:




... The main reason is that the AT24XX MTD driver only can handle 
one type of devices on a single bus. ..
The is a deficiency in the driver and should be pretty easy to fix by 
passing the I2C address during driver initialization. Other drivers 
do that.


This has alrady been fixed - there is an option for that. The main 
problem is that the capacity aka chip type is still a compile-time 
option, and I'd like not to change this since it may break other 
people's code.


I was referring to the run time configuration of the I2C address so that 
you can run multiple copies of the driver.  That would involve adding an 
address parameter to at24c_initialize().  This is done for many other 
drivers, for example, include/nuttx/sensors/lm75.h:


int lm75_register(FAR const char *devpath, FAR struct i2c_master_s *i2c,
   uint8_t addr);



Yes, this is already there, if CONFIG_AT24XX_MULTI is defined.

#ifdef CONFIG_AT24XX_MULTI
FAR struct mtd_dev_s *at24c_initialize(FAR struct i2c_master_s *dev,
   uint8_t address)
#else
FAR struct mtd_dev_s *at24c_initialize(FAR struct i2c_master_s *dev)
#endif

The char driver also allows for chip type runtine configuration. This 
should be added to at24xx.


int ee24xx_initialize(FAR struct i2c_master_s *bus, uint8_t devaddr,
  FAR char *devname, int devtype, int readonly)

Re: How to use small I2C EEPROMs the NuttX way?

[Frank-Christian Kruegel]

Am 29.04.2021 um 20:43 schrieb Gregory Nutt:


... The main reason is that the AT24XX MTD driver only can handle one 
type of devices on a single bus. ..
The is a deficiency in the driver and should be pretty easy to fix by 
passing the I2C address during driver initialization.  Other drivers do 
that.


This has alrady been fixed - there is an option for that. The main 
problem is that the capacity aka chip type is still a compile-time 
option, and I'd like not to change this since it may break other 
people's code.

Re: How to use small I2C EEPROMs the NuttX way?

[Frank-Christian Kruegel]

Am 29.04.2021 um 15:23 schrieb Gregory Nutt:
There are several Microchip/Atmel boards that come with an Atmel MAC in 
AT24MAC402 EEPROM.  You should be able to clone that logic (including 
setting the MAC address).  See:


samv7/samv71-xult/src/sam_ethernet.c
samv7/same70-xplained/src/sam_ethernet.c

These keep the MAC address in the AT24MAC402 which requires some special 
operations.


Thank you for your suggestions.

I can't use the method shown in in the samv7 boards. The main reason is 
that the AT24XX MTD driver only can handle one type of devices on a 
single bus. My hardware however has got an AT24MAC402 on #50 and an 
AT24C256 on #51 on a single bus. My plan is to use the AT24XX MTD driver 
for the 24C256 and put a NuttFS on it, and use the i2c_xx24xx char 
driver for the 24MAC402, which is too small for a fs anyway. The char 
driver already has support for the UUID area on the 24MAC402, and I 
patched the driver with minimal effort also to export another device for 
the MAC of an AT24MAC402 (48 bit) or AT24MAC602 (64 bit).


The (yet untested) patch is appended to this posting. I can make a pull 
request if you like it.


The stm32_ethernet drivers for STM32F7 and STM32H7 don't accept an 
external MAC but hash one out internally from the STM32 uid. I guess I 
need to add a stm32_emac_setmacaddr(uint8_t mac[6]) function to these 
drivers. Do you like me to upload these patches as well?


Best Regards

Frank-Christian
diff -r -u ../../nuttx1/nuttx/drivers/eeprom/i2c_xx24xx.c 
./drivers/eeprom/i2c_xx24xx.c
--- ../../nuttx1/nuttx/drivers/eeprom/i2c_xx24xx.c  2021-04-15 
13:38:39.0 +0200
+++ ./drivers/eeprom/i2c_xx24xx.c   2021-04-29 15:09:01.926357073 +0200
@@ -94,7 +94,22 @@
 #  define CONFIG_EE24XX_FREQUENCY 10
 #endif
 
+#ifdef CONFIG_AT24CS_UUID
+#define UUID_START  128
 #define UUID_SIZE   16
+#endif
+
+#ifdef CONFIG_AT24CS_MAC
+#if defined(CONFIG_AT24CS_E48)
+#define MAC_START  154
+#define MAC_SIZE   6
+#elif defined(CONFIG_AT24CS_E64)
+#define MAC_START  152
+#define MAC_SIZE   8
+#else
+#error "if CONFIG_AT24CS_MAC then define CONFIG_AT24CS_E48 or 
CONFIG_AT24CS_E64"
+#endif
+#endif
 
 /
  * Types
@@ -253,6 +268,19 @@
 };
 #endif
 
+#ifdef CONFIG_AT24CS_MAC
+static const struct file_operations at24cs_mac_fops =
+{
+  ee24xx_open,  /* piggyback on the ee24xx_open */
+  ee24xx_close, /* piggyback on the ee24xx_close */
+  at24cs_read_mac,  /* read */
+  NULL, /* write */
+  NULL, /* seek */
+  NULL, /* ioctl */
+  NULL  /* poll */
+};
+#endif
+
 /
  * Private Functions
  /
@@ -633,7 +661,7 @@
 
   finfo("READ %d bytes at pos %d\n", len, filep->f_pos);
 
-  regindx   = 0x80; /* reg index of UUID[0] */
+  regindx   = UUID_START;   /* reg index of UUID[0] */
 
   msgs[0].frequency = eedev->freq;
   msgs[0].addr  = eedev->addr + 8;  /* slave addr of UUID */
@@ -668,6 +696,82 @@
 #endif
 
 /
+ * Name: at24cs_read_mac
+ /
+
+#ifdef CONFIG_AT24CS_MAC
+static ssize_t at24cs_read_mac(FAR struct file *filep, FAR char *buffer,
+   size_t len)
+{
+  FAR struct ee24xx_dev_s *eedev;
+  FAR struct inode*inode = filep->f_inode;
+  struct i2c_msg_s msgs[2];
+  uint8_t  regindx;
+  int  ret;
+
+  DEBUGASSERT(inode && inode->i_private);
+  eedev = (FAR struct ee24xx_dev_s *)inode->i_private;
+
+  ret = ee24xx_semtake(eedev);
+  if (ret < 0)
+{
+  return ret;
+}
+
+  /* trim len if read would go beyond end of device */
+
+  if ((filep->f_pos + len) > MAC_SIZE)
+{
+  len = MAC_SIZE - filep->f_pos;
+}
+
+  if (len == 0)
+{
+  /* We are at end of file */
+
+  ret = 0;
+  goto done;
+}
+
+  /* Write data address */
+
+  finfo("READ %d bytes at pos %d\n", len, filep->f_pos);
+
+  regindx   = MAC_START;/* reg index of MAC[0] */
+
+  msgs[0].frequency = eedev->freq;
+  msgs[0].addr  = eedev->addr + 8;  /* slave addr of MAC */
+  msgs[0].flags = 0;
+  msgs[0].buffer= 
+  msgs[0].length= 1;
+
+  /* Read data */
+
+  msgs[1].frequency = msgs[0].frequency;
+  msgs[1].addr  = msgs[0].addr;
+  msgs[1].flags = I2C_M_READ;
+  msgs[1].buffer= (uint8_t *)buffer;
+  msgs[1].length= len;
+
+  ret = I2C_TRANSFER(eedev->i2c, msgs, 2);
+  if (ret < 0)
+{
+  goto done;
+}
+
+  ret = len;
+
+  /* Update the file position */
+
+  filep->f_pos += len;
+
+done:
+  ee24xx_semgive(eedev);
+  return ret;
+}
+#endif
+

How to use small I2C EEPROMs the NuttX way?

[Frank-Christian Kruegel]

Hi.

I'm currently porting NuttX to some proprietary compute modules with 
STM32F7 and STM32H7. Each and every board has got a small AT24MAC402 256 
Byte EEPROM with additional UID and MAC address accessible under a 
second I2C address, and many boards have an additional AT24C256 32kB EEPROM.


I've had a look at the At24 driver and example board drivers. For the 
32k EEPROM using a file system seems a good idea. The small ID EEPROM 
however is another story. 256 bytes seem to me way to small to use a 
file system on it. And how do I extract the 6 bytes of MAC address 
residing in the midde of the second bank?


How is this designed to work? I have no problem using the at24 driver as 
a base for something own, but I'd rather like to use what is there or 
feed my own solution back into the main repository so others can reuse it.


Best Regards

Frank-Christian

Datasheet for AT24MAC402/602:
https://ww1.microchip.com/downloads/en/DeviceDoc/I%C2%B2C-Compatible-(Two-Wire)-Serial-EEPROM-with-a-Factory%E2%80%91Programmed-EUI-48%E2%84%A2-or-EUI-64%E2%84%A2-Address-Plus-a-Unique-Factory-Programmed-128%E2%80%91Bit-Serial-Number-2%E2%80%91Kbit-(256x8)-20006430A.pdf

Re: USB Host and Bluetooth "dongle".

[Frank-Christian Kruegel]

Am 24.03.2021 um 18:34 schrieb Tim:


I can also build in Bluetooth support and the demo app, but as far as I can
tell there are no actual Bluetooth host drivers in NuttX to properly support
a detected Bluetooth device. My custom board actually has a SiLabs Bluetooth
module on it (connected to the SAM via UART and proven to work) but I quite
like the idea of just using plug-in Bluetooth devices instead :)


Bluetooth is quite complex. You will have to deal with several layers:

1. Hardware driver (like Ethernet Hardware driver)
2. Low Level Protocol Stack (HCI, like network TCP/IP layer)
3. High Level Protocol Stack ("Profiles", like network mail, web, ntp, 
nfs application protocols)


A complete stack fron top to bottom has a code size of several 1 
lines of code.


USB dongles usually implement the hardware driver and the low-level 
protocol stack (HCI). The computer has to run the high level protocol stack.


Other modules, especially the serial ones, implement the whole stack: 
hardware driver, low-level stack, and one or more profiles (SPP, 
audio,...). If you only need SPP, you really should use these modules. 
This allows you to write only 100 lines of code instad of 1.


fchk

CANFD on ST32H7

[Frank-Christian Kruegel]

Hi,

I'm currently in the process of testing all peripherials on my Nucleo 
STM32H743ZI board. So far, I2C, SPI, UART, and Ethernet seem to work.


My next step would be CANFD, but I've noticed that there is no 
stm32_can.c/.h in arch/arm/src/stm32h7 as there is for stm32f7.


Since the F7 doen't have CANFD I assume I cannot use the f7 can driver 
on the h7 even if I would loose CAN-FD capability.


Are there plans to support CAN on STM32H7? Is there any schedule for this?

Thanks

Frank-Christian

/dev/i2c* and /dev/spi* missing - why?

[Frank-Christian Kruegel]

Hi.

Platform: STM32H743 Nucleo144 board.

I've enabled in menuconfig:

System Type:

    STM32H7 Peripherial Selection: I2C1 and I2C2, SPI->SYSCFG

    I2C Configuration: defaults

Device Drivers:

    I2C Configuration: (enabled)

        Support I2C reset enabled

        I2C character driver enabled

    SPI Configuration: (enabled)

        SPI Exchange enabled

        SPI character driver enabled


Problem:

Selecting "I2C character driver" and "SPI character driver" should get 
me /dev/i2c0, /dev/i2c1, and some /dev/spi... device entries. I don't 
get them. I've set a breakpoint in register_driver(), and I do get 
/dev/null, /dev/console, /denttyS0, /dev/ttyS1, /dev/ttyS2.


Where is my error?

Thanks

Frank-Christian

Bug in arch/arm/stm32h7/src/stm32_ethernet.c

[Frank-Christian Kruegel]

Hello World();

When using the CONFIG_STM32H7_PHYINIT option I get an compile error 
saying that ret ist undefined.


Fix:

--- nuttx-org/arch/arm/src/stm32h7/stm32_ethernet.c    2020-10-26 
12:09:41.855853749 +0100
+++ nuttx/arch/arm/src/stm32h7/stm32_ethernet.c    2020-10-26 
12:12:50.923943167 +0100

@@ -4421,12 +4421,14 @@
 #ifdef CONFIG_STM32H7_PHYINIT
   /* Perform any necessary, board-specific PHY initialization */

-  ret = stm32_phy_boardinitialize(0);
+  {
+  int ret = stm32_phy_boardinitialize(intf);
   if (ret < 0)
 {
   nerr("ERROR: Failed to initialize the PHY: %d\n", ret);
   return ret;
 }
+  }
 #endif

   /* Put the interface in the down state. */

Furthermore, I guess the argument of stm32_phy_boardinitialize() shound 
be the interface id, not a fixed 0.


Please consider this path for the next release.

Frank-Christian

STM32H7: Support for Multiprocessing between Cortex M7 and Cortex M4

[Frank-Christian Kruegel]

Hello World;

I'm about to choose a Cortex M7 microcontroller for a new project. All 
major vendors (Atmel/Microchip SAME70/V71, STM32F7/H7, NXP IMXRT) seem 
to be supported.


In the list of supportex boards I see a STM32H747i Discovery. The 
STM32H747 has both a Cortex M7 core and a Cortex M4 core. Does NuttX 
support using both cores together? Can The M4 wait for a signal from the 
M7 and vice versa? Or will the M4 stay unused?


Thanks

Frank.