Thread: [Flashforth-devel] building flashforth with avra?
Brought to you by:
oh2aun
Menu
▾
▴
flashforth-devel
|
From: Christopher H. <chr...@li...> - 2021-03-25 21:27:52
|
Hi, is there anybody who has been able to build flashforth with avra ( https://github.com/Ro5bert/avra/tree/master/includes)? If so, can you share your command line calls, and any source edits you had to make? In trying to build flashforth for m328p (or, i guess, m328...?), I'm running into some confusion. avra has a m328p definition file but not a m328. And the avr config.inc with FF is a bit confusing to me as it seems to include m328pdef.inc in all builds but only m328def.inc if ffm328 is definied. As I try to work it out on the command line I end up with basic stuff like portd not defined. I was trying to build FF without using any proprietary avrstudio components, and avra seemed the easiest path. I couldn't find any source for avrasm2 anywhere, but information on the internet was confusing, so maybe I missed something. Christopher |
|
From: Mikael N. <mik...@fl...> - 2021-03-28 09:36:21
|
Hi, Inspired by this question, I started to re-write FlashForth for Atmega to compile with the Microchip MPLABX and XC8 compiler. It is still coded in assembler. It already compiles. Need to sort out some linking details before it is ready. Getting FF working with XC8 would also enable use of FF in the new Atmega parts from Microchip. BR Mikael On 2021-03-25 23:27, Christopher Howard wrote: > Hi, is there anybody who has been able to build flashforth with avra > (https://github.com/Ro5bert/avra/tree/master/includes)? |
|
From: Peter J. <pe...@me...> - 2021-03-28 11:10:28
|
Mikael, It would be interesting to have FF running on Atmega4809. I bought a few of those thinking that I would come back to doing some FF-related work this year (2021). It has been a while since I have had any time to play, so part of my plans included a refresh of the tutorial documents, possibly into ASCIIDOC source form. I expect that such a form would allow them to be more easily included on your web site and, also, that it would be easier to copy and paste code from them. Cheers, Peter J. On 28/3/21 7:36 pm, Mikael Nordman wrote: > Hi, > > Inspired by this question, I started to re-write FlashForth for Atmega > to compile with the Microchip MPLABX and XC8 compiler. > > It is still coded in assembler. > > It already compiles. Need to sort out some linking details before it > is ready. > > Getting FF working with XC8 would also enable use of FF in the new > Atmega parts from Microchip. > > BR Mikael > > On 2021-03-25 23:27, Christopher Howard wrote: > >> Hi, is there anybody who has been able to build flashforth with avra >> (https://github.com/Ro5bert/avra/tree/master/includes)? > > > _______________________________________________ > Flashforth-devel mailing list > Fla...@li... > https://lists.sourceforge.net/lists/listinfo/flashforth-devel |
|
From: Christopher H. <chr...@li...> - 2021-03-29 17:06:45
|
I played around with it for about 2 hours last week, but haven't
figured it out. It seems that flashforth is expecting different
included files than what is provided by avra - with FF referencing
m328def.inc and m328pdef.inc, and avra providing only m328Pdef.inc. If
I edit file names on one side or the other I end up with strings of
errors like below. Some of the error messages are a bit confusing.
christopher@theoden ~/Repos/flashforth$ ../avra/src/avra -D ffm328 -D
op0 -I ../avra/includes/ -I avr/src/ -o avr/hex/328-16MHz-38400.hex -fI
avr/src/ff-atmega.asm AVRA: advanced AVR macro assembler (version
1.4.2)Pass 1...avr/src/config.inc(115) : Error : Found no
label/variable/constant named avr/src/macros.inc(39) : Warning : r26 is
already assigned to 'XL'!avr/src/macros.inc(40) : Warning : r27 is
already assigned to 'XH'!avr/src/macros.inc(41) : Warning : r30 is
already assigned to 'ZL'!avr/src/macros.inc(42) : Warning : r31 is
already assigned to 'ZH'!avr/src/ff-atmega.asm(38) : Error : Found no
label/variable/constant named avr/src/ff-atmega.asm(99) : Error :
Found no label/variable/constant named TX0_avr/src/ff-atmega.asm(100) :
Error : Found no label/variable/constant named RX0_avr/src/ff-
atmega.asm(101) : Error : Found no label/variable/constant named
RX0Qavr/src/ff-atmega.asm(463) : Error : Unknown mnemonic/macro:
fdw(exit_l)avr/src/ff-atmega.asm(471) : Error : Unknown
mnemonic/macro: fdw(idle_l)avr/src/ff-atmega.asm(4226) : Error :
[Macro: avr/src/macros.inc: 56:] Found no label/variable/constant named
UCSR1Aavr/src/ff-atmega.asm(4229) : Error : [Macro:
avr/src/macros.inc: 64:] Found no label/variable/constant named
UDR1avr/src/ff-atmega.asm(4254) : Error : [Macro: avr/src/macros.inc:
56:] Found no label/variable/constant named UCSR1Aavr/src/ff-
atmega.asm(4254) : [Macro: avr/src/macros.inc: 58:] Maximum error count
reached. Exiting...
-----Original Message-----From: Stefan <fli...@gm...>To:
Christopher Howard <chr...@li...>Subject: Re:
[Flashforth-devel] building flashforth with avra?Date: Sun, 28 Mar 2021
14:51:26 +0200
Hi Christopher,
could you solve your problem?
I cannot help you with avra-problem, 'cause I'm using AVR Studio
4.19.
But I am pretty sure, that there is no difference in definition
between ATmega328 and ATmega328p - the p(ico power)-version just
uses less energy.
greets
bitflipser
Am 25.03.2021 um 22:27 schrieb
Christopher Howard:
> Hi, is there anybody who has been able to build flashforth
> with avra (
> https://github.com/Ro5bert/avra/tree/master/includes)?
> If so, can you share your command line calls, and any source
> edits you had to make? In trying to build flashforth for
> m328p
> (or, i guess, m328...?), I'm running into some confusion.
> avra
> has a m328p definition file but not a m328. And the avr
> config.inc with FF is a bit confusing to me as it seems to
> include m328pdef.inc in all builds but only m328def.inc if
> ffm328 is definied. As I try to work it out on the command
> line
> I end up with basic stuff like portd not defined.
>
>
>
> I was trying to build FF without using any proprietary
> avrstudio components, and avra seemed the easiest path. I
> couldn't find any source for avrasm2 anywhere, but
> information
> on the internet was confusing, so maybe I missed something.
>
>
>
> Christopher
>
>
>
>
>
>
>
>
>
>
> _______________________________________________Flashforth-devel
> mailing lis...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel
>
>
|
|
From: Christopher H. <chr...@li...> - 2021-03-29 20:29:16
|
I'm a little confused -- I'm not seeing anything by way of source code or free software licensing for these projects. Is that something you get access to after getting the installers to run on your system...? -----Original Message----- From: Mikael Nordman <mik...@fl...> To: fla...@li... Subject: Re: [Flashforth-devel] building flashforth with avra? Date: Sun, 28 Mar 2021 12:36:05 +0300 Hi, Inspired by this question, I started to re-write FlashForth for Atmega to compile with the Microchip MPLABX and XC8 compiler. It is still coded in assembler. It already compiles. Need to sort out some linking details before it is ready. Getting FF working with XC8 would also enable use of FF in the new Atmega parts from Microchip. BR Mikael On 2021-03-25 23:27, Christopher Howard wrote: > Hi, is there anybody who has been able to build flashforth with avra > (https://github.com/Ro5bert/avra/tree/master/includes)? _______________________________________________Flashforth-devel mailing lis...@li... https://lists.sourceforge.net/lists/listinfo/flashforth-devel |
|
From: Mikael N. <mik...@fl...> - 2021-03-30 06:48:52
|
XC8 is based on the Gnu Compiler toolchain. There is a free licence with the MPLABX and XC8 toolchains. These are the binaries you get. $ ls /opt/microchip/xc8/v2.32/avr/bin avr-addr2line avr-as avr-c++filt avr-elfedit avr-gcc avr-gcc-ar avr-gcc-ranlib avr-gcov-tool avr-gdb-py avr-ld avr-man avr-objcopy avr-ranlib avr-size avr-strip avr-ar avr-c++ avr-cpp avr-g++ avr-gcc-5.4.0 avr-gcc-nm avr-gcov avr-gdb avr-gprof avr-ld.bfd avr-nm avr-objdump avr-readelf avr-strings I have not looked for the source code. I do not need it. If you do not want to use XC8 you can find prebuilt Gnu Compiler toolchains on the internet. For example here https://gnutoolchains.com/avr/ BR Mikael On 2021-03-29 23:28, Christopher Howard wrote: > I'm a little confused -- I'm not seeing anything by way of source code > or free software licensing for these projects. Is that something you > get access to after getting the installers to run on your system...? > > -----Original Message----- > From: Mikael Nordman <mik...@fl...> > > Inspired by this question, I started to re-write FlashForth for Atmega > > to compile with the Microchip MPLABX and XC8 compiler. |
|
From: Mikael N. <mik...@fl...> - 2021-04-12 15:04:54
|
Peter, sorry for my slow response. FF Atmega is now transformed to be compiled with MPLABX and XC8. Does ASCIIDOC require some server side support? I am not familiar with it. It seems all peripherals, including flash and eeprom, are different on the 4809. Maybe you have an eager student to take on the task ? BR Mikael On 2021-03-28 13:49, Peter Jacobs wrote: > Mikael, > It would be interesting to have FF running on Atmega4809. I bought a > few of those thinking that I would come back to doing some FF-related > work this year (2021). It has been a while since I have had any time > to play, so part of my plans included a refresh of the tutorial > documents, possibly into ASCIIDOC source form. I expect that such a > form would allow them to be more easily included on your web site and, > also, that it would be easier to copy and paste code from them. > Cheers, > Peter J. |
|
From: Christopher H. <chr...@li...> - 2021-04-15 18:16:14
|
Hi, for those not willing to use MPLABX/XC8, do you have any instructions on how to build with avr-gcc toolchain? Christopher -----Original Message-----From: Mikael Nordman < mik...@fl...>To: Christopher Howard < chr...@li...>Cc: fla...@li...Subject: Re: [Flashforth-devel] building flashforth with avra?Date: Tue, 30 Mar 2021 09:48:32 +0300 XC8 is based on the Gnu Compiler toolchain.There is a free licence with the MPLABX and XC8 toolchains. These are the binaries you get.$ ls /opt/microchip/xc8/v2.32/avr/binavr-addr2line avr-as avr- c++filt avr-elfedit avr-gcc avr-gcc-ar avr-gcc-ranlib avr- gcov-tool avr-gdb-py avr-ld avr-man avr-objcopy avr- ranlib avr-size avr-stripavr-ar avr-c++ avr- cpp avr-g++ avr-gcc-5.4.0 avr-gcc-nm avr-gcov avr- gdb avr-gprof avr-ld.bfd avr-nm avr-objdump avr- readelf avr-strings I have not looked for the source code. I do not need it. If you do not want to use XC8 you can find prebuilt Gnu Compiler toolchains on the internet.For example here https://gnutoolchains.com/avr/ BR Mikael On 2021-03-29 23:28, Christopher Howard wrote: > I'm a little confused -- I'm not seeing anything by way of source > code or free software licensing for these projects. Is that something > you get access to after getting the installers to run on your > system...? > -----Original Message-----From: Mikael Nordman < > mik...@fl...> > Inspired by this question, I started to re-write FlashForth for > Atmega > to compile with the Microchip MPLABX and XC8 compiler. |
|
From: Mikael N. <mik...@fl...> - 2021-04-15 20:45:04
|
I do not have instructions. I need to publish the XC8 instructions, have not done that yet. You can try with the avr-gcc, but I believe it does not support the .section .NRWW, code, address() directive. Microchip stated the address() part was their addition to XC8, but you can try. On 2021-04-15 21:15, Christopher Howard wrote: > Hi, for those not willing to use MPLABX/XC8, do you have any instructions on how to build with avr-gcc toolchain? |
|
From: Christopher H. <chr...@li...> - 2021-04-15 23:31:20
|
After some work searching around and getting registered at their Website, I was finally able to download source archive for XC8 2.31 at https://www.microchip.com/en-us/development-tools-tools-and-software/mplab-ecosystem-downloads-archive#Source%20Archives . I don't know where are the sources for 2.32 - hopefully you are getting them with the the 2.32 binaries. The 2.31 archive contains modifications to avr-gcc. Hopefully that is all that I will need, beside figuring out the build commands of course. If XC8 outputs a list of avr-gcc calls that somebody could share, that would be helpful. I'm hoping all the definitions used in ff-xc8.asm are contained entirely in config-xc8.inc and avr-gcc toolchain but I've really got no idea at this point. Christopher -----Original Message----- From: Mikael Nordman <mik...@fl...> To: fla...@li... Subject: Re: [Flashforth-devel] building flashforth with avra? Date: Thu, 15 Apr 2021 23:44:47 +0300 I do not have instructions. I need to publish the XC8 instructions, have not done that yet. You can try with the avr-gcc, but I believe it does not support the .section .NRWW, code, address() directive. Microchip stated the address() part was their addition to XC8, but you can try. On 2021-04-15 21:15, Christopher Howard wrote: > Hi, for those not willing to use MPLABX/XC8, do you have any > instructions on how to build with avr-gcc toolchain? > _______________________________________________Flashforth-devel mailing lis...@li... https://lists.sourceforge.net/lists/listinfo/flashforth-devel |
|
From: Christopher H. <chr...@li...> - 2021-04-16 18:07:36
|
Thank you. I am hoping to play around with this in the next week or so during some lunch break. Christopher -----Original Message-----From: Mikael Nordman < mik...@fl...>To: Christopher Howard < chr...@li...>Subject: Re: [Flashforth-devel] building flashforth with avra?Date: Fri, 16 Apr 2021 09:13:57 +0300 Hi Chris, Here is the verbose output of building with XC8. BR Mikael CLEAN SUCCESSFUL (total time: 82ms) make -f nbproject/Makefile-default.mk SUBPROJECTS= .build-conf make[1]: Entering directory '/home/mikael/ff/avr/mchip1.X' make -f nbproject/Makefile-default.mk dist/default/production/mchip1.X.production.hex make[2]: Entering directory '/home/mikael/ff/avr/mchip1.X' "/opt/microchip/xc8/v2.32/bin/xc8-cc" -c -mcpu=ATmega328P -x assembler-with-cpp -D__ATmega328P__ -O0 -funsigned-char -funsigned- bitfields -I"../src" -v -Wall -DXPRJ_default=default -gdwarf-3 -Wa, --defsym=__MPLAB_BUILD=1 -MD -MP -MF "build/default/production/_ext/1360937237/ff-xc8.o.d" -MT "build/default/production/_ext/1360937237/ff-xc8.o.d" -MT build/default/production/_ext/1360937237/ff-xc8.o -o build/default/production/_ext/1360937237/ff-xc8.o ../src/ff-xc8.asm /opt/microchip/xc8/v2.32/avr/bin/avr-gcc @/tmp/xcXIIDODB.cmd [ -c -mmcu=atmega328p -x assembler-with-cpp -D__ATmega328P__ -O0 -funsigned- char -funsigned-bitfields -I../src -v -Wall -DXPRJ_default=default -gdwarf-3 -Wa,--defsym=__MPLAB_BUILD=1 -MD -MP -MF build/default/production/_ext/1360937237/ff-xc8.o.d -MT build/default/production/_ext/1360937237/ff-xc8.o.d -MT build/default/production/_ext/1360937237/ff-xc8.o -obuild/default/production/_ext/1360937237/ff-xc8.o ../src/ff-xc8.asm -Wl,--info-linker -mdevice=atmega328p -mconst-data-in-progmem -mdfp=/opt/microchip/xc8/v2.32/dfp/xc8 -D__XC -D__XC8 -D__XC__ -D__XC8__ -D__XC8_VERSION=2320 ] Using built-in specs. Reading specs from /opt/microchip/xc8/v2.32/dfp/xc8/avr/device- specs/specs-atmega328p COLLECT_GCC=/opt/microchip/xc8/v2.32/avr/bin/avr-gcc Target: avr Configured with: /home/toolsbuild/workspace/xc8-avr- gcc/src/gcc/configure CFLAGS='-Os -g0 -I /home/toolsbuild/workspace/xc8-avr-gcc/avr8-gnu-toolchain-linux_x86_64- hostlibs/include/libxml2 -DMCHP_XCLM_SHA256_DIGEST=1c9650392a44b34ccfd84f998b692a608aac687e614c1 ae66f6fd1791578e752 -DMCHP_FXCLM_SHA256_DIGEST=8727ea3da9bdd624fee0130eb6133188719892bcbee7 da32606911a8b08a1a8d -I /home/toolsbuild/workspace/xc8-avr-gcc/avr8- gnu-toolchain-linux_x86_64-hostlibs/include/' CXXFLAGS='-I /home/toolsbuild/workspace/xc8-avr-gcc/avr8-gnu-toolchain-linux_x86_64- hostlibs/include/libxml2 -DMCHP_XCLM_SHA256_DIGEST=1c9650392a44b34ccfd84f998b692a608aac687e614c1 ae66f6fd1791578e752 -DMCHP_FXCLM_SHA256_DIGEST=8727ea3da9bdd624fee0130eb6133188719892bcbee7 da32606911a8b08a1a8d -I /home/toolsbuild/workspace/xc8-avr-gcc/avr8- gnu-toolchain-linux_x86_64-hostlibs/include/' LDFLAGS=- L/home/toolsbuild/workspace/xc8-avr-gcc/avr8-gnu-toolchain- linux_x86_64-hostlibs/lib CPPFLAGS= --target=avr --host=x86_64-pc- linux-gnu --build=x86_64-pc-linux-gnu -- prefix=/home/toolsbuild/workspace/xc8-avr-gcc/avr8-gnu-toolchain- linux_x86_64 --libdir=/home/toolsbuild/workspace/xc8-avr-gcc/avr8-gnu- toolchain-linux_x86_64/lib --enable-languages=c,c++ --with-dwarf2 -- enable-doc --disable-shared --disable-libada --disable-libssp -- disable-nls --with-avrlibc=yes --with- mpfr=/home/toolsbuild/workspace/xc8-avr-gcc/avr8-gnu-toolchain- linux_x86_64-hostlibs --with-gmp=/home/toolsbuild/workspace/xc8-avr- gcc/avr8-gnu-toolchain-linux_x86_64-hostlibs --with- mpc=/home/toolsbuild/workspace/xc8-avr-gcc/avr8-gnu-toolchain- linux_x86_64-hostlibs --with- pkgversion=AVR_8_bit_GNU_Toolchain_3.6.6_293 --with-bugurl= http://www.microchip.com Thread model: single gcc version 5.4.0 (AVR_8_bit_GNU_Toolchain_3.6.6_293) COLLECT_GCC_OPTIONS='-c' '-D' '__ATmega328P__' '-O0' '-funsigned-char' '-funsigned-bitfields' '-I' '../src' '-v' '-Wall' '-D' 'XPRJ_default=default' '-gdwarf-3' '-MD' '-MP' '-MF' 'build/default/production/_ext/1360937237/ff-xc8.o.d' '-MT' 'build/default/production/_ext/1360937237/ff-xc8.o.d' '-MT' 'build/default/production/_ext/1360937237/ff-xc8.o' '-o' 'build/default/production/_ext/1360937237/ff-xc8.o' '- mdevice=atmega328p' '-mconst-data-in-progmem' '-D' '__XC' '-D' '__XC8' '-D' '__XC__' '-D' '__XC8__' '-D' '__XC8_VERSION=2320' '-mpack- dir=/opt/microchip/xc8/v2.32/dfp/xc8' '-B' '/opt/microchip/xc8/v2.32/dfp/xc8/avr/' '-I' '/opt/microchip/xc8/v2.32/dfp/xc8/avr/include' '-B' '/opt/microchip/xc8/v2.32/dfp/xc8/avr/lib' '-specs=device-specs/specs- atmega328p' '-mmcu=avr5' '-mdevice=atmega328p' /opt/microchip/xc8/v2.32/avr/bin/../libexec/gcc/avr/5.4.0/cc1 -E -lang-asm -quiet -v -I ../src -I /opt/microchip/xc8/v2.32/dfp/xc8/avr/include -imultilib avr5/memx-const -iprefix /opt/microchip/xc8/v2.32/avr/bin/../lib/gcc/avr/5.4.0/ -isystem /opt/microchip/xc8/v2.32/dfp/xc8/avr/include -MD build/default/production/_ext/1360937237/ff-xc8.d -MF build/default/production/_ext/1360937237/ff-xc8.o.d -MP -MT build/default/production/_ext/1360937237/ff-xc8.o.d -MT build/default/production/_ext/1360937237/ff-xc8.o -D__AVR_ATmega328P__ -D__AVR_DEVICE_NAME__=atmega328p -D__AVR_DEV_LIB_NAME__=m328p -D __ATmega328P__ -D XPRJ_default=default -D __XC -D __XC8 -D __XC__ -D __XC8__ -D __XC8_VERSION=2320 ../src/ff-xc8.asm -mn-flash=1 -mno-skip- bug -mdevice=atmega328p -mconst-data-in-progmem -mpack- dir=/opt/microchip/xc8/v2.32/dfp/xc8 -mmcu=avr5 -mdevice=atmega328p -Wall -funsigned-char -funsigned-bitfields -gdwarf-3 -fworking- directory -O0 -fno-directives-only -o /tmp/cclHrIj6.s ignoring nonexistent directory "/opt/microchip/xc8/v2.32/avr/bin/../lib/gcc/avr/5.4.0/../../../../avr/ sys-include" ignoring duplicate directory "/opt/microchip/xc8/v2.32/avr/bin/../lib/gcc/../../lib/gcc/avr/5.4.0/in clude" ignoring duplicate directory "/opt/microchip/xc8/v2.32/avr/bin/../lib/gcc/../../lib/gcc/avr/5.4.0/in clude-fixed" ignoring nonexistent directory "/opt/microchip/xc8/v2.32/avr/bin/../lib/gcc/../../lib/gcc/avr/5.4.0/.. /../../../avr/sys-include" ignoring duplicate directory "/opt/microchip/xc8/v2.32/avr/bin/../lib/gcc/../../lib/gcc/avr/5.4.0/.. /../../../avr/include" ignoring duplicate directory "/opt/microchip/xc8/v2.32/dfp/xc8/avr/include" as it is a non-system directory that duplicates a system directory #include "..." search starts here: #include <...> search starts here: ../src /opt/microchip/xc8/v2.32/dfp/xc8/avr/include /opt/microchip/xc8/v2.32/avr/bin/../lib/gcc/avr/5.4.0/include /opt/microchip/xc8/v2.32/avr/bin/../lib/gcc/avr/5.4.0/include-fixed /opt/microchip/xc8/v2.32/avr/bin/../lib/gcc/avr/5.4.0/../../../../avr/ include End of search list. COLLECT_GCC_OPTIONS='-c' '-D' '__ATmega328P__' '-O0' '-funsigned-char' '-funsigned-bitfields' '-I' '../src' '-v' '-Wall' '-D' 'XPRJ_default=default' '-gdwarf-3' '-MD' '-MP' '-MF' 'build/default/production/_ext/1360937237/ff-xc8.o.d' '-MT' 'build/default/production/_ext/1360937237/ff-xc8.o.d' '-MT' 'build/default/production/_ext/1360937237/ff-xc8.o' '-o' 'build/default/production/_ext/1360937237/ff-xc8.o' '- mdevice=atmega328p' '-mconst-data-in-progmem' '-D' '__XC' '-D' '__XC8' '-D' '__XC__' '-D' '__XC8__' '-D' '__XC8_VERSION=2320' '-mpack- dir=/opt/microchip/xc8/v2.32/dfp/xc8' '-B' '/opt/microchip/xc8/v2.32/dfp/xc8/avr/' '-I' '/opt/microchip/xc8/v2.32/dfp/xc8/avr/include' '-B' '/opt/microchip/xc8/v2.32/dfp/xc8/avr/lib' '-specs=device-specs/specs- atmega328p' '-mmcu=avr5' '-mdevice=atmega328p' /opt/microchip/xc8/v2.32/avr/bin/../lib/gcc/avr/5.4.0/../../../../avr/ bin/as --gdwarf2 -mmcu=avr5 -mno-skip-bug --defsym=__MPLAB_BUILD=1 -o build/default/production/_ext/1360937237/ff-xc8.o /tmp/cclHrIj6.s COMPILER_PATH=/opt/microchip/xc8/v2.32/dfp/xc8/avr/:/opt/microchip/xc8/ v2.32/dfp/xc8/avr/lib/:/opt/microchip/xc8/v2.32/avr/bin/../libexec/gcc/ avr/5.4.0/:/opt/microchip/xc8/v2.32/avr/bin/../libexec/gcc/:/opt/microc hip/xc8/v2.32/avr/bin/../lib/gcc/avr/5.4.0/../../../../avr/bin/ LIBRARY_PATH=/opt/microchip/xc8/v2.32/dfp/xc8/avr/lib/avr5/memx- const/:/opt/microchip/xc8/v2.32/avr/bin/../lib/gcc/avr/5.4.0/avr5/memx- const/:/opt/microchip/xc8/v2.32/avr/bin/../lib/gcc/avr/5.4.0/../../../. ./avr/lib/avr5/memx- const/:/opt/microchip/xc8/v2.32/dfp/xc8/avr/:/opt/microchip/xc8/v2.32/d fp/xc8/avr/lib/:/opt/microchip/xc8/v2.32/avr/bin/../lib/gcc/avr/5.4.0/: /opt/microchip/xc8/v2.32/avr/bin/../lib/gcc/:/opt/microchip/xc8/v2.32/a vr/bin/../lib/gcc/avr/5.4.0/../../../../avr/lib/ COLLECT_GCC_OPTIONS='-c' '-D' '__ATmega328P__' '-O0' '-funsigned-char' '-funsigned-bitfields' '-I' '../src' '-v' '-Wall' '-D' 'XPRJ_default=default' '-gdwarf-3' '-MD' '-MP' '-MF' 'build/default/production/_ext/1360937237/ff-xc8.o.d' '-MT' 'build/default/production/_ext/1360937237/ff-xc8.o.d' '-MT' 'build/default/production/_ext/1360937237/ff-xc8.o' '-o' 'build/default/production/_ext/1360937237/ff-xc8.o' '- mdevice=atmega328p' '-mconst-data-in-progmem' '-D' '__XC' '-D' '__XC8' '-D' '__XC__' '-D' '__XC8__' '-D' '__XC8_VERSION=2320' '-mpack- dir=/opt/microchip/xc8/v2.32/dfp/xc8' '-B' '/opt/microchip/xc8/v2.32/dfp/xc8/avr/' '-I' '/opt/microchip/xc8/v2.32/dfp/xc8/avr/include' '-B' '/opt/microchip/xc8/v2.32/dfp/xc8/avr/lib' '-specs=device-specs/specs- atmega328p' '-mmcu=avr5' '-mdevice=atmega328p' Using built-in specs. Reading specs from /opt/microchip/xc8/v2.32/dfp/xc8/avr/device- specs/specs-atmega328p COLLECT_GCC=/opt/microchip/xc8/v2.32/avr/bin/avr-gcc COLLECT_LTO_WRAPPER=/opt/microchip/xc8/v2.32/avr/bin/../libexec/gcc/avr /5.4.0/lto-wrapper Target: avr Configured with: /home/toolsbuild/workspace/xc8-avr- gcc/src/gcc/configure CFLAGS='-Os -g0 -I /home/toolsbuild/workspace/xc8-avr-gcc/avr8-gnu-toolchain-linux_x86_64- hostlibs/include/libxml2 -DMCHP_XCLM_SHA256_DIGEST=1c9650392a44b34ccfd84f998b692a608aac687e614c1 ae66f6fd1791578e752 -DMCHP_FXCLM_SHA256_DIGEST=8727ea3da9bdd624fee0130eb6133188719892bcbee7 da32606911a8b08a1a8d -I /home/toolsbuild/workspace/xc8-avr-gcc/avr8- gnu-toolchain-linux_x86_64-hostlibs/include/' CXXFLAGS='-I /home/toolsbuild/workspace/xc8-avr-gcc/avr8-gnu-toolchain-linux_x86_64- hostlibs/include/libxml2 -DMCHP_XCLM_SHA256_DIGEST=1c9650392a44b34ccfd84f998b692a608aac687e614c1 ae66f6fd1791578e752 -DMCHP_FXCLM_SHA256_DIGEST=8727ea3da9bdd624fee0130eb6133188719892bcbee7 da32606911a8b08a1a8d -I /home/toolsbuild/workspace/xc8-avr-gcc/avr8- gnu-toolchain-linux_x86_64-hostlibs/include/' LDFLAGS=- L/home/toolsbuild/workspace/xc8-avr-gcc/avr8-gnu-toolchain- linux_x86_64-hostlibs/lib CPPFLAGS= --target=avr --host=x86_64-pc- linux-gnu --build=x86_64-pc-linux-gnu -- prefix=/home/toolsbuild/workspace/xc8-avr-gcc/avr8-gnu-toolchain- linux_x86_64 --libdir=/home/toolsbuild/workspace/xc8-avr-gcc/avr8-gnu- toolchain-linux_x86_64/lib --enable-languages=c,c++ --with-dwarf2 -- enable-doc --disable-shared --disable-libada --disable-libssp -- disable-nls --with-avrlibc=yes --with- mpfr=/home/toolsbuild/workspace/xc8-avr-gcc/avr8-gnu-toolchain- linux_x86_64-hostlibs --with-gmp=/home/toolsbuild/workspace/xc8-avr- gcc/avr8-gnu-toolchain-linux_x86_64-hostlibs --with- mpc=/home/toolsbuild/workspace/xc8-avr-gcc/avr8-gnu-toolchain- linux_x86_64-hostlibs --with- pkgversion=AVR_8_bit_GNU_Toolchain_3.6.6_293 --with-bugurl= http://www.microchip.com Thread model: single gcc version 5.4.0 (AVR_8_bit_GNU_Toolchain_3.6.6_293) COMPILER_PATH=/opt/microchip/xc8/v2.32/dfp/xc8/avr/:/opt/microchip/xc8/ v2.32/dfp/xc8/avr/lib/:/opt/microchip/xc8/v2.32/avr/bin/../libexec/gcc/ avr/5.4.0/:/opt/microchip/xc8/v2.32/avr/bin/../libexec/gcc/:/opt/microc hip/xc8/v2.32/avr/bin/../lib/gcc/avr/5.4.0/../../../../avr/bin/ LIBRARY_PATH=/opt/microchip/xc8/v2.32/dfp/xc8/avr/lib/avr5/memx- const/:/opt/microchip/xc8/v2.32/avr/bin/../lib/gcc/avr/5.4.0/avr5/memx- const/:/opt/microchip/xc8/v2.32/avr/bin/../lib/gcc/avr/5.4.0/../../../. ./avr/lib/avr5/memx- const/:/opt/microchip/xc8/v2.32/dfp/xc8/avr/:/opt/microchip/xc8/v2.32/d fp/xc8/avr/lib/:/opt/microchip/xc8/v2.32/avr/bin/../lib/gcc/avr/5.4.0/: /opt/microchip/xc8/v2.32/avr/bin/../lib/gcc/:/opt/microchip/xc8/v2.32/a vr/bin/../lib/gcc/avr/5.4.0/../../../../avr/lib/ COLLECT_GCC_OPTIONS= '-D' 'XPRJ_default=default' '-O0' '-funsigned- char' '-funsigned-bitfields' '-I' '../src' '-v' '-Wall' '-gdwarf-3' '- nostartfiles' '-o' 'dist/default/production/mchip1.X.production.elf' '- o' 'dist/default/production/mchip1.X.production.elf' '- mdevice=atmega328p' '-mconst-data-in-progmem' '-D' '__XC' '-D' '__XC8' '-D' '__XC__' '-D' '__XC8__' '-D' '__XC8_VERSION=2320' '-mpack- dir=/opt/microchip/xc8/v2.32/dfp/xc8' '-B' '/opt/microchip/xc8/v2.32/dfp/xc8/avr/' '-I' '/opt/microchip/xc8/v2.32/dfp/xc8/avr/include' '-B' '/opt/microchip/xc8/v2.32/dfp/xc8/avr/lib' '-specs=device-specs/specs- atmega328p' '-mmcu=avr5' '-mdevice=atmega328p' /opt/microchip/xc8/v2.32/avr/bin/../libexec/gcc/avr/5.4.0/collect2 -plugin /opt/microchip/xc8/v2.32/avr/bin/../libexec/gcc/avr/5.4.0/liblto_plugin .so -plugin- opt=/opt/microchip/xc8/v2.32/avr/bin/../libexec/gcc/avr/5.4.0/lto- wrapper -plugin-opt=-fresolution=/tmp/cczRqt3L.res -plugin-opt=-pass- through=-lgcc -plugin-opt=-pass-through=-lm -plugin-opt=-pass-through=- lc -plugin-opt=-pass-through=-latmega328p -mavr5 -Tdata 0x800100 -o dist/default/production/mchip1.X.production.elf -o dist/default/production/mchip1.X.production.elf -L/opt/microchip/xc8/v2.32/dfp/xc8/avr/lib/avr5/memx-const -L/opt/microchip/xc8/v2.32/avr/bin/../lib/gcc/avr/5.4.0/avr5/memx-const -L/opt/microchip/xc8/v2.32/avr/bin/../lib/gcc/avr/5.4.0/../../../../avr /lib/avr5/memx-const -L/opt/microchip/xc8/v2.32/dfp/xc8/avr -L/opt/microchip/xc8/v2.32/dfp/xc8/avr/lib -L/opt/microchip/xc8/v2.32/avr/bin/../lib/gcc/avr/5.4.0 -L/opt/microchip/xc8/v2.32/avr/bin/../lib/gcc -L/opt/microchip/xc8/v2.32/avr/bin/../lib/gcc/avr/5.4.0/../../../../avr /lib -Map=dist/default/production/mchip1.X.production.map -- defsym=__MPLAB_BUILD=1 --memorysummary dist/default/production/memoryfile.xml build/default/production/_ext/1360937237/ff-xc8.o --start-group --end- group --info-linker --start-group -lgcc -lm -lc -latmega328p --end- group "/opt/microchip/xc8/v2.32/bin/xc8-cc" -mcpu=ATmega328P -Wl,- Map=dist/default/production/mchip1.X.production.map -DXPRJ_default=default -Wl,--defsym=__MPLAB_BUILD=1 -O0 -funsigned- char -funsigned-bitfields -I"../src" -v -Wall -gdwarf-3 -nostartfiles -Wl, --memorysummary,dist/default/production/memoryfile.xml -o dist/default/production/mchip1.X.production.elf -o dist/default/production/mchip1.X.production.elf build/default/production/_ext/1360937237/ff-xc8.o -Wl,--start- group -Wl,--end-group /opt/microchip/xc8/v2.32/avr/bin/avr-gcc @/tmp/xcXpLeMMo.cmd [ -mmcu=atmega328p -Wl,- Map=dist/default/production/mchip1.X.production.map -DXPRJ_default=default -Wl,--defsym=__MPLAB_BUILD=1 -O0 -funsigned-char -funsigned-bitfields -I../src -v -Wall -gdwarf-3 -nostartfiles -Wl, --memorysummary,dist/default/production/memoryfile.xml -odist/default/production/mchip1.X.production.elf -odist/default/production/mchip1.X.production.elf build/default/production/_ext/1360937237/ff-xc8.o -Wl,--start-group -Wl,--end-group -Wl,--info-linker -mdevice=atmega328p -mconst-data-in- progmem -mdfp=/opt/microchip/xc8/v2.32/dfp/xc8 -D__XC -D__XC8 -D__XC__ -D__XC8__ -D__XC8_VERSION=2320 ] Info: Loading file: /opt/microchip/xc8/v2.32/avr/avr/bin/../lib/ldscripts/avr5.xn "/opt/microchip/xc8/v2.32/bin"/avr-objcopy -O ihex "dist/default/production/mchip1.X.production.elf" "dist/default/production/mchip1.X.production.hex" make[2]: Leaving directory '/home/mikael/ff/avr/mchip1.X' make[1]: Leaving directory '/home/mikael/ff/avr/mchip1.X' BUILD SUCCESSFUL (total time: 880ms) Loading code from /home/mikael/ff/avr/mchip1.X/dist/default/production/mchip1.X.productio n.hex... Program loaded with pack,ATmega_DFP,2.1.87,Microchip Loading completed |
|
From: Christopher H. <chr...@li...> - 2021-04-30 13:25:19
|
Hi, I've put a few hours into trying to figure out how to build with just avr-gcc toolchain, without the proprietary XC8 assembler. To my surprise (given my lack of knowledge) I seemed to have gotten pretty far with this call avr-gcc -mmcu=atmega328p -I. -D__ATmega328P__ -x assembler-with-cpp ff- libre.asm Which mostly does not give errors, so long as I drop the "#include <xc.h>" directive from all the files. However, I'm stuck on this code: ;*******************************************************************KER NEL_END:;***********************************************************.se ction .nrww, code, address(NRWW_START);*************************************************** ********** which gives error ff-libre.asm: Assembler messages:ff-libre.asm:6334: Error: character following name is not '#' Not sure if there is some actual .section syntax incompatibility, or if I need another gcc flag, or if am trying to build the wrong output format (ELF, etc.)... On Fri, 2021-04-16 at 10:07 -0800, Christopher Howard wrote: > Thank you. I am hoping to play around with this in the next week or > so during some lunch break. > > Christopher > > -----Original Message----- > From: Mikael Nordman <mik...@fl...> > To: Christopher Howard <chr...@li...> > Subject: Re: [Flashforth-devel] building flashforth with avra? > Date: Fri, 16 Apr 2021 09:13:57 +0300 > > > Hi Chris, > > Here is the verbose output of building with XC8. > > BR Mikael > > -- Christopher Howard blog: https://librehacker.com social: https://gnusocial.club/librehacker |
|
From: Christopher H. <chr...@li...> - 2021-04-30 13:31:09
|
I should mention I have been trying to use the avr-gcc (GCC) 7.5.0 toolchain, rather than the modified avr-gcc sources from the released XC8_v2.30_AVR_Sources, which I think were using version 5 or something older. On Fri, 2021-04-30 at 05:24 -0800, Christopher Howard wrote: > Hi, I've put a few hours into trying to figure out how to build with > just avr-gcc toolchain, without the proprietary XC8 assembler. To my > surprise (given my lack of knowledge) I seemed to have gotten pretty > far with this call > > avr-gcc -mmcu=atmega328p -I. -D__ATmega328P__ -x assembler-with-cpp > ff-libre.asm > > Which mostly does not give errors, so long as I drop the "#include > <xc.h>" directive from all the files. However, I'm stuck on this > code: > > ;******************************************************************* > KERNEL_END: > ;*********************************************************** > .section .nrww, code, address(NRWW_START) > ;************************************************************* > > which gives error > > ff-libre.asm: Assembler messages: > ff-libre.asm:6334: Error: character following name is not '#' > > Not sure if there is some actual .section syntax incompatibility, or > if I need another gcc flag, or if am trying to build the wrong output > format (ELF, etc.)... > > > -- > Christopher Howard > blog: https://librehacker.com > social: https://gnusocial.club/librehacker > > On Fri, 2021-04-16 at 10:07 -0800, Christopher Howard wrote: > > Thank you. I am hoping to play around with this in the next week or > > so during some lunch break. > > > > Christopher > > > > -----Original Message----- > > From: Mikael Nordman <mik...@fl...> > > To: Christopher Howard <chr...@li...> > > Subject: Re: [Flashforth-devel] building flashforth with avra? > > Date: Fri, 16 Apr 2021 09:13:57 +0300 > > > > > > Hi Chris, > > > > Here is the verbose output of building with XC8. > > > > BR Mikael > > > > > > _______________________________________________Flashforth-devel > mailing lis...@li... > https://lists.sourceforge.net/lists/listinfo/flashforth-devel -- Christopher Howard blog: https://librehacker.com social: https://gnusocial.club/librehacker |
|
From: Christopher H. <chr...@li...> - 2021-04-30 14:34:34
|
Additional note: I also had to include the <avr/io.h> header. -- Christopher Howard blog: https://librehacker.com social: https://gnusocial.club/librehacker On Fri, 2021-04-30 at 05:30 -0800, Christopher Howard wrote: > I should mention I have been trying to use the avr-gcc (GCC) 7.5.0 > toolchain, rather than the modified avr-gcc sources from the released > XC8_v2.30_AVR_Sources, which I think were using version 5 or > something older. > > -- > Christopher Howard > blog: https://librehacker.com > social: https://gnusocial.club/librehacker > > On Fri, 2021-04-30 at 05:24 -0800, Christopher Howard wrote: > > Hi, I've put a few hours into trying to figure out how to build > > with just avr-gcc toolchain, without the proprietary XC8 assembler. > > To my surprise (given my lack of knowledge) I seemed to have gotten > > pretty far with this call > > avr-gcc -mmcu=atmega328p -I. -D__ATmega328P__ -x assembler-with-cpp > > ff-libre.asm > > Which mostly does not give errors, so long as I drop the "#include > > <xc.h>" directive from all the files. However, I'm stuck on this > > code: > > ;****************************************************************** > > *KERNEL_END:;****************************************************** > > *****.section .nrww, code, > > address(NRWW_START);*********************************************** > > ************** > > which gives error > > ff-libre.asm: Assembler messages:ff-libre.asm:6334: Error: > > character following name is not '#' > > Not sure if there is some actual .section syntax incompatibility, > > or if I need another gcc flag, or if am trying to build the wrong > > output format (ELF, etc.)... > > -- > > Christopher Howard > > blog: https://librehacker.com > > social: https://gnusocial.club/librehacker > > On Fri, 2021-04-16 at 10:07 -0800, Christopher Howard wrote: > > > Thank you. I am hoping to play around with this in the next week > > > or so during some lunch break. > > > > > > Christopher > > > > > > -----Original Message----- > > > From: Mikael Nordman <mik...@fl...> > > > To: Christopher Howard <chr...@li...> > > > Subject: Re: [Flashforth-devel] building flashforth with avra? > > > Date: Fri, 16 Apr 2021 09:13:57 +0300 > > > > > > > > > Hi Chris, > > > > > > Here is the verbose output of building with XC8. > > > > > > BR Mikael > > > > > > > > > > _______________________________________________Flashforth-devel > > mailing lis...@li... > > https://lists.sourceforge.net/lists/listinfo/flashforth-devel > > _______________________________________________Flashforth-devel > mailing lis...@li... > https://lists.sourceforge.net/lists/listinfo/flashforth-devel > |
|
From: Mikael N. <mik...@fl...> - 2021-05-01 03:46:25
|
I wrote this in an earlier post in this chain. "You can try with the avr-gcc, but I believe it does not support the .section .NRWW, code, address() directive. Microchip stated the address() part was their addition to XC8, but you can try." You can use the ".fill" directive instead to fill the flash memory with 0xffff so that the NRWW code starts 0x400 bytes from the end of flash. That solution makes for a much longer hex file, taking a longer time to program the hex file into the chip. On 2021-04-30 16:24, Christopher Howard wrote: > Hi, I've put a few hours into trying to figure out how to build with just avr-gcc toolchain, without the proprietary XC8 assembler. To my surprise (given my lack of knowledge) I seemed to have gotten pretty far with this call > > avr-gcc -mmcu=atmega328p -I. -D__ATmega328P__ -x assembler-with-cpp ff-libre.asm > > Which mostly does not give errors, so long as I drop the "#include <xc.h>" directive from all the files. However, I'm stuck on this code: > > ;******************************************************************* > KERNEL_END: > ;*********************************************************** > .section .nrww, code, address(NRWW_START) > ;************************************************************* > > which gives error > > ff-libre.asm: Assembler messages: > ff-libre.asm:6334: Error: character following name is not '#' > > Not sure if there is some actual .section syntax incompatibility, or if I need another gcc flag, or if am trying to build the wrong output format (ELF, etc.)... > > -- > > Christopher Howard > blog: https://librehacker.com > social: https://gnusocial.club/librehacker > > On Fri, 2021-04-16 at 10:07 -0800, Christopher Howard wrote: > >> Thank you. I am hoping to play around with this in the next week or so during some lunch break. >> >> Christopher >> >> -----Original Message----- >> From: Mikael Nordman <mik...@fl...> >> To: Christopher Howard <chr...@li...> >> Subject: Re: [Flashforth-devel] building flashforth with avra? >> Date: Fri, 16 Apr 2021 09:13:57 +0300 >> >> Hi Chris, >> >> Here is the verbose output of building with XC8. >> >> BR Mikael -- -- Mikael |
|
From: Christopher H. <chr...@li...> - 2021-05-04 06:01:54
|
That you for your help. I'm no expert on the subject at this point, but it seems like there must be some better way to do this than filling a ton of memory each time I upload FlashForth to a chip. Seems like I should be able to get something equivalent to .NRWW directive with some combination of a named section and a section address in a linker script. I'm mildly curious what is really going on behind that XC8 .NRWW "addition". Unless they've somehow crossed the assembler/linker boundry, they must pass some extra information on to the linker...? Something that gives instructions to their own linker script, or to a modified Gnu LD? Anyway, sounds like I've finally got an excuse now to become an expert on linking. On Sat, 2021-05-01 at 06:46 +0300, Mikael Nordman wrote: > I wrote this in an earlier post in this chain. > "You can try with the avr-gcc, but I believe it does not support the > .section .NRWW, code, address() directive. > Microchip stated the address() part was their addition to XC8, but > you can try." > You can use the ".fill" directive instead to fill the flash memory > with 0xffff so that the NRWW code > starts 0x400 bytes from the end of flash. > That solution makes for a much longer hex file, taking a longer time > to program the hex file into the chip. > > > On 2021-04-30 16:24, Christopher Howard wrote: > > Hi, I've put a few hours into trying to figure out how to build > > with just avr-gcc toolchain, without the proprietary XC8 assembler. > > To my surprise (given my lack of knowledge) I seemed to have gotten > > pretty far with this call > > > > avr-gcc -mmcu=atmega328p -I. -D__ATmega328P__ -x assembler-with-cpp > > ff-libre.asm > > > > Which mostly does not give errors, so long as I drop the "#include > > <xc.h>" directive from all the files. However, I'm stuck on this > > code: > > > > ;****************************************************************** > > * > > KERNEL_END: > > ;*********************************************************** > > .section .nrww, code, address(NRWW_START) > > ;************************************************************* > > > > which gives error > > > > ff-libre.asm: Assembler messages: > > ff-libre.asm:6334: Error: character following name is not '#' > > > > Not sure if there is some actual .section syntax incompatibility, > > or if I need another gcc flag, or if am trying to build the wrong > > output format (ELF, etc.)... > > > > > > > > -- > > Christopher Howard > > blog: https://librehacker.com > > social: https://gnusocial.club/librehacker > > > > > > On Fri, 2021-04-16 at 10:07 -0800, Christopher Howard wrote: > > > Thank you. I am hoping to play around with this in the next week > > > or so during some lunch break. > > > > > > Christopher > > > > > > -----Original Message----- > > > From: Mikael Nordman <mik...@fl...> > > > To: Christopher Howard <chr...@li...> > > > Subject: Re: [Flashforth-devel] building flashforth with avra? > > > Date: Fri, 16 Apr 2021 09:13:57 +0300 > > > > > > Hi Chris, > > > Here is the verbose output of building with XC8. > > > BR Mikael > > > > > > > > > -- > > -- > Mikael > > -- Christopher Howard blog: https://librehacker.com social: https://gnusocial.club/librehacker |
|
From: Mikael N. <mik...@fl...> - 2021-05-04 10:06:57
|
Hi Chris, Here is the link for the answer I got from Microchip. They modified the XC8 suite somehow. Maybe both AVR-AS and AVR-LD. https://www.microchip.com/forums/m1170217.aspx It is possible use a custom linker script instead, but I did not want to maintain linker files for FlashForth. If you come up with the linker scripts for the supported Atmegas, I can add them into FlashForth. BR Mikael On 2021-05-04 09:01, Christopher Howard wrote: > That you for your help. > > I'm no expert on the subject at this point, but it seems like there _must_ be some better way to do this than filling a ton of memory each time I upload FlashForth to a chip. Seems like I should be able to get something equivalent to .NRWW directive with some combination of a named section and a section address in a linker script. > > I'm mildly curious what is really going on behind that XC8 .NRWW "addition". Unless they've somehow crossed the assembler/linker boundry, they must pass some extra information on to the linker...? Something that gives instructions to their own linker script, or to a modified Gnu LD? > > Anyway, sounds like I've finally got an excuse now to become an expert on linking. |
|
From: Christopher H. <chr...@li...> - 2021-05-04 12:36:08
|
I believe that I should be able to figure out linker scripts, though in the process I am getting stuck on another linker issue. I modified the XC directive to a simple .section NRWW and tried avr-gcc --verbose -mmcu=atmega328p -I. -D__ATmega328P__ -x assembler-with-cpp ff- libre.asm, in hopes that verbose output would dump the exact location of the default linker script, which I could use as a starting point. (According to gcc docs there is always a default linker script if non is specified.) Insteader linker dies with error avr-ld: /home/christopher/.guix- profile/avr/lib/avr5/crtatmega328p.o:(.init9+0x0): undefined reference to `main' I guess I need to figure out what to pass in to avr-gcc to fit the FlashForth entry paradigm. I looked for some guidance from avr-libc- users-manual, which has a lot of info on assembly and AVR, but the paradigm there seems to expect that you have a .text section, a main(), and maybe an .initN section. On Tue, 2021-05-04 at 13:06 +0300, Mikael Nordman wrote: > Hi Chris, > Here is the link for the answer I got from Microchip. They modified > the XC8 suite somehow. Maybe both AVR-AS and AVR-LD. > https://www.microchip.com/forums/m1170217.aspx > It is possible use a custom linker script instead, but I did not want > to maintain linker files for FlashForth. > If you come up with the linker scripts for the supported Atmegas, I > can add them into FlashForth. > BR Mikael > > > On 2021-05-04 09:01, Christopher Howard wrote: > > That you for your help. > > > > I'm no expert on the subject at this point, but it seems like there > > must be some better way to do this than filling a ton of memory > > each time I upload FlashForth to a chip. Seems like I should be > > able to get something equivalent to .NRWW directive with some > > combination of a named section and a section address in a linker > > script. > > > > I'm mildly curious what is really going on behind that XC8 .NRWW > > "addition". Unless they've somehow crossed the assembler/linker > > boundry, they must pass some extra information on to the linker...? > > Something that gives instructions to their own linker script, or to > > a modified Gnu LD? > > > > Anyway, sounds like I've finally got an excuse now to become an > > expert on linking. > > -- Christopher Howard blog: https://librehacker.com social: https://gnusocial.club/librehacker |
|
From: Mikael N. <mik...@fl...> - 2021-05-05 06:29:54
|
Have you tried the linker option "-nostartfiles" ? That is what I am using to skip linking the "crt.s" file. On 2021-05-04 15:35, Christopher Howard wrote: > avr-ld: /home/christopher/.guix-profile/avr/lib/avr5/crtatmega328p.o:(.init9+0x0): undefined reference to `main' |
|
From: Christopher H. <chr...@li...> - 2021-05-10 14:03:07
|
Hi, I think I'm getting fairly close to figuring this out. Aiming at
first for output on the 328p, I found the default avr5.x linker script
in avr-binutils sources. I seem to be able to accomplish what I want
adding a section like so:
.nrww ADDR(.text) + __TEXT_REGION_LENGTH__ - 0x400 :
{ PROVIDE (__nrww_start = .)
; *(.nrww) *(.nrww*) *(COMMON) PROVIDE (__nrww_end = .)
; } > text
and running
avr-gcc --verbose -mmcu=atmega328p -I. -D__ATmega328P__ -x assembler-
with-cpp -nostartfiles -T linker/avr5.x ff-libre.asm -o 328p.out
I was wondering though if you could help me with two questions:
(1) Is there a significant difference between the following?
.nrww ADDR(.text) + __TEXT_REGION_LENGTH__ - 0x400 :
and
.nrww ADDR(.text) + __TEXT_REGION_LENGTH__ - 0x400 : AT (ADDR
(.nrww))
(2) To make this work specifically for 328P, I had to adjust the linker
script line
__TEXT_REGION_LENGTH__ = DEFINED(__TEXT_REGION_LENGTH__) ?
__TEXT_REGION_LENGTH__ : 128K;
to
__TEXT_REGION_LENGTH__ = DEFINED(__TEXT_REGION_LENGTH__) ?
__TEXT_REGION_LENGTH__ : 32K;
I thought I should be able instead to just pass in
-D__TEXT_REGION_LENGTH__=32K to avr-gcc, but that does work. If I try
that the address location of .nrww comes out to just before 128K. Do
you know how to properly pass in this define?
I suspect that this is a problem because I am using an entirely new
linker script, rather than just passing in the new section to augment
the default script. But I haven't learned yet how to pass in just one
new section to the linker. Maybe if I was doing that, then avr-gcc
would have the correct region lengths set for the particular chip I had
specified.
On Wed, 2021-05-05 at 09:29 +0300, Mikael Nordman wrote:
> Have you tried the linker option "-nostartfiles" ? That is what I am
> using to skip linking the "crt.s" file.
>
> On 2021-05-04 15:35, Christopher Howard wrote:
> > avr-ld: /home/christopher/.guix-
> > profile/avr/lib/avr5/crtatmega328p.o:(.init9+0x0): undefined
> > reference to `main'
> >
--
Christopher Howard
blog: https://librehacker.com
social: https://gnusocial.club/librehacker
|
|
From: Christopher H. <chr...@li...> - 2021-05-10 20:30:48
|
Hi, I just wanted to confirm: in my reading of the license notices and text, it appeared that FlashForth is licensed as GPL-v3-only, as opposed to GPL-v3-or-later. I've got no problem with that, I just wanted to confirm that that is what is intended. Christopher Howard |
|
From: Christopher H. <chr...@li...> - 2021-05-23 01:57:04
|
Mikael, would you be willing to do a build of your xc8 code, for the 328p, and send me a copy of the objdump on your elf file (before you convert it to ihex)? `avr-objdump -D <elf-file>' is what I was looking for. You could email it to me or send me a link to a paste bin file. -- Christopher Howard blog: https://librehacker.com social: https://gnusocial.club/librehacker |
|
From: Peter J. <pe...@me...> - 2022-01-06 04:34:06
|
Mikael, many months have passed... No, asciidoctor produces HTML files that can be part of a static web site. I have put the rendered files in a github repository so that they appear at https://pajacobs-ghub.github.io/ These are essentially a port of the LateX documents, as they were in 2016, 2017. Quite a few little details need to be revised because I have not kept up with things since then, however, the current state are a good indication of how the revised documents might turn out. The source asciidoc files are in the repository with the LaTeX files at https://github.com/pajacobs-ghub/flashforth-docs Compared with the lateX source, I think that they will be much easier to maintain. Anyway, now that I have retired from the UQ payroll, I should find time to update the docs. Unfortunately, that also means that I no longer have access to eager thesis students who might be skilled in assembly language. Regards, Peter J. On 13/4/21 1:04 am, Mikael Nordman wrote: > Peter, sorry for my slow response. > > FF Atmega is now transformed to be compiled with MPLABX and XC8. > > Does ASCIIDOC require some server side support? I am not familiar with > it. > > It seems all peripherals, including flash and eeprom, are different on > the 4809. > Maybe you have an eager student to take on the task ? > > BR Mikael > > On 2021-03-28 13:49, Peter Jacobs wrote: >> Mikael, >> It would be interesting to have FF running on Atmega4809. I bought a >> few of those thinking that I would come back to doing some FF-related >> work this year (2021). It has been a while since I have had any time >> to play, so part of my plans included a refresh of the tutorial >> documents, possibly into ASCIIDOC source form. I expect that such a >> form would allow them to be more easily included on your web site and, >> also, that it would be easier to copy and paste code from them. >> Cheers, >> Peter J. |
|
From: Frans-Pieter V. <ner...@xs...> - 2022-01-08 15:10:27
|
Hi Peter, Thank you for putting effort in keeping the documentation of flashforth up to date. Also introducing asciidoc for writing documentation was interesting. I found out that gitlab and github support this format. With your cheatsheet I tried to seperate the Atmega from the PIC information. Did not succeed yet. Probably that TEX is still the best solution for compact cheatsheets. I'm learning FORTH playing along with flashforth on my arduino nano's. At my school I teach computer programming at 12/13/14 year olds students. The arduino IDE is what we use normally, as the examples and code are self-explanatory and easy to copy and paste. However, when I master FORTH enough I will introduce them to ForthForh. Learning to program in FORTH alongside an introduction about the inner workings of the microcontroller can form an interesting course. On the internet dye's can be found of decapped atmega328p's that show eeprom, ram, GPIO. This physical "evidence" that memory is not just an abstract concept but really exist inside the microcontroller is a strong didactic argument. Likewise in biology, when you teach about cells students prepare samples and study them under a microscope. And in advanced classes you even experiment with dna, the program off life. Decapping a microcontroller is mostly done with chemicals which makes it not very practical in class. However internet shows there are mechanical techniques to do this. Grinding the protective layer with find sandpaper and heating and breaking of the protective shell should be possible. So using the biological analogy, with FORTH you can reprogram artificial life. This perspective, focusing on the small and simple is the message of Chuck Moore's talk, minimizing energy is the key https://www.youtube.com/watch?v=0PclgBd6_Zs Greets, Frans-Pieter Vonck > Op 06-01-2022 05:18 schreef Peter Jacobs <pe...@me...>: > > > Mikael, > many months have passed... > > No, asciidoctor produces HTML files that can be part of a static web > site. I have put the rendered files in a github repository so that they > appear at https://pajacobs-ghub.github.io/ > > These are essentially a port of the LateX documents, as they were in > 2016, 2017. Quite a few little details need to be revised because I > have not kept up with things since then, however, the current state are > a good indication of how the revised documents might turn out. > > The source asciidoc files are in the repository with the LaTeX files at > https://github.com/pajacobs-ghub/flashforth-docs > Compared with the lateX source, I think that they will be much easier to > maintain. > > Anyway, now that I have retired from the UQ payroll, I should find time > to update the docs. Unfortunately, that also means that I no longer have > access to eager thesis students who might be skilled in assembly language. > > Regards, > Peter J. > > > On 13/4/21 1:04 am, Mikael Nordman wrote: > > Peter, sorry for my slow response. > > > > FF Atmega is now transformed to be compiled with MPLABX and XC8. > > > > Does ASCIIDOC require some server side support? I am not familiar with > > it. > > > > It seems all peripherals, including flash and eeprom, are different on > > the 4809. > > Maybe you have an eager student to take on the task ? > > > > BR Mikael > > > > On 2021-03-28 13:49, Peter Jacobs wrote: > >> Mikael, > >> It would be interesting to have FF running on Atmega4809. I bought a > >> few of those thinking that I would come back to doing some FF-related > >> work this year (2021). It has been a while since I have had any time > >> to play, so part of my plans included a refresh of the tutorial > >> documents, possibly into ASCIIDOC source form. I expect that such a > >> form would allow them to be more easily included on your web site and, > >> also, that it would be easier to copy and paste code from them. > >> Cheers, > >> Peter J. > > > > > _______________________________________________ > Flashforth-devel mailing list > Fla...@li... > https://lists.sourceforge.net/lists/listinfo/flashforth-devel |
|
From: Peter J. <pe...@me...> - 2022-01-10 11:49:26
|
Frans-Pieter, Yes, I thing that the LaTeX will be the easiest to get into a compact form on paper. For me, I think that Forth is excellent for accessing small scale computing but, for using many computing elements in parallel, I have chosen the D programming language and the MPI library for our Eilmer flow solver https://gdtk.uqcloud.net/ With several thousand x86_64 cores working for me, the power demand is many kilowatts and there are times that it seems wasteful. Cheers, Peter J. On 9/1/22 1:10 am, Frans-Pieter Vonck wrote: > Hi Peter, > > Thank you for putting effort in keeping the documentation of flashforth up to date. Also introducing asciidoc for writing documentation was interesting. I found out that gitlab and github support this format. With your cheatsheet I tried to seperate the Atmega from the PIC information. Did not succeed yet. Probably that TEX is still the best solution for compact cheatsheets. > > I'm learning FORTH playing along with flashforth on my arduino nano's. At my school I teach computer programming at 12/13/14 year olds students. The arduino IDE is what we use normally, as the examples and code are self-explanatory and easy to copy and paste. However, when I master FORTH enough I will introduce them to ForthForh. Learning to program in FORTH alongside an introduction about the inner workings of the microcontroller can form an interesting course. > On the internet dye's can be found of decapped atmega328p's that show eeprom, ram, GPIO. This physical "evidence" that memory is not just an abstract concept but really exist inside the microcontroller is a strong didactic argument. Likewise in biology, when you teach about cells students prepare samples and study them under a microscope. And in advanced classes you even experiment with dna, the program off life. > Decapping a microcontroller is mostly done with chemicals which makes it not very practical in class. However internet shows there are mechanical techniques to do this. Grinding the protective layer with find sandpaper and heating and breaking of the protective shell should be possible. So using the biological analogy, with FORTH you can reprogram artificial life. > > This perspective, focusing on the small and simple is the message of Chuck Moore's talk, minimizing energy is the key https://www.youtube.com/watch?v=0PclgBd6_Zs > > Greets, > > Frans-Pieter Vonck >> Op 06-01-2022 05:18 schreef Peter Jacobs <pe...@me...>: >> >> >> Mikael, >> many months have passed... >> >> No, asciidoctor produces HTML files that can be part of a static web >> site. I have put the rendered files in a github repository so that they >> appear at https://pajacobs-ghub.github.io/ >> >> These are essentially a port of the LateX documents, as they were in >> 2016, 2017. Quite a few little details need to be revised because I >> have not kept up with things since then, however, the current state are >> a good indication of how the revised documents might turn out. >> >> The source asciidoc files are in the repository with the LaTeX files at >> https://github.com/pajacobs-ghub/flashforth-docs >> Compared with the lateX source, I think that they will be much easier to >> maintain. >> >> Anyway, now that I have retired from the UQ payroll, I should find time >> to update the docs. Unfortunately, that also means that I no longer have >> access to eager thesis students who might be skilled in assembly language. >> >> Regards, >> Peter J. >> >> >> On 13/4/21 1:04 am, Mikael Nordman wrote: >>> Peter, sorry for my slow response. >>> >>> FF Atmega is now transformed to be compiled with MPLABX and XC8. >>> >>> Does ASCIIDOC require some server side support? I am not familiar with >>> it. >>> >>> It seems all peripherals, including flash and eeprom, are different on >>> the 4809. >>> Maybe you have an eager student to take on the task ? >>> >>> BR Mikael >>> >>> On 2021-03-28 13:49, Peter Jacobs wrote: >>>> Mikael, >>>> It would be interesting to have FF running on Atmega4809. I bought a >>>> few of those thinking that I would come back to doing some FF-related >>>> work this year (2021). It has been a while since I have had any time >>>> to play, so part of my plans included a refresh of the tutorial >>>> documents, possibly into ASCIIDOC source form. I expect that such a >>>> form would allow them to be more easily included on your web site and, >>>> also, that it would be easier to copy and paste code from them. >>>> Cheers, >>>> Peter J. >> >> >> >> _______________________________________________ >> Flashforth-devel mailing list >> Fla...@li... >> https://lists.sourceforge.net/lists/listinfo/flashforth-devel > > _______________________________________________ > Flashforth-devel mailing list > Fla...@li... > https://lists.sourceforge.net/lists/listinfo/flashforth-devel |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X