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.fo...@nassur.net> writes:
> Hello Christian,
>
>
> On 08/07/2013 02:16 PM, Christian Kellermann wrote:
>> * Matthias Trute <mtr...@web.de> [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
------------------------------------------------------------------------------
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/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel
