amforth-devel — Development discussion and user support

Re: [Amforth] What files are put in which locations to get 1-wire running on an ATmega2560 platform?

[Michael P. <mp...@rc...>]

Hello Erich,

Thank you!

This is very helpful.  Will give it a try over the weekend and see how
things play out.

Regards,

Michael


On 8/16/2013 10:39 AM, Erich Waelde wrote:
> Hello Michael,
>
> On 08/16/2013 01:01 AM, Michael Picco wrote:
>> Hello Erich,
>>
>> Thank you for the reply.  Can I safely assume the template file can be
>> copied/pasted to my new project and used as-is for 1wire?
>> The other question is about the other files required:
>> dict_appl
>> dict_appl_core
>> etc.
>> Should I be using the ones in the atmega2561 directory for creation of
>> atmega2560 project?
> Hmmm. I don't know. Looking at appl/atmega2561/atmega256.asm says:
>   ; Settings for the avr butterfly demo board
>   .include "macros.asm"
>   .include "device.asm"
>   ...
> You are not using the butterfly board, do you? Allthough I cannot
> exclude the possibility, that this is a leftover comment from
> somewhere else [1], I personally would start with a copy of
>   appl/template/
> and go from there. Crystal frequency and baud rate go into
>   appl/template/template.asm
> The device type goes into
>   appl/template/makefile
>
> If you are using Windows/Atmel Studio then consult Karl Lunt's
> documentation listet ond the amforth webpage [2] (I cannot help
> you out with Windows/Atmel Studio, sorry).
>
> Hope this helps,
> Erich
>
> [1] there is also the directory appl/avr-butterfly
>     for a project for that particular device.
> [2] http://amforth.sourceforge.net/ and
>     http://amforth.sourceforge.net/UG/amforth_user.html#user-guide
>
>
>
> ------------------------------------------------------------------------------
> Get 100% visibility into Java/.NET code with AppDynamics Lite!
> It's a free troubleshooting tool designed for production.
> Get down to code-level detail for bottlenecks, with <2% overhead. 
> Download for free and get started troubleshooting in minutes. 
> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel

[Amforth] addition to docs/ makefile

