software i2c?
Hi, by any chance does anyone have a software I2C implementation laying around (but tested) that could be submitted to NuttX? If the basis is there I can do any required adaptation. Thanks, Matias
Re: software i2c?
Hi, I do have one. It was designed to run on STM32F103s where the I2C peripheral has some errata limitations. I have used it extensively on many projects without any issues. Although I used it only for "simple" transfers of just a few bytes, I don't see any reason it wouldn't work in any other scenario. Apart from the low performance, of course. It is properly documented, and generally uses my own HAL. So hardware calls are abstracted and self-explanatory. Two issues: 1. It needs some work to get into NuttX. It has a very different structure, it's not just styling that needs to be changed. I believe however that it is a good basis. I am also willing to help with testing this on my targets. 2. License. I am only using it on some of my small personal projects, so I just didn't pay much attention to licencing. It loosely originates from an open source library. I think it was the arduino-compatible library of Maple (https://www.leaflabs.com/maple), but I am not sure. Surely I have re-written most of it, to the point that I don't know whether there is actually any original code in there, but again it may need to be checked. In any case, it may serve as a basis for freshly written NuttX code. If this is of any interest to you, please tell me and I can provide the code. Στις Δευ, 18 Ιαν 2021 στις 7:29 μ.μ., ο/η Matias N. έγραψε: > Hi, > > by any chance does anyone have a software I2C implementation laying around > (but tested) that could be submitted to NuttX? If the basis is there I can > do any required adaptation. > > Thanks, > Matias
Re: software i2c?
Hi, that's great. I don't mind adapting it for NuttX. I think it could be made to have a hardware dependant lower-half to abstract the calls to GPIO handling. The part I'm unsure about is the licensing. If it is based on some code you cannot identify I think it would not be possible to include it unless we know the original license is compatible. Do you think you can identify where it came from? (maybe by googling a piece of code or comment) Best, Matias On Mon, Jan 18, 2021, at 15:12, Fotis Panagiotopoulos wrote: > Hi, > > I do have one. > It was designed to run on STM32F103s where the I2C peripheral has some > errata limitations. > I have used it extensively on many projects without any issues. > Although I used it only for "simple" transfers of just a few bytes, I don't > see any reason it wouldn't work in any other scenario. Apart from the low > performance, of course. > > It is properly documented, and generally uses my own HAL. So hardware calls > are abstracted and self-explanatory. > > Two issues: > 1. It needs some work to get into NuttX. It has a very different structure, > it's not just styling that needs to be changed. > I believe however that it is a good basis. I am also willing to help with > testing this on my targets. > > 2. License. I am only using it on some of my small personal projects, so I > just didn't pay much attention to licencing. > It loosely originates from an open source library. I think it was the > arduino-compatible library of Maple (https://www.leaflabs.com/maple), but I > am not sure. > Surely I have re-written most of it, to the point that I don't know whether > there is actually any original code in there, but again it may need to be > checked. > In any case, it may serve as a basis for freshly written NuttX code. > > If this is of any interest to you, please tell me and I can provide the > code. > > > Στις Δευ, 18 Ιαν 2021 στις 7:29 μ.μ., ο/η Matias N. έγραψε: > > > Hi, > > > > by any chance does anyone have a software I2C implementation laying around > > (but tested) that could be submitted to NuttX? If the basis is there I can > > do any required adaptation. > > > > Thanks, > > Matias >
Re: software i2c?
>(maybe by googling a piece of code or comment) Nah... Impossible. It certainly looks nothing like the original code. They may not even share a common line of code any more. This was not a "port" of an external library, rather I used the lib as a basis to write my own think. At least to the part I remember, it was many years ago. I am looking for this maple library, but I think that it is not publicly available any more. The current libraries are a different thing I believe. Στις Δευ, 18 Ιαν 2021 στις 8:22 μ.μ., ο/η Matias N. έγραψε: > Hi, > that's great. > > I don't mind adapting it for NuttX. I think it could be made to have a > hardware dependant lower-half to abstract > the calls to GPIO handling. > > The part I'm unsure about is the licensing. If it is based on some code > you cannot identify I think it would not > be possible to include it unless we know the original license is > compatible. Do you think you can identify > where it came from? (maybe by googling a piece of code or comment) > > Best, > Matias > > On Mon, Jan 18, 2021, at 15:12, Fotis Panagiotopoulos wrote: > > Hi, > > > > I do have one. > > It was designed to run on STM32F103s where the I2C peripheral has some > > errata limitations. > > I have used it extensively on many projects without any issues. > > Although I used it only for "simple" transfers of just a few bytes, I > don't > > see any reason it wouldn't work in any other scenario. Apart from the low > > performance, of course. > > > > It is properly documented, and generally uses my own HAL. So hardware > calls > > are abstracted and self-explanatory. > > > > Two issues: > > 1. It needs some work to get into NuttX. It has a very different > structure, > > it's not just styling that needs to be changed. > > I believe however that it is a good basis. I am also willing to help with > > testing this on my targets. > > > > 2. License. I am only using it on some of my small personal projects, so > I > > just didn't pay much attention to licencing. > > It loosely originates from an open source library. I think it was the > > arduino-compatible library of Maple (https://www.leaflabs.com/maple), > but I > > am not sure. > > Surely I have re-written most of it, to the point that I don't know > whether > > there is actually any original code in there, but again it may need to be > > checked. > > In any case, it may serve as a basis for freshly written NuttX code. > > > > If this is of any interest to you, please tell me and I can provide the > > code. > > > > > > Στις Δευ, 18 Ιαν 2021 στις 7:29 μ.μ., ο/η Matias N. > έγραψε: > > > > > Hi, > > > > > > by any chance does anyone have a software I2C implementation laying > around > > > (but tested) that could be submitted to NuttX? If the basis is there I > can > > > do any required adaptation. > > > > > > Thanks, > > > Matias > > >
Re: software i2c?
It is very possible that this was the original library: https://github.com/leaflabs/libmaple/tree/master/libraries/Wire By a quick look of it, it "seems" unrelated to my current code. Στις Δευ, 18 Ιαν 2021 στις 8:40 μ.μ., ο/η Fotis Panagiotopoulos < f.j.pa...@gmail.com> έγραψε: > >(maybe by googling a piece of code or comment) > Nah... Impossible. It certainly looks nothing like the original code. They > may not even share a common line of code any more. > This was not a "port" of an external library, rather I used the lib as a > basis to write my own think. > > At least to the part I remember, it was many years ago. > > I am looking for this maple library, but I think that it is not publicly > available any more. > The current libraries are a different thing I believe. > > > Στις Δευ, 18 Ιαν 2021 στις 8:22 μ.μ., ο/η Matias N. > έγραψε: > >> Hi, >> that's great. >> >> I don't mind adapting it for NuttX. I think it could be made to have a >> hardware dependant lower-half to abstract >> the calls to GPIO handling. >> >> The part I'm unsure about is the licensing. If it is based on some code >> you cannot identify I think it would not >> be possible to include it unless we know the original license is >> compatible. Do you think you can identify >> where it came from? (maybe by googling a piece of code or comment) >> >> Best, >> Matias >> >> On Mon, Jan 18, 2021, at 15:12, Fotis Panagiotopoulos wrote: >> > Hi, >> > >> > I do have one. >> > It was designed to run on STM32F103s where the I2C peripheral has some >> > errata limitations. >> > I have used it extensively on many projects without any issues. >> > Although I used it only for "simple" transfers of just a few bytes, I >> don't >> > see any reason it wouldn't work in any other scenario. Apart from the >> low >> > performance, of course. >> > >> > It is properly documented, and generally uses my own HAL. So hardware >> calls >> > are abstracted and self-explanatory. >> > >> > Two issues: >> > 1. It needs some work to get into NuttX. It has a very different >> structure, >> > it's not just styling that needs to be changed. >> > I believe however that it is a good basis. I am also willing to help >> with >> > testing this on my targets. >> > >> > 2. License. I am only using it on some of my small personal projects, >> so I >> > just didn't pay much attention to licencing. >> > It loosely originates from an open source library. I think it was the >> > arduino-compatible library of Maple (https://www.leaflabs.com/maple), >> but I >> > am not sure. >> > Surely I have re-written most of it, to the point that I don't know >> whether >> > there is actually any original code in there, but again it may need to >> be >> > checked. >> > In any case, it may serve as a basis for freshly written NuttX code. >> > >> > If this is of any interest to you, please tell me and I can provide the >> > code. >> > >> > >> > Στις Δευ, 18 Ιαν 2021 στις 7:29 μ.μ., ο/η Matias N. >> έγραψε: >> > >> > > Hi, >> > > >> > > by any chance does anyone have a software I2C implementation laying >> around >> > > (but tested) that could be submitted to NuttX? If the basis is there >> I can >> > > do any required adaptation. >> > > >> > > Thanks, >> > > Matias >> > >> >
Re: Problem with USB CDC initialization on board based on STM32F4DISCO
I have good news (for me) :-) I've built my customization using the stm32discovery:usbnsh configuration and it worked. I will restart from there. Thank you for all your considerations. Best regards, Flavio Em dom., 17 de jan. de 2021 às 19:16, spudaneco escreveu: > > This probably explains why you get no USB log. How could you? It is > configured to go to the console (i.e., /dev/console) but there is no console > device.Sent from my Galaxy > Original message From: Flavio Castro Alves Filho > Date: 1/17/21 3:50 PM (GMT-06:00) To: > dev@nuttx.apache.org Subject: Re: Problem with USB CDC initialization on > board based on STM32F4DISCO Em dom, 17 de jan de 2021 13:52, Gregory Nutt > escreveu:> I don't think that this combination will > work:>> CONFIG_CDCACM_CONSOLE=y> CONFIG_CONSOLE_SYSLOG=y>> I think that the > syslog console device would have to be available at> bootup. Normally a RAM > log is is used to hold syslog data if a USB> console is used.>In my case, I > am following the implementation from discovery board, wheresyslog is pointing > to the uart and console on the USB.I will review if it was done > correctly.Thank you for your remark.Best regardsFlavio> I might be wrong > about that and this should not prevent the USB device> connecting.>> On > 1/17/2021 9:10 AM, Flavio Castro Alves Filho wrote:> > Thank you very much > for your fast response.> >> > I checked the boot calls and they are the same, > regarding USB> initialization.> >> > I compared the include/nuttx/config.h > files too ... at least regarding> > USB, I couldn't see anything critical.> > >> > The development approach that I am working was exactly starting with> > > stm32discovery board and increasing features. Maybe I have to restart,> > > checking first the USB.> >> > Best regards,> >> > Flavio> >> > Em dom., 17 de > jan. de 2021 às 11:39, Grr escreveu:> >> What you can do > is compare .config generated from that defconfig to> .config> >> generated > from "./tools/configure.sh -l stm32f4discovery:usbnsh" and see> >> the > differences. You can also compare include/nuttx/config.h from both> >> > configs> >>> >> Another approach is to start from discovery config and do > the> modifications> >> for your board. After you have it working, clone the > config to a> different> >> board name. With "make savedefconfig" you can save > your working> defconfig> >>> >> El dom, 17 ene 2021 a las 7:51, Flavio Castro > Alves Filho (<> >> flavio.al...@gmail.com>) escribió:> >>> >>> As an > additional information, if I load the STM32F4DISCO on my board,> USB> >>> > works.> >>> Em dom., 17 de jan. de 2021 às 10:43, Flavio Castro Alves > Filho> >>> escreveu:> Hello,> > I am > working to port NuttX on a board based on STM32F4DISCOVERY. The> > microcontroller is the STM32F407VET6.> > USB CDC support is not > initializing.> > When I plug the USB on the board, I have the > following dmesg response> in> >>> Linux:> [517062.075048] usb > usb1-port2: attempt power cycle> [517062.726922] usb 1-2: new full-speed > USB device number 47 using> >>> xhci_hcd> [517062.727170] usb 1-2: > Device not responding to setup address.> [517062.935148] usb 1-2: Device > not responding to setup address.> [517063.142906] usb 1-2: device not > accepting address 47, error -71> [517063.270916] usb 1-2: new full-speed > USB device number 48 using> >>> xhci_hcd> [517063.271141] usb 1-2: > Device not responding to setup address.> [517063.479134] usb 1-2: Device > not responding to setup address.> > When I run > stm32f4discovery:usbnsh on my discovery board, it works.> > I > compared the defconfig from the base project and from mine and I> > believe I have initialized everything that is related to the USB.> > > Here is the defconfig for my board:> > #> # This file is > autogenerated: PLEASE DO NOT EDIT IT.> #> # You can use "make > menuconfig" to make any modifications to the> installed .config file.> > # You can then do "make savedefconfig" to generate a new defconfig> > file that includes your> # modifications.> #> # > CONFIG_ARCH_FPU is not set> # CONFIG_MMCSD_MMCSUPPORT is not set> # > CONFIG_MMCSD_SPI is not set> # CONFIG_NSH_ARGCAT is not set> # > CONFIG_NSH_CMDOPT_HEXDUMP is not set> # CONFIG_NSH_CMDPARMS is not set> > CONFIG_ADC=y> CONFIG_ANALOG=y> CONFIG_ARCH="arm"> > CONFIG_ARCH_BOARD="phi-innovations"> > CONFIG_ARCH_BOARD_STM32F4_PHI_IOT_GATEWAY=y> CONFIG_ARCH_CHIP="stm32"> > CONFIG_ARCH_CHIP_STM32=y> CONFIG_ARCH_CHIP_STM32F407VG=y> > CONFIG_ARCH_STACKDUMP=y> CONFIG_ARMV7M_MEMCPY=y> > CONFIG_BOARDCTL_RESET=y> CONFIG_BOARDCTL_UNIQUEID=y> > CONFIG_BOARDCTL_USBDEVCTRL=y> CONFIG_BOARD_LOOPSPERMSEC=16717> > CONFIG_BUILTIN=y>
Re: software i2c?
Ok, so if you feel that your code is now no longer related to that since it is actually completely rewritten I think it is no problem. Otherwise, if you think there may still be code from there, the one you linked is MIT so at least I think it could be a compatible license with Apache 2.0. Do you have your code available somewhere? That way I can take a look and think how it can be integrated to NuttX. Also, if you can place the apropriate license header already it would be better. Best, Matias On Mon, Jan 18, 2021, at 15:42, Fotis Panagiotopoulos wrote: > It is very possible that this was the original library: > > https://github.com/leaflabs/libmaple/tree/master/libraries/Wire > > By a quick look of it, it "seems" unrelated to my current code. > > > > Στις Δευ, 18 Ιαν 2021 στις 8:40 μ.μ., ο/η Fotis Panagiotopoulos < > f.j.pa...@gmail.com> έγραψε: > > > >(maybe by googling a piece of code or comment) > > Nah... Impossible. It certainly looks nothing like the original code. They > > may not even share a common line of code any more. > > This was not a "port" of an external library, rather I used the lib as a > > basis to write my own think. > > > > At least to the part I remember, it was many years ago. > > > > I am looking for this maple library, but I think that it is not publicly > > available any more. > > The current libraries are a different thing I believe. > > > > > > Στις Δευ, 18 Ιαν 2021 στις 8:22 μ.μ., ο/η Matias N. > > έγραψε: > > > >> Hi, > >> that's great. > >> > >> I don't mind adapting it for NuttX. I think it could be made to have a > >> hardware dependant lower-half to abstract > >> the calls to GPIO handling. > >> > >> The part I'm unsure about is the licensing. If it is based on some code > >> you cannot identify I think it would not > >> be possible to include it unless we know the original license is > >> compatible. Do you think you can identify > >> where it came from? (maybe by googling a piece of code or comment) > >> > >> Best, > >> Matias > >> > >> On Mon, Jan 18, 2021, at 15:12, Fotis Panagiotopoulos wrote: > >> > Hi, > >> > > >> > I do have one. > >> > It was designed to run on STM32F103s where the I2C peripheral has some > >> > errata limitations. > >> > I have used it extensively on many projects without any issues. > >> > Although I used it only for "simple" transfers of just a few bytes, I > >> don't > >> > see any reason it wouldn't work in any other scenario. Apart from the > >> low > >> > performance, of course. > >> > > >> > It is properly documented, and generally uses my own HAL. So hardware > >> calls > >> > are abstracted and self-explanatory. > >> > > >> > Two issues: > >> > 1. It needs some work to get into NuttX. It has a very different > >> structure, > >> > it's not just styling that needs to be changed. > >> > I believe however that it is a good basis. I am also willing to help > >> with > >> > testing this on my targets. > >> > > >> > 2. License. I am only using it on some of my small personal projects, > >> so I > >> > just didn't pay much attention to licencing. > >> > It loosely originates from an open source library. I think it was the > >> > arduino-compatible library of Maple (https://www.leaflabs.com/maple), > >> but I > >> > am not sure. > >> > Surely I have re-written most of it, to the point that I don't know > >> whether > >> > there is actually any original code in there, but again it may need to > >> be > >> > checked. > >> > In any case, it may serve as a basis for freshly written NuttX code. > >> > > >> > If this is of any interest to you, please tell me and I can provide the > >> > code. > >> > > >> > > >> > Στις Δευ, 18 Ιαν 2021 στις 7:29 μ.μ., ο/η Matias N. > >> έγραψε: > >> > > >> > > Hi, > >> > > > >> > > by any chance does anyone have a software I2C implementation laying > >> around > >> > > (but tested) that could be submitted to NuttX? If the basis is there > >> I can > >> > > do any required adaptation. > >> > > > >> > > Thanks, > >> > > Matias > >> > > >> > > >
Re: software i2c?
Also the Maple lib is C++, while my code is pure C.
The code is not published anywhere, till now.
I am attaching it here.
If you have any problems, I can create a new github repo for you.
///**
* @file i2c.c
*
* @author Fotis Panagiotopoulos
* @license WTFPL
*
* I2C driver for the STM32F103. This is a software implementation.
*
***/
#include "i2c.h"
#include "hal.h"
#include "hal_os.h"
#include "hal_assert.h"
#include "hal_types.h"
#include "gpio.h"
#include "delay.h"
#include "hal_config.h"
#if CPU_FREQ != 7200
#warning "The current I2C implementation is a software one. The selected CPU frequency may cause non accurate I2C frequency!"
#endif
//This sets the pin setting functions' overhead. Assumes a clock of 72MHz.
//Needs re-calibration if the CPU frequency is changed. Has no effect when
//max speed is set.
#define I2C_SOFT_OVERHEAD_US 5
typedef struct {
GPIO_Pin_t sda;
GPIO_Pin_t scl;
uint32_t delay;
I2C_Status_t status;
} I2C_Soft_t;
OS_mutex_t I2C0_mtx;
OS_mutex_t I2C1_mtx;
OS_mutex_t * I2C_mtx[] = { &I2C0_mtx, &I2C1_mtx };
static I2C_Soft_t I2C_Soft_1 = { .sda = PB7, .scl = PB6 };
static I2C_Soft_t I2C_Soft_2 = { .sda = PB11, .scl = PB10 };
static I2C_Soft_t * I2Cx[] = { &I2C_Soft_1, &I2C_Soft_2 };
static void SDA(I2C_Soft_t * channel, int state);
static void SCL(I2C_Soft_t * channel, int state);
void I2C_init(uint32_t channel, uint32_t frequency, uint32_t config)
{
HAL_ASSERT(channel == 0 || channel == 1);
if (channel == I2C_1)
{
if (config & I2C_1_REMAP)
{
I2Cx[0]->sda = PB9;
I2Cx[0]->scl = PB8;
}
else
{
I2Cx[0]->sda = PB7;
I2Cx[0]->scl = PB6;
}
}
GPIO_setState(I2Cx[channel]->sda, HIGH);
GPIO_setState(I2Cx[channel]->scl, HIGH);
GPIO_setMode(I2Cx[channel]->sda, OUTPUT_OPEN_DRAIN);
GPIO_setMode(I2Cx[channel]->scl, OUTPUT_OPEN_DRAIN);
int delay = ((100 / frequency) / 2) - I2C_SOFT_OVERHEAD_US;
if (delay < 0)
delay = 0;
I2Cx[channel]->delay = delay;
I2Cx[channel]->status = I2C_OK;
OS_mutex_init(I2C_mtx[channel]);
}
void I2C_deinit(uint32_t channel)
{
GPIO_setMode(I2Cx[channel]->sda, INPUT);
GPIO_setMode(I2Cx[channel]->scl, INPUT);
}
I2C_Status_t I2C_status(uint32_t channel)
{
return I2Cx[channel]->status;
}
int I2C_send(uint32_t channel, uint8_t address, const uint8_t * buffer, uint32_t size)
{
HAL_ASSERT(channel == 0 || channel == 1);
I2Cx[channel]->status = I2C_OK;
//Send the start bit
SCL(I2Cx[channel], HIGH);
SDA(I2Cx[channel], LOW);
SCL(I2Cx[channel], LOW);
//Send the address
for (int i = 0; i < 8; i++)
{
SDA(I2Cx[channel], !!(((address << 1) | I2C_WRITE) & (1 << (7 - i;
SCL(I2Cx[channel], HIGH);
SCL(I2Cx[channel], LOW);
}
//Wait for ACK
SDA(I2Cx[channel], HIGH);
SCL(I2Cx[channel], HIGH);
int j = 0;
while(GPIO_getState(I2Cx[channel]->sda) && j < I2C_SLAVE_TIMEOUT)
{
delayASM(1);
j++;
}
if (j == I2C_SLAVE_TIMEOUT)
{
I2Cx[channel]->status = I2C_NO_RESPONSE;
return 0;
}
SCL(I2Cx[channel], LOW);
while(size--)
{
//Send the data
for (int i = 0; i < 8; i++)
{
SDA(I2Cx[channel], !!(*buffer & (1 << (7 - i;
SCL(I2Cx[channel], HIGH);
SCL(I2Cx[channel], LOW);
}
//Wait for ACK
SDA(I2Cx[channel], HIGH);
SCL(I2Cx[channel], HIGH);
j = 0;
while(GPIO_getState(I2Cx[channel]->sda) && j < I2C_SLAVE_TIMEOUT)
{
delayASM(1);
j++;
}
if (j == I2C_SLAVE_TIMEOUT)
{
I2Cx[channel]->status = I2C_NACK;
return 0;
}
SCL(I2Cx[channel], LOW);
buffer++;
}
//Send stop
SDA(I2Cx[channel], LOW);
SCL(I2Cx[channel], HIGH);
SDA(I2Cx[channel], HIGH);
return 1;
}
int I2C_sendCmd(uint32_t channel, uint8_t address, uint8_t * buffer, uint32_t writeSize, uint32_t readSize)
{
HAL_ASSERT(channel == 0 || channel == 1);
I2Cx[channel]->status = I2C_OK;
//Send the start bit
SCL(I2Cx[channel], HIGH);
SDA(I2Cx[channel], LOW);
SCL(I2Cx[channel], LOW);
//Send the address
int i;
for (i = 0; i < 8; i++)
{
SDA(I2Cx[channel], !!(((address << 1) | I2C_WRITE) & (1 << (7 - i;
SCL(I2Cx[channel], HIGH);
SCL(I2Cx[channel], LOW);
}
//Wait for ACK
SDA(I2Cx[channel], HIGH);
SCL(I2Cx[channel], HIGH);
int j = 0;
while(GPIO_getState(I2Cx[channel]->sda) && j < I2C_SLAVE_TIMEOUT)
{
delayASM(1);
j++;
}
if (j == I2C_SLAVE_TIMEOUT)
{
I2Cx[channel]->status = I2C_NO_RESPONSE;
return 0;
}
SCL(I2Cx[channel], LOW);
int k;
for (k = 0; k < writeSize; k++)
{
//Send the data
for (i = 0; i < 8; i++)
{
SDA(I2Cx[channel], !!(buffer[k] & (1 << (7 - i;
SCL(I2Cx[channel], HIGH);
SCL(I2Cx[channel], LOW);
}
//Wait for ACK
SDA(I2Cx[channel], HIGH);
SCL(I2Cx[channel], HIGH);
j = 0;
while(GPIO_getState(I2Cx[channel]->sda) && j < I2C_SLAVE_TIMEOUT)
{
delayASM(1);
j++;
}
if (j == I2C_SLAVE_TIMEOUT)
{
I2Cx[channel]->stat
Re: Problem with USB CDC initialization on board based on STM32F4DISCO
Hello, Confirming: it is not working. I tried to see the syslog messages on an UART port while using nutshell on usb but it didn't work. Best regards, Flavio Em dom., 17 de jan. de 2021 às 13:52, Gregory Nutt escreveu: > > I don't think that this combination will work: > > CONFIG_CDCACM_CONSOLE=y > CONFIG_CONSOLE_SYSLOG=y > > I think that the syslog console device would have to be available at > bootup. Normally a RAM log is is used to hold syslog data if a USB > console is used. > > I might be wrong about that and this should not prevent the USB device > connecting. > > On 1/17/2021 9:10 AM, Flavio Castro Alves Filho wrote: > > Thank you very much for your fast response. > > > > I checked the boot calls and they are the same, regarding USB > > initialization. > > > > I compared the include/nuttx/config.h files too ... at least regarding > > USB, I couldn't see anything critical. > > > > The development approach that I am working was exactly starting with > > stm32discovery board and increasing features. Maybe I have to restart, > > checking first the USB. > > > > Best regards, > > > > Flavio > > > > Em dom., 17 de jan. de 2021 às 11:39, Grr escreveu: > >> What you can do is compare .config generated from that defconfig to .config > >> generated from "./tools/configure.sh -l stm32f4discovery:usbnsh" and see > >> the differences. You can also compare include/nuttx/config.h from both > >> configs > >> > >> Another approach is to start from discovery config and do the modifications > >> for your board. After you have it working, clone the config to a different > >> board name. With "make savedefconfig" you can save your working defconfig > >> > >> El dom, 17 ene 2021 a las 7:51, Flavio Castro Alves Filho (< > >> flavio.al...@gmail.com>) escribió: > >> > >>> As an additional information, if I load the STM32F4DISCO on my board, USB > >>> works. > >>> > >>> Em dom., 17 de jan. de 2021 às 10:43, Flavio Castro Alves Filho > >>> escreveu: > Hello, > > I am working to port NuttX on a board based on STM32F4DISCOVERY. The > microcontroller is the STM32F407VET6. > > USB CDC support is not initializing. > > When I plug the USB on the board, I have the following dmesg response in > >>> Linux: > [517062.075048] usb usb1-port2: attempt power cycle > [517062.726922] usb 1-2: new full-speed USB device number 47 using > >>> xhci_hcd > [517062.727170] usb 1-2: Device not responding to setup address. > [517062.935148] usb 1-2: Device not responding to setup address. > [517063.142906] usb 1-2: device not accepting address 47, error -71 > [517063.270916] usb 1-2: new full-speed USB device number 48 using > >>> xhci_hcd > [517063.271141] usb 1-2: Device not responding to setup address. > [517063.479134] usb 1-2: Device not responding to setup address. > > When I run stm32f4discovery:usbnsh on my discovery board, it works. > > I compared the defconfig from the base project and from mine and I > believe I have initialized everything that is related to the USB. > > Here is the defconfig for my board: > > # > # This file is autogenerated: PLEASE DO NOT EDIT IT. > # > # You can use "make menuconfig" to make any modifications to the > installed .config file. > # You can then do "make savedefconfig" to generate a new defconfig > file that includes your > # modifications. > # > # CONFIG_ARCH_FPU is not set > # CONFIG_MMCSD_MMCSUPPORT is not set > # CONFIG_MMCSD_SPI is not set > # CONFIG_NSH_ARGCAT is not set > # CONFIG_NSH_CMDOPT_HEXDUMP is not set > # CONFIG_NSH_CMDPARMS is not set > CONFIG_ADC=y > CONFIG_ANALOG=y > CONFIG_ARCH="arm" > CONFIG_ARCH_BOARD="phi-innovations" > CONFIG_ARCH_BOARD_STM32F4_PHI_IOT_GATEWAY=y > CONFIG_ARCH_CHIP="stm32" > CONFIG_ARCH_CHIP_STM32=y > CONFIG_ARCH_CHIP_STM32F407VG=y > CONFIG_ARCH_STACKDUMP=y > CONFIG_ARMV7M_MEMCPY=y > CONFIG_BOARDCTL_RESET=y > CONFIG_BOARDCTL_UNIQUEID=y > CONFIG_BOARDCTL_USBDEVCTRL=y > CONFIG_BOARD_LOOPSPERMSEC=16717 > CONFIG_BUILTIN=y > CONFIG_CDCACM=y > CONFIG_CDCACM_CONSOLE=y > CONFIG_CDCACM_RXBUFSIZE=256 > CONFIG_CDCACM_TXBUFSIZE=256 > CONFIG_CLOCK_MONOTONIC=y > CONFIG_CONSOLE_SYSLOG=y > CONFIG_DEBUG_ASSERTIONS=y > CONFIG_DEBUG_DMA=y > CONFIG_DEBUG_DMA_ERROR=y > CONFIG_DEBUG_DMA_INFO=y > CONFIG_DEBUG_DMA_WARN=y > CONFIG_DEBUG_ERROR=y > CONFIG_DEBUG_FEATURES=y > CONFIG_DEBUG_FS=y > CONFIG_DEBUG_FS_ERROR=y > CONFIG_DEBUG_FS_WARN=y > CONFIG_DEBUG_FULLOPT=y > CONFIG_DEBUG_HARDFAULT_ALERT=y > CONFIG_DEBUG_INFO=y > CONFIG_DEBUG_NET=y > CONFIG_DEBUG_NET_ERROR=y > CONFIG_DEBUG_NET_INFO=y > CONFIG_DEBUG_NET_WARN=y > CONFIG_DEBUG_RTC=y > CONFIG_DEBUG_RTC_ERROR=y > CONFIG_DEBUG_RTC_INFO=y >
Re: Problem with USB CDC initialization on board based on STM32F4DISCO
Often, a RAM log is used with a USB console. But a serial port works too. There are many examples. See $ find boards/ -name defconfig | xargs grep -l CDCACM_CONSOLE | xargs grep SYSLOG_DEVPATH On 1/18/2021 3:49 PM, Flavio Castro Alves Filho wrote: Hello, Confirming: it is not working. I tried to see the syslog messages on an UART port while using nutshell on usb but it didn't work. Best regards, Flavio Em dom., 17 de jan. de 2021 às 13:52, Gregory Nutt escreveu: I don't think that this combination will work: CONFIG_CDCACM_CONSOLE=y CONFIG_CONSOLE_SYSLOG=y I think that the syslog console device would have to be available at bootup. Normally a RAM log is is used to hold syslog data if a USB console is used. I might be wrong about that and this should not prevent the USB device connecting. On 1/17/2021 9:10 AM, Flavio Castro Alves Filho wrote: Thank you very much for your fast response. I checked the boot calls and they are the same, regarding USB initialization. I compared the include/nuttx/config.h files too ... at least regarding USB, I couldn't see anything critical. The development approach that I am working was exactly starting with stm32discovery board and increasing features. Maybe I have to restart, checking first the USB. Best regards, Flavio Em dom., 17 de jan. de 2021 às 11:39, Grr escreveu: What you can do is compare .config generated from that defconfig to .config generated from "./tools/configure.sh -l stm32f4discovery:usbnsh" and see the differences. You can also compare include/nuttx/config.h from both configs Another approach is to start from discovery config and do the modifications for your board. After you have it working, clone the config to a different board name. With "make savedefconfig" you can save your working defconfig El dom, 17 ene 2021 a las 7:51, Flavio Castro Alves Filho (< flavio.al...@gmail.com>) escribió: As an additional information, if I load the STM32F4DISCO on my board, USB works. Em dom., 17 de jan. de 2021 às 10:43, Flavio Castro Alves Filho escreveu: Hello, I am working to port NuttX on a board based on STM32F4DISCOVERY. The microcontroller is the STM32F407VET6. USB CDC support is not initializing. When I plug the USB on the board, I have the following dmesg response in Linux: [517062.075048] usb usb1-port2: attempt power cycle [517062.726922] usb 1-2: new full-speed USB device number 47 using xhci_hcd [517062.727170] usb 1-2: Device not responding to setup address. [517062.935148] usb 1-2: Device not responding to setup address. [517063.142906] usb 1-2: device not accepting address 47, error -71 [517063.270916] usb 1-2: new full-speed USB device number 48 using xhci_hcd [517063.271141] usb 1-2: Device not responding to setup address. [517063.479134] usb 1-2: Device not responding to setup address. When I run stm32f4discovery:usbnsh on my discovery board, it works. I compared the defconfig from the base project and from mine and I believe I have initialized everything that is related to the USB. Here is the defconfig for my board: # # This file is autogenerated: PLEASE DO NOT EDIT IT. # # You can use "make menuconfig" to make any modifications to the installed .config file. # You can then do "make savedefconfig" to generate a new defconfig file that includes your # modifications. # # CONFIG_ARCH_FPU is not set # CONFIG_MMCSD_MMCSUPPORT is not set # CONFIG_MMCSD_SPI is not set # CONFIG_NSH_ARGCAT is not set # CONFIG_NSH_CMDOPT_HEXDUMP is not set # CONFIG_NSH_CMDPARMS is not set CONFIG_ADC=y CONFIG_ANALOG=y CONFIG_ARCH="arm" CONFIG_ARCH_BOARD="phi-innovations" CONFIG_ARCH_BOARD_STM32F4_PHI_IOT_GATEWAY=y CONFIG_ARCH_CHIP="stm32" CONFIG_ARCH_CHIP_STM32=y CONFIG_ARCH_CHIP_STM32F407VG=y CONFIG_ARCH_STACKDUMP=y CONFIG_ARMV7M_MEMCPY=y CONFIG_BOARDCTL_RESET=y CONFIG_BOARDCTL_UNIQUEID=y CONFIG_BOARDCTL_USBDEVCTRL=y CONFIG_BOARD_LOOPSPERMSEC=16717 CONFIG_BUILTIN=y CONFIG_CDCACM=y CONFIG_CDCACM_CONSOLE=y CONFIG_CDCACM_RXBUFSIZE=256 CONFIG_CDCACM_TXBUFSIZE=256 CONFIG_CLOCK_MONOTONIC=y CONFIG_CONSOLE_SYSLOG=y CONFIG_DEBUG_ASSERTIONS=y CONFIG_DEBUG_DMA=y CONFIG_DEBUG_DMA_ERROR=y CONFIG_DEBUG_DMA_INFO=y CONFIG_DEBUG_DMA_WARN=y CONFIG_DEBUG_ERROR=y CONFIG_DEBUG_FEATURES=y CONFIG_DEBUG_FS=y CONFIG_DEBUG_FS_ERROR=y CONFIG_DEBUG_FS_WARN=y CONFIG_DEBUG_FULLOPT=y CONFIG_DEBUG_HARDFAULT_ALERT=y CONFIG_DEBUG_INFO=y CONFIG_DEBUG_NET=y CONFIG_DEBUG_NET_ERROR=y CONFIG_DEBUG_NET_INFO=y CONFIG_DEBUG_NET_WARN=y CONFIG_DEBUG_RTC=y CONFIG_DEBUG_RTC_ERROR=y CONFIG_DEBUG_RTC_INFO=y CONFIG_DEBUG_RTC_WARN=y CONFIG_DEBUG_SYMBOLS=y CONFIG_DEBUG_WARN=y CONFIG_DEV_GPIO=y CONFIG_ETH0_PHY_LAN8742A=y CONFIG_EXAMPLES_PPPD=y CONFIG_FAT_LCNAMES=y CONFIG_FAT_LFN=y CONFIG_FS_FAT=y CONFIG_FS_PROCFS=y CONFIG_FS_SMARTFS=y CONFIG_HAVE_CXX=y CONFIG_HAVE_CXXINITIALIZE=y CONFIG_HEAP_COLORATION=y CONFIG_IDLETHREAD_STACKSIZE=2048 CONFIG_INTELHEX_BINARY=y CONFIG_IOEXPANDER=y CONFIG_LIB_HOSTNAME="STM32F4-Discovery" CONFIG_MAX_TASKS=16 CONFIG_MMCSD=y CONFIG_MMCSD_MULTIBLOCK_D
Re: software i2c?
Thanks a lot! I will convert it to a proper NuttX driver, test it and open a PR. Best, Matias On Mon, Jan 18, 2021, at 17:05, Fotis Panagiotopoulos wrote: > Also the Maple lib is C++, while my code is pure C. > > The code is not published anywhere, till now. > > I am attaching it here. > If you have any problems, I can create a new github repo for you. > > > > *Attachments:* > * i2c.c > * i2c.h
Re: Problem with USB CDC initialization on board based on STM32F4DISCO
Thank you, I will look into it. But now I found the cause of my problem: there is a conflict between USB and USART3. In my specific case, I intend to use USART3 as RS-485. When I enable USART3, USB stops. I checked the pins and everything is fine. In addition, some leds (which I have set but not tested yet) turn on and blink. I have no idea about what it could be. Could you give me some insight about this usb-uart3 issue? Best regards, Flavio Em seg., 18 de jan. de 2021 às 19:03, Gregory Nutt escreveu: > > Often, a RAM log is used with a USB console. But a serial port works > too. There are many examples. See > > $ find boards/ -name defconfig | xargs grep -l CDCACM_CONSOLE | xargs > grep SYSLOG_DEVPATH > > On 1/18/2021 3:49 PM, Flavio Castro Alves Filho wrote: > > Hello, > > > > Confirming: it is not working. > > > > I tried to see the syslog messages on an UART port while using > > nutshell on usb but it didn't work. > > > > Best regards, > > > > Flavio > > > > Em dom., 17 de jan. de 2021 às 13:52, Gregory Nutt > > escreveu: > >> I don't think that this combination will work: > >> > >> CONFIG_CDCACM_CONSOLE=y > >> CONFIG_CONSOLE_SYSLOG=y > >> > >> I think that the syslog console device would have to be available at > >> bootup. Normally a RAM log is is used to hold syslog data if a USB > >> console is used. > >> > >> I might be wrong about that and this should not prevent the USB device > >> connecting. > >> > >> On 1/17/2021 9:10 AM, Flavio Castro Alves Filho wrote: > >>> Thank you very much for your fast response. > >>> > >>> I checked the boot calls and they are the same, regarding USB > >>> initialization. > >>> > >>> I compared the include/nuttx/config.h files too ... at least regarding > >>> USB, I couldn't see anything critical. > >>> > >>> The development approach that I am working was exactly starting with > >>> stm32discovery board and increasing features. Maybe I have to restart, > >>> checking first the USB. > >>> > >>> Best regards, > >>> > >>> Flavio > >>> > >>> Em dom., 17 de jan. de 2021 às 11:39, Grr escreveu: > What you can do is compare .config generated from that defconfig to > .config > generated from "./tools/configure.sh -l stm32f4discovery:usbnsh" and see > the differences. You can also compare include/nuttx/config.h from both > configs > > Another approach is to start from discovery config and do the > modifications > for your board. After you have it working, clone the config to a > different > board name. With "make savedefconfig" you can save your working defconfig > > El dom, 17 ene 2021 a las 7:51, Flavio Castro Alves Filho (< > flavio.al...@gmail.com>) escribió: > > > As an additional information, if I load the STM32F4DISCO on my board, > > USB > > works. > > > > Em dom., 17 de jan. de 2021 às 10:43, Flavio Castro Alves Filho > > escreveu: > >> Hello, > >> > >> I am working to port NuttX on a board based on STM32F4DISCOVERY. The > >> microcontroller is the STM32F407VET6. > >> > >> USB CDC support is not initializing. > >> > >> When I plug the USB on the board, I have the following dmesg response > >> in > > Linux: > >> [517062.075048] usb usb1-port2: attempt power cycle > >> [517062.726922] usb 1-2: new full-speed USB device number 47 using > > xhci_hcd > >> [517062.727170] usb 1-2: Device not responding to setup address. > >> [517062.935148] usb 1-2: Device not responding to setup address. > >> [517063.142906] usb 1-2: device not accepting address 47, error -71 > >> [517063.270916] usb 1-2: new full-speed USB device number 48 using > > xhci_hcd > >> [517063.271141] usb 1-2: Device not responding to setup address. > >> [517063.479134] usb 1-2: Device not responding to setup address. > >> > >> When I run stm32f4discovery:usbnsh on my discovery board, it works. > >> > >> I compared the defconfig from the base project and from mine and I > >> believe I have initialized everything that is related to the USB. > >> > >> Here is the defconfig for my board: > >> > >> # > >> # This file is autogenerated: PLEASE DO NOT EDIT IT. > >> # > >> # You can use "make menuconfig" to make any modifications to the > >> installed .config file. > >> # You can then do "make savedefconfig" to generate a new defconfig > >> file that includes your > >> # modifications. > >> # > >> # CONFIG_ARCH_FPU is not set > >> # CONFIG_MMCSD_MMCSUPPORT is not set > >> # CONFIG_MMCSD_SPI is not set > >> # CONFIG_NSH_ARGCAT is not set > >> # CONFIG_NSH_CMDOPT_HEXDUMP is not set > >> # CONFIG_NSH_CMDPARMS is not set > >> CONFIG_ADC=y > >> CONFIG_ANALOG=y > >> CONFIG_ARCH="arm" > >> CONFIG_ARCH_BOARD="phi-innovations" > >> CONFIG_ARCH_BOARD_STM32F4_PHI_IOT_GATEWAY=y > >> CONFIG_ARCH_CHIP="stm32" > >>
Re: software i2c?
Feel free to ask if anything is not clear to you, or you need any information on the included headers. One detail. This driver does support clock-stretching, with the assumption that the selected GPIOs can be set to open-collector mode! Which is not true for all MCUs, or all pins. If your slave devices do not support clock-stretching, I think you can get away with normal plain push-pull GPIOs. Of course, in this case, you will have to manually switch the GPIOs between inputs and outputs. In any case, this has to be handled somehow from the driver. Στις Τρί, 19 Ιαν 2021 στις 12:31 π.μ., ο/η Matias N. έγραψε: > Thanks a lot! > I will convert it to a proper NuttX driver, test it and open a PR. > > Best, > Matias > > On Mon, Jan 18, 2021, at 17:05, Fotis Panagiotopoulos wrote: > > Also the Maple lib is C++, while my code is pure C. > > > > The code is not published anywhere, till now. > > > > I am attaching it here. > > If you have any problems, I can create a new github repo for you. > > > > > > > > *Attachments:* > > * i2c.c > > * i2c.h >
Re: software i2c?
I managed to write a more or less complete implementation based on your code (although I think it was mostly rewritten). Can you have a look at the PR here: https://github.com/apache/incubator-nuttx/pull/2717 ? (I couldn't find your github username). I haven't tested this yet, as I'm unsure about GPIO handling (don't want to fry any pins or the I2C device). Best, Matias On Mon, Jan 18, 2021, at 20:07, Fotis Panagiotopoulos wrote: > Feel free to ask if anything is not clear to you, or you need any > information on the included headers. > > One detail. This driver does support clock-stretching, with the assumption > that the selected GPIOs can be set to open-collector mode! Which is not > true for all MCUs, or all pins. > If your slave devices do not support clock-stretching, I think you can get > away with normal plain push-pull GPIOs. Of course, in this case, you will > have to manually switch the GPIOs between inputs and outputs. > > In any case, this has to be handled somehow from the driver. > > Στις Τρί, 19 Ιαν 2021 στις 12:31 π.μ., ο/η Matias N. > έγραψε: > > > Thanks a lot! > > I will convert it to a proper NuttX driver, test it and open a PR. > > > > Best, > > Matias > > > > On Mon, Jan 18, 2021, at 17:05, Fotis Panagiotopoulos wrote: > > > Also the Maple lib is C++, while my code is pure C. > > > > > > The code is not published anywhere, till now. > > > > > > I am attaching it here. > > > If you have any problems, I can create a new github repo for you. > > > > > > > > > > > > *Attachments:* > > > * i2c.c > > > * i2c.h > > >
