Finding proper names

Go To Last Post
22 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This is probably very simple, but seems rather perplexing.  I have an old mega asm2 program that I'm moving over asap to the mega4808.

I can't find the bit names recognized by asm2 for this build.  For example, if I want to turn on PB3:

 

ldi XL, (1<<PORTB3)

sts portb_dir, XL

sts_portb_out, XL

 

This fails, it claims it doesn't know "PORTB3"  (or the older  "PB3" )  ...what is the  correct term to use (what is pb3 called)

say I want to turn on PB3 & PB7  ,,,,typically  you'd have

  ldi XL, (1 <<PB3 ) | (1 << PB7)  ...what is the newfangled name?

 

 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Wed. Jul 22, 2020 - 08:24 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Your DFP version number may vary but the file is something like:

C:\Program Files (x86)\Atmel\Studio\7.0>dir m4809*.inc /s
 Volume in drive C is OSDISK
 Volume Serial Number is 7AF3-B2D0

 Directory of C:\Program Files (x86)\Atmel\Studio\7.0\packs\atmel\ATmega_DFP\1.3.300\avrasm\inc

27/11/2018  10:13           238,938 m4809def.inc
               1 File(s)        238,938 bytes

 Directory of C:\Program Files (x86)\Atmel\Studio\7.0\packs\atmel\ATmega_DFP\1.4.346\avrasm\inc

20/12/2019  08:12           233,473 m4809def.inc
               1 File(s)        233,473 bytes

 Directory of C:\Program Files (x86)\Atmel\Studio\7.0\packs\atmel\ATmega_DFP\1.4.351\avrasm\inc

16/03/2020  13:33           233,472 m4809def.inc
               1 File(s)        233,472 bytes

I looked at the last of those. I don't see any definition of bit names but why don't you simply use:

ldi XL, (1 << 3)
sts portb_dir, XL
sts_portb_out, XL
  ldi XL, (1 << 3 ) | (1 << 7)  ...what is the newfangled name?

There's nothing "special" about "PB3" or "PORTB3" or whatever. At the end of the day it just resolves to (1 << 3) and then in turn to 0x08.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There's nothing "special" about "PB3" or "PORTB3" or whatever. At the end of the day it just resolves to (1 << 3) and then in turn to 0x08.

Thanks--I got tired of looking around and did just that (1<<5 , etc), though I think it is quite strange they don't have pin names....they have 5327 different names for everything else!!  You'd think something so fundamental would rank up there.    Of course, if nothing really is prescribed, I might  define my own.  This just a "quick" & dirty (supposedly) porting over of some old codes.  

 

I didn't realize that NONE of the peripherals reside in the <3F memory area, save for the virtual ports.  They could have stashed a uart or adc down there  (I suppose that would "wreck" having cousins uniformly spaced)..I don't think 0x20-0x2F is even used (or I overlooked).  A pity, since the compilers can use in/out sbi, etc down there.  I couldn't find a memory register map for that area.  In the old datasheet days they could fit all the registers on one or 2 sheets.

 

 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