[Erich W. <ew....@na...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Matthias,

feel free to add the lines

  SP12=-c sp12 -i 10 -P /dev/parport0
  MKII=-c avrispmkII -P usb
  DRAGON=-c dragon_isp -P usb

to the makefile snippet in
http://amforth.sourceforge.net/UG/linux.html
Project Setup

and to trunk/appl/template/makefile

Cheers,
Erich
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIcBAEBAgAGBQJSDmdLAAoJEHx024vXVRNQGN0P/3IeE2nr3tCY8tQhcUvDyFZv
TdQjycL+g7S9AjR9Uf/tWL+F0NjYbYp/IuKRmsxllAuhNGVUphBgcxOYtS2uk+Hy
AJDwd5rmBwNfgdsYkckO0vP9fYrqWm61Hpe3GTGCfUa8blC8bCVohOhfLl67d5kO
OVZ7wVPEOOElDl6m7Q7xIYeLFccxmOQu+LDWr6TeKLSTa4WL22OkAn4MRqVUzM4e
Tqebx1NDPQsN//JJXr19SySyTJkJ7/u9t4A/WQDGIOYBqb3be40qHwjvmtNDCmsz
2vuLY2cBMK3/rSZg/QItDWCibkLZ3qvp8JDhrTuqU6GB5uA/0mNucX4di291FMhe
NSnjzXCTDYTy95qLpsqTpl1juAvgSIP+bVokBWI+5LU9hPjtLvLz2hLM7xz3fqFl
D8DmEiC1FD2zsH8Yq8s0ROBLcGg9ec376o1iA05duh1/8MytP61F6q0qOuvWNM5I
2uK8vgoK6f7j5HVytwQCsIxl4SUwzWuikqAgD/gaJPrspkB+ijWV6vnMhLEFm4Dt
wsJQiz9xypV8AjWbSneC7acnalw2Dnrflb0A3rQAokqnpkY8uWxqSIhV7L3tNYx5
Vips+hPqBo7NTtIfPgBD9dzWjdRfYe7moFR1Oas3lPelqK+ojQpNzXRQq9b6kSam
P5SPIZtOsXbcawEGzkS3
=w0Sa
-----END PGP SIGNATURE-----

Re: [Amforth] What files are put in which locations to get 1-wire running on an ATmega2560 platform?

[Erich W. <ew....@na...>]

Hello Michael,

On 08/16/2013 01:01 AM, Michael Picco wrote:
> Hello Erich,
> 
> Thank you for the reply.  Can I safely assume the template file can be
> copied/pasted to my new project and used as-is for 1wire?
> The other question is about the other files required:
> dict_appl
> dict_appl_core
> etc.
> Should I be using the ones in the atmega2561 directory for creation of
> atmega2560 project?

Hmmm. I don't know. Looking at appl/atmega2561/atmega256.asm says:
  ; Settings for the avr butterfly demo board
  .include "macros.asm"
  .include "device.asm"
  ...
You are not using the butterfly board, do you? Allthough I cannot
exclude the possibility, that this is a leftover comment from
somewhere else [1], I personally would start with a copy of
  appl/template/
and go from there. Crystal frequency and baud rate go into
  appl/template/template.asm
The device type goes into
  appl/template/makefile

If you are using Windows/Atmel Studio then consult Karl Lunt's
documentation listet ond the amforth webpage [2] (I cannot help
you out with Windows/Atmel Studio, sorry).

Hope this helps,
Erich

[1] there is also the directory appl/avr-butterfly
    for a project for that particular device.
[2] http://amforth.sourceforge.net/ and
    http://amforth.sourceforge.net/UG/amforth_user.html#user-guide

Re: [Amforth] What files are put in which locations to get 1-wire running on an ATmega2560 platform?

[Michael P. <mp...@rc...>]

Hello Erich,

Thank you for the reply.  Can I safely assume the template file can be
copied/pasted to my new project and used as-is for 1wire?
The other question is about the other files required:
dict_appl
dict_appl_core
etc.
Should I be using the ones in the atmega2561 directory for creation of
atmega2560 project?

Thanks again!

Michael



On 8/15/2013 12:53 PM, Erich Waelde wrote:
> Hello Michael,
>
> On 08/15/2013 09:24 PM, Michael Picco wrote:
>> I am using the avrispMK2 and Atmel Studio 5.0.
>>
>> ...  The other
>> question I have is the where in the 'project' I should include the 1wire
>> file from the driver directory?
> 1wire:
> If you look into appl/template/template.asm you will find the include
> near the end of the file together with 2 definitions (amforth 5.1)
> ------------------------------
> ...
> ; settings for 1wire interface, if desired
> .equ OW_PORT=PORTA
> .EQU OW_BIT=4
> .include "drivers/1wire.asm"
>
> ; include the whole source tree.
> .include "amforth.asm"
> -------------------------------
>
>
>
> Cheers,
> Erich
>
> ------------------------------------------------------------------------------
> Get 100% visibility into Java/.NET code with AppDynamics Lite!
> It's a free troubleshooting tool designed for production.
> Get down to code-level detail for bottlenecks, with <2% overhead. 
> Download for free and get started troubleshooting in minutes. 
> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Build recent amforth with avra

[Mark M. <m.m...@gm...>]

Erich,

your results confirm mine - even making the same move of "words/noop.asm" -
5.1 assembles but no terminal prompt (for the 328P).  With 5.0, simply
moving .include "drivers/usart_0.asm" above terminal settings in the
template.asm file eliminates the error and assembles working code.
I have tried your patch as well as Hannu's with the same result.  With 5.0,
the errors are:

Pass 1...
template.asm(45) : Error   : Found no label/variable/constant named bm_ASYNC
template.asm(49) : Error   : Found no label/variable/constant named
bm_ENABLE_TX

With Amforth5.1:

Pass 1...
../../core/drivers/usart_common.asm(28) : Error   : Found no
label/variable/constant named XT_NOOP


When you think about it - this seems odd.  Looking through the various
source code files in avra, in Pass 1 undefined labels/variable/constants
should be blacklisted (so I understand) and sorted out on Pass 2.  A
warning might be issued rather than an error halting assembly. Assembling
the same Amforth's (5.0 or 5.1) using wine+ avrasm(Studio4), warnings are
also issued for these "forward referenced" labels - but assembles ok.  This
might suggest that for whatever reason with avra a flag is throwing an
error rather than a warning... halting assembly.

I also found this patch :
http://www.mail-archive.com/avr...@li.../msg00077.html
which I edited into an instance of avra - thinking it might sort out the
issues.  It's not in the current repository files.  Avra compiled fine with
the patch... but the results for assembling Amforth are the same.

Mark


On Thu, Aug 15, 2013 at 3:23 PM, Marcin Cieslak <sa...@sa...> wrote:

> On Thu, 15 Aug 2013, Erich Waelde wrote:
>
> > All this just confirms that this particular version of avra is lacking
> > support for "forward references".
>
> Yeah, we need to get it right and quickly release a new version...
>
> //Marcin
>
>
> ------------------------------------------------------------------------------
> Get 100% visibility into Java/.NET code with AppDynamics Lite!
> It's a free troubleshooting tool designed for production.
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

Re: [Amforth] What files are put in which locations to get 1-wire running on an ATmega2560 platform?

[Erich W. <ew....@na...>]

Hello Michael,

On 08/15/2013 09:24 PM, Michael Picco wrote:
> I am using the avrispMK2 and Atmel Studio 5.0.
> 
> ...  The other
> question I have is the where in the 'project' I should include the 1wire
> file from the driver directory?

1wire:
If you look into appl/template/template.asm you will find the include
near the end of the file together with 2 definitions (amforth 5.1)
------------------------------
...
; settings for 1wire interface, if desired
.equ OW_PORT=PORTA
.EQU OW_BIT=4
.include "drivers/1wire.asm"

; include the whole source tree.
.include "amforth.asm"
-------------------------------



Cheers,
Erich

[Amforth] What files are put in which locations to get 1-wire running on an ATmega2560 platform?

[Michael P. <mp...@rc...>]

I am using the avrispMK2 and Atmel Studio 5.0.

I don't find an ASM file specifically for the 2560 and wonder if the
2561 file is the one I should being using.  The other
question I have is the where in the 'project' I should include the 1wire
file from the driver directory?

Any guidance is appreciated.

Regards,

Michael

Re: [Amforth] Build recent amforth with avra

[Marcin C. <sa...@sa...>]

On Thu, 15 Aug 2013, Erich Waelde wrote:

> All this just confirms that this particular version of avra is lacking
> support for "forward references".

Yeah, we need to get it right and quickly release a new version...

//Marcin

Re: [Amforth] Build recent amforth with avra

[Erich W. <ew....@na...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/13/2013 09:01 PM, Erich Waelde wrote:
> Hi all,
> 
> same experiment for atmega32, on amd64 host.
> same results, except that "usart_0.asm" is replaced by "usart.asm".
> 

same experiment with amforth-5.1
I'm using appl/template (not appl/arduino) in both cases.

Pass 1...
../../core/drivers/usart_common.asm(28) : Error   : Found no label/variable/constant named XT_NOOP

moving ``.include "words/noop.asm"'' out of ../../core/dict_minimum.inc
and into template.asm before the line  ``.include "drivers/usart.asm"''
does make this error go away, however, the result does not display the
ok-prompt.

Including words/1wire.asm back in results in
Pass 1...
Pass 2...
../../core/drivers/1wire.asm(53) : Error   : [Macro: ../../core/macros.asm: 142:] No register associated with Z
../../core/drivers/1wire.asm(53) : Error   : [Macro: ../../core/macros.asm: 142:] sbiw can only use registers R24, R26, R28 or R30
../../core/drivers/1wire.asm(61) : Error   : [Macro: ../../core/macros.asm: 142:] No register associated with Z
../../core/drivers/1wire.asm(61) : Error   : [Macro: ../../core/macros.asm: 142:] sbiw can only use registers R24, R26, R28 or R30
../../core/drivers/1wire.asm(73) : Error   : [Macro: ../../core/macros.asm: 142:] No register associated with Z
../../core/drivers/1wire.asm(73) : Error   : [Macro: ../../core/macros.asm: 142:] sbiw can only use registers R24, R26, R28 or R30
../../core/drivers/1wire.asm(145) : Error   : [Macro: ../../core/macros.asm: 142:] No register associated with Z
../../core/drivers/1wire.asm(145) : Error   : [Macro: ../../core/macros.asm: 142:] sbiw can only use registers R24, R26, R28 or R30
../../core/drivers/1wire.asm(155) : Error   : [Macro: ../../core/macros.asm: 142:] No register associated with Z
../../core/drivers/1wire.asm(155) : Error   : [Macro: ../../core/macros.asm: 142:] sbiw can only use registers R24, R26, R28 or R30
../../core/drivers/1wire.asm(155) : [Macro: ../../core/macros.asm: 142:] Maximum error count reached. Exiting...
done
Assembly aborted with 10 errors and 0 warnings.

All this just confirms that this particular version of avra is lacking
support for "forward references".


I'm not sure, whether I want to dig into avra just now ...

Cheers,
Erich
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIcBAEBAgAGBQJSDRvLAAoJEHx024vXVRNQP1sP/jA5uoQz3f+coPmmJoD9vXKl
4sjgKeBYxPu/WUAK5XZ7Tv4e685Zy0m4Y9oW1gIbQ1qjieNE/HuDbaPpbofHMFli
VfT3bb8YGVd6+oojOQ7OPX4XlaxWyqNIEWEUBzLVfHzFEkMImzEtuZWhi4E17uLq
9Sda9Cnjue9Zd47Aog67Fb7MxkMOvaP33plMxq+RyBvwy4Yz+FgChcs7hAoOl7sv
XLkAxbVOvTikT7xDOqpDtaWbgk8lKENl6nPGTRD7/Fd1puitAAYnbr55ZpIdRgOk
0HZDygJYm7Z5UOkbTmS+Kvz1PUfQYHRms65uxjUZ4tDNbewB1Seze21j/4wmUpdO
Y41jFV1VyNx7TNRpB6bjaAc3dlrU2155JTo++EfifhX+u3+xpfrySmp79T8JYHCf
ElkhhBaHQ6Fnf65YQfoloPMSxWGANWkDd5ZcCQRmOaGD5/kXSmYxSE139VosVHar
4qwPDg5lDZRUsZSQ746R2GoDiWHlf8jgcWuKTe/6UUYPULWhdTWLqmFByr9ZoWk+
MbPOX0lYVaDctCSJ7VvegyND59EjVAX4AaVMm7mDoo/NdNv4RbklfXCbLSETDMHj
GH7Y4B3zhGa7+ERUAQUz81bzcS4GIEt981GrxrLIt1HyE2atXMTeoVLpqqASqXUq
gMslNs+c1aZ7ExEw0bI7
=A7/m
-----END PGP SIGNATURE-----

Re: [Amforth] Build recent amforth with avra

[Hannu V. <vu...@ms...>]

The read_args has const in C and not in h file.

I didn't test my build as I just went to wine route for easines.

 And I commented out the dead code. I thought it could be easier to make PKGBUILD file for Arch Linux

I even made patch.

https://sourceforge.net/p/avra/mailman/message/31229619/

Best regards,
Hannu Vuolasaho 		 	   		  

Re: [Amforth] Build recent amforth with avra

[Erich W. <ew....@na...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all,

same experiment for atmega32, on amd64 host.
same results, except that "usart_0.asm" is replaced by "usart.asm".


On 08/13/2013 03:21 PM, Mark Malmros wrote:
> Assembling Amforth5.0 for an Atmega328P using the Raspberry Pi avra
> instance:
> 
> Untaring  Amforth.5.0.tar.gz, I copied the "Appnotes" directory from
> Studio4 (on my desktop) into the core directory.
> Using template.asm edited for the atmega328p, set  ".equ F_CPU = 16000000"
> (and and commented out the 1wire interface settings and added '.include
> "devices/atmega328p/device.inc"' to the dict_appl.inc file):
> 
> pi@raspberrypi /home/amforth50/appl/template $ sudo avra  -fI  -I
> ../../core -I ../../core/devices/ -I ../../core/Appnotes  template.asm
> 
> Pass 1...
> template.asm(42) : Error   : Found no label/variable/constant named bm_ASYNC
> template.asm(46) : Error   : Found no label/variable/constant named
> bm_ENABLE_TX
> 
> Looking in core/devices/usart_0.asm, both bm_ASYNC and bm_ENABLE_TX are
> there with .equ.
> A simplistic analysis suggests that there is an issue with forward
> referencing with avra that avrasm.exe or Studio4 doesn't have.  Thinking
> that the .include order is important, I simply moved
> 
> .include "drivers/usart_0.asm"
> 
> just above
> 
> .set WANT_ISR_RX = 1 ; interrupt driven receive
> .set WANT_ISR_TX = 0 ; send slowly but with less code space
> 
> in my template file and re-assembled with avra...
> 
> Pass 1...
> Pass 2...
> ../../core/words/brackettick.asm(6) : Warning : A .DB segment with an odd
> number of bytes is detected. A zero byte is added.
> ../../core/words/tick.asm(6) : Warning : A .DB segment with an odd number
> of bytes is detected. A zero byte is added.
> done
> 
> Assembly complete with no errors (2 warnings).
> Segment usage:
>    Code      :      4223 words (8446 bytes)
>    Data      :       221 bytes
>    EEPROM    :        82 bytes
> 
> 
> The resulting template.hex and template.eep.hex ( > template.eep) were
> flashed on to a Atmega328P using avrdude.  The terminal prompt came up!  I
> loaded atmega328p.frt and a simple stepper motor program and it ran.
> 

I compared the hexfiles created via wine+avrasm2 and avra. template.eep.hex
files are identical. template.hex files are different in 2 bytes only:

$ diff -wu 1_avrasm2_template.hex template.hex 
- --- 1_avrasm2_template.hex	2013-08-13 20:34:45.795745430 +0200
+++ template.hex	2013-08-13 20:36:38.354121499 +0200
@@ -20,7 +20,7 @@
 :02004C000BD0D7
 :1000500009D00008000400701500080041546D65C7
 :04006000676133326F
- -:040000000C94E50572
+:02000000E4C555
 :100064000A920FB60A920F900F900A9400926000C1
 :1000740009900FBE09906894089505FF665F637048
 :10008400750000000A38413800C04138A8002438FF

Turns out this is the PFA_COLD jump (look in .lst files)

wine+avrasm2:
- -----------------------------------------------------
                 .set pc_ = pc
                 .org $0000
000000 940c 05e5   jmp_ PFA_COLD
                 .org pc_
                 .include "drivers/generic-isr.asm"
- -----------------------------------------------------
avra:
- -----------------------------------------------------
          .set pc_ = pc
          .org $0000
C:000000   +    jmp_ PFA_COLD
         

          .ifdef PFA_COLD
          .if (PFA_COLD-pc > 2040) || (pc-PFA_COLD>2040)
C:000000 c5e4      rjmp PFA_COLD
          .endif
          .else
          .org pc_
- -----------------------------------------------------

Seems like avra expands jmp_ to rjmp, whereas avrasm2 does it differently.
The controller talks to me in both cases, so this is not a significant
difference --- cold is executed in any case.

Cheers,
Erich




-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIcBAEBAgAGBQJSCoJwAAoJEHx024vXVRNQcNUP/3ZYj519+fPO6E96XsSXVO0H
A/C00r9YvkgVt6PJ1sOJKF3+yhbQmUo01rwtd0Rdrsml0PYN46GILbNr3VvbZY/S
4FGaLgNuaOXBVLC0E3tp3d0PP6l72PUlx4Ysvey+3v5IbSR9ZqQ2pTW5Fpg2Stai
vkx/rYOcSI0Cp49NL4oDCpJ658GUCc0hlwjUaSEnyUu5tDlHZPyjMzsR+ql+K+F+
D+7oU6QY+dy8HSWCntUvg8qOz/f+eUUc1W3d11Nqgg1Nt1PhKeD40XZpc8mGDBYc
i7iW/vz2hRggYuPTzohVKgTpTXXDGWs/JSiu8jx4LWBukH6qPMoKSIKDodMKFb2Q
Dyjt49BVzVrGmAnQ4K1xpLCzXkIplTKk6T3dfqjYQCqXy0nXNTN46D2BLac8XHOS
AX9WSP7kcATxR68KDeCJzKTFJpFn20ZRhp4EIF73SpC5tvxud/0l4X8KfrDkdGf0
6E4R3c3bnPkBxAzwmkWTztj2wN0LV/ZEjOmDlAIENpgJ8iQMMjhQEeColAzNUnfN
gpQ4BwjiKwTqdTissZuybWVBfb82jORWdCpWt/NHabZNbMzFJgujVMLRWDjSKGvA
sObpnmBDQEbIG3Y0pUuQQUuN5Z/+I5QqBU0bix9H9Bhk8p10P3ccazegFAfrzS59
E7+6QamNcEr/znx3eF+C
=kfG+
-----END PGP SIGNATURE-----

Re: [Amforth] Build recent amforth with avra

[Mark M. <m.m...@gm...>]

Assembling Amforth5.0 for an Atmega328P using the Raspberry Pi avra
instance:

Untaring  Amforth.5.0.tar.gz, I copied the "Appnotes" directory from
Studio4 (on my desktop) into the core directory.
Using template.asm edited for the atmega328p, set  ".equ F_CPU = 16000000"
(and and commented out the 1wire interface settings and added '.include
"devices/atmega328p/device.inc"' to the dict_appl.inc file):

pi@raspberrypi /home/amforth50/appl/template $ sudo avra  -fI  -I
../../core -I ../../core/devices/ -I ../../core/Appnotes  template.asm

Pass 1...
template.asm(42) : Error   : Found no label/variable/constant named bm_ASYNC
template.asm(46) : Error   : Found no label/variable/constant named
bm_ENABLE_TX

Looking in core/devices/usart_0.asm, both bm_ASYNC and bm_ENABLE_TX are
there with .equ.
A simplistic analysis suggests that there is an issue with forward
referencing with avra that avrasm.exe or Studio4 doesn't have.  Thinking
that the .include order is important, I simply moved

.include "drivers/usart_0.asm"

just above

.set WANT_ISR_RX = 1 ; interrupt driven receive
.set WANT_ISR_TX = 0 ; send slowly but with less code space

in my template file and re-assembled with avra...

Pass 1...
Pass 2...
../../core/words/brackettick.asm(6) : Warning : A .DB segment with an odd
number of bytes is detected. A zero byte is added.
../../core/words/tick.asm(6) : Warning : A .DB segment with an odd number
of bytes is detected. A zero byte is added.
done

Assembly complete with no errors (2 warnings).
Segment usage:
   Code      :      4223 words (8446 bytes)
   Data      :       221 bytes
   EEPROM    :        82 bytes


The resulting template.hex and template.eep.hex ( > template.eep) were
flashed on to a Atmega328P using avrdude.  The terminal prompt came up!  I
loaded atmega328p.frt and a simple stepper motor program and it ran.


Amforth-5.1 to be continued...


On Tue, Aug 13, 2013 at 7:05 AM, Mark Malmros <m.m...@gm...> wrote:

> Erich, Keith, Enoch, Christian and all other interested parties...
>
> To double check my luck I started with a clean Debian image
> (2013-wheezy-raspian.img (armhf)) on a Raspberry pi  which comes complete
> with all the build utilities - having only to add automake...
>
> $cd /home
> $ sudo apt-get install automake
>     ...
>
> $ git clone git://avra.git.sourceforge.net/gitroot/avra/avra
>     ...
> $ cd avra/src
>     ...
> After a number of iterations and failed compilations, the following works:
> As the git clone had no configure.in, I copied that file from the
> avra-1.3.0 tarball as well as Makefile.am.  (The Makefile.linux in
> src/makefiles wouldn't build the target for reasons I can't figure out -
> the avra-1.3.0 Makefile.am is wonderfully simple!)  For both files I
> literally copied and pasted from my Desktop into the pi.
>
> $sudo nano configure.in
>     ...
> $sudo nano Makefile.am
>     ...
>
> I followed the compile instructions for linux  in the avra/doc/README.txt
> file running everything as sudo:
>
> $ sudo aclocal
> $ sudo autoconf
> $ sudo automake -a
>
> automake complains about missing files NEWS, README, AUTHORS, and
> ChangeLog. (Seriously?)
>
> $ sudo touch NEWS
> $ sudo touch README
> $ sudo touch AUTHORS
> $ sudo touch ChangeLog
>
> $ sudo automake -a
> $ sudo ./configure
> $ sudo make && sudo make install
>
> compilation fails with similar (not the same) terminal messages as Erich
> shows... ending in:
>
>
> args.c:124:1: error: conflicting types for ‘read_args’
> args.h:77:5: note: previous declaration of ‘read_args’ was here
> make: *** [args.o] Error 1
>
> Why two declarations for 'read_args'?
> Using nano, I simply commented out line 77 in args.h (at the end of the
> file):
>
> struct args *alloc_args(int arg_count);
> // int read_args(struct args *args, int argc, const char *argv[]);
> int add_arg(struct data_list **last_data, const char *argv);
> void free_args(struct args *args);
> void define_arg(struct args *args, int index, int type, char letter, char
> *long$
> void define_arg_int(struct args *args, int index, int type, char letter,
> char *$
>
> #endif /* end of args.h */
>
> $ sudo make
>
> pi@raspberrypi /home/avra/src $ sudo make install
> make[1]: Entering directory `/home/avra/src'
>  /bin/mkdir -p '/usr/local/bin'
>   /usr/bin/install -c avra '/usr/local/bin'
> make[1]: Nothing to be done for `install-data-am'.
> make[1]: Leaving directory `/home/avra/src'
>
> occasionally things work.
>
> To be continued...
>
>
>
> On Mon, Aug 12, 2013 at 4:12 PM, Erich Waelde <ew....@na...> wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Hello Mark and all,
>>
>> On 08/07/2013 01:55 PM, Mark Malmros wrote:
>> > If my "working" avra under Debian for Amforth 5.0 is of interest to
>> anyone,
>> > I'll track down the minor changes I've made and pass them along. Be
>> > forewarned: as with life, I have no idea how I got here or what I am
>> doing,
>> > but occasionally it all seems to work.
>>
>> Yes, definitely of interest. Now, to make this more interesting to anyone
>> else lurking on the list, I thought, I'll give it a try:
>>
>> $ mkdir tmp.avra; cd tmp.avra
>> $ cp -a ...path-to-my-old-avra/ avra-1
>> $ ls
>> avra-1
>> $ mkdir avra-2
>> $ cd avra-2
>> $ git clone git://avra.git.sourceforge.net/gitroot/avra/avra
>> Cloning into 'avra'...
>> remote: Counting objects: 528, done.
>> remote: Compressing objects: 100% (435/435), done.
>> remote: Total 528 (delta 276), reused 286 (delta 75)
>> Receiving objects: 100% (528/528), 1.03 MiB | 442.00 KiB/s, done.
>> Resolving deltas: 100% (276/276), done.
>> Checking connectivity... done
>> $ cd avra/src
>> $ > make -f makefiles/Makefile.linux
>> gcc -Wall -O3   -c -o avra.o avra.c
>> avra.c: In function ‘main’:
>> avra.c:136:5: warning: passing argument 3 of ‘read_args’ from
>> incompatible pointer type [enabled by default]
>>      c = read_args(args, argc, argv);
>>      ^
>> In file included from avra.c:34:0:
>> args.h:77:5: note: expected ‘const char **’ but argument is of type ‘char
>> **’
>>  int read_args(struct args *args, int argc, const char *argv[]);
>>      ^
>> gcc -Wall -O3   -c -o device.o device.c
>> gcc -Wall -O3   -c -o parser.o parser.c
>> gcc -Wall -O3   -c -o expr.o expr.c
>> gcc -Wall -O3   -c -o mnemonic.o mnemonic.c
>> gcc -Wall -O3   -c -o directiv.o directiv.c
>> gcc -Wall -O3   -c -o macro.o macro.c
>> gcc -Wall -O3   -c -o file.o file.c
>> gcc -Wall -O3   -c -o map.o map.c
>> gcc -Wall -O3   -c -o coff.o coff.c
>> coff.c: In function ‘write_coff_file’:
>> coff.c:167:37: warning: variable ‘StringsOffset’ set but not used
>> [-Wunused-but-set-variable]
>>      int LinesOffset, SymbolsOffset, StringsOffset, RawOffset;
>>                                      ^
>> coff.c: In function ‘parse_stabs’:
>> coff.c:495:49: warning: variable ‘pEnd’ set but not used
>> [-Wunused-but-set-variable]
>>      char *pString, *p2, *p3, *p4, *p5, *pType, *pEnd, *pp, *pJoined;
>>                                                  ^
>> coff.c: In function ‘parse_stabn’:
>> coff.c:646:52: warning: variable ‘pEnd’ set but not used
>> [-Wunused-but-set-variable]
>>      char *p1, *p2, *p3, *p4, *pLabel, *pFunction, *pEnd;
>>                                                     ^
>> gcc -Wall -O3   -c -o args.o args.c
>> args.c:124:1: error: conflicting types for ‘read_args’
>>  read_args(struct args *args, int argc, char *argv[])
>>  ^
>> In file included from args.c:33:0:
>> args.h:77:5: note: previous declaration of ‘read_args’ was here
>>  int read_args(struct args *args, int argc, const char *argv[]);
>>      ^
>> make: *** [args.o] Error 1
>>
>> So it does not build. :-(
>> But my old stuff does, so let's look at the diff
>>
>> # --- start-of-diff ------------------------------------
>> diff -Naur avra-2/avra/src/args.c avra-1/src/args.c
>> - --- avra-2/avra/src/args.c    2013-08-12 21:45:02.811727443 +0200
>> +++ avra-1/src/args.c   2012-02-28 20:25:32.555406533 +0100
>> @@ -52,7 +52,7 @@
>>  }
>>
>>  const struct dataset *
>> - -match_dataset(const struct dataset datasets[], const char *key)
>> +match_dataset(const struct dataset const datasets[], const char *key)
>>  {
>>         const struct dataset *ds;
>>         for (ds = datasets;
>> @@ -66,7 +66,7 @@
>>  }
>>
>>  void
>> - -print_dataset(const struct dataset datasets[])
>> +print_dataset(const struct dataset const datasets[])
>>  {
>>         const struct dataset *ds;
>>         printf("either ");
>> @@ -121,7 +121,7 @@
>>  }
>>
>>  int
>> - -read_args(struct args *args, int argc, char *argv[])
>> +read_args(struct args *args, int argc, const char *argv[])
>>  {
>>         int i, j, k, ok, i_old;
>>         struct data_list **last_data;
>> diff -Naur avra-2/avra/src/avra.c avra-1/src/avra.c
>> - --- avra-2/avra/src/avra.c    2013-08-12 21:45:02.811727443 +0200
>> +++ avra-1/src/avra.c   2012-09-30 15:35:12.557700410 +0200
>> @@ -38,6 +38,7 @@
>>  #define debug 0
>>
>>  const char *title =
>> +  "avra: 2012-08-16 ew a6e8b2957953810dae6467eeb4905bfc5ea6c33e\n"
>>    "AVRA: advanced AVR macro assembler Version %i.%i.%i Build %i (%s)\n"
>>    "Copyright (C) 1998-2010. Check out README file for more info\n"
>>    "\n"
>> @@ -95,7 +96,7 @@
>>  static struct segment_info DATA_SEG;
>>  static struct segment_info EEPROM_SEG;
>>
>> - -int main(int argc, char *argv[])
>> +int main(int argc, const char *argv[])
>>  {
>>    int show_usage = False;
>>    struct prog_info *pi;
>> diff -Naur avra-2/avra/src/device.c avra-1/src/device.c
>> - --- avra-2/avra/src/device.c  2013-08-12 21:45:02.811727443 +0200
>> +++ avra-1/src/device.c 2012-09-30 15:34:49.199369981 +0200
>> @@ -104,6 +104,7 @@
>>    { "ATmega328P",       16384,     0x100,     2048,   1024,
>> DF_NO_EICALL|DF_NO_EIJMP|DF_NO_ELPM|DF_NO_ESPM},
>>    {   "ATmega32",       16384,      0x60,     2048,   1024,
>> DF_NO_EICALL|DF_NO_EIJMP|DF_NO_ELPM|DF_NO_ESPM},
>>    {  "ATmega603",       32768,      0x60,     4096,   2048,
>> DF_NO_EICALL|DF_NO_EIJMP|DF_NO_MUL|DF_NO_MOVW|DF_NO_LPM_X|DF_NO_ELPM|DF_NO_SPM|DF_NO_ESPM|DF_NO_BREAK},
>> +  { "ATmega644P",       32768,     0x100,     4096,   2048,
>> DF_NO_EICALL|DF_NO_EIJMP|DF_NO_ELPM|DF_NO_ESPM},
>>    {  "ATmega103",       65536,      0x60,     4096,   4096,
>> DF_NO_EICALL|DF_NO_EIJMP|DF_NO_MUL|DF_NO_MOVW|DF_NO_LPM_X|DF_NO_ELPM_X|DF_NO_SPM|DF_NO_ESPM|DF_NO_BREAK},
>> // 137 - EICALL - EIJMP - MUL(6) - MOVW - LPM_X(2) - ELPM_X(2) - SPM - ESPM
>> - BREAK = 121
>>    {  "ATmega104",       65536,      0x60,     4096,   4096,
>> DF_NO_EICALL|DF_NO_EIJMP|DF_NO_ESPM}, // Old name for mega128
>>    {  "ATmega128",       65536,     0x100,     4096,   4096,
>> DF_NO_EICALL|DF_NO_EIJMP|DF_NO_ESPM}, // 137 - EICALL - EIJMP - ESPM = 134
>> (Data sheet says 133 but it's wrong)
>> @@ -145,6 +146,7 @@
>>                 if(!nocase_strcmp(name, device_list[i].name)) {
>>                         LastDevice=i;
>>              def_dev(pi);
>> +
>>  pi->dseg->lo_addr=device_list[LastDevice].ram_start; /* fixme: set
>> ram_start in the correct place */
>>                         return(&device_list[i]);
>>                 }
>>                 i++;
>> @@ -188,8 +190,7 @@
>>         return(True);
>>  }
>>
>> - -void
>> - -list_devices(void)
>> +void list_devices()
>>  {
>>    int i = 1;
>>    printf("Device name | Flash size | RAM start | RAM size | EEPROM size
>> |  Supported\n"
>> diff -Naur avra-2/avra/src/stdextra.c avra-1/src/stdextra.c
>> - --- avra-2/avra/src/stdextra.c        2013-08-12 21:45:02.811727443
>> +0200
>> +++ avra-1/src/stdextra.c       2012-02-28 20:25:32.559406275 +0100
>> @@ -191,7 +191,7 @@
>>  snprint(char ** buf, size_t *limit, const char * const str) {
>>         int rc;
>>         rc = snprintf(*buf, *limit, "%s", str);
>> - -     if (rc <= (int)*limit)
>> +       if (rc <= *limit)
>>                 *buf += rc, *limit -= rc;
>>         else
>>                 *limit = 0;
>> @@ -213,7 +213,7 @@
>>                         snprint(&ptr, &limit, ", ");
>>         }
>>         rc = snprintf(ptr, limit, "\"%s\"", str_list[i]);
>> - -     if (rc <= (int)limit)
>> +       if (rc <= limit)
>>                 ptr += rc, limit -= rc;
>>         else
>>                 limit = 0;
>> @@ -222,8 +222,7 @@
>>  }
>>
>>  void
>> - -test_print_list(void)
>> - -{
>> +test_print_list() {
>>         static const char * const test_value[] = {
>>                 "DEFAULT",
>>                 "IGNORE",
>> # --- end-of-diff --------------------------------------
>>
>> args.c has received a few "const" modifiers.
>> avra.c has a change in the version message and one const
>> stdextra.c has a missing cast (int) and a changed function header.
>>
>> all of these look innocent.
>>
>> devices.c has received an additional entry for atmega644p and
>> the fix I already mentioned.
>>
>> Applying this patch makes avra compile.
>>
>> $ make -f makefiles/Makefile.linux
>> gcc -Wall -O3   -c -o avra.o avra.c
>> gcc -Wall -O3   -c -o device.o device.c
>> gcc -Wall -O3   -c -o parser.o parser.c
>> gcc -Wall -O3   -c -o expr.o expr.c
>> gcc -Wall -O3   -c -o mnemonic.o mnemonic.c
>> gcc -Wall -O3   -c -o directiv.o directiv.c
>> gcc -Wall -O3   -c -o macro.o macro.c
>> gcc -Wall -O3   -c -o file.o file.c
>> gcc -Wall -O3   -c -o map.o map.c
>> gcc -Wall -O3   -c -o coff.o coff.c
>> coff.c: In function ‘write_coff_file’:
>> coff.c:167:37: warning: variable ‘StringsOffset’ set but not used
>> [-Wunused-but-set-variable]
>>      int LinesOffset, SymbolsOffset, StringsOffset, RawOffset;
>>                                      ^
>> coff.c: In function ‘parse_stabs’:
>> coff.c:495:49: warning: variable ‘pEnd’ set but not used
>> [-Wunused-but-set-variable]
>>      char *pString, *p2, *p3, *p4, *p5, *pType, *pEnd, *pp, *pJoined;
>>                                                  ^
>> coff.c: In function ‘parse_stabn’:
>> coff.c:646:52: warning: variable ‘pEnd’ set but not used
>> [-Wunused-but-set-variable]
>>      char *p1, *p2, *p3, *p4, *pLabel, *pFunction, *pEnd;
>>                                                     ^
>> gcc -Wall -O3   -c -o args.o args.c
>> gcc -Wall -O3   -c -o stdextra.o stdextra.c
>> gcc -static -o avra avra.o device.o parser.o expr.o mnemonic.o directiv.o
>> macro.o file.o map.o coff.o args.o stdextra.o -s
>>
>> $ ./avra --version
>> avra: 2012-08-16 ew a6e8b2957953810dae6467eeb4905bfc5ea6c33e
>> AVRA: advanced AVR macro assembler Version 1.3.0 Build 1 (8 May 2010)
>> Copyright (C) 1998-2010. Check out README file for more info
>>
>>    AVRA is an open source assembler for Atmel AVR microcontroller family
>>    It can be used as a replacement of 'AVRASM32.EXE' the original
>> assembler
>>    shipped with AVR Studio. We do not guarantee full compatibility for
>> avra.
>>
>>    AVRA comes with NO WARRANTY, to the extent permitted by law.
>>    You may redistribute copies of avra under the terms
>>    of the GNU General Public License.
>>    For more information about these matters, see the files named COPYING.
>>
>> I did this on 3 systems: Debian/unstable on amd64 and i486;
>> Debian/squeeze on armv7l (ecafe)
>> with identical results so far.
>>
>> So next I need to compile amforth with the executable and compare
>> the hexfiles to those of wine+avrasm2.
>>
>> Cheers,
>> Erich
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.14 (GNU/Linux)
>> Comment: Using GnuPG with Icedove - http://www.enigmail.net/
>>
>> iQIcBAEBAgAGBQJSCUGyAAoJEHx024vXVRNQ46wP/irQeEEi4WtFl0BNVd5L7fD6
>> ZaZGr/lGYZz/4QBlGDWvGCXRfa6d0moJrMrlfgcQ9JirkN+ElVfIRA9E5Vc3KvQF
>> f3vjjA0EQ3tnrOG9IxQXG1P6lbLIU0Jib4z3S4PLuyPd/SyBoHcWTV207hRfqP9p
>> hRwCUMXJw3tEgQz4mzE/3nLddKnyELMsEbsqWAvaRwYne5tKKN8upwQzSkz2AG73
>> XPgzhkN05O3SPVkF/ghe+8myF0KSPAxW0LZqlG5i0RYGx/KG9BLQONjyjoThjfJB
>> mCv7wQ0unWZPrSLkvFgCcwHJHTLF+BwP+iazq4eZkpeBi+rRwwgwHTKfaIDOj6lN
>> 5u0p+pFFyQKoSYmDzawSVha0Pw72HscHLNzbgVOXOrRvX6DiZcCJ08Fl/BGTky7p
>> gQj+zCHH/aYzte/CF0ypqef01NxnOl+un4RvOgGdkz8su2d1umaHpa/PTDEkZ8di
>> gWrlO1Cr1IIzLOZlxNtJ9ObvuKUwVL83XN920lLm+4w2O0G8VR++B4bw1QtshRQt
>> fo3wJjan8OO/H5AHzd68f8OgkpObjwkhx6m6HDT21WigUsBEMQ36P2+cAS+qq6uo
>> vifigAQ90AajZfNslCNJxe4fOi7LKMHbixRzfxZG7VOwJwwkOQ35BAS/6GOZZcZc
>> 1+wua+OTJPYbRRlnkfKH
>> =gs2Q
>> -----END PGP SIGNATURE-----
>>
>>
>> ------------------------------------------------------------------------------
>> Get 100% visibility into Java/.NET code with AppDynamics Lite!
>> It's a free troubleshooting tool designed for production.
>> Get down to code-level detail for bottlenecks, with <2% overhead.
>> Download for free and get started troubleshooting in minutes.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Amforth-devel mailing list for http://amforth.sf.net/
>> Amf...@li...
>> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>>
>
>

Re: [Amforth] Build recent amforth with avra

[Mark M. <m.m...@gm...>]

Erich, Keith, Enoch, Christian and all other interested parties...

To double check my luck I started with a clean Debian image
(2013-wheezy-raspian.img (armhf)) on a Raspberry pi  which comes complete
with all the build utilities - having only to add automake...

$cd /home
$ sudo apt-get install automake
    ...
$ git clone git://avra.git.sourceforge.net/gitroot/avra/avra
    ...
$ cd avra/src
    ...
After a number of iterations and failed compilations, the following works:
As the git clone had no configure.in, I copied that file from the
avra-1.3.0 tarball as well as Makefile.am.  (The Makefile.linux in
src/makefiles wouldn't build the target for reasons I can't figure out -
the avra-1.3.0 Makefile.am is wonderfully simple!)  For both files I
literally copied and pasted from my Desktop into the pi.

$sudo nano configure.in
    ...
$sudo nano Makefile.am
    ...

I followed the compile instructions for linux  in the avra/doc/README.txt
file running everything as sudo:

$ sudo aclocal
$ sudo autoconf
$ sudo automake -a

automake complains about missing files NEWS, README, AUTHORS, and
ChangeLog. (Seriously?)

$ sudo touch NEWS
$ sudo touch README
$ sudo touch AUTHORS
$ sudo touch ChangeLog

$ sudo automake -a
$ sudo ./configure
$ sudo make && sudo make install

compilation fails with similar (not the same) terminal messages as Erich
shows... ending in:

args.c:124:1: error: conflicting types for ‘read_args’
args.h:77:5: note: previous declaration of ‘read_args’ was here
make: *** [args.o] Error 1

Why two declarations for 'read_args'?
Using nano, I simply commented out line 77 in args.h (at the end of the
file):

struct args *alloc_args(int arg_count);
// int read_args(struct args *args, int argc, const char *argv[]);
int add_arg(struct data_list **last_data, const char *argv);
void free_args(struct args *args);
void define_arg(struct args *args, int index, int type, char letter, char
*long$
void define_arg_int(struct args *args, int index, int type, char letter,
char *$

#endif /* end of args.h */

$ sudo make

pi@raspberrypi /home/avra/src $ sudo make install
make[1]: Entering directory `/home/avra/src'
 /bin/mkdir -p '/usr/local/bin'
  /usr/bin/install -c avra '/usr/local/bin'
make[1]: Nothing to be done for `install-data-am'.
make[1]: Leaving directory `/home/avra/src'

occasionally things work.

To be continued...



On Mon, Aug 12, 2013 at 4:12 PM, Erich Waelde <ew....@na...> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello Mark and all,
>
> On 08/07/2013 01:55 PM, Mark Malmros wrote:
> > If my "working" avra under Debian for Amforth 5.0 is of interest to
> anyone,
> > I'll track down the minor changes I've made and pass them along. Be
> > forewarned: as with life, I have no idea how I got here or what I am
> doing,
> > but occasionally it all seems to work.
>
> Yes, definitely of interest. Now, to make this more interesting to anyone
> else lurking on the list, I thought, I'll give it a try:
>
> $ mkdir tmp.avra; cd tmp.avra
> $ cp -a ...path-to-my-old-avra/ avra-1
> $ ls
> avra-1
> $ mkdir avra-2
> $ cd avra-2
> $ git clone git://avra.git.sourceforge.net/gitroot/avra/avra
> Cloning into 'avra'...
> remote: Counting objects: 528, done.
> remote: Compressing objects: 100% (435/435), done.
> remote: Total 528 (delta 276), reused 286 (delta 75)
> Receiving objects: 100% (528/528), 1.03 MiB | 442.00 KiB/s, done.
> Resolving deltas: 100% (276/276), done.
> Checking connectivity... done
> $ cd avra/src
> $ > make -f makefiles/Makefile.linux
> gcc -Wall -O3   -c -o avra.o avra.c
> avra.c: In function ‘main’:
> avra.c:136:5: warning: passing argument 3 of ‘read_args’ from incompatible
> pointer type [enabled by default]
>      c = read_args(args, argc, argv);
>      ^
> In file included from avra.c:34:0:
> args.h:77:5: note: expected ‘const char **’ but argument is of type ‘char
> **’
>  int read_args(struct args *args, int argc, const char *argv[]);
>      ^
> gcc -Wall -O3   -c -o device.o device.c
> gcc -Wall -O3   -c -o parser.o parser.c
> gcc -Wall -O3   -c -o expr.o expr.c
> gcc -Wall -O3   -c -o mnemonic.o mnemonic.c
> gcc -Wall -O3   -c -o directiv.o directiv.c
> gcc -Wall -O3   -c -o macro.o macro.c
> gcc -Wall -O3   -c -o file.o file.c
> gcc -Wall -O3   -c -o map.o map.c
> gcc -Wall -O3   -c -o coff.o coff.c
> coff.c: In function ‘write_coff_file’:
> coff.c:167:37: warning: variable ‘StringsOffset’ set but not used
> [-Wunused-but-set-variable]
>      int LinesOffset, SymbolsOffset, StringsOffset, RawOffset;
>                                      ^
> coff.c: In function ‘parse_stabs’:
> coff.c:495:49: warning: variable ‘pEnd’ set but not used
> [-Wunused-but-set-variable]
>      char *pString, *p2, *p3, *p4, *p5, *pType, *pEnd, *pp, *pJoined;
>                                                  ^
> coff.c: In function ‘parse_stabn’:
> coff.c:646:52: warning: variable ‘pEnd’ set but not used
> [-Wunused-but-set-variable]
>      char *p1, *p2, *p3, *p4, *pLabel, *pFunction, *pEnd;
>                                                     ^
> gcc -Wall -O3   -c -o args.o args.c
> args.c:124:1: error: conflicting types for ‘read_args’
>  read_args(struct args *args, int argc, char *argv[])
>  ^
> In file included from args.c:33:0:
> args.h:77:5: note: previous declaration of ‘read_args’ was here
>  int read_args(struct args *args, int argc, const char *argv[]);
>      ^
> make: *** [args.o] Error 1
>
> So it does not build. :-(
> But my old stuff does, so let's look at the diff
>
> # --- start-of-diff ------------------------------------
> diff -Naur avra-2/avra/src/args.c avra-1/src/args.c
> - --- avra-2/avra/src/args.c    2013-08-12 21:45:02.811727443 +0200
> +++ avra-1/src/args.c   2012-02-28 20:25:32.555406533 +0100
> @@ -52,7 +52,7 @@
>  }
>
>  const struct dataset *
> - -match_dataset(const struct dataset datasets[], const char *key)
> +match_dataset(const struct dataset const datasets[], const char *key)
>  {
>         const struct dataset *ds;
>         for (ds = datasets;
> @@ -66,7 +66,7 @@
>  }
>
>  void
> - -print_dataset(const struct dataset datasets[])
> +print_dataset(const struct dataset const datasets[])
>  {
>         const struct dataset *ds;
>         printf("either ");
> @@ -121,7 +121,7 @@
>  }
>
>  int
> - -read_args(struct args *args, int argc, char *argv[])
> +read_args(struct args *args, int argc, const char *argv[])
>  {
>         int i, j, k, ok, i_old;
>         struct data_list **last_data;
> diff -Naur avra-2/avra/src/avra.c avra-1/src/avra.c
> - --- avra-2/avra/src/avra.c    2013-08-12 21:45:02.811727443 +0200
> +++ avra-1/src/avra.c   2012-09-30 15:35:12.557700410 +0200
> @@ -38,6 +38,7 @@
>  #define debug 0
>
>  const char *title =
> +  "avra: 2012-08-16 ew a6e8b2957953810dae6467eeb4905bfc5ea6c33e\n"
>    "AVRA: advanced AVR macro assembler Version %i.%i.%i Build %i (%s)\n"
>    "Copyright (C) 1998-2010. Check out README file for more info\n"
>    "\n"
> @@ -95,7 +96,7 @@
>  static struct segment_info DATA_SEG;
>  static struct segment_info EEPROM_SEG;
>
> - -int main(int argc, char *argv[])
> +int main(int argc, const char *argv[])
>  {
>    int show_usage = False;
>    struct prog_info *pi;
> diff -Naur avra-2/avra/src/device.c avra-1/src/device.c
> - --- avra-2/avra/src/device.c  2013-08-12 21:45:02.811727443 +0200
> +++ avra-1/src/device.c 2012-09-30 15:34:49.199369981 +0200
> @@ -104,6 +104,7 @@
>    { "ATmega328P",       16384,     0x100,     2048,   1024,
> DF_NO_EICALL|DF_NO_EIJMP|DF_NO_ELPM|DF_NO_ESPM},
>    {   "ATmega32",       16384,      0x60,     2048,   1024,
> DF_NO_EICALL|DF_NO_EIJMP|DF_NO_ELPM|DF_NO_ESPM},
>    {  "ATmega603",       32768,      0x60,     4096,   2048,
> DF_NO_EICALL|DF_NO_EIJMP|DF_NO_MUL|DF_NO_MOVW|DF_NO_LPM_X|DF_NO_ELPM|DF_NO_SPM|DF_NO_ESPM|DF_NO_BREAK},
> +  { "ATmega644P",       32768,     0x100,     4096,   2048,
> DF_NO_EICALL|DF_NO_EIJMP|DF_NO_ELPM|DF_NO_ESPM},
>    {  "ATmega103",       65536,      0x60,     4096,   4096,
> DF_NO_EICALL|DF_NO_EIJMP|DF_NO_MUL|DF_NO_MOVW|DF_NO_LPM_X|DF_NO_ELPM_X|DF_NO_SPM|DF_NO_ESPM|DF_NO_BREAK},
> // 137 - EICALL - EIJMP - MUL(6) - MOVW - LPM_X(2) - ELPM_X(2) - SPM - ESPM
> - BREAK = 121
>    {  "ATmega104",       65536,      0x60,     4096,   4096,
> DF_NO_EICALL|DF_NO_EIJMP|DF_NO_ESPM}, // Old name for mega128
>    {  "ATmega128",       65536,     0x100,     4096,   4096,
> DF_NO_EICALL|DF_NO_EIJMP|DF_NO_ESPM}, // 137 - EICALL - EIJMP - ESPM = 134
> (Data sheet says 133 but it's wrong)
> @@ -145,6 +146,7 @@
>                 if(!nocase_strcmp(name, device_list[i].name)) {
>                         LastDevice=i;
>              def_dev(pi);
> +
>  pi->dseg->lo_addr=device_list[LastDevice].ram_start; /* fixme: set
> ram_start in the correct place */
>                         return(&device_list[i]);
>                 }
>                 i++;
> @@ -188,8 +190,7 @@
>         return(True);
>  }
>
> - -void
> - -list_devices(void)
> +void list_devices()
>  {
>    int i = 1;
>    printf("Device name | Flash size | RAM start | RAM size | EEPROM size |
>  Supported\n"
> diff -Naur avra-2/avra/src/stdextra.c avra-1/src/stdextra.c
> - --- avra-2/avra/src/stdextra.c        2013-08-12 21:45:02.811727443 +0200
> +++ avra-1/src/stdextra.c       2012-02-28 20:25:32.559406275 +0100
> @@ -191,7 +191,7 @@
>  snprint(char ** buf, size_t *limit, const char * const str) {
>         int rc;
>         rc = snprintf(*buf, *limit, "%s", str);
> - -     if (rc <= (int)*limit)
> +       if (rc <= *limit)
>                 *buf += rc, *limit -= rc;
>         else
>                 *limit = 0;
> @@ -213,7 +213,7 @@
>                         snprint(&ptr, &limit, ", ");
>         }
>         rc = snprintf(ptr, limit, "\"%s\"", str_list[i]);
> - -     if (rc <= (int)limit)
> +       if (rc <= limit)
>                 ptr += rc, limit -= rc;
>         else
>                 limit = 0;
> @@ -222,8 +222,7 @@
>  }
>
>  void
> - -test_print_list(void)
> - -{
> +test_print_list() {
>         static const char * const test_value[] = {
>                 "DEFAULT",
>                 "IGNORE",
> # --- end-of-diff --------------------------------------
>
> args.c has received a few "const" modifiers.
> avra.c has a change in the version message and one const
> stdextra.c has a missing cast (int) and a changed function header.
>
> all of these look innocent.
>
> devices.c has received an additional entry for atmega644p and
> the fix I already mentioned.
>
> Applying this patch makes avra compile.
>
> $ make -f makefiles/Makefile.linux
> gcc -Wall -O3   -c -o avra.o avra.c
> gcc -Wall -O3   -c -o device.o device.c
> gcc -Wall -O3   -c -o parser.o parser.c
> gcc -Wall -O3   -c -o expr.o expr.c
> gcc -Wall -O3   -c -o mnemonic.o mnemonic.c
> gcc -Wall -O3   -c -o directiv.o directiv.c
> gcc -Wall -O3   -c -o macro.o macro.c
> gcc -Wall -O3   -c -o file.o file.c
> gcc -Wall -O3   -c -o map.o map.c
> gcc -Wall -O3   -c -o coff.o coff.c
> coff.c: In function ‘write_coff_file’:
> coff.c:167:37: warning: variable ‘StringsOffset’ set but not used
> [-Wunused-but-set-variable]
>      int LinesOffset, SymbolsOffset, StringsOffset, RawOffset;
>                                      ^
> coff.c: In function ‘parse_stabs’:
> coff.c:495:49: warning: variable ‘pEnd’ set but not used
> [-Wunused-but-set-variable]
>      char *pString, *p2, *p3, *p4, *p5, *pType, *pEnd, *pp, *pJoined;
>                                                  ^
> coff.c: In function ‘parse_stabn’:
> coff.c:646:52: warning: variable ‘pEnd’ set but not used
> [-Wunused-but-set-variable]
>      char *p1, *p2, *p3, *p4, *pLabel, *pFunction, *pEnd;
>                                                     ^
> gcc -Wall -O3   -c -o args.o args.c
> gcc -Wall -O3   -c -o stdextra.o stdextra.c
> gcc -static -o avra avra.o device.o parser.o expr.o mnemonic.o directiv.o
> macro.o file.o map.o coff.o args.o stdextra.o -s
>
> $ ./avra --version
> avra: 2012-08-16 ew a6e8b2957953810dae6467eeb4905bfc5ea6c33e
> AVRA: advanced AVR macro assembler Version 1.3.0 Build 1 (8 May 2010)
> Copyright (C) 1998-2010. Check out README file for more info
>
>    AVRA is an open source assembler for Atmel AVR microcontroller family
>    It can be used as a replacement of 'AVRASM32.EXE' the original assembler
>    shipped with AVR Studio. We do not guarantee full compatibility for
> avra.
>
>    AVRA comes with NO WARRANTY, to the extent permitted by law.
>    You may redistribute copies of avra under the terms
>    of the GNU General Public License.
>    For more information about these matters, see the files named COPYING.
>
> I did this on 3 systems: Debian/unstable on amd64 and i486; Debian/squeeze
> on armv7l (ecafe)
> with identical results so far.
>
> So next I need to compile amforth with the executable and compare
> the hexfiles to those of wine+avrasm2.
>
> Cheers,
> Erich
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.14 (GNU/Linux)
> Comment: Using GnuPG with Icedove - http://www.enigmail.net/
>
> iQIcBAEBAgAGBQJSCUGyAAoJEHx024vXVRNQ46wP/irQeEEi4WtFl0BNVd5L7fD6
> ZaZGr/lGYZz/4QBlGDWvGCXRfa6d0moJrMrlfgcQ9JirkN+ElVfIRA9E5Vc3KvQF
> f3vjjA0EQ3tnrOG9IxQXG1P6lbLIU0Jib4z3S4PLuyPd/SyBoHcWTV207hRfqP9p
> hRwCUMXJw3tEgQz4mzE/3nLddKnyELMsEbsqWAvaRwYne5tKKN8upwQzSkz2AG73
> XPgzhkN05O3SPVkF/ghe+8myF0KSPAxW0LZqlG5i0RYGx/KG9BLQONjyjoThjfJB
> mCv7wQ0unWZPrSLkvFgCcwHJHTLF+BwP+iazq4eZkpeBi+rRwwgwHTKfaIDOj6lN
> 5u0p+pFFyQKoSYmDzawSVha0Pw72HscHLNzbgVOXOrRvX6DiZcCJ08Fl/BGTky7p
> gQj+zCHH/aYzte/CF0ypqef01NxnOl+un4RvOgGdkz8su2d1umaHpa/PTDEkZ8di
> gWrlO1Cr1IIzLOZlxNtJ9ObvuKUwVL83XN920lLm+4w2O0G8VR++B4bw1QtshRQt
> fo3wJjan8OO/H5AHzd68f8OgkpObjwkhx6m6HDT21WigUsBEMQ36P2+cAS+qq6uo
> vifigAQ90AajZfNslCNJxe4fOi7LKMHbixRzfxZG7VOwJwwkOQ35BAS/6GOZZcZc
> 1+wua+OTJPYbRRlnkfKH
> =gs2Q
> -----END PGP SIGNATURE-----
>
>
> ------------------------------------------------------------------------------
> Get 100% visibility into Java/.NET code with AppDynamics Lite!
> It's a free troubleshooting tool designed for production.
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

Re: [Amforth] Build recent amforth with avra

[Erich W. <ew....@na...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello Mark and all,

On 08/07/2013 01:55 PM, Mark Malmros wrote:
> If my "working" avra under Debian for Amforth 5.0 is of interest to anyone,
> I'll track down the minor changes I've made and pass them along. Be
> forewarned: as with life, I have no idea how I got here or what I am doing,
> but occasionally it all seems to work.

Yes, definitely of interest. Now, to make this more interesting to anyone
else lurking on the list, I thought, I'll give it a try:

$ mkdir tmp.avra; cd tmp.avra
$ cp -a ...path-to-my-old-avra/ avra-1
$ ls
avra-1
$ mkdir avra-2
$ cd avra-2
$ git clone git://avra.git.sourceforge.net/gitroot/avra/avra
Cloning into 'avra'...
remote: Counting objects: 528, done.        
remote: Compressing objects: 100% (435/435), done.        
remote: Total 528 (delta 276), reused 286 (delta 75)        
Receiving objects: 100% (528/528), 1.03 MiB | 442.00 KiB/s, done.
Resolving deltas: 100% (276/276), done.
Checking connectivity... done
$ cd avra/src
$ > make -f makefiles/Makefile.linux
gcc -Wall -O3   -c -o avra.o avra.c
avra.c: In function ‘main’:
avra.c:136:5: warning: passing argument 3 of ‘read_args’ from incompatible pointer type [enabled by default]
     c = read_args(args, argc, argv);
     ^
In file included from avra.c:34:0:
args.h:77:5: note: expected ‘const char **’ but argument is of type ‘char **’
 int read_args(struct args *args, int argc, const char *argv[]);
     ^
gcc -Wall -O3   -c -o device.o device.c
gcc -Wall -O3   -c -o parser.o parser.c
gcc -Wall -O3   -c -o expr.o expr.c
gcc -Wall -O3   -c -o mnemonic.o mnemonic.c
gcc -Wall -O3   -c -o directiv.o directiv.c
gcc -Wall -O3   -c -o macro.o macro.c
gcc -Wall -O3   -c -o file.o file.c
gcc -Wall -O3   -c -o map.o map.c
gcc -Wall -O3   -c -o coff.o coff.c
coff.c: In function ‘write_coff_file’:
coff.c:167:37: warning: variable ‘StringsOffset’ set but not used [-Wunused-but-set-variable]
     int LinesOffset, SymbolsOffset, StringsOffset, RawOffset;
                                     ^
coff.c: In function ‘parse_stabs’:
coff.c:495:49: warning: variable ‘pEnd’ set but not used [-Wunused-but-set-variable]
     char *pString, *p2, *p3, *p4, *p5, *pType, *pEnd, *pp, *pJoined;
                                                 ^
coff.c: In function ‘parse_stabn’:
coff.c:646:52: warning: variable ‘pEnd’ set but not used [-Wunused-but-set-variable]
     char *p1, *p2, *p3, *p4, *pLabel, *pFunction, *pEnd;
                                                    ^
gcc -Wall -O3   -c -o args.o args.c
args.c:124:1: error: conflicting types for ‘read_args’
 read_args(struct args *args, int argc, char *argv[])
 ^
In file included from args.c:33:0:
args.h:77:5: note: previous declaration of ‘read_args’ was here
 int read_args(struct args *args, int argc, const char *argv[]);
     ^
make: *** [args.o] Error 1

So it does not build. :-(
But my old stuff does, so let's look at the diff

# --- start-of-diff ------------------------------------
diff -Naur avra-2/avra/src/args.c avra-1/src/args.c
- --- avra-2/avra/src/args.c	2013-08-12 21:45:02.811727443 +0200
+++ avra-1/src/args.c	2012-02-28 20:25:32.555406533 +0100
@@ -52,7 +52,7 @@
 }
 
 const struct dataset *
- -match_dataset(const struct dataset datasets[], const char *key)
+match_dataset(const struct dataset const datasets[], const char *key)
 {
 	const struct dataset *ds;
 	for (ds = datasets;
@@ -66,7 +66,7 @@
 }
 
 void
- -print_dataset(const struct dataset datasets[])
+print_dataset(const struct dataset const datasets[])
 {
 	const struct dataset *ds;
 	printf("either ");
@@ -121,7 +121,7 @@
 }
 
 int
- -read_args(struct args *args, int argc, char *argv[])
+read_args(struct args *args, int argc, const char *argv[])
 {
 	int i, j, k, ok, i_old;
 	struct data_list **last_data;
diff -Naur avra-2/avra/src/avra.c avra-1/src/avra.c
- --- avra-2/avra/src/avra.c	2013-08-12 21:45:02.811727443 +0200
+++ avra-1/src/avra.c	2012-09-30 15:35:12.557700410 +0200
@@ -38,6 +38,7 @@
 #define debug 0
 
 const char *title =
+  "avra: 2012-08-16 ew a6e8b2957953810dae6467eeb4905bfc5ea6c33e\n"
   "AVRA: advanced AVR macro assembler Version %i.%i.%i Build %i (%s)\n"
   "Copyright (C) 1998-2010. Check out README file for more info\n"
   "\n"
@@ -95,7 +96,7 @@
 static struct segment_info DATA_SEG;
 static struct segment_info EEPROM_SEG;
 
- -int main(int argc, char *argv[])
+int main(int argc, const char *argv[])
 {
   int show_usage = False;
   struct prog_info *pi;
diff -Naur avra-2/avra/src/device.c avra-1/src/device.c
- --- avra-2/avra/src/device.c	2013-08-12 21:45:02.811727443 +0200
+++ avra-1/src/device.c	2012-09-30 15:34:49.199369981 +0200
@@ -104,6 +104,7 @@
   { "ATmega328P",       16384,     0x100,     2048,   1024, DF_NO_EICALL|DF_NO_EIJMP|DF_NO_ELPM|DF_NO_ESPM},
   {   "ATmega32",       16384,      0x60,     2048,   1024, DF_NO_EICALL|DF_NO_EIJMP|DF_NO_ELPM|DF_NO_ESPM},
   {  "ATmega603",       32768,      0x60,     4096,   2048, DF_NO_EICALL|DF_NO_EIJMP|DF_NO_MUL|DF_NO_MOVW|DF_NO_LPM_X|DF_NO_ELPM|DF_NO_SPM|DF_NO_ESPM|DF_NO_BREAK},
+  { "ATmega644P",       32768,     0x100,     4096,   2048, DF_NO_EICALL|DF_NO_EIJMP|DF_NO_ELPM|DF_NO_ESPM},
   {  "ATmega103",       65536,      0x60,     4096,   4096, DF_NO_EICALL|DF_NO_EIJMP|DF_NO_MUL|DF_NO_MOVW|DF_NO_LPM_X|DF_NO_ELPM_X|DF_NO_SPM|DF_NO_ESPM|DF_NO_BREAK}, // 137 - EICALL - EIJMP - MUL(6) - MOVW - LPM_X(2) - ELPM_X(2) - SPM - ESPM - BREAK = 121
   {  "ATmega104",       65536,      0x60,     4096,   4096, DF_NO_EICALL|DF_NO_EIJMP|DF_NO_ESPM}, // Old name for mega128
   {  "ATmega128",       65536,     0x100,     4096,   4096, DF_NO_EICALL|DF_NO_EIJMP|DF_NO_ESPM}, // 137 - EICALL - EIJMP - ESPM = 134 (Data sheet says 133 but it's wrong)
@@ -145,6 +146,7 @@
 		if(!nocase_strcmp(name, device_list[i].name)) {
 			LastDevice=i;
             def_dev(pi);
+                        pi->dseg->lo_addr=device_list[LastDevice].ram_start; /* fixme: set ram_start in the correct place */
 			return(&device_list[i]);
 		}
 		i++;
@@ -188,8 +190,7 @@
 	return(True);
 }
 
- -void
- -list_devices(void)
+void list_devices()
 {
   int i = 1;
   printf("Device name | Flash size | RAM start | RAM size | EEPROM size |  Supported\n"
diff -Naur avra-2/avra/src/stdextra.c avra-1/src/stdextra.c
- --- avra-2/avra/src/stdextra.c	2013-08-12 21:45:02.811727443 +0200
+++ avra-1/src/stdextra.c	2012-02-28 20:25:32.559406275 +0100
@@ -191,7 +191,7 @@
 snprint(char ** buf, size_t *limit, const char * const str) {
 	int rc;
 	rc = snprintf(*buf, *limit, "%s", str);
- -	if (rc <= (int)*limit) 
+	if (rc <= *limit) 
 		*buf += rc, *limit -= rc;
 	else
 		*limit = 0;
@@ -213,7 +213,7 @@
 			snprint(&ptr, &limit, ", ");
 	}
 	rc = snprintf(ptr, limit, "\"%s\"", str_list[i]);
- -	if (rc <= (int)limit)
+	if (rc <= limit)
 		ptr += rc, limit -= rc;
 	else
 		limit = 0;
@@ -222,8 +222,7 @@
 }
 
 void
- -test_print_list(void)
- -{
+test_print_list() {
 	static const char * const test_value[] = {
 		"DEFAULT",
 		"IGNORE",
# --- end-of-diff --------------------------------------

args.c has received a few "const" modifiers.
avra.c has a change in the version message and one const 
stdextra.c has a missing cast (int) and a changed function header.

all of these look innocent.

devices.c has received an additional entry for atmega644p and
the fix I already mentioned.

Applying this patch makes avra compile.

$ make -f makefiles/Makefile.linux
gcc -Wall -O3   -c -o avra.o avra.c
gcc -Wall -O3   -c -o device.o device.c
gcc -Wall -O3   -c -o parser.o parser.c
gcc -Wall -O3   -c -o expr.o expr.c
gcc -Wall -O3   -c -o mnemonic.o mnemonic.c
gcc -Wall -O3   -c -o directiv.o directiv.c
gcc -Wall -O3   -c -o macro.o macro.c
gcc -Wall -O3   -c -o file.o file.c
gcc -Wall -O3   -c -o map.o map.c
gcc -Wall -O3   -c -o coff.o coff.c
coff.c: In function ‘write_coff_file’:
coff.c:167:37: warning: variable ‘StringsOffset’ set but not used [-Wunused-but-set-variable]
     int LinesOffset, SymbolsOffset, StringsOffset, RawOffset;
                                     ^
coff.c: In function ‘parse_stabs’:
coff.c:495:49: warning: variable ‘pEnd’ set but not used [-Wunused-but-set-variable]
     char *pString, *p2, *p3, *p4, *p5, *pType, *pEnd, *pp, *pJoined;
                                                 ^
coff.c: In function ‘parse_stabn’:
coff.c:646:52: warning: variable ‘pEnd’ set but not used [-Wunused-but-set-variable]
     char *p1, *p2, *p3, *p4, *pLabel, *pFunction, *pEnd;
                                                    ^
gcc -Wall -O3   -c -o args.o args.c
gcc -Wall -O3   -c -o stdextra.o stdextra.c
gcc -static -o avra avra.o device.o parser.o expr.o mnemonic.o directiv.o macro.o file.o map.o coff.o args.o stdextra.o -s

$ ./avra --version
avra: 2012-08-16 ew a6e8b2957953810dae6467eeb4905bfc5ea6c33e
AVRA: advanced AVR macro assembler Version 1.3.0 Build 1 (8 May 2010)
Copyright (C) 1998-2010. Check out README file for more info

   AVRA is an open source assembler for Atmel AVR microcontroller family
   It can be used as a replacement of 'AVRASM32.EXE' the original assembler
   shipped with AVR Studio. We do not guarantee full compatibility for avra.

   AVRA comes with NO WARRANTY, to the extent permitted by law.
   You may redistribute copies of avra under the terms
   of the GNU General Public License.
   For more information about these matters, see the files named COPYING.

I did this on 3 systems: Debian/unstable on amd64 and i486; Debian/squeeze on armv7l (ecafe)
with identical results so far.

So next I need to compile amforth with the executable and compare
the hexfiles to those of wine+avrasm2.

Cheers,
Erich
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIcBAEBAgAGBQJSCUGyAAoJEHx024vXVRNQ46wP/irQeEEi4WtFl0BNVd5L7fD6
ZaZGr/lGYZz/4QBlGDWvGCXRfa6d0moJrMrlfgcQ9JirkN+ElVfIRA9E5Vc3KvQF
f3vjjA0EQ3tnrOG9IxQXG1P6lbLIU0Jib4z3S4PLuyPd/SyBoHcWTV207hRfqP9p
hRwCUMXJw3tEgQz4mzE/3nLddKnyELMsEbsqWAvaRwYne5tKKN8upwQzSkz2AG73
XPgzhkN05O3SPVkF/ghe+8myF0KSPAxW0LZqlG5i0RYGx/KG9BLQONjyjoThjfJB
mCv7wQ0unWZPrSLkvFgCcwHJHTLF+BwP+iazq4eZkpeBi+rRwwgwHTKfaIDOj6lN
5u0p+pFFyQKoSYmDzawSVha0Pw72HscHLNzbgVOXOrRvX6DiZcCJ08Fl/BGTky7p
gQj+zCHH/aYzte/CF0ypqef01NxnOl+un4RvOgGdkz8su2d1umaHpa/PTDEkZ8di
gWrlO1Cr1IIzLOZlxNtJ9ObvuKUwVL83XN920lLm+4w2O0G8VR++B4bw1QtshRQt
fo3wJjan8OO/H5AHzd68f8OgkpObjwkhx6m6HDT21WigUsBEMQ36P2+cAS+qq6uo
vifigAQ90AajZfNslCNJxe4fOi7LKMHbixRzfxZG7VOwJwwkOQ35BAS/6GOZZcZc
1+wua+OTJPYbRRlnkfKH
=gs2Q
-----END PGP SIGNATURE-----

Re: [Amforth] Build recent amforth with avra

[Keith A. <ca...@pi...>]

On Wed, 2013-08-07 at 07:55 -0400, Mark Malmros wrote:
> If my "working" avra under Debian for Amforth 5.0 is of interest to anyone,
> I'll track down the minor changes I've made and pass them along. Be
> forewarned: as with life, I have no idea how I got here or what I am doing,
> but occasionally it all seems to work.

Although I'm not sure when I'll get the time to work with it, this is
definitely of interest to me.

      --- Keith

Re: [Amforth] Build recent amforth with avra

[Enoch <ix...@ho...>]

Hello AmForth-ers:

Like all I went through AVRA GIT first and had to dump it as it did not
produce correct code (in my at90can128 case). Candidly, I don't see a
reason to maintain an avrasm2.exe compatible when the latter works well
under Linux wine.

Making AmForth avr-as compatible (from binutils) is a worthy cause
though. How about making AmForth avr-gcc compatible, i.e., being able to
implement a complex word in C :-)

Cheers, Enoch.

Erich Waelde <ew....@na...> writes:

> Hello Christian,
>
>
> On 08/07/2013 02:16 PM, Christian Kellermann wrote:
>> * Matthias Trute <mt...@we...> [130804 20:57]:
>>> Hi,
>>>
>>>
>>>> I am trying to build the 5.1 release for an arduino uni with avra
>>>> on a 32bit OpenBSD.
>>>
>>> According to Wine HQ openBSD may support wine (to some degree).
>>> Avra is a hopeless case. Unfortunately.
>> 
>> No it's broken and it also does not work on non x86 HW.
>> 
>>>> Does this message ring a bell for someone on here? Did anyone build
>>>> this release with avra successfully?  I remember that last time I
>>>> needed to do this (amforth-4.2 IIRC) I needed a specific avra version
>>>> from git. Unfortunately I have lost my notes so I am unable to
>>>> reproduce my steps taken back then.
>>>
>>> Tried the search option of the mailing list?
>> 
>> I have been subscribed to this list for over a year now and could
>> not find a post related to this question. Hence myself asking. If
>> that's too much traffic I will refrain from consulting this list
>> in the future.
>> 
>> Sorry for the noise.
> No need to be sorry or give up.
>
>
> I did experiment with avra more than a year ago.
>
> - I needed avra from the git repo
>
>   $ git reflog
>   930634e HEAD@{0}: checkout: moving from c132dae7be7eca3c26c4881f431467f737b9d88f to master
>   c132dae HEAD@{1}: checkout: moving from master to c132dae7be7ec
>   930634e HEAD@{2}: commit: added git hash to Version info
>   a6e8b29 HEAD@{3}: pull: Fast-forward
>   b296ddf HEAD@{4}: clone: from git://avra.git.sourceforge.net/gitroot/avra/avra
>
>   Do not waste your time with officially packaged avra binaries.
>
>
> - In my directory tree I find .hex/.eep.hex files produced with avra and wine+avrasm2 for atmega32.
>
>   - amforth 4.2: 
>     both sets are equal, so this did work at the time
>
>   - amforth 4.5: 
>     this needed a change in the amforth sources, because avra deals badly with
>     forward references. But I would need to dig into my source trees to find the difference
>     (something with _doplusloop)
>
>     nonetheless both sets are equal, so this did work at the time as well.
>
>   - amforth 4.9:
>     I tried this version again, but it did not work. It seems that I gave up at this point.
>
>
> Please note that I did this with _atmega_32_.
> I have tried to use avra for atmega644. The device is listed in the device
> table (source code of avra), the size of flash is correct, but it was not
> used! So I added a very ugly hack to avra (not understanding where the
> correct place in the code would be) and after that a better hex file for
> atmega644 was produced.
>
> Looking at you first post to the list, it seems that atmega328p (arduino) is
> just not supported.
> /me checking sources:
> $ grep 328 src/device.c.bak 
>   { "ATmega328P",       16384,     0x100,     2048,   1024, DF_NO_EICALL|DF_NO_EIJMP|DF_NO_ELPM|DF_NO_ESPM},
> -----------------------------------^^^^^^
> This is the same size problem as with the 644.
>
>
> $ git diff device.c
> diff --git a/src/device.c b/src/device.c
> index 2dc4171..470678c 100644
> --- a/src/device.c
> +++ b/src/device.c
> @@ -104,6 +104,7 @@ struct device device_list[] =
>    { "ATmega328P",       16384,     0x100,     2048,   1024, DF_NO_EICALL|DF_NO_EIJMP|DF_NO_ELPM|DF_NO_ESPM},
>    {   "ATmega32",       16384,      0x60,     2048,   1024, DF_NO_EICALL|DF_NO_EIJMP|DF_NO_ELPM|DF_NO_ESPM},
>    {  "ATmega603",       32768,      0x60,     4096,   2048, DF_NO_EICALL|DF_NO_EIJMP|DF_NO_MUL|DF_NO_MOVW|DF_NO_LPM_X|DF_NO_ELPM|DF_NO_SPM|DF_NO_ESPM|DF_NO_BREAK},
> +  { "ATmega644P",       32768,     0x100,     4096,   2048, DF_NO_EICALL|DF_NO_EIJMP|DF_NO_ELPM|DF_NO_ESPM},
>    {  "ATmega103",       65536,      0x60,     4096,   4096, DF_NO_EICALL|DF_NO_EIJMP|DF_NO_MUL|DF_NO_MOVW|DF_NO_LPM_X|DF_NO_ELPM_X|DF_NO_SPM|DF_NO_ESPM|DF_NO_BREAK}, // 137 - EICALL - EIJMP - MUL(6) - MOVW - LPM_X(2) - ELPM_X(2) - SPM - ESPM - BREAK = 121
>    {  "ATmega104",       65536,      0x60,     4096,   4096, DF_NO_EICALL|DF_NO_EIJMP|DF_NO_ESPM}, // Old name for mega128
>    {  "ATmega128",       65536,     0x100,     4096,   4096, DF_NO_EICALL|DF_NO_EIJMP|DF_NO_ESPM}, // 137 - EICALL - EIJMP - ESPM = 134 (Data sheet says 133 but it's wrong)
> @@ -145,6 +146,7 @@ struct device *get_device(struct prog_info *pi, char *name)
>  		if(!nocase_strcmp(name, device_list[i].name)) {
>  			LastDevice=i;
>              def_dev(pi);
> +                        pi->dseg->lo_addr=device_list[LastDevice].ram_start; /* fixme: set ram_start in the correct place */
>  			return(&device_list[i]);
>  		}
>  		i++;
>
>
> The second added line (pi->dseg->lo_addr=device_list[LastDevice].ram_start;) makes
> avra obey the bigger size. Feel free to use the patch --- but beware, it's *UGLY*.
> :-)
>
> Do base your experiments on amForth 4.2. Otherwise you will run into the problem
> mentioned above, which should be fixed separately.
>
> --
>
> I would definitely prefer avra over wine+avrasm2 because I do have an ARM based Notebook.
> I even made a code analysis of avra (what size, what parts etc.). However, I currently
> don't have the time to dig into this. I'm currently not doing any amForth related
> stuff at all.
>
> If you or someone else want's to dig into avra, I can certainly dig out, what I changed.
> And it's probably a good idea to contact Marcin. He has done some patches to avra in
> the past.
>
>
> Hope this helps.
>
> Cheers,
> Erich
>
>
> ------------------------------------------------------------------------------
> Get 100% visibility into Java/.NET code with AppDynamics Lite!
> It's a free troubleshooting tool designed for production.
> Get down to code-level detail for bottlenecks, with <2% overhead. 
> Download for free and get started troubleshooting in minutes. 
> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk

Re: [Amforth] Build recent amforth with avra

[Erich W. <ew....@na...>]

Hello Christian,


On 08/07/2013 02:16 PM, Christian Kellermann wrote:
> * Matthias Trute <mt...@we...> [130804 20:57]:
>> Hi,
>>
>>
>>> I am trying to build the 5.1 release for an arduino uni with avra
>>> on a 32bit OpenBSD.
>>
>> According to Wine HQ openBSD may support wine (to some degree).
>> Avra is a hopeless case. Unfortunately.
> 
> No it's broken and it also does not work on non x86 HW.
> 
>>> Does this message ring a bell for someone on here? Did anyone build
>>> this release with avra successfully?  I remember that last time I
>>> needed to do this (amforth-4.2 IIRC) I needed a specific avra version
>>> from git. Unfortunately I have lost my notes so I am unable to
>>> reproduce my steps taken back then.
>>
>> Tried the search option of the mailing list?
> 
> I have been subscribed to this list for over a year now and could
> not find a post related to this question. Hence myself asking. If
> that's too much traffic I will refrain from consulting this list
> in the future.
> 
> Sorry for the noise.
No need to be sorry or give up.


I did experiment with avra more than a year ago.

- I needed avra from the git repo

  $ git reflog
  930634e HEAD@{0}: checkout: moving from c132dae7be7eca3c26c4881f431467f737b9d88f to master
  c132dae HEAD@{1}: checkout: moving from master to c132dae7be7ec
  930634e HEAD@{2}: commit: added git hash to Version info
  a6e8b29 HEAD@{3}: pull: Fast-forward
  b296ddf HEAD@{4}: clone: from git://avra.git.sourceforge.net/gitroot/avra/avra

  Do not waste your time with officially packaged avra binaries.


- In my directory tree I find .hex/.eep.hex files produced with avra and wine+avrasm2 for atmega32.

  - amforth 4.2: 
    both sets are equal, so this did work at the time

  - amforth 4.5: 
    this needed a change in the amforth sources, because avra deals badly with
    forward references. But I would need to dig into my source trees to find the difference
    (something with _doplusloop)

    nonetheless both sets are equal, so this did work at the time as well.

  - amforth 4.9:
    I tried this version again, but it did not work. It seems that I gave up at this point.


Please note that I did this with _atmega_32_.
I have tried to use avra for atmega644. The device is listed in the device
table (source code of avra), the size of flash is correct, but it was not
used! So I added a very ugly hack to avra (not understanding where the
correct place in the code would be) and after that a better hex file for
atmega644 was produced.

Looking at you first post to the list, it seems that atmega328p (arduino) is
just not supported.
/me checking sources:
$ grep 328 src/device.c.bak 
  { "ATmega328P",       16384,     0x100,     2048,   1024, DF_NO_EICALL|DF_NO_EIJMP|DF_NO_ELPM|DF_NO_ESPM},
-----------------------------------^^^^^^
This is the same size problem as with the 644.


$ git diff device.c
diff --git a/src/device.c b/src/device.c
index 2dc4171..470678c 100644
--- a/src/device.c
+++ b/src/device.c
@@ -104,6 +104,7 @@ struct device device_list[] =
   { "ATmega328P",       16384,     0x100,     2048,   1024, DF_NO_EICALL|DF_NO_EIJMP|DF_NO_ELPM|DF_NO_ESPM},
   {   "ATmega32",       16384,      0x60,     2048,   1024, DF_NO_EICALL|DF_NO_EIJMP|DF_NO_ELPM|DF_NO_ESPM},
   {  "ATmega603",       32768,      0x60,     4096,   2048, DF_NO_EICALL|DF_NO_EIJMP|DF_NO_MUL|DF_NO_MOVW|DF_NO_LPM_X|DF_NO_ELPM|DF_NO_SPM|DF_NO_ESPM|DF_NO_BREAK},
+  { "ATmega644P",       32768,     0x100,     4096,   2048, DF_NO_EICALL|DF_NO_EIJMP|DF_NO_ELPM|DF_NO_ESPM},
   {  "ATmega103",       65536,      0x60,     4096,   4096, DF_NO_EICALL|DF_NO_EIJMP|DF_NO_MUL|DF_NO_MOVW|DF_NO_LPM_X|DF_NO_ELPM_X|DF_NO_SPM|DF_NO_ESPM|DF_NO_BREAK}, // 137 - EICALL - EIJMP - MUL(6) - MOVW - LPM_X(2) - ELPM_X(2) - SPM - ESPM - BREAK = 121
   {  "ATmega104",       65536,      0x60,     4096,   4096, DF_NO_EICALL|DF_NO_EIJMP|DF_NO_ESPM}, // Old name for mega128
   {  "ATmega128",       65536,     0x100,     4096,   4096, DF_NO_EICALL|DF_NO_EIJMP|DF_NO_ESPM}, // 137 - EICALL - EIJMP - ESPM = 134 (Data sheet says 133 but it's wrong)
@@ -145,6 +146,7 @@ struct device *get_device(struct prog_info *pi, char *name)
 		if(!nocase_strcmp(name, device_list[i].name)) {
 			LastDevice=i;
             def_dev(pi);
+                        pi->dseg->lo_addr=device_list[LastDevice].ram_start; /* fixme: set ram_start in the correct place */
 			return(&device_list[i]);
 		}
 		i++;


The second added line (pi->dseg->lo_addr=device_list[LastDevice].ram_start;) makes
avra obey the bigger size. Feel free to use the patch --- but beware, it's *UGLY*.
:-)

Do base your experiments on amForth 4.2. Otherwise you will run into the problem
mentioned above, which should be fixed separately.

--

I would definitely prefer avra over wine+avrasm2 because I do have an ARM based Notebook.
I even made a code analysis of avra (what size, what parts etc.). However, I currently
don't have the time to dig into this. I'm currently not doing any amForth related
stuff at all.

If you or someone else want's to dig into avra, I can certainly dig out, what I changed.
And it's probably a good idea to contact Marcin. He has done some patches to avra in
the past.


Hope this helps.

Cheers,
Erich

Re: [Amforth] Build recent amforth with avra

[Christian K. <ck...@pe...>]

* Matthias Trute <mt...@we...> [130804 20:57]:
> Hi,
> 
> 
> > I am trying to build the 5.1 release for an arduino uni with avra
> > on a 32bit OpenBSD.
> 
> According to Wine HQ openBSD may support wine (to some degree).
> Avra is a hopeless case. Unfortunately.

No it's broken and it also does not work on non x86 HW.

> > Does this message ring a bell for someone on here? Did anyone build
> > this release with avra successfully?  I remember that last time I
> > needed to do this (amforth-4.2 IIRC) I needed a specific avra version
> > from git. Unfortunately I have lost my notes so I am unable to
> > reproduce my steps taken back then.
> 
> Tried the search option of the mailing list?

I have been subscribed to this list for over a year now and could
not find a post related to this question. Hence myself asking. If
that's too much traffic I will refrain from consulting this list
in the future.

Sorry for the noise.

Christian

-- 
In the world, there is nothing more submissive and weak than
water. Yet for attacking that which is hard and strong, nothing can
surpass it. --- Lao Tzu

Re: [Amforth] Build recent amforth with avra

[Mark M. <m.m...@gm...>]

> Avra is a hopeless case. Unfortunately.

I'm not so sure it's totally hopeless - just that it seems there few
willing to dig into it to compile amforth with avra as there are simpler
alternatives!
 <http://avra.git.sourceforge.net/gitroot/avra/avra>

I have been using the Raspberry Pi (Debian) as an "IDE" for some 328P
projects. Initially I would build Amforth on my desktop using Studio4 under
wine (also under VM/XP) and move the hex files to the pi and load with
avrdude.  Since the pi is an ARM architecture, it won't run wine nor VM.
But I wanted to be able to rebuild, load, and run amforth on the pi for a
cleaner ( a bit faster) tool chain.  I am using the Pi (and the hardware
SPI) as my ISP programmer (see
http://kevincuzner.com/2013/05/27/raspberry-pi-as-an-avr-programmer/ ) and
the GPIO serial port to "chat" with my forth interpeter)

Using avra from git hub (git clone git://
avra.git.sourceforge.net/gitroot/avra/avra) and taking the configure.in and
Makefile.am (Makefile.linux) from the avra-1.3.0 build package, I can build
and install avra and assemble Amforth 5.0.  I do get the .db warnings for
tick.asm and brackettick.asm but otherwise the hex files load and boot and
run fine for the 328P.

"Unfortunately" I haven't been able to build "working" hex files from 5.1
(although I do get hex files) - but I may not have tracked down all my
hacks from the 5.0 install that is working for me (I need to make better
notes!) Note that I haven't successfully compiled 5.1 with Studio4 or
avrasm2.exe and I can't seem to  install Studio6 under wine or VM/XP.

If my "working" avra under Debian for Amforth 5.0 is of interest to anyone,
I'll track down the minor changes I've made and pass them along. Be
forewarned: as with life, I have no idea how I got here or what I am doing,
but occasionally it all seems to work.


On Mon, Aug 5, 2013 at 10:19 AM, <dn...@se...> wrote:

> I think people mainly use the atmel studio tools, either under windows,
> windows in a VM, or maybe under wine. We're past the days when an
> XP-or-better machine costs used car money, after all. 50 bux will get you
> something that still runs, even if linux is your first love.
>
> > Message: 2
> > Date: Mon, 5 Aug 2013 03:43:21 +0300
> > From: Hannu Vuolasaho <vu...@ms...>
> > Subject: Re: [Amforth] Build recent amforth with avra
> > To: "amf...@li..."
> >       <amf...@li...>
> > Message-ID: <DUB...@ph...l>
> > Content-Type: text/plain; charset="iso-8859-1"
> >
> >> Avra is a hopeless case. Unfortunately.
> >
> > Thanks for confirming that.
> >
> > I have been trying to ansver this question for ages but it seems avra is
> > somehow
> > badly broken. I can't even build it cleanly.
> >
> > Are there any alternatives? avr-as might be good but has different
> syntax.
> >
> > Or is the latest stable avra good enough for the current users (except
> > amforthers)
> > so no-one writes good assembler?
> >
> > Best regards,
> > Hannu Vuolasaho
>
>
>
>
> ------------------------------------------------------------------------------
> Get your SQL database under version control now!
> Version control is standard for application code, but databases havent
> caught up. So what steps can you take to put your SQL databases under
> version control? Why should you start doing it? Read more to find out.
> http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

Re: [Amforth] Build recent amforth with avra

[<dn...@se...>]

I think people mainly use the atmel studio tools, either under windows,
windows in a VM, or maybe under wine. We're past the days when an
XP-or-better machine costs used car money, after all. 50 bux will get you
something that still runs, even if linux is your first love.

> Message: 2
> Date: Mon, 5 Aug 2013 03:43:21 +0300
> From: Hannu Vuolasaho <vu...@ms...>
> Subject: Re: [Amforth] Build recent amforth with avra
> To: "amf...@li..."
> 	<amf...@li...>
> Message-ID: <DUB...@ph...l>
> Content-Type: text/plain; charset="iso-8859-1"
>
>> Avra is a hopeless case. Unfortunately.
>
> Thanks for confirming that.
>
> I have been trying to ansver this question for ages but it seems avra is
> somehow
> badly broken. I can't even build it cleanly.
>
> Are there any alternatives? avr-as might be good but has different syntax.
>
> Or is the latest stable avra good enough for the current users (except
> amforthers)
> so no-one writes good assembler?
>
> Best regards,
> Hannu Vuolasaho

Re: [Amforth] Build recent amforth with avra

[Hannu V. <vu...@ms...>]

> Avra is a hopeless case. Unfortunately.

Thanks for confirming that.

I have been trying to ansver this question for ages but it seems avra is somehow
badly broken. I can't even build it cleanly.

Are there any alternatives? avr-as might be good but has different syntax.

Or is the latest stable avra good enough for the current users (except amforthers)
so no-one writes good assembler?

Best regards,
Hannu Vuolasaho 		 	   		  

Re: [Amforth] Build recent amforth with avra

[Matthias T. <mt...@we...>]

Hi,


> I am trying to build the 5.1 release for an arduino uni with avra
> on a 32bit OpenBSD.

According to Wine HQ openBSD may support wine (to some degree).
Avra is a hopeless case. Unfortunately.

> Does this message ring a bell for someone on here? Did anyone build
> this release with avra successfully?  I remember that last time I
> needed to do this (amforth-4.2 IIRC) I needed a specific avra version
> from git. Unfortunately I have lost my notes so I am unable to
> reproduce my steps taken back then.

Tried the search option of the mailing list?

Matthias

[Amforth] Build recent amforth with avra

[Christian K. <ck...@pe...>]

Dear list,

I am trying to build the 5.1 release for an arduino uni with avra
on a 32bit OpenBSD. I obtained the device definition files but when
I issue the gmake command I get the following error:

Pass 1...
/home/ckeen/proj/amforth-5.1/core/drivers/usart_common.asm(28) : Error   : Found no label/variable/constant named XT_NOOP
Warning : No .DEVICE definition found. Cannot make useful address range check !
Warning : No .DEVICE definition found. Cannot make useful address range check !
Warning : No .DEVICE definition found. Cannot make useful address range check !
gmake: *** [uno.hex] Error 1

Does this message ring a bell for someone on here? Did anyone build
this release with avra successfully?  I remember that last time I
needed to do this (amforth-4.2 IIRC) I needed a specific avra version
from git. Unfortunately I have lost my notes so I am unable to
reproduce my steps taken back then.

Thanks in advance for your help!

Christian

-- 
In the world, there is nothing more submissive and weak than
water. Yet for attacking that which is hard and strong, nothing can
surpass it. --- Lao Tzu

Re: [Amforth] Fwd: Native Forth for Arduino Uno

[Mark M. <m.m...@gm...>]

AmForth Pi & Carl's dilemma

Carl's desire to develop in Forth rather than C/C++ (or whatever they do
with Arudino) is something I can identify with.  While I don't mind C,
Forth just works better for me in certain projects.  And I have some legacy
Forth that's nice to re-use. I've built out a hardware toolchain based on
the Raspberry Pi.  Having a linux distro on card makes this a handy IDE for
my Amforth & C microcontroller projects.  It's not much more expensive than
an USB ISP from Atmel.  There's a patch for avrdude to use the Pi's SPI
GPIO pins and there's a nice pair for connecting to the serial port.  I put
all my software on an SD card on my Pi.  I use a USB WiFi and ssh into the
Pi - but there are other options.
Of course - and this is a deal breaker for many  people - you need to know
linux.  But given how popular the Raspberry Pi has become - I'm sure that's
less of a problem.

I've wire wrapped ( not cool now I guess ) a number of boards for the
ATmega328p with female headers to plug onto the Pi's header. I use the 3.3
v supply, serial, SPI,  etc... very nice.

I was considering putting up a small Kickstarter project to design a few
different boards for developing Amforth based microcontroller projects
using the Raspberry Pi as the programmer and "IDE".  I backed one project
on Kickstarter (
http://www.kickstarter.com/projects/annikaskywalker/microprocessor-about-the-cost-and-size-of-a-pack-o)
with the idea of plugging an AmForth 328P on it and find something
interesting to do with it. I'm still waiting for my copy of the board.

Unfortunately for Carl, you do need to  re-flash the chip if you find your
forth code does not get you back to the prompt.  It's not "bricked" of
course.  While developing with the Pi, I simply reload my current compiled
Amforth using avrdude and move on (scratching my head as to what I did
wrong!) (Note: I compile my amforth to suit my taste using Studio 4 under
wine.  I  tried using avra but there is a compiler directive syntax
inconsistency that needs to be fixed - haven't gotten to it yet...  my
install of Studio 4 won't compile my C programs (?) so I go with avr-gcc
toolchain)

I'm not sure how many people would be interested... and I would need to
learn a board layout program - but it appeals to me.  It would be nice to
have some ready made boards - wire wrapping gets old in a hurry.

Any thoughts on this idea?


On Sun, Jul 21, 2013 at 4:39 PM, <car...@sp...> wrote:

> Erich,
>
> I don't mind the 40 euro for the programmer, but I really don't have the
> time to order, wait for delivery, and
> get into the programming business.  Perhaps after this project is over that
> will look attractive to me.
>
> I do like your suggestion to ask about someone in my locality.  I'm in the
> Phoenix, AZ area and would appreciate hearing from anyone near me.
>
> Thanks for the suggestion.
>
> Carl
>
>
> On Sun, Jul 21, 2013 at 1:25 PM, Carl Baxter <car...@sp...> wrote:
>
> > Matthias,
> >
> > Another post indicated that it was possible (likely) that a 328P with
> > AmForth might be bricked
> > during developing a program.  With you 328P being surface mount it sounds
> > as if that is a
> > show stopper, depending on how dead the 328P was.
> >
> > My understanding is that surface mount 328P's were only used when  the
> DIP
> > versions were not available.
> >  I only have one Arduino Uno and it is the DIP version.
> >
> > I have a project with a deadline and my scarcest resource is time.  Even
> > if it isn't rocket science I can't
> > let myself get sidetracked with peripheral activities.
> >
> > You said,in an earlier post, that the Arduino Uno wouldn't be your first
> > choice for a SBC for AmForth.  I'm
> > not locked into the Arduino Uno,  It was available at an attractive price
> > for this project.  Can your recommend
> > another SBC that would come up in Forth and be in this general price
> > range?  I wouldn't mind pausing the
> > development of my existing Arduino Uno  "c" program and try another board
> > if it would get me up and running
> >  in Forth without delay.
> >
> > I appreciate your input.
> >
> > Carl
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On Sun, Jul 21, 2013 at 11:00 AM, Matthias Trute <mt...@we...> wrote:
> >
> >> * Replies will be sent through Spamex to
> >> amf...@li...
> >> * For additional info click -> http://www.spamex.com/i/?v=79288160
> >>
> >> Hi Carl,
> >>
> >> > Thank you for your detailed analysis of the situation.  I have to
> >> > admit that we have different goals or that I don't understand the
> >> > problem.  I'm willing to believe that it's that I don't understand,
> >> > but I get the flavor that you are shooting for a solution which uses
> >> > the actual chip in the Arduino Uno and want to be able to recover
> >> > its original operation.
> >>
> >> All of my arduino's have SMD chips. I could not replace them, not even
> >> if I would need to.
> >>
> >> > I had hoped for a solution where the original ATmega328P is removed
> >> > from the board and replaced with another 328P already programed for
> >> > AmForth.
> >>
> >> Since the arduino provide the ISP pins for in place programming (a 2x3
> >> pin header), I see no need to physically replace the chips. All that
> >> differs is software and it can be changed any time. You need
> >> a ISP capable programming device (e.g. another arduino with an
> >> ISP-MK2 sketch or a real programmer like the AVR ISP MK2 from Atmel).
> >>
> >> There's no rocket science involved.
> >>
> >> > I appreciate your interest and would be pleased to hear your take on
> >> >  removing the existing 328P and replacing it with a pre-programmed
> >> > Forth chip. I would think bootloader considerations would go away
> >> > under these circumstances.
> >>
> >> The bootloader can easily re-programmed with the Arduino IDE (there's a
> >> menu option for it). All you need (again) is a programming device. And
> >> after that, your arduino works as nothing has happened at all.
> >>
> >> Matthias
> >>
> >>
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> See everything from the browser to the database with AppDynamics
> >> Get end-to-end visibility with application monitoring from AppDynamics
> >> Isolate bottlenecks and diagnose root cause in seconds.
> >> Start your free trial of AppDynamics Pro today!
> >>
> >>
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> >> _______________________________________________
> >> Amforth-devel mailing list for http://amforth.sf.net/
> >> Amf...@li...
> >> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> >>
> >
> >
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

Re: [Amforth] Fwd: Native Forth for Arduino Uno

[<car...@sp...>]

Erich,

I don't mind the 40 euro for the programmer, but I really don't have the
time to order, wait for delivery, and
get into the programming business.  Perhaps after this project is over that
will look attractive to me.

I do like your suggestion to ask about someone in my locality.  I'm in the
Phoenix, AZ area and would appreciate hearing from anyone near me.

Thanks for the suggestion.

Carl


On Sun, Jul 21, 2013 at 1:25 PM, Carl Baxter <car...@sp...> wrote:

> Matthias,
>
> Another post indicated that it was possible (likely) that a 328P with
> AmForth might be bricked
> during developing a program.  With you 328P being surface mount it sounds
> as if that is a
> show stopper, depending on how dead the 328P was.
>
> My understanding is that surface mount 328P's were only used when  the DIP
> versions were not available.
>  I only have one Arduino Uno and it is the DIP version.
>
> I have a project with a deadline and my scarcest resource is time.  Even
> if it isn't rocket science I can't
> let myself get sidetracked with peripheral activities.
>
> You said,in an earlier post, that the Arduino Uno wouldn't be your first
> choice for a SBC for AmForth.  I'm
> not locked into the Arduino Uno,  It was available at an attractive price
> for this project.  Can your recommend
> another SBC that would come up in Forth and be in this general price
> range?  I wouldn't mind pausing the
> development of my existing Arduino Uno  "c" program and try another board
> if it would get me up and running
>  in Forth without delay.
>
> I appreciate your input.
>
> Carl
>
>
>
>
>
>
>
>
>
>
> On Sun, Jul 21, 2013 at 11:00 AM, Matthias Trute <mt...@we...> wrote:
>
>> * Replies will be sent through Spamex to
>> amf...@li...
>> * For additional info click -> http://www.spamex.com/i/?v=79288160
>>
>> Hi Carl,
>>
>> > Thank you for your detailed analysis of the situation.  I have to
>> > admit that we have different goals or that I don't understand the
>> > problem.  I'm willing to believe that it's that I don't understand,
>> > but I get the flavor that you are shooting for a solution which uses
>> > the actual chip in the Arduino Uno and want to be able to recover
>> > its original operation.
>>
>> All of my arduino's have SMD chips. I could not replace them, not even
>> if I would need to.
>>
>> > I had hoped for a solution where the original ATmega328P is removed
>> > from the board and replaced with another 328P already programed for
>> > AmForth.
>>
>> Since the arduino provide the ISP pins for in place programming (a 2x3
>> pin header), I see no need to physically replace the chips. All that
>> differs is software and it can be changed any time. You need
>> a ISP capable programming device (e.g. another arduino with an
>> ISP-MK2 sketch or a real programmer like the AVR ISP MK2 from Atmel).
>>
>> There's no rocket science involved.
>>
>> > I appreciate your interest and would be pleased to hear your take on
>> >  removing the existing 328P and replacing it with a pre-programmed
>> > Forth chip. I would think bootloader considerations would go away
>> > under these circumstances.
>>
>> The bootloader can easily re-programmed with the Arduino IDE (there's a
>> menu option for it). All you need (again) is a programming device. And
>> after that, your arduino works as nothing has happened at all.
>>
>> Matthias
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> See everything from the browser to the database with AppDynamics
>> Get end-to-end visibility with application monitoring from AppDynamics
>> Isolate bottlenecks and diagnose root cause in seconds.
>> Start your free trial of AppDynamics Pro today!
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Amforth-devel mailing list for http://amforth.sf.net/
>> Amf...@li...
>> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>>
>
>