Unable to compile TinyOs applications with avr-gcc 4.2.1 but able to compile with avr-gcc 3.3

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

Hi, i'm trying to compile TinyOs 1.x applications on my cygwin machine. I'm able to compile the applications of TinyOs 1.x using avr-gcc v3.3 but not with v4.2.1. 

I wanted to upgrade my avr-gcc from v3.3 to v4.2.1 as there are support for new controllers. So i followed the steps that were provided to build the toolchains. 

Building AVR Toolchain

 

I have used : binutils-2.17, gcc-4.2-20070719 , avr-libc-1.8.1 to build my toolchain. I choose this versions because it is the base version for the new mcu's support. 

Now when i try to compile the TinyOs applications using v4.2.1 , i'm stuck at the errors like this.

Error Given while compiling with avr-gcc v4.2.1

 

And For v3.3 : binutils-2.13, gcc-3.3 , avr-libc-20030512 are used.

 

Working with avr-gcc v3.3 

 

and additionally : nesc-1.1-1w.cygwin.i386.rpm, tinyos-1.1.0-1.cygwin.noarch.rpm, tinyos-tools-1.1.0-1.cygwin.i386.rpm, galsc-0.1.0-1.cygwin.i386.rpm were installed for both the versions of avr-gcc.

How can i fix this error ? If more information needed, feel free to ask. Thank you in advance .

This topic has a solution.

Thanks and Regards,
Biswajeet Sahoo

Last Edited: Tue. Apr 9, 2019 - 06:31 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You're on Windows. Why on earth wouldn't you just use Atmel/Microchip's latest issue (5.4) ?

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

Thanks for the reply.

 

The actual job is develop a avr-gcc which has support for atmega1281. The current version that is working is avr-gcc v3.3 which doesn't have support for Atmega1281. So i had to look for the gcc which has an support for atmega1281 then make it compatible with TinyOS. Though the compilation i'm doing is for atmega128 which is supported by v3.3 and v4.2.1. 

Thanks and Regards,
Biswajeet Sahoo

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

Atmel's build of avr-gcc 5.4 supports all the AVRs that were in production when it was released (2017/2018) and by "device packs" even some that weren't.

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

Okay thanks.

I'll look search for the build toolchain for avr-gcc v5.4 in internet.

If i don't find them then i'll build for the avr-gcc from gcc v5.4 with binutils v2.29/v2.28 and avr-libc v1.8.1 .

Thanks and Regards,
Biswajeet Sahoo

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

Errors above start at line 54 of clock.h, can you post that file using the "<>" code tag in the edit menu?

 

Jim

 

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274
get $5 free gold/silver https://www.onegold.com/join/713...

 

 

 

 

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

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

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

At Sysprogs is a FSF AVR GCC 5.3 and binutlls 2.25 on Windows :

Prebuilt GNU toolchain for avr

and, in general, build instructions :

Prebuilt GNU Toolchains for Windows - Building your own GNU toolchains

 

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

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

On line number 53, enum declaration ends. I can not add the whole code but find the snippet.

Thanks and Regards,
Biswajeet Sahoo

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

Thanks and i have followed the same steps provided and stuck at those errors. 

Thanks and Regards,
Biswajeet Sahoo

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

I found only this thing searching in internet. Adding it here. Hope it makes some sense.

This is the same error that i'm getting. 

error : stray '$' in program.

Page where i got the above information : Tinyos Install Guide

-------------------------------------------------------------------------

This is a .c file generated from .nc file. While the .c file generation, the '$' is added.

Same file and same formatted code is generated with avr-gcc v3.3 and also with avr-gcc v4.2.1. But it successfully compiles with v3.3 and throws the '$' error in v4.2.1.

/*  The below code is from the generated file app.c.
    And the enum is from Clock.h
*/
enum __nesc_unnamed4256 {
  DEFAULT_SCALE = 3, DEFAULT_INTERVAL = 128
};
static  result_t PotM$Pot$init(uint8_t arg_0x200ab0c8);
static  result_t HPLPotC$Pot$finalise(void);
static  result_t HPLPotC$Pot$decrease(void);
static  result_t HPLPotC$Pot$increase(void);

Snippet From Clock.h

 

Thanks and Regards,
Biswajeet Sahoo

Last Edited: Wed. Feb 27, 2019 - 05:23 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That code is not valid C. The C standard shows that these are the valid characters in symbol names:

 

So apart from a..z, A..Z and 0..9 the only other valid character is '_' so '$' is not valid. It is not C.

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

