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. 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. >
