On 2/8/2024 2:50 PM, Alan C. Assis wrote:
Thank you for clarifying Greg, but I think PIC32 is using little
endian, at least I can't see CONFIG_ENDIAN_BIG defined to them at boards/
You are right. MIPS is traditionally big-endian or powers up
big-endian, but Microchip opted to force little
Dear Alan, Dear NuttX community, greetings!
> Nice to see they added JTAG support to avrdude, but only few AVR8
> has JTAG support (i.e. Atmega128 has).
I trust you're all doing so well. I revisited the NuttX codebase today. I
created a sample at32uc3b0256 (avr32dev1) Microchip Studio project to
Nice to see they added JTAG support to avrdude, but only few AVR8 has
JTAG support (i.e. Atmega128 has).
BR,
Alan
On 11/24/23, Tomek CEDRO wrote:
> On Fri, Nov 24, 2023 at 5:32 PM Alan C. Assis wrote:
>> Thank you Tomek,
>> I searched in the source code and didn't find AVR32 support, it is
>>
On Fri, Nov 24, 2023 at 5:32 PM Alan C. Assis wrote:
> Thank you Tomek,
> I searched in the source code and didn't find AVR32 support, it is
> strange because I remember of seeing "at32uc3b512" is the avrdude
> command line (our board uses at32uc3b256).
Quick search shows example list of
Thank you Tomek,
I searched in the source code and didn't find AVR32 support, it is
strange because I remember of seeing "at32uc3b512" is the avrdude
command line (our board uses at32uc3b256).
BR,
Alan
On 11/24/23, Tomek CEDRO wrote:
> On Fri, Nov 24, 2023 at 4:35 PM Alan C. Assis wrote:
>>
On Fri, Nov 24, 2023 at 4:35 PM Alan C. Assis wrote:
> Unfortunately in this case OpenOCD also is not helping, because the
> AVR32 support it very limited (AFAIK there is no support to flash
> AVR32 chips) and because I don't have the original Atmel JTAGICE MkII
> I cannot use their avr32program
Hi Raman,
Thank you very much for this detailed update! I'm really impressed by
your hard work to get it working. I think AVR32 itself is very
challenging now on Linux because Atmel original code is rusting
(unfortunately not in the Rust way hehehe).
So or later this old tools will stop to work
Dear Alan, Greetings!
I re-installed my GNU/Linux. I am running Ubuntu 23.10. Atleast,
things are working as expected. All my problems with /dev are
solved. My Atmel ICE device is getting enumerated fine. Here is my
version.
raman@foo:~$ lsb_release -a
No LSB modules are available.
Distributor
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,
Dear Greg, Greetings,
> It is likely that you could create a pure Windows native build (using a
> Windows native toolchain) or a pure Cygwin build (using a tool chain built
> under Cygwin) with CMake.
This can involve hacking the recipe files for crosstool-NG for AVR32 [1].
`wget'
(within the
But again, I think we can avoid this tortuous path and fix the CMake or
Makefile to build on Windows.
Fully understand.
It is likely that you could create a pure Windows native build (using a
Windows native toolchain) or a pure Cygwin build (using a tool chain
built under Cygwin) with CMake.
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
> Do you have a logic analyzer? That strange character could be something,
case
> the clock is incorrect.
This is an awesome idea! :) I will get my logic analyser to check if I can
see
anything at all.
R
On Mon, 20 Nov 2023 at 18:45, Alan C. Assis wrote:
> Hi Raman,
>
> On 11/20/23, Raman
Hi Raman,
On 11/20/23, Raman Gopalan wrote:
> Dear Alan,
>
> I confirm the following settings from the NuttX make menuconfig. RX: PA24,
> alternate function 0. TX: PA23, alternate function 0. So, this is correct.
> Greg's user manual helped. I just grepped for the definitions.
>
> I see that the
Hi Raman,
On 11/20/23, Raman Gopalan 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
Dear Alan,
I confirm the following settings from the NuttX make menuconfig. RX: PA24,
alternate function 0. TX: PA23, alternate function 0. So, this is correct.
Greg's user manual helped. I just grepped for the definitions.
I see that the MCUZone's AT32UC3B isn't very different from the
penocd -f openocd.cfg
>
> > Reflections from a couple of months ago: On Ubuntu 22.04.3 LTS (the one
> I'm
> > running on this machine), I wasn't able to get the AVR32DEV1 OR Mizar32
> to
> > show
> > up on /dev as an ACM device - like it normally would.
> >
> &
Dear Alan,
> Did you setup your serial console terminal to 57600 ? Normally NuttX uses
> 115200, but for avr32dev1 the default is this value.
Yes, for sure. I checked .config. It was exactly 57600. Also on `minicom'.
> Do you have the AVR32DEV1 schematic? I didn't find it.
This has been a
Hi Raman,
Did you setup your serial console terminal to 57600 ?
Normally NuttX uses 115200, but for avr32dev1 the default is this value.
Do you have the AVR32DEV1 schematic? I didn't find it.
Looking the NuttX source code, the console is using USART1 PA24 as RXD
and PA17 as TXD.
Best Regards,
> Question: did you cloned nuttx-apps as apps/ in the same directory you
have
> cloned nuttx ?
For sure Alan. This is exactly how it is on both my machines.
> NuttX "depends on" apps/ to compile (it doesn't depend, but the build
system
> depends/expects to find it there).
Fully understand. Yes,
Dear All,
I just connected the FTDI to the MCUZone at32uc3b0256 breakout. Here are the
connections: I used my Fluke 115 to trace out the lines. I am sure they
work.
1) GND (FTDI) to GND (development board)
2) RX (FTDI) to J2, pin 10.
3) TX (FTDI) to J2, pin 7.
I don't see the nsh shell yet. It
Hi Greg,
AFAIK, Mr. Zou (CC here) fixed the Windows/Cygwin build few months ago.
We just need to add it in our CI to avoid it breaks again in the feature.
Brennan/Petro/Xiang, do you have a machine to add the Windows CI ?
Best Regards,
Alan
On 11/18/23, Gregory Nutt wrote:
> AFAIK, the
Hi Raman,
On 11/19/23, Raman Gopalan wrote:
> Dear Alan, Dear Gregory, Greetings!
>
> Hello Kevin and Zou Boan!
>
> Many thanks for your suggestions. I will write in detail in a bit but
> before, I was too excited about Alan's suggestion.
>
>> Other option could be extend the CMake support to
this before?
>
> Just thoughts: I wanted to seek your opinion:
>
> 1) Alan, which GNU/Linux distro do you use? I am willing to move to
> another/
> switch GNU/Linux distribution if that is what it takes to solve the Atmel
> ICE
> problem - OR just the debug problem in general on GNU/L
;
> 1) Alan, which GNU/Linux distro do you use? I am willing to move to
> another/
> switch GNU/Linux distribution if that is what it takes to solve the Atmel
> ICE
> problem - OR just the debug problem in general on GNU/Linux for AVR32 on
> NuttX.
>
> 2) Just as an example: t
GNU/Linux for AVR32 on
NuttX.
2) Just as an example: to inform you of my approach to a similar problem: I
hacked RT-Thread recently for the Mizar32 platform. I had build problems
with
it as well.
I worked with Microchip Studio for the entirety of the hack. To get things
to
work (debug, see if the
'
> >> '/home/alan/nuttxspace/nuttx/sched' ./clock/clock_initialize.c
> >> make[2]: *** [/home/alan/nuttxspace/nuttx/tools/Config.mk:228:
> >> clock_initialize.ddc] Error 1
> >> make[1]: *** [Makefile:70: .depend] Error 2
> >> make: *** [tools/Unix.mk:611
AFAIK, the Cygwin build using a windows native tool chain has been
broken for years. There is no advice anyone can give that that is just
going to make it work. It is broken and no one has interest in fixing
that which they have broken. People make many changes to the build
system but never
--
>>
>> $ make
>> LN: platform/board to /home/alan/nuttxspace/apps/platform/dummy
>> Register: nsh
>> Register: sh
>> CC: clock/clock.c as: loadlocale.c:130: _nl_intern_locale_data:
>> Assertion `cnt < (sizeof (_nl_value_type_LC_TIME) / sizeo
* [tools/LibTargets.mk:180: libs/libc/libc.a] Error 2
>
> Solution: edited libs/libc/assert/Make.defs and removed no-lto
>
>
in/../lib/gcc/avr32/4.4.7/../../../../avr32/include/sys/_types.h:56:
error: conflicting types for '_ssize_t'
/home/alan/nuttxspace/nuttx/include/arch/avr32/types.h:82: note:
previous declaration of '_ssize_t' was here
make[1]: *** [Makefile:153: bin/lib_strtol
31 matches
Mail list logo