The C code is generated from nesC (.nc) , based on C standard, how does avr-gcc v3.3 is able to compile the generated code but avr-gcc v4.2 is not able to.

Thanks and Regards,
Biswajeet Sahoo

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

its_bapzz wrote:
how does avr-gcc v3.3 is able to compile
Clearly the old and buggy 3.3 had a serious flaw that was fixed by version 4.2. This is why it's probably unwise to be using compilers from 15..20 years ago as 10's of ,000's of things have been fixed in the intervening years. The most recent issue of avr-gcc is 8.x, the most recent stable release from Atmel dates from 18 months..2 years ago and is 5.4

 

AFAIK there has never been an issue of the C standard where '$' was ever a valid character in a C symbol name. This is the C89 standard documented in 1990:

 

 

Also this is what Kerninghan & Ritchie has to say about C variables...

 

 

Again this is clear it is alphanumeric and the character '_' and nothing else.

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

I understand this, this is the basic thing from C. But my current situation is i'm stuck here.

As nesC is generating the C file and the new gcc is unable to compile. these C files are auto generated and i have no control over it.

 

How to proceed now so that , i can get the new avr-gcc that will be able to compile the .nc(nesC) files. 

 

Thanks and Regards,
Biswajeet Sahoo

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

make a global replace of <$> with <_dollar_>

 

add:

For sure $ is not legal in C, but perhaps "some" preprocessors can eat them and in this case perhaps replace with a number , like  tasknumber (just a guess) 

Last Edited: Wed. Feb 27, 2019 - 12:38 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sparrow2 wrote:
<_dollar_>
Or simply <_> ? ;-)

 

static  result_t PotM_Pot_init(uint8_t arg_0x200ab0c8);
static  result_t HPLPotC_Pot_finalise(void);
static  result_t HPLPotC_Pot_decrease(void);
static  result_t HPLPotC_Pot_increase(void);

is valid C (and arguably more "readable" than the $ version as well!)

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

Sorry, i didn't understand exactly what to do. 

What i understood from this is

make a global replace of <$> with <_dollar_>

I have to replace '$' in the generated C file.

 

Which i have tried but the problem with is approach is, the complete process happens with the starting of accumulating the .nc files and generating a .c file, then the c file is compiled. and throws the error. 

and everything is taken care by a Makefile and i'm currently trying to debug the makefile. 

 

If i try removing the '$' from .c file and compile latter, i get some path issues. i'm currently working/figuring it out by providing the paths absolutely while compiling.

Thanks and Regards,
Biswajeet Sahoo

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

This is why God invented "sed". It's a "command line editor". You can invoke it as a build step between the nesC and the avr-gcc to do the replacement. Unfortunately while AS7 comes with C:\Program Files (x86)\Atmel\Studio\7.0\shellutils I'm afraid that does not contain a copy of sed for WIndows but Google says: http://gnuwin32.sourceforge.net/...

 

 

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

Something like:

C:\One>type test.c
enum __nesc_unnamed4256 {
  DEFAULT_SCALE = 3, DEFAULT_INTERVAL = 128
};
static  result_t PotM$Pot$init(uint8_t arg_0x200ab0c8);
static  result_t HPLPotC$Pot$finalise(void);
static  result_t HPLPotC$Pot$decrease(void);
static  result_t HPLPotC$Pot$increase(void);

C:\One>sed "s/\$/_/g" test.c
enum __nesc_unnamed4256 {
  DEFAULT_SCALE = 3, DEFAULT_INTERVAL = 128
};
static  result_t PotM_Pot_init(uint8_t arg_0x200ab0c8);
static  result_t HPLPotC_Pot_finalise(void);
static  result_t HPLPotC_Pot_decrease(void);
static  result_t HPLPotC_Pot_increase(void);

This has taken the original file with '$' and created a new copy with '_' instead. If I used something like

C:\One>sed "s/\$/_/g" test.c > newtest.c
C:\One>avr-gcc .... newtest.c

then this would compile OK. So it just requires your Makefile or whatever your build system is to invoke sed after the nescc step but before the avr-cc step.

 

 

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

Well i know Mr.Sed pretty well and working with him. With the help of Mr.Sed i'm able to fix the '$' issue but not completely. This is the current issue.

I have replaced the '$' with '.' .

 

If i replace with '-', i get this error

 

 

Previously, this was the error.

 

 

Thanks and Regards,
Biswajeet Sahoo

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

