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
_______________________________________________
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel
