GPIO0 on atmega 128 and atmel studio question ?

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

Everyone,

 

How can I use GPIO0 on atmega 128 and atmel studio in C ?

Do I miss a library here ?

 

Thanks

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

bianchi77 wrote:
How can I use GPIO0 on atmega 128 and atmel studio in C ? Do I miss a library here ?

???  Tell a bit more about this.  What "GPIO0" is on a Mega128?  Or on any other AVR8 model?  There are no hits when searching the datasheet for "gpio".

 

 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

That's why I tried to find out, how can I use general purpose register on atmega128 ? I want to use it as a system status storage.

GPIOR0, how can I use it in C for atmega128 ?

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

bianchi77 wrote:
GPIOR0, how can I use it in C for atmega128 ?
theusch wrote:
There are no hits when searching the datasheet for "gpio".

Thus, there are no hits for GPIOR0 either -- that model has no "general-purpose I/O registers".  If it did, then you could use them in C just as you "talk to" any other AVR8 I/O register.

 

 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

any ideas on how to use general purpose register on atmega128 ? I saw in datasheet, it has 32x8 general purpose register.

 

from datasheet :

 

– 32 x 8 General Purpose Working Registers + Peripheral Control Registers

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

The C compiler uses these. Why would you want to touch them?

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

temporary storage for system status, or any other ways ?

 

/* System status register and bit definitions */
 #define Stat		GPIOR0
 #define S_RUN		0x01
 #define S_LBT		0x02
 #define S_PAUSE	0x04
 #define S_FLED		0x08
 #define S_LOOPALL	0x80

 

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

Why would you not just put these in a normal variable? I'm failing to understand what you are wanting to achieve. Where is the source of these wonderful ideas?

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

From clawson: 

  1. Home
  2. » Communities
  3. » AVR Freaks
  4. » Forums
  5. » AVR Microcontrollers
  6. » megaAVR and tinyAVR
  7. » IO register reserved ????

 

As it says in the datasheet the 48/88/168/328 provide three SFRs for your own storage uses GPIOR0, GPIOR1 and GPIOR2 but only the first of those is REALLY useful because it's in range for the SBI/CBI opcodes. The other two are in range of IN/OUT so are slightly faster than RAM locations that need to use STS/LDS, but it does seem a shame that they couldn't have mapped all 3 to some of the "reserved" spaces in the 0x00..0x1F I/O range.

 the ATMega128 does not have these SFRs.

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

And then how can I adapt GPIOR0 with Atmega128 ?

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

bianchi77 wrote:
And then how can I adapt GPIOR0 with Atmega128 ?

Is there a large language barrier here?  The Mega128 model HAS NO GPIO I/O registers.  Some other models do.

 

The Mega128 has no UNICORNS either.  It is like asking you how to use UNICORNS with C and a Mega128.

 

The general-purpose registers you mentioned from the Mega128 datasheet are labeled as R0 through R31.  How they are used in C, and how you might access them directly, will vary depending on which toolchain you are using.

 

If you want to know about GP register usage in code generated by a C compiler, I suggest you take a tiny C appication and look at the generated code.  Take that and your toolchain's documentation -- you >>have<< already studied that, haven't you? -- and then go from there.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

The reason for GPIORn in the later AVR that came out long after the 128 is just to give the user 3 bytes of variable storage that are a bit quicker to access than normal RAM variables because they are in range of IN/OUT instead of needing LDS/STS and in the case of GPIOR0 it's even in range of SBI/CBI but all this buys you are "fast variables" but C will do its best to do that anyway. When it can it'll hold your data in the 32 CPU registers.

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

bianchi77 wrote:
temporary storage for system status

 

Kartman wrote:
Why would you not just put these in a normal variable?

+1

 

uint8_t     SYS_STAT;

Each bit in variable SYS_STAT can be an individual flag, OR you could write a value to indicate system status.

 

If you use each bit as a flag, then it is simple bit manipulation, and testing in your code.

 

JIm

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

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

jgmdesign wrote:

Kartman wrote:
Why would you not just put these in a normal variable?

+1

 ... ... ...

JIm

-1

There are some excellent reasons for using GPIOR0 for global booleans:

 

  1. Set, Clear and Test access is via one instruction, no need to load into a working register first. (creates small & fast code)
  2. Set, Clear don't affect any registers or affect SREG so make possible an ultra lightweight (naked) ISR as demonstrated in this post here:
    https://www.avrfreaks.net/comment/2063196#comment-2063196
  3. Set, Clear and Test access is naturally atomic, no need for atomic block protection if boolean can be modified in an ISR.

 

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

N.Winterbottom wrote:
There are some excellent reasons for using GPIOR0 for global booleans:

I don't disagree.  However, in context, OP is [repeatedly] asking how to use a feature not available on the chosen AVR model.  This implies a level of expertise that isn't going to be concerned with an exta cycle or two.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

Ok, thanks, I'll use normal variable.