On Fri, Oct 30, 2020 at 12:26:33PM +0100, Bernd Walter wrote:
> On Thu, Oct 29, 2020 at 07:39:16PM -0300, Alan Carvalho de Assis wrote:
> > Ok, now I understood the issue you found
> >
> > Yes, arch/arm/include/samd2l2/sam_adc.h is wrong.
> >
> > I think this file shouldn't exit, it doesn't exist to other arches.
>
> OK - I will take a look into this and change it to match other arches.
> But I like to find the other ADC problem before I rearrange the code.
> Might take a few days.
Well, thiss is all weird.
My Chip is a SAMD21E17A, so it has only 16k RAM.
I had been using in in another project with my own IO code and NXFFS on
an SPI flash (W25), but had to reduce stack sizes to have enough RAM
for the NXFFS.
This was with old NuttX code, shortly before the Apache change.
This project runs on a similar board, but uses different IO.
One of the IOs I need is the ADC and NuttX had no ADC support for the
SAMD21 in the code I had been using, therefor I upgraded in that project.
I'm running FreeBSD and had to work arround a few additional Linuxisms,
like calling "make" from a shell script and expect it to be GNU make.
Anyways - the board is tight on IO Pins and I have no UART left for console.
I did all my debugging with gdb and a bunch of LEDs.
This is the first part of my main routine:
int
main()
{
tm16_init();
// // enable first digit as test
// for (;;) {
// tm16_setbmp(3, 0x01);
// usleep(100);
// }
//
LED_data[STATUS_LED] = 1;
LED_data[ERROR_LED] = 1;
LED_out();
LED_out();
sleep(1);
LED_data[ERROR_LED] = 0;
LED_out();
boardctl(BOARDIOC_INIT, 0);
config_init();
serial_init();
#ifdef CONFIG_SAMD2L2_ADCx
if (sam_adc_setup() < 0) {
syslog(LOG_ERR, "Failed to initialize the ADC driver\n");
}
#endif
...
tm16_init is just bit bang, also LED_out(), which delivers data to the tm1653
chip I'm using to drive the LEDs.
config_init() tries to read json config file from NXFFS, which should have been
mounted after boardctl.
serial_init() is empty for later use.
Up until sam_adc_setup gets called, /dev/null gets init, the via
board_app_initialize() I mount procfs and my SPI flash.
When sam_adc_setup() gets called somehow the inodes tables it searches in
seem to be corrup, at least the result makes no sense for me, but I don't
understand that code path and memory structures well enough yet.
If I call sam_adc_setup() before boardctl() it does init, but fails to
open later when I try to use it.
Then I thought, lets reduce memory usage and don't mount the NXFFS for now.
Without that (which also inits the SPI), it never returns from boardctl().
I'm open for ideas.
My current plan is to setup a Linux system and try plain NuttX on an
Arduino Zero.
> > Its content should be inside the arch/arm/src/samd2l2/sam_adc.h
> >
> > BR,
> >
> > Alan
> >
> > On 10/29/20, Bernd Walter <ti...@cicely7.cicely.de> wrote:
> > > On Thu, Oct 29, 2020 at 06:33:46PM -0300, Alan Carvalho de Assis wrote:
> > >> I don't think it is wrong.
> > >
> > > Well - inlcuding and requiring two files with the same protector clearly
> > > is wrong.
> > >
> > >> See: arch/arm/src/stm32/stm32_adc.h
> > >
> > > There is no arch/arm/include/stm32/stm32_adc.h
> > > There is a arch/arm/src/stm32/hardware/stm32_adc.h, which uses
> > > __ARCH_ARM_SRC_STM32H7_HARDWARE_STM32_ADC_H, so no collision
> > >
> > > arch/arm/include/samd2l2/sam_adc.h
> > > arch/arm/src/samd2l2/sam_adc.h
> > > Both use the same protector
> > > There is also arch/arm/src/samd2l2/hardware/samd_adc.h, which uses
> > > __ARCH_ARM_SRC_SAMD2L2_HARDWARE_SAMD_ADC_H, so no collision with
> > > this file.
> > >
> > > arch/arm/include/samd2l2/sam_adc.h used to be named adc.h with
> > > a matching protector name and originally had no collision.
> > >
> > >>
> > >> Now look inside boards/arm/stm32/ and you will find many board that
> > >> includes this file same way.
> > >
> > > As I said - there is no arch/arm/include/stm32/stm32_adc.h
> > > This is likely very unique to those two archs:
> > > [239]cicely7> ls -al arch/arm/include/*/*adc.h
> > > -rw-r--r-- 1 ticso 1000 3395 Oct 29 20:42
> > > arch/arm/include/cxd56xx/adc.h
> > > -rw-r--r-- 1 ticso 1000 2798 Oct 29 20:42
> > > arch/arm/include/samd2l2/sam_adc.h
> > >
> > > As you can see, the cxd56xx isn't prefixed, which is the same it had been
> > > for the samd2l2 until 6bff1f4df4ae3e4fc21d7d98afdbfdcc855a6ed2 changed the
> > > filename and protector name.
> > >
> > >> On 10/29/20, Bernd Walter <ti...@cicely7.cicely.de> wrote:
> > >> > On Thu, Oct 29, 2020 at 05:42:58PM -0300, Alan Carvalho de Assis wrote:
> > >> >> Hello,
> > >> >>
> > >> >> On 10/29/20, Bernd Walter <ti...@cicely7.cicely.de> wrote:
> > >> >> > On Thu, Oct 29, 2020 at 08:51:13AM -0300, Alan Carvalho de Assis
> > >> >> > wrote:
> > >> >> >> Hi Bernd,
> > >> >> >>
> > >> >> >> It was "working" few mont ago. I put working covered by quotes
> > >> >> >> because
> > >> >> >> the ADC convertion wasn't linear. I think the calibration process
> > >> >> >> was
> > >> >> >> failing.
> > >> >> >
> > >> >> > arch/arm/src/samd2l2/sam_adc.h was previously named
> > >> >> > arch/arm/src/samd2l2/adc.h
> > >> >> > With the rename the protector define was updated to be identic to
> > >> >> > the
> > >> >> > one
> > >> >> > in arch/arm/src/samd2l2/sam_adc.h
> > >> >> > https://github.com/apache/incubator-nuttx/commit/6bff1f4df4ae3e4fc21d7d98afdbfdcc855a6ed2
> > >> >> >
> > >> >> > No idea what the convention for the fix would be, beside not using
> > >> >> > the
> > >> >> > same
> > >> >> > protector name.
> > >> >> >
> > >> >>
> > >> >> Well, the sam_adc.h appears correct and the #ifdef protection appears
> > >> >> correct too.
> > >> >
> > >> > It is correct by itself, but not in the bigger context:
> > >> > arch/arm/include/samd2l2/sam_adc.c:
> > >> > ...
> > >> > #include <arch/chip/sam_adc.h>
> > >> > ...
> > >> > #include "sam_adc.h"
> > >> >
> > >> > Both included files have the same filename and use the same #define to
> > >> > protect.
> > >> > The first gets included and the content of the second is then missing.
> > >> >
> > >> >>
> > >> >> >> I tested it on Arduino Zero board (SAMD21).
> > >> >> >
> > >> >> > Ok - I do have an Arduino Zero board to test on.
> > >> >> > The second problem is puzzling me.
> > >> >> > For my board code I copied
> > >> >> > boards/arm/samd2l2/arduino-m0/src/sam_adc.c
> > >> >> > It calls adc_register with "/dev/adc0", which calls
> > >> >> > register_driver),
> > >> >> > in which inode_reserve() then fails with EEXIST.
> > >> >> > This is common code for all platforms, which fails.
> > >> >> >
> > >> >>
> > >> >> The EEXIST error means that the file already exist and then probably
> > >> >> the ADC was registers twice. Maybe sam_adc_setup() was called twice or
> > >> >> it is called once but adc_register("/dev/adc0") is called from other
> > >> >> place.
> > >> >
> > >> > Thanks you for the hints.
> > >> > Chaning the path didn't work, but did no further tests today.
> > >> >
> > >> >> Try to enable CONFIG_DEBUG_ANALOG_INFO and see if it will give you
> > >> >> some
> > >> >> hints.
> > >> >>
> > >> >> BR,
> > >> >>
> > >> >> Alan
> > >> >
> > >> > --
> > >> > B.Walter <be...@bwct.de> http://www.bwct.de
> > >> > Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
> > >> >
> > >
> > > --
> > > B.Walter <be...@bwct.de> http://www.bwct.de
> > > Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
> > >
>
> --
> B.Walter <be...@bwct.de> http://www.bwct.de
> Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
--
B.Walter <be...@bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
