Bugfix for MCUs with SRAM start != 0x60, fix in segment check

[burki-de]

Hello I've added some new devices and include files (m***def.inc) and made some bug fixes. Please take a look at the CHANGELOG file. I wrote all corrections and additions there. Attached the packed source file and changes as patch file (excluding new files in include folder). P.S.: I'm not new with that project. I made the changes or release 1.2.3 :-)

B.A. diff_avra-master_2020-07-15_avra_1.4.2-NEW.patch.zip avra-1.4.2.zip

[Ro5bert]

Hello,

Thanks for the fixes and additions. I'll incorporate your patch into an 1.4.2 release. I haven't been as diligent as I should be about keeping the changelog up to date, and there have been a few changes (mostly device additions) since 1.4.1, so I'll document those in the changelog first. Plus I've been meaning to clean up some minor things to satisfy my OCD (e.g., I see you updated the copyright notice in the title; I'd like to do the same for the comments in the source).

Good to know where all the comments marked "B.A." have come from :)

Robert.

[burki-de]

Hi Robert,

thanks for quick response. By the way.. for me it's ok to clean some historical comments about old, long forgotten bugfixes. Some new comments I made to some changes (I guess yours ?) you can kill after reading ;-) Should be a hint for the programmer to think about... Today made a lot testing and assembled nearly 100 of my assembler programms for different processors from AT90S1200 to ATmega1284 with the patched "1.4.2" version. I got no difference in hex-files in comparison with my old, patches 1.2.3 version. Sometimes the obj-file is different, but I never used it and didn't took a look why. I'm curious, why you implemented the option to accept overlapping segments. For what in the hell you need that?

Burkhard

Am Donnerstag, den 16.07.2020, 09:25 -0700 schrieb Robert Russell:

Hello,

Thanks for the fixes and additions. I'll incorporate your patch into an 1.4.2 release. I haven't been as diligent as I should be about keeping the changelog up to date, and there have been a few changes (mostly device additions) since 1.4.1, so I'll document those in the changelog first. Plus I've been meaning to clean up some minor things to satisfy my OCD (e.g., I see you updated the copyright notice in the title; I'd like to do the same for the comments in the source).

Good to know where all the comments marked "B.A." have come from :)

Robert.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[Ro5bert]

Hi Burkhard,

I only recently took up maintainership of the project (in March of this year, I think). The changes you commented on (both here and in the code) weren't made by me. For what it's worth, I do agree with your comments. In particular, you commented on the pi and si recursive pointer thing, and that also stuck me as strange when I first saw it. I get the impression that as the project was passed around, there was no clear standard and everyone more-or-less did their own thing (something I'd like to change), so it's a little messy.

Good to hear the hex files for your programs haven't change since 1.2.3. I can't say why the obj files are different, but it you ever find out the difference is significant, be sure to let me know :)

The overlapping segments option appears to have been implemented in 94708b06. The commit message suggests the feature was added for AVRASM compatibility, which apparently has the same option. No clue why you'd need that feature though.

Robert

[Nevada317]

Overlapping segments can, in fact, be useful. For example: you want to implement a couple of different algorithms, each of those needs large amount of memory during execution. If you control, that they run one-at-a-time, you may want to write different ram mappings for those and everything will work.

P.S. Nice to see that project alive! Thanks

[Ro5bert]

Can't you just do something like this, in that case:

.dseg
.org 0x0200
.byte 1024 ; Allocate for case1 and case2

; Mapping for case1
.org 0x0200
case1a:
.org 0x0200 + 32
case1b:
; Etc...

; Mapping for case2
.org 0x0200
case2a:
.org 0x0200 + 64
case2b:
; Etc...

I've never actually done this before, so maybe I'm missing something. I just deleted a similar comment, because I thought this solution was a little error prone, but it's better than just throwing away overlap detection altogether, as the assembler will still give you errors if you overlap unrelated .byte segments.