Dear Alan, Greetings!
About the CMake files: Despite installing Kconfiglib (for Python3) I get
errors
like these:
raman@foo:~/Skullets/nuttxspace/nuttx$ cmake -B build
-DBOARD_CONFIG=avr32dev1:nsh -GNinja
CMake Error at CMakeLists.txt:82 (message):
Kconfig environment depends on kconfiglib, Please install:
$ pip install kconfiglib
-- Configuring incomplete, errors occurred!
I wish not to raise a PR for something I have not tested. I am just pasting
the
files here for now.
raman@foo:~/Skullets/nuttxspace/nuttx$ cat
boards/avr/at32uc3/avr32dev1/src/CMakeLists.txt
set(SRCS avr32_boot.c avr32_bringup.c)
if(CONFIG_BOARDCTL)
list(APPEND SRCS avr32_appinit.c)
endif()
if(CONFIG_ARCH_BUTTONS)
list(APPEND SRCS avr32_buttons.c)
endif()
if(CONFIG_ARCH_LEDS)
list(APPEND SRCS avr32_leds.c)
endif()
target_sources(board PRIVATE ${SRCS})
set_property(GLOBAL PROPERTY LD_SCRIPT
"${NUTTX_BOARD_DIR}/scripts/avr32dev1.ld")
--
raman@foo:~/Skullets/nuttxspace/nuttx$ cat
boards/avr/at32uc3/avr32dev1/CMakeLists.txt
add_subdirectory(src)
--
Sorry Alan. I will try to reboot my machine with an updated Ubuntu GNU/Linux
and redo all tests with cmake, openocd and dfu-programmer.
Highest regards,
R
On Mon, 20 Nov 2023 at 20:57, Raman Gopalan <ramangopa...@gmail.com> wrote:
>
> Dear Alan,
>
> > But again, I think we can avoid this tortuous path and fix the CMake or
> > Makefile to build on Windows.
>
> Fully understand.
>
> > BTW, could you please submit a PR with yours CMakefiles to AVR32? I
> want to
> > test it here too.
>
> For sure. May I send them to you tomorrow? I wrote them on Windows. An
> invocation of cmake complained with errors on Windows like I mentioned. I
> will
> test the CMake files with GNU/Linux before I send them to you tomorrow.
>
> R
>
> On Mon, 20 Nov 2023 at 18:39, Alan C. Assis <acas...@gmail.com> wrote:
>
>> Hi Raman,
>>
>> On 11/20/23, Raman Gopalan <ramangopa...@gmail.com> wrote:
>> > Dear Alan, Greetings!
>> >
>> > Many thanks for your suggestions.
>> >
>> >> Note that I already adapted it to use your Atmel ICE Device S/N. I just
>> > use: $
>> >> sudo openocd -f openocd.cfg
>> >
>> > Thank you Alan. I just pasted your openocd configuration and invoked
>> > openocd
>> > just like you suggested. Unfortunately, I still see the same problem I
>> had
>> > yesterday. Here is the output:
>> >
>> > raman@foo:~/Skullets$ sudo openocd -f openocd.cfg
>> > Open On-Chip Debugger 0.12.0+dev-00342-g21f17260d (2023-09-28-16:32)
>> > Licensed under GNU GPL v2
>> > For bug reports, read
>> > http://openocd.org/doc/doxygen/bugs.html
>> > DEPRECATED! use 'adapter driver' not 'interface'
>> > DEPRECATED! use 'adapter serial' not 'cmsis_dap_serial'
>> > Info : auto-selecting first available session transport "swd". To
>> override
>> > use 'transport select <transport>'.
>> > DEPRECATED! use 'adapter srst delay' not 'adapter_nsrst_delay'
>> > DEPRECATED! use 'adapter srst pulse_width' not
>> 'adapter_nsrst_assert_width'
>> > adapter srst pulse_width: 100
>> > Info : Listening on port 6666 for tcl connections
>> > Info : Listening on port 4444 for telnet connections
>> > Error: unable to find a matching CMSIS-DAP device
>> >
>> > raman@foo:~/Skullets$
>> >
>> > But I also confirm that the Atmel ICE works fine with Microchip Studio
>> OR
>> > `atprogram', the command line tool that comes with it.
>> >
>> > Do you see a similar "unable to find" error at your end?
>> >
>>
>> No, here OpenOCD is able to find my device, see log (without any board
>> connected to it)
>>
>> $ sudo openocd -f openocd.cfg
>> Open On-Chip Debugger 0.11.0+dev-00062-g6405d35f3 (2023-08-28-15:47)
>> Licensed under GNU GPL v2
>> For bug reports, read
>> http://openocd.org/doc/doxygen/bugs.html
>> DEPRECATED! use 'adapter driver' not 'interface'
>> Info : auto-selecting first available session transport "swd". To
>> override use 'transport select <transport>'.
>> DEPRECATED! use 'adapter srst delay' not 'adapter_nsrst_delay'
>> DEPRECATED! use 'adapter srst pulse_width' not
>> 'adapter_nsrst_assert_width'
>> adapter srst pulse_width: 100
>>
>> Info : Listening on port 6666 for tcl connections
>> Info : Listening on port 4444 for telnet connections
>> Info : CMSIS-DAP: SWD Supported
>> Info : CMSIS-DAP: JTAG Supported
>> Info : CMSIS-DAP: FW Version = 01.27.0082
>> Info : CMSIS-DAP: Serial# = J41800093472
>> Info : CMSIS-DAP: Interface Initialised (SWD)
>> Info : SWCLK/TCK = 1 SWDIO/TMS = 1 TDI = 1 TDO = 1 nTRST = 0 nRESET = 1
>> Info : CMSIS-DAP: Interface ready
>> Info : clock speed 400 kHz
>> Error: Error connecting DP: cannot read IDR
>>
>> >> Ubuntu, like you are using.
>> >
>> > Perfect! Only I don't see what I'm getting wrong yet.
>> >
>> >> as said, Kevin Liu was able to integrate NuttX into Microchip Studio
>> > about 4
>> >> years ago, but he compiled and exported NuttX as library, just like PX4
>> > and
>> >> other projects are doing.
>> >
>> > That is so jolly good! Understand, Alan.
>> >
>> >> Raman, I think this hack approach it not easy to do with NuttX, because
>> >> different from other RTOS NuttX is very *very* customizable, that means
>> > you
>> >> can fine tune each internal bolts and nuts of it using some existent
>> >> CONFIG_something. So, besides selecting the right files, it also needs
>> >> the
>> >> right CONFIGs
>> >
>> > Understand. But is there a way to also get the config files onto
>> Microchip
>> > Studio? OR are these config files temporary (/tmp for example) and not
>> > physical
>> > config files. Just a quick workflow I imagine: configure the NuttX build
>> > for a
>> > specific target (say, avr32dev1) like we typically do on Cygwin.
>> >
>> > The ./tools/configure.sh -c avr32dev:nsh doesn't fail. Perhaps there's a
>> > way to
>> > employ a tool to recurse through the NuttX codebase and copy the C files
>> > and
>> > config files - assuming a default configuration? But if I have a rough
>> idea
>> > of
>> > the structure (and where to look for these file and their target
>> > destination for
>> > pickup), I can help whip up something quick and dirty as a proof of
>> > concept.
>> >
>>
>> At root of nuttx/ you will find a .config with all CONFIG_ selected.
>>
>> But again, I think we can avoid this tortuous path and fix the CMake
>> or Makefile to build on Windows.
>>
>> BTW, could you please submit a PR with yours CMakefiles to AVR32? I
>> want to test it here too.
>>
>> > I can also imagine this: I haven't tried this so far but I'm sure
>> Microchip
>> > Studio is powered by Visual Studio. Its project configuration is listed
>> > here
>> > [1], for example. I was just exploring to evaluate/gauge if we can
>> generate
>> > the
>> > cproj file at all. Just thoughts so far.
>> >
>> > In essence, I wanted to check with you if CMake/GNU Make do something
>> with
>> > the
>> > build that might otherwise be tricky to achieve using just Microchip
>> > Studio?
>> > Especially, on the Windows environment?
>> >
>> > Edit: I just ran `make -n' within nuttxspace/nuttx after configuring the
>> > build
>> > for avr32dev1. Oh, it such a long recipe! :) I understand it can be
>> tricky.
>> > I haven't read the echo to its entirely.
>> >
>>
>> You can run "make V=1" to see all files been compiled and flag parameters.
>>
>> >> Yes, you can git checkout an old version tag (i.e 7.x or 8.x) of nuttx
>> >> and
>> >> also the same version of apps.
>> >
>> > Understand.
>> >
>> >> Nice! Probably you will see something coming from serial. Also you can
>> > enable
>> >> the Debug to print the ABC... letter of each stage of the early boot
>> > process.
>> >> Similar to old days of LILO bootloader of Linux.
>> >
>> > Very nice. I will enable Debug to check this.
>> >
>>
>> Best Regards,
>>
>> Alan
>>
>