they are called something like VPORTB (the nameing follow Xmega's)

 

They are placed at the same addr so perhaps define PORTB3 etc

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sparrow2 wrote:
they are called something like VPORTB (the nameing follow Xmega's)
Not seeing that in m4809inc.def ??

 

I had a look through for (1<<5)s and 0x20s and there are a few but non relating to PORT/VPORT. The only defines in the VPORT section are:

;*************************************************************************
;** VPORT - Virtual Ports
;*************************************************************************

; VPORT_INTFLAGS masks
.equ VPORT_INT_gm = 0xFF                 ; Pin Interrupt group mask
.equ VPORT_INT_gp = 0                    ; Pin Interrupt group position
.equ VPORT_INT0_bm = (1<<0)              ; Pin Interrupt bit 0 mask
.equ VPORT_INT0_bp = 0                   ; Pin Interrupt bit 0 position
.equ VPORT_INT1_bm = (1<<1)              ; Pin Interrupt bit 1 mask
.equ VPORT_INT1_bp = 1                   ; Pin Interrupt bit 1 position
.equ VPORT_INT2_bm = (1<<2)              ; Pin Interrupt bit 2 mask
.equ VPORT_INT2_bp = 2                   ; Pin Interrupt bit 2 position
.equ VPORT_INT3_bm = (1<<3)              ; Pin Interrupt bit 3 mask
.equ VPORT_INT3_bp = 3                   ; Pin Interrupt bit 3 position
.equ VPORT_INT4_bm = (1<<4)              ; Pin Interrupt bit 4 mask
.equ VPORT_INT4_bp = 4                   ; Pin Interrupt bit 4 position
.equ VPORT_INT5_bm = (1<<5)              ; Pin Interrupt bit 5 mask
.equ VPORT_INT5_bp = 5                   ; Pin Interrupt bit 5 position
.equ VPORT_INT6_bm = (1<<6)              ; Pin Interrupt bit 6 mask
.equ VPORT_INT6_bp = 6                   ; Pin Interrupt bit 6 position
.equ VPORT_INT7_bm = (1<<7)              ; Pin Interrupt bit 7 mask
.equ VPORT_INT7_bp = 7                   ; Pin Interrupt bit 7 position

but those are "INT" bits.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


I had a look at the data sheet, and it's the C structure is like the Xmega, but the VPORT is fixed as it was an org mega:

 

 

And for DIR OUT IN it's the same as DDR PORT and PIN

 

And I would just define those so you could use the old code  :) 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sparrow,

 

He was simply talking about names of the 0..7 in (1 << SYM_NAME) not the registers (which are in the def.inc file)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There's nothing "special" about "PB3" or "PORTB3" or whatever. At the end of the day it just resolves to (1 << 3) and then in turn to 0x08.

Because the old code would use IN and OUT instructions for this, and not LDS STS.

That is why you also need DDRB PORTB PINB etc. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I fear you are missing the point. A traditional def.inc (m32def.inc in this case) has something like:

; ***** PORTB ************************
; PORTB - Port B Data Register
.equ	PORTB0	= 0	; Port B Data Register bit 0
.equ	PB0	= 0	; For compatibility
.equ	PORTB1	= 1	; Port B Data Register bit 1
.equ	PB1	= 1	; For compatibility
.equ	PORTB2	= 2	; Port B Data Register bit 2
.equ	PB2	= 2	; For compatibility
.equ	PORTB3	= 3	; Port B Data Register bit 3
.equ	PB3	= 3	; For compatibility
.equ	PORTB4	= 4	; Port B Data Register bit 4
.equ	PB4	= 4	; For compatibility
.equ	PORTB5	= 5	; Port B Data Register bit 5
.equ	PB5	= 5	; For compatibility
.equ	PORTB6	= 6	; Port B Data Register bit 6
.equ	PB6	= 6	; For compatibility
.equ	PORTB7	= 7	; Port B Data Register bit 7
.equ	PB7	= 7	; For compatibility

but these new ones don't. That is what he was opining.

 

It's about bit names, not register names but like I say, and as you can see, these bit names are just the numbers '0' to '7' so one might as well use '0'..'7' anyway.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

And that is is the reason I suggest OP to define the missing things, and that ALSO need to be DDRn PORTn PINn   (where n is a letter)

 

 

as like this I had to do so I could use the extra IO's on 328pb with a 328p compiler setting (using winavr).

 

#define PINE _SFR_IO8(0x0C)
#define DDRE _SFR_IO8(0x0D)
#define PORTE _SFR_IO8(0x0E)

 

I know this is for the C compiler, but same for ASM as I remember. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The last time I worked with the iom4809.h file it was not assembly friendly.

Located here is a script to convert the atdf to something for assembly.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Personally,   I quite like PB7.   It tells you both the Port and the bit number.

 

Codevision defines PORTB7, PINB7, DDB7 etc but not PB7.

 

When porting a GCC program to CV,  I would define PB7 as PORTB7 for compatibility.

When writing a fresh program,  I would probably just use 7.    But more likely,  I would define a meaningful symbol  e.g. GREEN_LED as 7 or GREEN_LED_bm as (1<<7)

 

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avrcandies wrote:
I have an old mega asm2 program that I'm moving over asap to the mega4808.

The OP needs to understand that the new 0/1 AVR's are more like xmega's then old mega's, porting will not be straight forward due to the structured naming scheme these xmega's use.

That seems to be the confusion here, you know that, the OP did not.

 

Jim

 

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

MattRW wrote:
The last time I worked with the iom4809.h file it was not assembly friendly.
But that's not relevant here. He said "asm2" so that means XXXdef.inc files not ioXXX.h files. Both are in the DFPs.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That seems to be the confusion here, you know that, the OP did not.

On no, I do know they are like the XMEGAS, and I have used those...and they will use PORTB2, for example. ...The question was, what does the 4808 use?  apparently nothing is supplied. ...strange, since pins are one of the main building blocks & would seem s first in line for naming rights.  Oh wellz, can just use numbers, or make something up--didn't want to recreate the wheel. 

 

 

 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

When using avrasm2.exe as the assembler, I include the listing file for the individual type of AVR device at the beginning of the source file.  This file's name starts with a the abbreviation of the device's name followed by ...def with the file extension being .inc.   Possibly a reference to this file is missing from the original source, or, more likely, the  ...def.inc file can't be found in the directory that you are using for the old source code.  

   For example, the AVR Tiny24 has a def file called:  tn24def.inc

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

When using avrasm2.exe as the assembler, I include the listing file for the individual type of AVR device at the beginning of the source file. 

Nowadays, the file is included automatically & can also be viewed in the project explorer, under dependencies  (m4808def.inc)

 

However it is 4400 lines long (!!!) in somewhat random order & I couldn't find any pin names, like PB3 or  PORTB3....so I was wondering what they are, my search was fruitless.

 

the mega88 file is "only" about 960 lines lineg....1/4th the size!

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avrcandies wrote:
in somewhat random order
Ah not entirely true. I thought the groupings seemed haphazard at first until I realised they are in alpha order. So when someone mentioned "VPORT" above I knew exactly where to look as VPORT comes between "USERROW" and "VREF"
avrcandies wrote:
the mega88 file is "only" about 960 lines lineg....1/4th the size!
An observation that simply testifies to the fact that Xmega based AVR are considerably more complex than Tiny/Mega. When you do things like change DDR/PORT/PIN to a group of 19 registers to control an IO port then, yeah, the file that defines all the registers IS going to get bigger (it's not just IO that have more registers/functionality, it's everything and there are also new peripherals)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ah not entirely true. I thought the groupings seemed haphazard at first until I realised they are in alpha order

Yep, however if you are trying to find something that you don't know exactly what it is & to be able to conclude it's "nowhere in there" , you have to look at the whole thing. I more or less did so & started mumbling, shaking, and breakdancing near the end.

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Go on.  Xmega and Xtiny are much easier than ARM header files.    Especially the horrible SAMD ones.

 

Yes,  the skill is searching for the "best" regular expression.

Much like Google-fu

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avrcandies wrote:
I didn't realize that NONE of the peripherals reside in the <3F memory area, save for the virtual ports.  They could have stashed a uart or adc down there

I don't think there's enough room for ADC. Each USART is allocated 32 bytes in SFR space (despite not fully used though) so that won't fit either.

 

Well written code for ADC and USART etc. will have the SFR register access localised to just a few functions in one module, so there is little to gain in using IN or OUT instructions here versus accessing GPIO ports which will proliferate over the majority of most AVR code. In that respect the VPORTS are an excellent  "invention".

 

I actually think Atmel did a good job on XMEGA peripherals. It's also worth mentioning that GPIOR0 - GPIORn all now reside in the bit addressable section. This wasn't the case in many Megas  and I frequently ran out of these especially useful flags.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avrcandies wrote:

This is probably very simple, but seems rather perplexing.  I have an old mega asm2 program that I'm moving over asap to the mega4808.

I can't find the bit names recognized by asm2 for this build.  For example, if I want to turn on PB3:

 

ldi XL, (1<<PORTB3)

sts portb_dir, XL

sts_portb_out, XL

 

This fails, it claims it doesn't know "PORTB3"  (or the older  "PB3" )  ...what is the  correct term to use (what is pb3 called)

say I want to turn on PB3 & PB7  ,,,,typically  you'd have

  ldi XL, (1 <<PB3 ) | (1 << PB7)  ...what is the newfangled name?

 

 

 

Forget "PB3" or "PORTB3". Just use "3". As such: (1 << 3).

 

Gentlemen may prefer Blondes, but Real Men prefer Redheads!