TestLinkLocalC compilation Problem Solved

[md-jamal]

Unable to compile the TestLinkLocalC Application present in the $(TOSDIR)/apps/blip/TestLinkLocal

Problem was it was unable to locate the printfUart.h directory and IN6_Prefix was not defined.

TestRPL application and PppRouter was also having same problem. This pull will solve it

[bradjc]

Thanks for fixing the test apps.

One question though, does PppRouterC.nc need components PrintfC,SerialStartC; in it for you to compile it? I can compile without that line, and adding it seems to dramatically increase the ROM/RAM required for the application. I looked back at an older version of PPPRouter and it did not have those components in there.

[md-jamal]

I was getting the following error when i compiled the PppRouter

PppRouterP.nc: In function ‘PppRouterP__Boot__booted’:
PppRouterP.nc:57:11: warning: unused variable ‘rc’
/usr/lib/gcc/msp430/4.5.3/../../../../msp430/bin/ld: build/telosb/main.exe section .text' will not fit in regionrom'
/usr/lib/gcc/msp430/4.5.3/../../../../msp430/bin/ld: section .vectors loaded at [0000ffe0,0000ffff] overlaps section .text loaded at [00004000,00010799]
/usr/lib/gcc/msp430/4.5.3/../../../../msp430/bin/ld: region rom' overflowed by 2190 bytes /tmp/ccfwak9S.o: In functionprintf_ieee154addr':
app.c:(.text+0x1184): undefined reference to putchar' /tmp/ccfwak9S.o: In functionIPForwardingEngineP__IPForward__send':
app.c:(.text+0x3956): undefined reference to putchar' app.c:(.text+0x3a9c): undefined reference toputchar'
app.c:(.text+0x3ab8): undefined reference to putchar' /tmp/ccfwak9S.o: In functionIPProtocolsP__IP__send':
app.c:(.text+0x4868): undefined reference to putchar' /tmp/ccfwak9S.o:app.c:(.text+0x48c6): more undefined references toputchar' follow
collect2: ld returned 1 exit status
make: *** [exe] Error 1

One solution is to either comment the following line in the Makefile

PFLAGS += -DNEW_PRINTF_SEMANTICS -DPRINTFUART_ENABLED

or either if we add PrintfC,SerialStartC to the Configuration File.

As you said if we add this it will not fit in the Telosb so, its better to comment it

[bradjc]

or either if we add PrintfC,SerialStartC to the Configuration File.

Wait, adding that line causes PppRouter to fit on the msp430?

My testing:

make telosb with PRINTFUART_ENABLED set; no PrintfC,SerialStartC components:

/usr/lib/gcc/msp430/4.6.3/../../../../msp430/bin/ld: region `rom' overflowed by 4244 bytes

make telosb with PRINTFUART_ENABLED set; PrintfC,SerialStartC components:

/usr/lib/gcc/msp430/4.6.3/../../../../msp430/bin/ld: region `rom' overflowed by 7670 bytes

make telosb with PRINTFUART_ENABLED unset; no PrintfC,SerialStartC components:

/usr/lib/gcc/msp430/4.6.3/../../../../msp430/bin/ld: region `rom' overflowed by 1536 bytes

Given that all variations compile (even if they don't fit on the microcontroller) I don't see what we gain by adding components PrintfC,SerialStartC;.

[md-jamal]

Its better to comment the PRINTFUART_ENABLED in the Makefile and remove those components (PrintfC,SerialStartC) from the configuration File.

When i compile the PppRouter with Commented PRINTFUART_ENABLED and no components in the Configuration

     48608 bytes in ROM
      9564 bytes in RAM

I think it is the compiler version , i am using 4.5.3..

So previous commit(e232985) solves the problem

[cire831]

4.5.3 has serious problems.

You need to be using 4.6.3

On Wed, Aug 13, 2014 at 9:10 PM, md-jamal [email protected] wrote:

Its better to comment the PRINTFUART_ENABLED in the Makefile and remove
those components (PrintfC,SerialStartC) from the configuration File.

When i compile the PppRouter with Commented PRINTFUART_ENABLED and no
components in the Configuration

 48608 bytes in ROM
  9564 bytes in RAM

I think it is the compiler version , i am using 4.5.3..

So previous commit(e232985
e232985)
solves the problem

—
Reply to this email directly or view it on GitHub
#303 (comment).

Eric B. Decker
Senior (over 50 :-) Researcher

[md-jamal]

Can i get the upgrade link for msp430-4.6.3

[md-jamal]

After installing 4.6.3(struggle), and compiling ppprouter,

`rom' overflowed by 1536 bytes

