Re: CAN RTR ioctl timeout
Hi Matt, I think the solution using timeout should be more appropriated. I don't remember using RTR and the test application doesn't use it. probably it was never exercised. Please submit a PR with your suggested modification. BR, Alan On 12/7/20, Matthew Trescott wrote: > Dear NuttX developers, > > I'm working on wiring up the CAN module for the Tiva/Stellaris chips > for NuttX (using the character device model for now since the > SocketCAN model still appears to be work-in-progress). I am looking at > implementing support for sending remote frames and receiving responses > with the CANIOC_RTR ioctl. Reading through can.c, everything looks > good except that it's not clear to me what happens if a response is > never received. It looks like the thread just waits for the semaphore > indefinitely in can_rtrread. Is this the correct interpretation? > > Being new to NuttX, I'm not exactly sure what to do about this if my > assumption is correct. Here's my general idea: > > - Add a "struct timespec timeout" field to struct canioc_rtr_s > - Change the can_takesem() to nxsem_timedwait(), using clock_gettime > and clock_timespec_add to get the absolute timeout > - If the semaphore wait time expires with no response, then the > lower-half driver would get a callback via can_ops_s with the index of > the RTR message number to disable. For my driver, that callback would > free the mailbox used for the RTR message in the TX FIFO. > - If the semaphore posts before the wait expires, then it means the > CAN hardware acknowledged the received message and freed the mailbox. > > The other possibility would be to just not implement this ioctl and > let the application perform the exchange asynchronously with the new > CONFIG_CAN_USE_RTR option. The latter definitely seems like the more > flexible option, but is there a consensus on the "right" way to do > this? Thanks! > > Matt >
Re: ssd1306 oled help
Thanks everyone - apologies for the delay, some other priorities blocked
me.
Looks like I was getting bit by cygwin and "make clean_context all" got me
sorted out and actually reflected my changes.
However, I'd like to understand how to get the i2ctool working. I was able
to add it and see it in nsh, though it reports that no buses are found.
I added this to my stm32_bringup.c (ripped it from the stm32f4discovery):
-
#if defined(CONFIG_I2C) && defined(CONFIG_SYSTEM_I2CTOOL)
static void stm32_i2c_register(int bus)
{
FAR struct i2c_master_s *i2c;
int ret;
i2c = stm32_i2cbus_initialize(bus);
if (i2c == NULL)
{
syslog(LOG_ERR, "ERROR: Failed to get I2C%d interface\n", bus);
}
else
{
ret = i2c_register(i2c, bus);
if (ret < 0)
{
syslog(LOG_ERR, "ERROR: Failed to register I2C%d driver: %d\n",
bus, ret);
stm32_i2cbus_uninitialize(i2c);
}
}
}
#endif
/
* Name: stm32_i2ctool
*
* Description:
* Register I2C drivers for the I2C tool.
*
/
#if defined(CONFIG_I2C) && defined(CONFIG_SYSTEM_I2CTOOL)
static void stm32_i2ctool(void)
{
stm32_i2c_register(1);
#if 0
stm32_i2c_register(1);
stm32_i2c_register(2);
#endif
}
#else
# define stm32_i2ctool()
#endif
--
Yet when I run the i2ctool from nsh I get this:
nsh> i2c bus
BUS EXISTS?
Bus 0: NO
Bus 1: NO
Bus 2: NO
Bus 3: NO
Bus 4: NO
Bus 5: NO
I'd like to understand how to get this tool running as I'll probably be
needing it in the future. :)
Thanks everyone!
Matt
On Sun, Dec 6, 2020 at 5:56 AM Alan Carvalho de Assis
wrote:
> Hi Matt,
>
> Sorry my delay to reply.
>
> As Mr. Greg pointed the issue is related to your OLED display I2C address.
>
> Normally these OLED display has an Address Select using a 0R resistor
> to 0x78 or 0x7A.
>
> You need to setup the CONFIG_SSD1306_I2CADDR with the right address.
>
> Also as Mr. Ben suggested, using the i2ctool you can scan your I2C bus
> and find the I2C address that your display is using.
>
> Any issue, please let us to know.
>
> BR,
>
> Alan
>
> On 12/4/20, Matt DeWall wrote:
> > Didn't know about that one, thanks! Found one of Alan's articles for
> that
> > and gonna give that a shot.
> >
> > Matt
> >
> > On Fri, Dec 4, 2020 at 5:01 PM Disruptive Solutions <
> > disruptivesolution...@gmail.com> wrote:
> >
> >> Did you try the i2c tool?
> >>
> >> Op za 5 dec. 2020 1:58 a.m. schreef Matt DeWall :
> >>
> >> > Got it. Ok - looks like my 116 errors were from my later
> >> > experimenting.
> >> > If I completely disconnect or try other i2c pins, I get 116, so that
> >> makes
> >> > sense.
> >> >
> >> > So it looks like when I connect the pins correctly I'm getting the 6
> >> error.
> >> >
> >> > I'm wondering if that just means somehow my device has an i2c address
> >> that
> >> > isn't the default that the driver is looking for?
> >> >
> >> > Mat
> >> >
> >> > On Fri, Dec 4, 2020 at 4:25 PM Gregory Nutt
> >> > wrote:
> >> >
> >> > > Should have mentioned that the error code 6 is defined in
> >> > include/errno.h:
> >> > >
> >> > > #define ENXIO 6
> >> > > #define ENXIO_STR "No such device or address"
> >> > >
> >> > > And errcode code 116 is:
> >> > >
> >> > > #define ETIMEDOUT 116
> >> > > #define ETIMEDOUT_STR "Connection timed out"
> >> > >
> >> > > Which is also reported by as an I2C failure by stm32_i2c_transfer():
> >> > >
> >> > >if (stm32_i2c_sem_waitdone(priv) < 0)
> >> > > {
> >> > >status = stm32_i2c_getstatus(priv);
> >> > >ret = -ETIMEDOUT;
> >> > >
> >> > > On 12/4/2020 6:19 PM, Gregory Nutt wrote:
> >> > > >
> >> > > > As far as I can tell, this looks like an I2C problem. Alan
> problem
> >> > > > knows better than I.
> >> > > >
> >> > > > I think the failure sequence is:
> >> > > >
> >> > > > fs/vfs:
> >> > > > ioctl(FBIO_UPDATE)
> >> > > >
> >> > > > drivers/video/fb.c ioctl method:
> >> > > > ret = fb->vtable->updatearea(fb->vtable, area);
> >> > > >
> >> > > > drivers/lcd/lcd_framebuffer.c, function lcdfb_updateearea():
> >> > > > ret = pinfo->putrun(row, startx, run, width);
> >> > > >
> >> > > > drivers/lcd/ssd1306.c, putrun method:
> >> > > > Calls ssd1306_sendbyte()
> >> > > >
> >> > > > arch/arm/src/stm32/stm32_i2c.c,
> >> > > > else if (status & I2C_SR1_AF)
> >> > > > {
> >> > > > /* Acknowledge Failure */
> >> > > >
> >> > > > ret = -ENXIO;
> >> > > > }
> >> > > >
> >> > > > So my best guess is that there is some issue with your I2C
> >> > > > interface.
> >> > > > It might be failing to acknowledge.
> >> > > >
> >> > > > On 12/4/2020 4:56 PM, Matt DeWall wrote:
> >> > > >> Hello NuttX devs!
> >
RE: ssd1306 oled help
Hello Matt,
You have 2 enable i2ctool in make menuconfig (also see blog Alan):
https://acassis.wordpress.com/2019/01/19/how-to-use-nuttx-i2c-scan-features/
And then on the prompt in NuttX you can do the command say:
i2c dev -b 1 0x00 0x7f
It will show you the used I2C addresses.
Hope this will help you!
With kind regards,
Ben
nuttx.nl
-Oorspronkelijk bericht-
Van: Matt DeWall
Verzonden: dinsdag 8 december 2020 21:17
Aan: dev@nuttx.apache.org
Onderwerp: Re: ssd1306 oled help
Thanks everyone - apologies for the delay, some other priorities blocked me.
Looks like I was getting bit by cygwin and "make clean_context all" got me
sorted out and actually reflected my changes.
However, I'd like to understand how to get the i2ctool working. I was able to
add it and see it in nsh, though it reports that no buses are found.
I added this to my stm32_bringup.c (ripped it from the stm32f4discovery):
-
#if defined(CONFIG_I2C) && defined(CONFIG_SYSTEM_I2CTOOL) static void
stm32_i2c_register(int bus) {
FAR struct i2c_master_s *i2c;
int ret;
i2c = stm32_i2cbus_initialize(bus);
if (i2c == NULL)
{
syslog(LOG_ERR, "ERROR: Failed to get I2C%d interface\n", bus);
}
else
{
ret = i2c_register(i2c, bus);
if (ret < 0)
{
syslog(LOG_ERR, "ERROR: Failed to register I2C%d driver: %d\n",
bus, ret);
stm32_i2cbus_uninitialize(i2c);
}
}
}
#endif
/
* Name: stm32_i2ctool
*
* Description:
* Register I2C drivers for the I2C tool.
*
/
#if defined(CONFIG_I2C) && defined(CONFIG_SYSTEM_I2CTOOL) static void
stm32_i2ctool(void) {
stm32_i2c_register(1);
#if 0
stm32_i2c_register(1);
stm32_i2c_register(2);
#endif
}
#else
# define stm32_i2ctool()
#endif
--
Yet when I run the i2ctool from nsh I get this:
nsh> i2c bus
BUS EXISTS?
Bus 0: NO
Bus 1: NO
Bus 2: NO
Bus 3: NO
Bus 4: NO
Bus 5: NO
I'd like to understand how to get this tool running as I'll probably be needing
it in the future. :)
Thanks everyone!
Matt
On Sun, Dec 6, 2020 at 5:56 AM Alan Carvalho de Assis
wrote:
> Hi Matt,
>
> Sorry my delay to reply.
>
> As Mr. Greg pointed the issue is related to your OLED display I2C address.
>
> Normally these OLED display has an Address Select using a 0R resistor
> to 0x78 or 0x7A.
>
> You need to setup the CONFIG_SSD1306_I2CADDR with the right address.
>
> Also as Mr. Ben suggested, using the i2ctool you can scan your I2C bus
> and find the I2C address that your display is using.
>
> Any issue, please let us to know.
>
> BR,
>
> Alan
>
> On 12/4/20, Matt DeWall wrote:
> > Didn't know about that one, thanks! Found one of Alan's articles
> > for
> that
> > and gonna give that a shot.
> >
> > Matt
> >
> > On Fri, Dec 4, 2020 at 5:01 PM Disruptive Solutions <
> > disruptivesolution...@gmail.com> wrote:
> >
> >> Did you try the i2c tool?
> >>
> >> Op za 5 dec. 2020 1:58 a.m. schreef Matt DeWall :
> >>
> >> > Got it. Ok - looks like my 116 errors were from my later
> >> > experimenting.
> >> > If I completely disconnect or try other i2c pins, I get 116, so
> >> > that
> >> makes
> >> > sense.
> >> >
> >> > So it looks like when I connect the pins correctly I'm getting
> >> > the 6
> >> error.
> >> >
> >> > I'm wondering if that just means somehow my device has an i2c
> >> > address
> >> that
> >> > isn't the default that the driver is looking for?
> >> >
> >> > Mat
> >> >
> >> > On Fri, Dec 4, 2020 at 4:25 PM Gregory Nutt
> >> > wrote:
> >> >
> >> > > Should have mentioned that the error code 6 is defined in
> >> > include/errno.h:
> >> > >
> >> > > #define ENXIO 6
> >> > > #define ENXIO_STR "No such device or address"
> >> > >
> >> > > And errcode code 116 is:
> >> > >
> >> > > #define ETIMEDOUT 116
> >> > > #define ETIMEDOUT_STR "Connection timed out"
> >> > >
> >> > > Which is also reported by as an I2C failure by stm32_i2c_transfer():
> >> > >
> >> > >if (stm32_i2c_sem_waitdone(priv) < 0)
> >> > > {
> >> > >status = stm32_i2c_getstatus(priv);
> >> > >ret = -ETIMEDOUT;
> >> > >
> >> > > On 12/4/2020 6:19 PM, Gregory Nutt wrote:
> >> > > >
> >> > > > As far as I can tell, this looks like an I2C problem. Alan
> problem
> >> > > > knows better than I.
> >> > > >
> >> > > > I think the failure sequence is:
> >> > > >
> >> > > > fs/vfs:
> >> > > > ioctl(FBIO_UPDATE)
> >> > > >
> >> > > > drivers/video/fb.c ioctl method:
> >> > > > ret = fb->vtable->updatearea(fb->vtable, area);
> >> > > >
> >> > > > drivers/lcd/lcd_framebuffer.c, function lcdfb_updateearea():
> >> > > > ret = pinfo->putrun(row, startx, run, width);
> >> > > >
> >> > > > drivers/lcd/ssd1306.c, putrun method:
> >>
Re: CAN RTR ioctl timeout
Hi Alan, OK. I'll have to tackle this after I have regular data frames working on the Tiva. Thinking about it more, the "right" answer is probably to support both methods for dealing with RTR frames... Matt On Tue, Dec 8, 2020 at 6:44 AM Alan Carvalho de Assis wrote: > > Hi Matt, > > I think the solution using timeout should be more appropriated. > > I don't remember using RTR and the test application doesn't use it. > probably it was never exercised. > > Please submit a PR with your suggested modification. > > BR, > > Alan > > On 12/7/20, Matthew Trescott wrote: > > Dear NuttX developers, > > > > I'm working on wiring up the CAN module for the Tiva/Stellaris chips > > for NuttX (using the character device model for now since the > > SocketCAN model still appears to be work-in-progress). I am looking at > > implementing support for sending remote frames and receiving responses > > with the CANIOC_RTR ioctl. Reading through can.c, everything looks > > good except that it's not clear to me what happens if a response is > > never received. It looks like the thread just waits for the semaphore > > indefinitely in can_rtrread. Is this the correct interpretation? > > > > Being new to NuttX, I'm not exactly sure what to do about this if my > > assumption is correct. Here's my general idea: > > > > - Add a "struct timespec timeout" field to struct canioc_rtr_s > > - Change the can_takesem() to nxsem_timedwait(), using clock_gettime > > and clock_timespec_add to get the absolute timeout > > - If the semaphore wait time expires with no response, then the > > lower-half driver would get a callback via can_ops_s with the index of > > the RTR message number to disable. For my driver, that callback would > > free the mailbox used for the RTR message in the TX FIFO. > > - If the semaphore posts before the wait expires, then it means the > > CAN hardware acknowledged the received message and freed the mailbox. > > > > The other possibility would be to just not implement this ioctl and > > let the application perform the exchange asynchronously with the new > > CONFIG_CAN_USE_RTR option. The latter definitely seems like the more > > flexible option, but is there a consensus on the "right" way to do > > this? Thanks! > > > > Matt > >
Re: ssd1306 oled help
Thank you everyone, such a helpful community!I was able to get the
i2ctool working and it found my screen.
I'm off to my next steps. :)
Matt
On Tue, Dec 8, 2020 at 1:44 PM wrote:
> Hello Matt,
>
> You have 2 enable i2ctool in make menuconfig (also see blog Alan):
>
> https://acassis.wordpress.com/2019/01/19/how-to-use-nuttx-i2c-scan-features/
>
> And then on the prompt in NuttX you can do the command say:
> i2c dev -b 1 0x00 0x7f
>
> It will show you the used I2C addresses.
>
> Hope this will help you!
>
> With kind regards,
> Ben
> nuttx.nl
>
>
> -Oorspronkelijk bericht-
> Van: Matt DeWall
> Verzonden: dinsdag 8 december 2020 21:17
> Aan: dev@nuttx.apache.org
> Onderwerp: Re: ssd1306 oled help
>
> Thanks everyone - apologies for the delay, some other priorities blocked
> me.
>
> Looks like I was getting bit by cygwin and "make clean_context all" got me
> sorted out and actually reflected my changes.
>
> However, I'd like to understand how to get the i2ctool working. I was
> able to add it and see it in nsh, though it reports that no buses are found.
>
> I added this to my stm32_bringup.c (ripped it from the stm32f4discovery):
>
>
> -
> #if defined(CONFIG_I2C) && defined(CONFIG_SYSTEM_I2CTOOL) static void
> stm32_i2c_register(int bus) {
> FAR struct i2c_master_s *i2c;
> int ret;
>
> i2c = stm32_i2cbus_initialize(bus);
> if (i2c == NULL)
> {
> syslog(LOG_ERR, "ERROR: Failed to get I2C%d interface\n", bus);
> }
> else
> {
> ret = i2c_register(i2c, bus);
> if (ret < 0)
> {
> syslog(LOG_ERR, "ERROR: Failed to register I2C%d driver: %d\n",
> bus, ret);
> stm32_i2cbus_uninitialize(i2c);
> }
> }
> }
> #endif
>
>
> /
> * Name: stm32_i2ctool
> *
> * Description:
> * Register I2C drivers for the I2C tool.
> *
>
> /
>
> #if defined(CONFIG_I2C) && defined(CONFIG_SYSTEM_I2CTOOL) static void
> stm32_i2ctool(void) {
> stm32_i2c_register(1);
> #if 0
> stm32_i2c_register(1);
> stm32_i2c_register(2);
> #endif
> }
> #else
> # define stm32_i2ctool()
> #endif
>
> --
>
> Yet when I run the i2ctool from nsh I get this:
>
> nsh> i2c bus
> BUS EXISTS?
> Bus 0: NO
> Bus 1: NO
> Bus 2: NO
> Bus 3: NO
> Bus 4: NO
> Bus 5: NO
>
> I'd like to understand how to get this tool running as I'll probably be
> needing it in the future. :)
>
> Thanks everyone!
>
> Matt
>
> On Sun, Dec 6, 2020 at 5:56 AM Alan Carvalho de Assis
> wrote:
>
> > Hi Matt,
> >
> > Sorry my delay to reply.
> >
> > As Mr. Greg pointed the issue is related to your OLED display I2C
> address.
> >
> > Normally these OLED display has an Address Select using a 0R resistor
> > to 0x78 or 0x7A.
> >
> > You need to setup the CONFIG_SSD1306_I2CADDR with the right address.
> >
> > Also as Mr. Ben suggested, using the i2ctool you can scan your I2C bus
> > and find the I2C address that your display is using.
> >
> > Any issue, please let us to know.
> >
> > BR,
> >
> > Alan
> >
> > On 12/4/20, Matt DeWall wrote:
> > > Didn't know about that one, thanks! Found one of Alan's articles
> > > for
> > that
> > > and gonna give that a shot.
> > >
> > > Matt
> > >
> > > On Fri, Dec 4, 2020 at 5:01 PM Disruptive Solutions <
> > > disruptivesolution...@gmail.com> wrote:
> > >
> > >> Did you try the i2c tool?
> > >>
> > >> Op za 5 dec. 2020 1:58 a.m. schreef Matt DeWall :
> > >>
> > >> > Got it. Ok - looks like my 116 errors were from my later
> > >> > experimenting.
> > >> > If I completely disconnect or try other i2c pins, I get 116, so
> > >> > that
> > >> makes
> > >> > sense.
> > >> >
> > >> > So it looks like when I connect the pins correctly I'm getting
> > >> > the 6
> > >> error.
> > >> >
> > >> > I'm wondering if that just means somehow my device has an i2c
> > >> > address
> > >> that
> > >> > isn't the default that the driver is looking for?
> > >> >
> > >> > Mat
> > >> >
> > >> > On Fri, Dec 4, 2020 at 4:25 PM Gregory Nutt
> > >> > wrote:
> > >> >
> > >> > > Should have mentioned that the error code 6 is defined in
> > >> > include/errno.h:
> > >> > >
> > >> > > #define ENXIO 6
> > >> > > #define ENXIO_STR "No such device or address"
> > >> > >
> > >> > > And errcode code 116 is:
> > >> > >
> > >> > > #define ETIMEDOUT 116
> > >> > > #define ETIMEDOUT_STR "Connection timed out"
> > >> > >
> > >> > > Which is also reported by as an I2C failure by
> stm32_i2c_transfer():
> > >> > >
> > >> > >if (stm32_i2c_sem_waitdone(priv) < 0)
> > >> > > {
> > >> > >status = stm32_i2c_getstatus(priv);
> > >> > >ret = -ETIMEDOUT;
> > >> > >
> > >> > > On 12/4/2020 6:19 PM, Gregory Nutt wrote:
> > >> > > >
> > >> > > > As far as I can tell, this looks like an I2C problem. Al
Re: about IDEs and dev boards
Thanks for the responses. Any others? On Fri, Dec 4, 2020, at 08:36, David Sidrane wrote: > Hi Matais, > > I use GNU ARM Eclipse http://gnuarmeclipse.github.io/ but it is now > https://eclipse-embed-cdt.github.io/ > > I value it for the Segger debugger integration and SVD support. > > I use make file builds imported from git. > > I use a lot of the PX4 boards the FMUv2 2.4.6 (Pixhawk2), FMUv4 (Pixracer > RC15) FMUV5 (Pixhawk4) > > IMXRT10x0-EVK > Nuceo-144 (F7,H7...) > OlimexSTM32 > > I always disable the built-in JTAG and use a Segger JLink or a JTrace and > real FTDI serial ports (isolated), not virtual ones. This decouples the > debugging hHW from the power cycling of the target. > > Imxrt has a cross bar switch but it is not any-to-any as it sounds like > the nRF52 is. > > David > > -Original Message- > From: Matias N. [mailto:mat...@imap.cc] > Sent: Thursday, December 03, 2020 5:54 PM > To: dev@nuttx.apache.org > Subject: about IDEs and dev boards > > Hi, > I was wondering what IDEs do you use with NuttX and what is your preferred > dev board (can be more than one). > I'm curious since I have used QtCreator for long time now and generally > works well, but it has some quirks. > And on hardware side I always favored STM32 boards (with embedded > debugger) but after getting into nRF52 I found > it to be much easier to work with and seems a very well designed SoC from > the users perspective. The "mux (almost) any peripheral to any pin" is > great (any other chip does that?). > > Best, > Matias >
Re: about IDEs and dev boards
On Thu, Dec 3, 2020 at 5:54 PM Matias N. wrote: > > Hi, > I was wondering what IDEs do you use with NuttX and what is your preferred > dev board (can be more than one). > I'm curious since I have used QtCreator for long time now and generally works > well, but it has some quirks. These days it is mostly a mixture of VIM and Visual Studio Code. I have been moving more and more to vscode for my development mostly because I use it a lot for work due to some really powerful remote features (COVID-19 has made that a lot more important). This plugin for vscode is really quite nice, it does a lot of what David has in his environment, with nice integration into JLink and OpenOCD, SVD support so you can easily inspect and debug all the registers for the MCU, and one of my favorite features visualizing data via ITM. https://marketplace.visualstudio.com/items?itemName=marus25.cortex-debug The only downside is that unless you set up filters on the files you can end up using a lot of memory while it reindexes intellisense. There are still quite a few times where I just find myself firing up the gdb shell because I used it directly for so many years. > And on hardware side I always favored STM32 boards (with embedded debugger) > but after getting into nRF52 I found > it to be much easier to work with and seems a very well designed SoC from the > users perspective. The "mux (almost) any peripheral to any pin" is great (any > other chip does that?). These days I am mostly using the NXP imx.rt, nRF52, or the STM32 families (the H7 and F7 are quite nice). But I also mess around with RISC-V on my FPGAs. The pinmux feature is getting to be quite common, NXP, Atmel, and Nordic all have fairly good options for this feature with limitations, STM32 is one of the most limited in that regard I think. If you really want the flexibility come over to the dark side of FPGAs :) I think the thing I don't like the most about the nRF chips is that a lot of the peripherals are quite limited, even the SPI IP has very limited clocking and modes. I guess that is a balance because it also means it is quite simple to implement things on it. --Brennan
Re: about IDEs and dev boards
Am 04.12.2020 um 02:54 schrieb Matias N.: Hi, I was wondering what IDEs do you use with NuttX and what is your preferred dev board (can be more than one). I'm curious since I have used QtCreator for long time now and generally works well, but it has some quirks. Jetbrains CLion is the IDE i use. It is not that great with Makefile projects and debugging but it is getting better. And it works well if you also use some of their other dev tools and ides. And on hardware side I always favored STM32 boards (with embedded debugger) but after getting into nRF52 I found it to be much easier to work with and seems a very well designed SoC from the users perspective. The "mux (almost) any peripheral to any pin" is great (any other chip does that?). Best, Matias Mostly AVRs here, the ones too small for Nuttx, and STM32. Usually custom boards. regards, Marc OpenPGP_signature Description: OpenPGP digital signature
