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.