Which bit of posts #12 and #13 did you not follow? You don't get a choice about this. The only valid symbols in C identifiers are a..z, A..Z, 0..9 and _

 

So 

HPLPotC_Pot_finalise

is a valid C symbol.

HPLPotC-Pot-finalise

is not (it would mean "subract finalise from Pot and subtract that from HPLPotC"). Also
 

HPLPotC.Pot.finalise

is not valid either. This talks about a sub-memeber called finalise within a memeber called Pot within an object called HPlPotC

 

C uses pretty much every type of punctuation character (*^/<>[];:%& etc) for various purposes which is why all that is left for symbol names are a..zA..Z0..9_

 

If you did use sed to change $ to _ then explore why that variant won't compile. There must be something else in the file that an accurate C compiler does not see as being valid C.

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

After some googling, I found this obscure gcc option: -fdollars-in-identifiers

This will enable the dollar sign as valid. Apparently, many years ago it was the default, now it's -fno-dollars-in-identifiers.

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

Let me explain the scenario.

 

If i use '_', i get this error.

 

So i looked for the functions of .nc and how it is.

For Example:

This is the generated code function.

So i looked for the declaration, and it was like this

and 

 

That's why i used '.' for replacing purpose.

 

Thanks and Regards,
Biswajeet Sahoo

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

clawson wrote:
I'm afraid that does not contain a copy of sed for WIndows but Google says: http://gnuwin32.sourceforge.net/...
or via MSYS :

https://github.com/msys2/MSYS2-packages/tree/master/sed

due to MSYS2 homepage

Reason : one instance of FSF GCC is built by tools in MSYS

 

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

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

Thanks a lot for this. 

 

Now i'm having this error. 

 

ncc invokes avr-gcc. but even if i absolutely compile the generated .c file through avr-gcc, i'm still getting the same error.

 

This is the snippet for the HPLClock.nc

Thanks and Regards,
Biswajeet Sahoo

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

its_bapzz wrote:

 

If i use '_', i get this error.

 

 

So by replacing the '$' with '_' giving the same error with the passing the  -fdollars-in-identifiers flag to gcc.

Thanks and Regards,
Biswajeet Sahoo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
This is the link that i found for fixing the bug for gcc w.r.t the internal compiler error. I looked for the diff provided and cross checked with the gcc that i have built and it has the required changes. 

As the bug that was generated for nake_attribute.c but for my case it is generated for HPLClock.nc .

 

Here's the Link : attribute "naked" on target AVR generate internal compiler error

Thanks and Regards,
Biswajeet Sahoo

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

its_bapzz wrote:

 

 

This is the snippet for the HPLClock.nc

 

How can i proceed forward ?

Thanks and Regards,
Biswajeet Sahoo

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

Can I suggest a different approach? When I google "TinyOS" I arrive here:

 

https://en.wikipedia.org/wiki/Ti...

 

That contains:

 

So from the 1.0 you are trying to use there were 10 years on ongoing development beyond that. I am willing to bet that this "$" issue was dropped very soon after 2002 !

 

Yet another approach would be to use a completely different OS for AVR. I compiled a list here:

 

https://www.avrfreaks.net/forum/...

 

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

try adding -fdollars-in-identifiers as argument to your gcc command.

 

Oops.  Missed the fine print: you tried.   It is accepted in my 5.4 version.

Last Edited: Fri. Mar 1, 2019 - 10:52 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

We can not change the TinyOs 1.x as many applications were developed on this. As i'm trying to build the applications for Atmega1281 (precisely) which is not supported by v3.3, that's why i'm opted for v4.2. 

 

I will try to compile the v5.4 as everyone has suggested. 

 

If there is any other way that i can add the architecture support for atmega1281 in avr-gcc v3.3 would be a worth a try.

Thanks and Regards,
Biswajeet Sahoo

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

Thanks i'll try building v5.4.

 

Which version of binutils, avr-libc, nesc, and tinyos you are using ?

 

It would be a great help to know the versions you have used.

Thanks and Regards,
Biswajeet Sahoo

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

I tried with many builds, different toolchains and nothing worked out.

But found out that the TinyOs1.x has some dependencies towards the libraries generated by avr-libc-cvs2003. 

And also, while executing the makefile, it was looking for avr-gcc-3.3tinyos.exe rather than avr-gcc.exe .

 

So in the end, i added support for ATmega1281 to my current toolchain and it worked.

Thanks and Regards,
Biswajeet Sahoo