Re: nrf52 input buffer
It looks like a bug. But for some reason with the input buffer turned off, reading the input pin still works (nrf52840). niedz., 10 sty 2021 o 19:17 Matias N. napisał(a): > Hi, > while debugging the issue I mentioned in the other thread, I found > something strange: when configuring a pin as input on nRF52, the input > buffer is not enabled (by clearing the relevant INPUT bit of the PIN_CFG > register): > https://github.com/apache/incubator-nuttx/blob/master/arch/arm/src/nrf52/nrf52_gpio.c#L94 > > Is this a bug? Or am I missing something? > > Best, > Matias
Re: nrf52 input buffer
I will make a PR with a fix soon. It seems that the input buffer is internally connected under certain conditions. But I found some case where the pin value was not being read correctly so I suppose this could be the issue. Best, Matias On Mon, Jan 11, 2021, at 06:33, raiden00pl wrote: > It looks like a bug. But for some reason with the input buffer turned off, > reading the input pin still works (nrf52840). > > niedz., 10 sty 2021 o 19:17 Matias N. napisał(a): > > > Hi, > > while debugging the issue I mentioned in the other thread, I found > > something strange: when configuring a pin as input on nRF52, the input > > buffer is not enabled (by clearing the relevant INPUT bit of the PIN_CFG > > register): > > https://github.com/apache/incubator-nuttx/blob/master/arch/arm/src/nrf52/nrf52_gpio.c#L94 > > > > Is this a bug? Or am I missing something? > > > > Best, > > Matias >
Re: I2C on nRF52840
I actually found it was my mistake (I was using the wrong pinout). Thanks! Matias On Mon, Jan 11, 2021, at 04:46, raiden00pl wrote: > Does your I2C device use I2C_M_NOSTART or I2C_M_NOSTOP flags for > communication ? They are not supported by the current NRF52 I2C > implementation. > > niedz., 10 sty 2021 o 05:42 Matias N. napisał(a): > > > I was about to enable error support but I noticed it is disabled in-code. > > From the look of it there's not that > > much else to do but to issue a STOP. > > > > Regarding the error I'm receiving, I'm seeing a NACK for every possible > > address, so I either have the wrong set of > > pins for the device or there something else going on. > > > > Best, > > Matias > > > > On Sun, Jan 10, 2021, at 00:36, Brennan Ashton wrote: > > > If I recall the error handling logic is largely missing for the I2C in > > > interrupt mode. I added some more to improve the situation for polled > > mode. > > > Have you tried that? > > > > > > --Brennan > > > > > > On Sat, Jan 9, 2021, 7:34 PM Matias N. wrote: > > > > > > > Hi, > > > > > > > > I'm having a hard time getting I2C working on nRF52840, the I2C read > > > > operation seems to hang (never reaches ISR). Depending on which set of > > pins > > > > (connected to different I2C device) it either hangs on TXSTARTED or I > > see > > > > the ERROR event set to 0x1. Since this is on a closed device I cannot > > > > verify signals so I'm not sure if I'm making a mistake or the I2C code > > is > > > > faulty. Anyone currently using I2C on this chip with code from master? > > > > > > > > Best, > > > > Matias > > > > > >
RE: Anyone using Clang?
sim on macOS is built by clang, so I think the result should be good in general. > -Original Message- > From: Anthony Merlino > Sent: Monday, January 11, 2021 5:42 AM > To: dev@nuttx.apache.org > Subject: Anyone using Clang? > > Hi all, > > Subject line says it all. I'm curious if anyone is successfully using clang > instead of gcc and if so, how successful have you been with it? > > Best, > Anthony
