Grr .. bad code examples

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

Porting some code from Mega16 to Mega644

 

UDR0 is now in extended i/o so the in command won't work - despite the datasheet using the in command for its examples.

 

Had me worried for a bit :-(

It's me again...

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

Using c it works. Using assembler, maybe not?

 

Imagecraft compiler user

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

The latest datasheet for that device is over 4 years old.  It's unlikely that Atmel will ever release a new version with corrections, but it's maybe a nice idea to let them know about it.  Open a ticket with Atmel support.

 

Also, post your findings here:

https://www.avrfreaks.net/forum/avr-errata-unpublished-and-other-gotchas?page=all

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

bobgardner wrote:

Using c it works. Using assembler, maybe not?

 

 

The compiler is clever enough to know when LDS/STS or IN/OUT need to be used. I'm not!

It's me again...

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

But it's not really the compiler. It just implements a generic rule (use in/out if address is below 0x5f and subtract 0x20 from that address). It's the addresses in the device defining .h files that ultimately defines what is used. If you are writing in Asm then the same info comes from the def.inc files as long as you use the LOAD/STORE macros from AVR001 they should adapt in the same way the compiler does. 

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

And IIRC there are macros for making the decision for you..

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

But OP's point is about the datasheet code examples.  [without looking at them] I'd guess >>they<< did not use LOAD/STORE.

 

That said, if I'm doing an AVR model port I lay the I/O register map side-by-side using migration app note as a guide, and highlight all the differences, and then see how it might affect my code.  And I'd think that would be even more important if there is ASM involved as the compiler might address some of the differences.

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

I checked and the datasheet is wrong, (as alway Atmel don't care there are always many cut and paste errors in the datasheets.)

 

Bob say :

Using c it works. Using assembler, maybe not?

yes it make the correct logic code, but because of bigger and slower code the program may not work.

 

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

I checked and the datasheet is wrong

But wink

 

https://www.avrfreaks.net/comment...

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Seems more like a retro-fix which Atmel used to try to absolve itself of actually writing correct examples :-/

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

+1

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

clawson wrote:

But it's not really the compiler. It just implements a generic rule (use in/out if address is below 0x5f and subtract 0x20 from that address). It's the addresses in the device defining .h files that ultimately defines what is used. If you are writing in Asm then the same info comes from the def.inc files as long as you use the LOAD/STORE macros from AVR001 they should adapt in the same way the compiler does. 

 

Macros? Atmel-supplied macros! >GASP<

 

That's almost as bad as using C! They might be inefficient!

 

I only use my own carefully-polished macros. I tell you, if I had my way I'd be programming one byte at a time with a hex keypad!

 

Seriously though, I'm one of the sad crew who find the doing (and understanding when to use the right instruction) more interesting than teh end result. To me a programming challenge is like a crossword and using shortcuts feels like peeping at the answers.

 

Now, where's my hair shirt?

 

Neil

 

P.S. is the spell checker rigged? It offered 'well-supported' as a correction for a mis-spelt version of Atmel-supplied.

 

P.P.S. It must have a sense of humour - it's now offering 'oatmeal' for 'Atmel'

 

It's me again...

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

oatmeal is probably a healthier choice.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

I'm not sure what you guys are running, but if I were you I'd keep it under close watch. You know what they say: "keep your friends close, keep your spell checker even closer"…

Hell, are you even sure it's not posting on your behalf when you're not watching?

ɴᴇᴛɪᴢᴇᴎ

Last Edited: Tue. Mar 29, 2016 - 09:16 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

netizen wrote:
Hell, are you even sure it's not posting on your behalf when you're not watching?

Are you Siri-us?

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

They might be inefficient!

 

I only use my own carefully-polished macros.

Just for the record AVR001 is here:

 

http://www.atmel.com/Images/doc2...

 

with the associated .zip file here:

 

http://www.atmel.com/images/AVR0...

 

The LOAD/STORE macros are the simplest thing in the entire file:

;*********************************************************
;*	Byte access anywhere in IO or lower $FF of data space
;* 	STORE - Store register in IO or data space
;* 	LOAD  - Load register from IO or data space
;*********************************************************

.MACRO STORE 		;Arguments: Address, Register
	.if	@0>0x3F
		sts	@0, @1
	.else
		out	@0, @1
	.endif
.ENDMACRO

.MACRO LOAD 		;Arguments: Register, Address
	.if	@1>0x3F
		lds	@0, @1
	.else
		in	@0, @1
	.endif
.ENDMACRO

Good luck with "polishing" those any further ;-)

 

(I do often wonder why this stuff came as an afterthought and isn't simply supplied with the assembler anyway - perhaps even making then psudeo-ops so you could use them without even a .include?)

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

Then you can't count time and code size.

And in some situations you would us LDD or simple LD (where X,Y or Z point on start of HW block)

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

Doesn't the assembler produce a listing file (with macros expanded) then? I would have thought you'd be able to use that for cycle counting if necessary. (actually it'd be kind of nice if it annotated each opcode with the cycles for the chosen model of AVR!)

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

clawson wrote:
(I do often wonder why this stuff came as an afterthought and isn't simply supplied with the assembler anyway - perhaps even making then psudeo-ops so you could use them without even a .include?)

 

Agreed. Why not have simple pseudo ops like addi x,n = subi x,-n

It's me again...

Last Edited: Sun. Apr 3, 2016 - 10:14 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Stub_Mandrel wrote:

Why not have simple pseudo ops like addi x,n = subi x,-n

I have a theory.  Assembler programmers are masochists.  Give them a macro that makes them more miserable and they would go for it.  smiley

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

steve17 wrote:

Stub_Mandrel wrote:

Why not have simple pseudo ops like addi x,n = subi x,-n

I have a theory.  Assembler programmers are masochists.  Give them a macro that makes them more miserable and they would go for it.  wink

 

Last Edited: Sun. Apr 3, 2016 - 12:50 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Stub_Mandrel wrote:
Why not have simple pseudo ops like addi x,n = subi x,-n

I prefer my "asm" macros to look like this..

int a,b,c;

c = a + b;

cheeky

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

WARNING:  a and b have not been initialized.  smiley

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

steve17 wrote:
WARNING: a and b have not been initialized

Oh, my error I omitted this part of the code:

int a,b,c;

void some_func(void) {
c = a + b;
}

so, actually, yes they have been initialised cheeky

(unless you are using a DSP compiler from TI - don't ask!)

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

steve17 wrote:

I have a theory.  Assembler programmers are masochists.  Give them a macro that makes them more miserable and they would go for it.  wink

 

 

Quite. If I used C I would have to beat myself with a hazel switch then run naked through a nettle patch each time my code ran without errors.

It's me again...