Copying strings in ATTiny416 unexpectedly painful

Go To Last Post
65 posts / 0 new

Pages

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

avr-gcc (AVR_8_bit_GNU_Toolchain_3.6.1_1750) 5.4.0

 

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

Jeff, when you would like to reply to a specific question from a member you can simply use "Quote" after hovery the sentence. this would make it easy to follow

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

Perhaps stupid but I assume you have tried to compile with –Og as optimizer level.   

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

You're welcome

Ned Zeppelin wrote:
... a tn104->tn417 port, ...
tiny817 Xplained Mini is mEDBG (you might not like thatwink

tiny817 Xplained Pro is EDBG but the tiny817 is at a fixed 3.3V for VCC (other Microchip boards have level translators with EDBG)

Might consider an Atmel-ICE (Atmel Studio 7, MPLAB X v5) or MPLAB PICkit 4 (MPLAB X v5, has Vpp for the multi-function UPDI/RESET/IO) or Power Debugger (Atmel Studio 7, 12V reset)

 

ATTINY417 - 8-bit AVR Microcontrollers

 

"Dare to be naïve." - Buckminster Fuller

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

I can't immediately find the release notes for Microchip AVR GCC 3.6.2.

Anyone, what changed between 3.6.1 and 3.6.2?

Thanks!

AVR- and Arm- Toolchains (C Compilers) | Microchip Technology

 

"Dare to be naïve." - Buckminster Fuller

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

Moe123 wrote:
westfw, I think this discussion is definetly out of your league. Sorry.
Woah - talk about condescension!  I take it you don't know who Bill Westfield actually is then? Don't suppose you've ever heard of Optiboot?

 

Try to remember that ad hominem attacks here will not be permitted.

 

Moderator

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

clawson wrote:

Moe123 wrote:
westfw, I think this discussion is definetly out of your league. Sorry.
Woah - talk about condescension!  I take it you don't know who Bill Westfield actually is then? Don't suppose you've ever heard of Optiboot?

 

Try to remember that ad hominem attacks here will not be permitted.

 

Moderator

 

Listen, do you have something against me personally. then say it. last time you came to help your friend who was insulting and threatining to ban me. Now I see that your guy has insulted someones ability and knowledge, I didnt accept it. if you have something personal say it directly

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

Guys, please stay on topic!

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

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

El Tangas wrote:

All array elements that are not initialized explicitly are initialized implicitly the same way as objects that have static storage duration.  

Implicit initialization

If an initializer is not provided:

  • pointers are initialized to null pointer values of their types
  • objects of integral types are initialized to unsigned zero
  • objects of floating types are initialized to positive zero
  • members of arrays, structs, and unions are initialized as described above, recursively, plus all padding bits are initialized to zero

 

My conclusion is, if any element of an array is initialized (for example, using array[size] = ""), all remaining elements get auto-initialized to zero. 

I agree with your conclusion.

I would expect the following to be functionally equivalent

    char outstr[10] = "";
    char outstr[10] = {0};
    char outstr[10] = {'\0'};
    char outstr[10] = {0,0,0,0,0,0,0,0,0,0};

On the ancient version of avr-gcc I have here (4.9.2), using the ="" seems to generate slightly worse code compared to = {0}.

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

 //char outstr[17] = "";
    char outstr[17];
    :
    strncpy(&outstr[6], desc, len > 10 ? 10 : len);        // <- OFFENDING CODE

 

The language spec says a definition like char str[10] = "";  initializes the array, but in this compiler it does not.

There is no evidence here that the array was not initialized, and several examples posted by others showing that it was initialized.

 

In the original post/example (quoted some above), the memory contents were shown AFTER the strncpy; it's looking at the wrong memory (which probably reads as all 0xFF), so strlen() results are invalid and probably very large, and the strncpy() duly copies "only 10" characters, which completely fills outstr with no null terminator.

Recall that strncpy() does not guarantee null terminations (but does do null padding), and is rarely the correct string copy function for dealing with generic strings (it's more useful for structure fields where you want the null padding.)  strlcpy() would be better.

 

 

 This is meaningless if the compiler's language compliance is unspecified.

gcc, including avr-gcc, is a widely known and respected C compiler that is at least believe to be compliant with any number of versions of the C standard, depending on exact switches.
https://gcc.gnu.org/onlinedocs/gcc/Standards.html )  I think that includes avr-gcc, with possible exceptions when it comes to avr-libc.  (But not anything as basic as string/array initialization.)

I haven't used Atmel Studio or its debugger enough to comment on their reliability :-(  (normally using Arduino or just CLI tools.)  It's certainly more likely that there would be bugs and/or less-well-understood behavior WRT the new TINY-0, TINY-1, and MEGA-0 architectural variations.  IDE issues are more likely that compiler bugs.

 

I do have one of the Nano416 boards, but it's at home, and I'm out-of-town dealing with a family medical emergency :-(  I'll give the code a try when I get home, but it may be a while...

 

 

Here is an IDE that may or may not display the value of auto variables, or even the symbols, often does not know their address or values, requires that I copy some values into a struct for that purpose if I want to see their values, drops values from the locals window between steps, won't display indexed members of some arrays

Aren't most of those complaints pretty standard for a debugger trying to interpret highly optimized compiler output?  In particular, "drops values" is what I'd expect to have happen if a variable gets put in registers that are later reused for some other purpose.   a REALLY GOOD debugger might give more informative messages about what's going on, but it is a reality that some variables can stop being available in the middle of a function (and alas, I don't think the AVR debugger is in the "really good" category.)

 

 

I have code that will run when using the PSTR macro, and will NOT run without it.  PROGMEM is nowhere in the code, BTW.

 

:

Someone else suggested LPM but I have not yet needed it

use of PSTR and PROGMEM are equivalent.   PSTR uses PROGMEM in its definition. http://svn.savannah.gnu.org/viewvc/avr-libc/trunk/avr-libc/include/avr/pgmspace.h?revision=2544&view=markup#l404
LPM is used by  by all of the "_P" functions; if you're using them, they expect to copy from PROGMEM/PSTR pointers/strings (ie 0x34) using the LPM instruction.  If you pass them a RAM pointer (including literal strings in remapped-flash, on the t0/t1/m0 devices), they will use LPM with the mapped address (probably FLASHSTART+0x34), which will return unintended

 

 

If you use the _P functions you must use that argument as with a PSTR() or progmem 

If you have a string in PROGMEM or defined with PSTR, then the must get matched up an approproate _P function.

If you have t0/t1/m0 cpus,  static constant strings are set up in the symbol table in the FLASH section of the RAM address space,  and should be used with the normal strcpy() functions (NOT _P)

 

and hinting at arduino tutorials trying to downgrade his knowledge is not a nice thing,

when you're not "getting it" in some way, looking up AVAILABLE DOCUMENTATION from ALL sources seems a necessary step.

 

 

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

meolsen wrote:

Guys, please stay on topic!

agreed!

 

If someone has a problem with another community member and its not resolved in a post then simply PM a Moderator - Theres enough of us to go around. 

 

I read the thread and what I see is an OP who certainly has the experience, and the know how, but maybe has been staring at the problem they are having so long they may not want to take a step or two back and understand what others are trying to explain.  Bites me in the bum all the time. 

 

These TINY416 devices...and their other close relatives we call XTINYS affectionately are a different breed. Some certainly have better understanding than others and we should first try to understand the advice rather than dismiss it.

 

Thanks,

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

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"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, RSLogix user

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


THANKS TO ALL - I have not had the time to pursue and nail down all the string-related issues.  Lots of people contributed and it takes a lot of time to consolidate all the knowledge.  I was using strings only for tracing and the appl handles no strings otherwise.  Once I got an SPI slave running in another controller I was able to see the designed output of the appl, which obviated the need for the uart and related trace strings (and the controller is still 99.1% full).  The worst of it all is the AS bugs.  Yes, they are real, and I did not even mention the total invisibility of the GPIORx register values in the IDE while debugging.  These problems could be in the nano board's debugger too.  Given that, trying to reproduce bugs in the simulator is not reliable.

 

This forum is definitely the place to go for help with AVRs.  I very much appreciate everyone's time and effort:  Enjoy this - it's on me...

 

Jeff

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

Ned Zeppelin wrote:
I no longer own a copy of the language standard (and it's $95).  So, I use ...

But the drafts are readily available; I guess I could issue a challenge on how the draft vs. "real" might affect your work.

 

Ned Zeppelin wrote:
learned to let condescension roll off my back

You Marines.  Most of us just let the condensation roll off our backs.

Ned Zeppelin wrote:
I've been a software engineer (for a living) since 1982, R&D since 2008. 

You kids.

Ned Zeppelin wrote:
Some of these tools are new to me and with free tools you get what you pay for. 

Aaah, I'm fond of calling that the infinite-value toolset if you accept that value=utility/cost

 

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

Support for devices with linear address space was added to avr-gcc v8 and needs Binutils 2.29 at least, see the GCC v8 release notes. .rodata will reside in flash and is not copied to RAM. LPM can still be used to access data in flash, but for correct operation data must reside in. progmem or similar so that no 0x8000 offset (0x4000 for avrtiny) is added to the address. The feature is basically just a reorganisation of.rodata in the linker script, apart from addition of new multilib and device support in gcc and avrlibc.

avrfreaks does not support Opera. Profile inactive.

Pages