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