[cire831]

understood.

4.5.3 still has known problems. that was why it was deprecated and
replaced with 4.6.3

Under certain circumstances it generates incorrect code.

On Wed, Aug 13, 2014 at 10:35 PM, md-jamal [email protected] wrote:

After installing 4.6.3(struggle), and compiling ppprouter,

`rom' overflowed by 1536 bytes

—
Reply to this email directly or view it on GitHub
#303 (comment).

Eric B. Decker
Senior (over 50 :-) Researcher

[md-jamal]

Then how we can use Ppprouter application??

[cire831]

On Wed, Aug 13, 2014 at 11:43 PM, md-jamal [email protected] wrote:

Then how we can use Ppprouter application??

a) use a different mote with more memory.

b) look at the memory map of the ppprouter application and figure out what
can be cut out. that will reduce the rom size.

there are good reasons that the Umich folks have gone to using a Raspberry
Pi for a border router.

—
Reply to this email directly or view it on GitHub
#303 (comment).

Eric B. Decker
Senior (over 50 :-) Researcher

[md-jamal]

No problems for us, because we have built a border router on beaglebone black with cc2520 driver and the driver is also accepted by the linux community

[cire831]

On Thu, Aug 14, 2014 at 12:06 AM, md-jamal [email protected] wrote:

No problems for us, because we have built a border router on beaglebone
black with cc2520 driver and the driver is also accepted by the linux
community

that makes a whole lot more sense than trying to shoe horn this code into a
1611 with 48K ROM and 10K RAM.

Some things are just plain silly.

—
Reply to this email directly or view it on GitHub
#303 (comment).

Eric B. Decker
Senior (over 50 :-) Researcher

[gnawali]

It will be great if we can contribute both Raspberry Pi and Beaglebone-based solution to TinyOS repository. Would make IPv6 more usable.

[md-jamal]

Its basically available in the linux source , again contributing to tinyos means ??

[gnawali]

Updating blip documentation and any scripts needed to configure/run.

[md-jamal]

Actually linux 6lowpan stack requires neighbor discovery to communicate (ping etc)..I developed whole neighbor discovery stack according to RFC 6775 and tested with the linux 6lowpan stack, also created a pull request but i think no one in the community is interested

[cire831]

On Thu, Aug 14, 2014 at 12:25 AM, md-jamal [email protected] wrote:

Actually linux 6lowpan stack requires neighbor discovery to communicate
(ping etc)..I developed whole neighbor discovery stack according to RFC
6775 and tested with the linux 6lowpan stack, also created a pull request
but i think no one in the community is interested

Oh contraire. Very interested.

The problem is finding someone with reasonable knowledge to review the code.

I've asked Brad (who does have the knowledge) to review it but
unfortunately he is extremely busy with other things.

I don't have the requisit knowledge.

—
Reply to this email directly or view it on GitHub
#303 (comment).

Eric B. Decker
Senior (over 50 :-) Researcher

[md-jamal]

Oh then it's OK,but i have added this neighbor discovery code some time in the last year,but this is a lot of time enough to test,and there is no need of brad to again make neighbor discovery code when it is already present

[cire831]

yeah I know its frustrating how long things take.

Brad did some great work on the new make system and it took me forever to
review and pull it in. Between things I needed to be paying attention for
other things and other distractions it kept falling off the radar.

I suspect the same thing is happening with your submission.

sorry about that.

On Thu, Aug 14, 2014 at 12:41 AM, md-jamal [email protected] wrote:

Oh then it's OK,but i have added this neighbor discovery code some time in
the last year,but this is a lot of time enough to test,and there is no need
of brad to again make neighbor discovery code when it is already present

—
Reply to this email directly or view it on GitHub
#303 (comment).

Eric B. Decker
Senior (over 50 :-) Researcher

[ppannuto]

@md-jamal I just looked at #295, and that needs be cleaned up a lot before anyone can reasonably be asked to look at it. For example, the last commit removes large chunks of code added by previous commits in the same series? It looks like I had a number of comments on the first commit that were never addressed as well (I'm guessing that @bradjc was waiting for these to be dealt with before looking at it). Lastly, since it's been sitting for a while, it no longer merges cleanly, which also needs to be fixed before anyone can look at it.

To update the patchset attached to the PR, you can rebase and otherwise update that branch locally to get it into a state that's ready for review, and then simply git push -f origin nd-rfc6775

[md-jamal]

@ppannuto Updated the Patchset .Please review the code. If there is need for any changes,i will change it