Re: [PATCH] bsp; Fix linker error for nrf51_arduino target

[Johan Hedberg]

Hi,

It seems you lost both the commit message and the author information
when applying the patch. It looks as follows in the commit history:

commit a4f466e542120950f012aa15908ac9a0f8ff1332
Author: Sterling Hughes 
Date:   Fri May 20 11:32:41 2016 -0500

apply patch to fix arduino 101 build

Since Łukasz took the effort of using git send-email to send it the
proper way to apply it would have been by using git am. I realize this
is a fairly trivial patch, but since it might not be the last one that
comes through the mailing list instead of github it'd be good to get
this process right as well.

Johan

On Fri, May 20, 2016, Sterling Hughes wrote:
> thanks - looks good, and applied.  dev should be up to date.
> 
> sterling
> 
> On 5/20/16 6:25 AM, Łukasz Rymanowski wrote:
> > This patch renames os_bsp_init to bsp_init to make nrf51_arduino
> > build.
> > ---
> >   hw/bsp/nrf51-arduino_101/src/os_bsp.c | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/hw/bsp/nrf51-arduino_101/src/os_bsp.c 
> > b/hw/bsp/nrf51-arduino_101/src/os_bsp.c
> > index b9d52e4..888519b 100644
> > --- a/hw/bsp/nrf51-arduino_101/src/os_bsp.c
> > +++ b/hw/bsp/nrf51-arduino_101/src/os_bsp.c
> > @@ -70,7 +70,7 @@ bsp_imgr_current_slot(void)
> >   }
> > 
> >   void
> > -os_bsp_init(void)
> > +bsp_init(void)
> >   {
> >   /*
> >* XXX this reference is here to keep this function in.
> > 

Re: [PATCH] bsp; Fix linker error for nrf51_arduino target

[Łukasz Rymanowski]

Hi Aditi,

By sign up you mean subscribe? Because I did subscribe just before sending
patch.

Br
Lukasz
20 maj 2016 21:09 "aditi hilbert"  napisał(a):

> Lukasz,
>
> Thanks - and do sign up for our dev@ mailing list :)
>
> aditi
>
> > On May 20, 2016, at 9:33 AM, Sterling Hughes 
> wrote:
> >
> > thanks - looks good, and applied.  dev should be up to date.
> >
> > sterling
> >
> > On 5/20/16 6:25 AM, Łukasz Rymanowski wrote:
> >> This patch renames os_bsp_init to bsp_init to make nrf51_arduino
> >> build.
> >> ---
> >>  hw/bsp/nrf51-arduino_101/src/os_bsp.c | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/hw/bsp/nrf51-arduino_101/src/os_bsp.c
> b/hw/bsp/nrf51-arduino_101/src/os_bsp.c
> >> index b9d52e4..888519b 100644
> >> --- a/hw/bsp/nrf51-arduino_101/src/os_bsp.c
> >> +++ b/hw/bsp/nrf51-arduino_101/src/os_bsp.c
> >> @@ -70,7 +70,7 @@ bsp_imgr_current_slot(void)
> >>  }
> >>
> >>  void
> >> -os_bsp_init(void)
> >> +bsp_init(void)
> >>  {
> >>  /*
> >>   * XXX this reference is here to keep this function in.
> >>
>
>

Re: core files, memory to include

[marko kiiskila]

Hi all,

package for coredumps is now checked into develop branch for
core and newt. This is for offline analysis of things that went wrong.

To use this, you must include the sys/coredump package in your
app’s pkg.yml file. Now,  if you get an unhandled exception, or
your app asserts, we try to collect a coredump.

This at the moment goes to flash, on the 2nd image slot. If
there already is a corefile there, it will not be overwritten.
If there is an image there, it will be overwritten.

To get the coredump out of the target, use newtmgr.
'newtmgr -c  image corelist’ shows if core is present.
‘newtmgr -c  image coredownload ’ loads the coredump,
converts it into ELF format, and places it in .
‘newtmgr -c  image coreerase’ removes this coredump
from the target.

After you have this corefile you can inspect it along with the elf file
which generated it. Now, the version of gdb we use does not have
support for corefiles, so you’ll need to build a new one.

Here’s what I did for this:
On Mac:
tar xvzf gdb-7.8.1.tar.gz
cd gdb-7.8.1
./configure --target=arm-elf-linux --without-lzma --without-guile 
--without-libunwind-ia64 --with-zlib
make
gdb/gdb -v

And with Linux (I’m running Ubuntu 14.04):
sudo apt-get install zlibc zlib1g zlib1g-dev libexpat-dev libncurses5-dev 
liblzma-dev
tar xvzf gdb-7.8.1.tar.gz
cd gdb-7.8.1
./configure --target=arm-elf-linux --with-lzma --with-expat 
--without-libunwind-ia64 --with-zlib --without-babeltrace
make
gdb/gdb -v

And this is what it should look like:
[marko@IsMyLaptop:~/src/incubator-mynewt-blinky]$ newtmgr -c olimex image 
corelist
Corefile present
[marko@IsMyLaptop:~/src/incubator-mynewt-blinky]$ newtmgr -c olimex image 
coredownload ~/core
Coredump download completed
Corefile created for
   bfae72e4d51761bf987329e40a44d9cca6926741a88684725c25f94095c00c7d
[marko@IsMyLaptop:~/src/incubator-mynewt-blinky]$ arm-elf-linux-gdb 
bin/slinky_zero/apps/slinky/slinky.elf ~/core
GNU gdb (GDB) 7.8.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=x86_64-apple-darwin14.5.0 
--target=arm-elf-linux".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from bin/slinky_zero/apps/slinky/slinky.elf...done.
[New process 1]
#0  0xc234 in coredump (argc=, argv=)
at main.c:258
258 *(int *)0x7f0 = 0;
(gdb) list
253 if (argc < 2) {
254 console_printf("Need more args: hf | assert | reset\n");
255 return 0;
256 }
257 if (!strcmp(argv[1], "hf")) {
258 *(int *)0x7f0 = 0;
259 } else if (!strcmp(argv[1], "assert")) {
260 assert(0);
261 } else if (!strcmp(argv[1], "reset")) {
262 system_reset();
(gdb) bt
#0  0xc234 in coredump (argc=, argv=)
at main.c:258
#1  0x000153f0 in shell_cmd (argc=2, argv=0x200011b4 , 
cmd=0x20005500 "core") at shell.c:169
#2  shell_process_command (line=, len=len@entry=7)
at shell.c:199
#3  0x0001556e in shell_read_console () at shell.c:445
#4  shell_task_func (arg=) at shell.c:481
#5  0x in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) info reg
r0 0x0  0
r1 0x1a848  108616
r2 0x0  0
r3 0x7f0134217712
r4 0x20005505   536892677
r5 0x20d0   536871120
r6 0x20005500   536892672
r7 0x20001240   536875584
r8 0xc  12
r9 0x1c 28
r100xc  12
r110x13 19
r120x2a 42
sp 0x20002478   0x20002478 
lr 0xc22d   49709
pc 0xc234   0xc234 
cpsr   0x6100   1627389952
(gdb) 

The coredump contains the hash of the image which generated it.
So you can eyeball that one against the image you built and make sure
that you have elf file which matches your core.

Let me know if you give this a go,
M

> On May 17, 2016, at 1:45 PM, marko kiiskila  wrote:
> 
> It would be quite a bit of work for a very specialized feature :)
> Modifying BSP’s array of memory regions should be easy
> enough to do in the cases where peripheral memory is
> wanted, IMHO.
> 
>> On May 17, 2016, at 1:31 PM, will sanfilippo  wrote:
>> 
>> Sounds good. I see if you have an array at the bsp you could just add the 
>> peripherals to 

Re: [DISCUSS] A users@ mailing list for Apache Mynewt

[Justin Mclean]

Hi,

> I agree 100% on the mail archive. If we could tee this off to a better 
> interface (more intuitive threading and search) and maintain sync, that would 
> help the community a lot.

And that exists! [1] On Other project we’ve also set up forums to mirror the 
mailing lists at nibble [2]. Does anyone one want me to do that? The mailing 
list are also archived and searchable here [3]

1. https://lists.apache.org/list.html?d...@mynewt.apache.org
2. http://www.nabble.com
3. http://apache.markmail.org/search/?q=list%3Aorg.apache.mynewt.dev

Thanks,
Justin

Re: [DISCUSS] A users@ mailing list for Apache Mynewt

[Marvin Humphrey]

On Fri, May 20, 2016 at 8:04 AM, James Pace  wrote:
> I agree 100% on the mail archive. If we could tee this off to a better
> interface (more intuitive threading and search) and maintain sync, that
> would help the community a lot.

There's now https://lists.apache.org/list.html?mynewt.apache.org announced
publicly last week at ApacheCon, which is slated to replace the existing
interface.

> I am also a newbie to the ASF, but wondering if someone in the
> infrastructure or incubator group might have some thoughts or heard this
> before. We can inquire at gene...@incubator.apache.org, which I’ll do.

What we in the Incubator have observed over the years is that when podlings
are just starting out and trying to expand their communities, it is better to
have all the user questions on one list.  Thus the default for new communities
is a single list.  (Here's the advice page:
.)

Eventually a community may grow to the size that it needs a separate user
list.  There's no exact threshold, but eventually it becomes clear.

Marvin Humphrey

Re: [DISCUSS] Release Apache Mynewt 0.9.0-incubating-rc1

[Christopher Collins]

All,

It is certainly not a big problem, but it is best if discussion about
the release goes in the [DISCUSS] thread rather than the [VOTE] thread.
Reserving the [VOTE] thread for votes makes it easy for lazy people such
as myself to produce a tally when the vote closes.

Please don't interpet this petty admonition as a request to stop the
conversation!

Thanks,
Chris

On Fri, May 20, 2016 at 09:05:40PM +0200, Kevin Townsend wrote:
> Hi Will,
> 
> Great, thanks.  I don't expect BLE emulation like the HAL layer, but it 
> is nice to be able to build to test shell commands and some basic logic 
> like DSP algorithms on the orientation sensors, etc.
> 
> K.
> 
> On 20/05/16 20:03, will sanfilippo wrote:
> > All:
> >
> > I committed a fix for the native ble build. Basically had to add a bunch of 
> > stubs to the phy and also include the xcvr.h header file. If there are any 
> > other issues please let me know.
> >
> > Will
> >
> >> On May 19, 2016, at 7:38 AM, Kevin Townsend  wrote:
> >>
> >> Hi Chris,
> >>
> >> Sorry this may be an old issue then so feel free to ignore. I understand
> >> that native emulation of the BLE stack doesn't currently work and there are
> >> other priorities, but copying that one file at least allows me to build a
> >> basic project to test some custom shell commands and make sure the command
> >> parsing works as expected etc.
> >>
> >> I'll wait for some feedback though to know what he plans are around nimble
> >> plus native mode. It was a 30 second issue to fix with my artificial test 
> >> case
> >> today but maybe there are other issues I'm not aware of down the road since
> >> I haven't started digging into nimble yet.
> >>
> >> K.
> 

Re: [PATCH] bsp; Fix linker error for nrf51_arduino target

[aditi hilbert]

Lukasz,

Thanks - and do sign up for our dev@ mailing list :)

aditi

> On May 20, 2016, at 9:33 AM, Sterling Hughes  wrote:
> 
> thanks - looks good, and applied.  dev should be up to date.
> 
> sterling
> 
> On 5/20/16 6:25 AM, Łukasz Rymanowski wrote:
>> This patch renames os_bsp_init to bsp_init to make nrf51_arduino
>> build.
>> ---
>>  hw/bsp/nrf51-arduino_101/src/os_bsp.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/hw/bsp/nrf51-arduino_101/src/os_bsp.c 
>> b/hw/bsp/nrf51-arduino_101/src/os_bsp.c
>> index b9d52e4..888519b 100644
>> --- a/hw/bsp/nrf51-arduino_101/src/os_bsp.c
>> +++ b/hw/bsp/nrf51-arduino_101/src/os_bsp.c
>> @@ -70,7 +70,7 @@ bsp_imgr_current_slot(void)
>>  }
>> 
>>  void
>> -os_bsp_init(void)
>> +bsp_init(void)
>>  {
>>  /*
>>   * XXX this reference is here to keep this function in.
>> 

Re: [VOTE] Release Apache Mynewt 0.9.0-incubating-rc1

[Kevin Townsend]

Hi Will,

Great, thanks.  I don't expect BLE emulation like the HAL layer, but it 
is nice to be able to build to test shell commands and some basic logic 
like DSP algorithms on the orientation sensors, etc.


K.

On 20/05/16 20:03, will sanfilippo wrote:

All:

I committed a fix for the native ble build. Basically had to add a bunch of 
stubs to the phy and also include the xcvr.h header file. If there are any 
other issues please let me know.

Will


On May 19, 2016, at 7:38 AM, Kevin Townsend  wrote:

Hi Chris,

Sorry this may be an old issue then so feel free to ignore. I understand
that native emulation of the BLE stack doesn't currently work and there are
other priorities, but copying that one file at least allows me to build a
basic project to test some custom shell commands and make sure the command
parsing works as expected etc.

I'll wait for some feedback though to know what he plans are around nimble
plus native mode. It was a 30 second issue to fix with my artificial test case
today but maybe there are other issues I'm not aware of down the road since
I haven't started digging into nimble yet.

K.

Re: [VOTE] Release Apache Mynewt 0.9.0-incubating-rc1

[will sanfilippo]

All:

I committed a fix for the native ble build. Basically had to add a bunch of 
stubs to the phy and also include the xcvr.h header file. If there are any 
other issues please let me know.

Will

> On May 19, 2016, at 7:38 AM, Kevin Townsend  wrote:
> 
> Hi Chris,
> 
> Sorry this may be an old issue then so feel free to ignore. I understand
> that native emulation of the BLE stack doesn't currently work and there are
> other priorities, but copying that one file at least allows me to build a
> basic project to test some custom shell commands and make sure the command
> parsing works as expected etc.
> 
> I'll wait for some feedback though to know what he plans are around nimble
> plus native mode. It was a 30 second issue to fix with my artificial test case
> today but maybe there are other issues I'm not aware of down the road since
> I haven't started digging into nimble yet.
> 
> K.

Re: [VOTE] Release Apache Mynewt 0.9.0-incubating-rc1

[will sanfilippo]

The vote is open for at least 72 hours and passes if a majority of at
least three +1 PPMC votes are cast.

[ X] +1 Release this package
[ ]  0 I don't feel strongly about it, but don't object
[ ] -1 Do not release this package because…

+1 binding

Will

Re: [VOTE] Release Apache Mynewt 0.9.0-incubating-rc1

[Christopher Collins]

On Wed, May 18, 2016 at 11:26:50PM -0700, Christopher Collins wrote:
> [X] +1 Release this package
> [ ]  0 I don't feel strongly about it, but don't object
> [ ] -1 Do not release this package because...

+1 (binding)

Thanks,
Chris

Re: [DISCUSS] Release Apache Mynewt 0.9.0-incubating-rc1

[will sanfilippo]

Unfortunately we dont really support the native bsp for ble as of yet. I 
normally compiled it regularly but it was not used for any particular purpose 
so I had neglected it in this release (my bad).

I will make sure it compiles. In the future it would be nice to create a sim 
project that can simulate a device to some extent (to what extent would be 
interesting to get opinions on).

Will

> On May 19, 2016, at 7:31 AM, Christopher Collins  wrote:
> 
> On Thu, May 19, 2016 at 11:30:05AM +0200, Kevin Townsend wrote:
>> I'm running in 'develop' which may not be the right branch, but 
>> switching a bare bones BLE project to 'native' as a BSP generates this 
>> error:
>> 
>> $ newt build bleuart
>> Building target targets/bleuart
>> Compiling ble_ll_adv.c
>> Error: ble_ll_adv.c:24:22: fatal error: ble/xcvr.h: No such file or 
>> directory
>> compilation terminated.
>> 
>> Copying the header from here 
>> (https://github.com/apache/incubator-mynewt-core/tree/develop/net/nimble/drivers/nrf51/include/ble)
>>  
>> solves this but the file should probably exist in 
>> net/nimble/drivers/native as well, right?
>> 
>> If 'develop' corresponds to 0.9.0-rc1 I can submit a pull request if 
>> develop is the right branch for this?
> 
> Hi Kevin,
> 
> The develop branch should be identical to the release candidate, so any
> issues you are seeing also exist in 0.9.0-rc1.  Just for my own
> clarification, is the issue you describe new to 0.9.0-rc1?  I was under
> the impression that native support for the nimble controller
> has never worked, and that it has been on the todo list for a while.
> 
> If you have a fix for the compiler error, then I am sure a pull request
> would probably be welcome.  Will is more familiar with the nimble
> controller, so I think I will let him and others chime in.
> 
> Thanks,
> Chris

Re: [VOTE] Release Apache Mynewt 0.9.0-incubating-rc1

[marko kiiskila]

> On May 18, 2016, at 11:26 PM, Christopher Collins  wrote:
> 
> Hello all,
> 
> I am pleased to be calling this vote for the source release of Apache
> Mynewt 0.9.0. Given that it is version 0.x, it is still a bit of a beta.
> 
...
> 
> The vote is open for at least 72 hours and passes if a majority of at
> least three +1 PPMC votes are cast.
> 
> [ ] +1 Release this package
> [ ]  0 I don't feel strongly about it, but don't object
> [ ] -1 Do not release this package because...
> 
> Anyone can participate in testing and voting, not just committers,
> please feel free to try out the release candidate and provide your
> votes.
> 

+1. This drop works for me.

Re: [PATCH] bsp; Fix linker error for nrf51_arduino target

[Sterling Hughes]

thanks - looks good, and applied.  dev should be up to date.

sterling

On 5/20/16 6:25 AM, Łukasz Rymanowski wrote:

This patch renames os_bsp_init to bsp_init to make nrf51_arduino
build.
---
  hw/bsp/nrf51-arduino_101/src/os_bsp.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/bsp/nrf51-arduino_101/src/os_bsp.c 
b/hw/bsp/nrf51-arduino_101/src/os_bsp.c
index b9d52e4..888519b 100644
--- a/hw/bsp/nrf51-arduino_101/src/os_bsp.c
+++ b/hw/bsp/nrf51-arduino_101/src/os_bsp.c
@@ -70,7 +70,7 @@ bsp_imgr_current_slot(void)
  }

  void
-os_bsp_init(void)
+bsp_init(void)
  {
  /*
   * XXX this reference is here to keep this function in.

[PATCH] bsp; Fix linker error for nrf51_arduino target

[Łukasz Rymanowski]

This patch renames os_bsp_init to bsp_init to make nrf51_arduino
build.
---
 hw/bsp/nrf51-arduino_101/src/os_bsp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/bsp/nrf51-arduino_101/src/os_bsp.c 
b/hw/bsp/nrf51-arduino_101/src/os_bsp.c
index b9d52e4..888519b 100644
--- a/hw/bsp/nrf51-arduino_101/src/os_bsp.c
+++ b/hw/bsp/nrf51-arduino_101/src/os_bsp.c
@@ -70,7 +70,7 @@ bsp_imgr_current_slot(void)
 }
 
 void
-os_bsp_init(void)
+bsp_init(void)
 {
 /*
  * XXX this reference is here to keep this function in.
-- 
2.7.4

Re: [DISCUSS] A users@ mailing list for Apache Mynewt

[David G. Simmons]

As a n00b, I’ll chime in here with my experience so far … Just my $0.02, so 
take it as you will. I’ve been involved in a few ‘new’ 
product/protocol/platform development efforts over the years though.

As a new user and (potential) developer, the lack of a ‘user’ list was (as 
another has previously stated) a bit intimidating. I’m not (yet) a mynewt 
developer, just a hacker trying to get stuff working. I finally bit the bullet 
and posted to the dev list and was obviously pleasantly surprised by both the 
speed and friendliness of the response. There is a LOT of value in having the 
folks actually developing the system see all the questions from the users. I 
know it can be a distraction from the ‘real’ work to get silly questions from 
new users, but in my experience, the success of a platform is in many ways 
highly dependent on the experience of new users. If someone new can’t start 
using the platform, then you wont’ have new users, and …

I found the archives, and attempted to go through them as best I could in order 
to find answers to questions I was having initially. I figured most of them out 
on my own, from repeated trips through the docs, etc., but the email archives 
could be much more helpful. The problem is that the mail archives are … so 
1998. Not searchable, only navigable by year/month, etc. Having a proper 
interface to the mail archives would make them much more useful to users. Even 
the mail-archive.com interface — which has search — would work nicely. Having a 
forum — along the lines of phpBB2, though those are notoriously hard to keep 
spammers out of — with an email-to-forum gateway would also be helpful.

Back to hacking …

dg




> On May 19, 2016, at 4:42 PM, James Pace  wrote:
> 
> I’d personally like to see these separated. Many of the comments that are 
> coming in are routine (though very informative) and do not inform the design 
> or development of Apache Mynewt.
> 
> And, besides, it is likely that you will have “user” and “dev”  sourced to 
> the same mailbox or mail filter!
> 
> On May 19, 2016, at 11:12, p...@wrada.com wrote:
> 
>> I¹d prefer to keep them together for now.  As this is new, I think that
>> developers are going to learn a lot from the users issues or questions,
>> and vice versa.  I agree that this will get too much at some point, but
>> I¹m really getting a lot from seeing the user and developer issues
>> together.
>> 
>> 
>> On 5/19/16, 11:08 AM, "aditi hilbert"  wrote:
>> 
>>> Hi,
>>> 
>>> With Mynewt attracting an increasing number of both users and developers
>>> of various levels, it might make practical sense to have a users@ mailing
>>> list separate from dev@ mailing list. That way support questions about
>>> product usage, asks, needs etc can be separated from
>>> developer/design/architecture discussions. Of course, there has to be
>>> communication between the two groups to build truly useful and usable
>>> features, but we can bring some organization to it with the separate
>>> mailing lists. Please comment on the suggestion.
>>> 
>>> Let¹s keep this thread open through the weekend to gauge the general
>>> response.
>>> 
>>> thanks,
>>> aditi
>> 
> 

--
David G. Simmons
(919) 534-5099
Web • Blog • Linkedin • Twitter • GitHub
/** Message digitally signed for security and authenticity.
 * If you cannot read the PGP.sig attachment, please go to
 * http://www.gnupg.com/ Secure your email!!!
 * Public key available at keyserver.pgp.com
**/
♺ This email uses 100% recycled electrons. Don't blow it by printing!

There are only 2 hard things in computer science: Cache invalidation, naming 
things, and off-by-one errors.




signature.asc
Description: Message signed with OpenPGP using GPGMail

Problems building bootloader for Arduino 101

[Bjorkengren, Ulf]

Hi,

I am trying to build the bootloader for Arduino 101, following the instructions 
on https://www.zephyrproject.org/doc/board/arduino_101_ble.html.

The target creation seems to have worked ok.

$ newt target show
targets/blehci
app=@apache-mynewt-core/apps/blehci
bsp=@apache-mynewt-core/hw/bsp/nrf51-arduino_101
build_profile=optimized
targets/boot
app=@apache-mynewt-core/apps/boot
bsp=@apache-mynewt-core/hw/bsp/nrf51-arduino_101
build_profile=optimized
targets/my_blinky_sim
app=apps/blinky
bsp=@apache-mynewt-core/hw/bsp/native
build_profile=debug

But when I try to build the bootloader i get a linker error
$ newt build boot
Compiling base64.c
Compiling cbmem.c

Compiling fs_mount.c
Compiling fsutil.c
Archiving fs.a
Linking boot.elf
/home/ubjorken/projects/mynewt/mynewt-projects/arduino101_controllerfw/bin/boot/libs/os/os.a(os_arch_arm.o):
 In function `os_arch_os_init':
/home/ubjorken/projects/mynewt/mynewt-projects/arduino101_controllerfw/repos/apache-mynewt-core/libs/os/src/arch/cortex_m0/os_arch_arm.c:218:
 undefined reference to `bsp_init'
collect2: error: ld returned 1 exit status
Error: exit status 1

I get the same error when trying to build the blehci app. 

I am running Ubuntu 12.04

Best regards,
Ulf
--
Intel Sweden AB
Registered Office: Isafjordsgatan 30B, 164 40 Kista, Stockholm, Sweden
Registration Number: 556189-6027

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: BLE Stack

[Sterling Hughes]

Hi Vitya,

On 5/19/16 5:42 AM, Vitya Gnatyuk wrote:

Hi! I earlier wrote you on github as gnatyukv. I forgot to ask a main
qustion. May your projects (from the apps folder) be compiled in Keil IDE?
How to do it? I have uVision V5.17 and Armcc compiler. I cannot compile
your code yet. Maybe another compiler (GCC) needed?



Unfortunately we don't support the armcc compiler yet.  You are correct, 
it needs GCC to compile.


A fair amount of the code uses GCC specific features, that said: it 
shouldn't be too hard to make it agnostic to compiler platform.  If 
you'd like to take on the project, I'd be happy to support you as you 
make the changes.


I think the easiest way to go would be to pick a few libraries, get them 
compiling with ARM's compiler, and then send a mail to the dev@ list 
with the changes we need to make (i.e. "DON'T explcitly used 
__attribute__((packed))") -- and then everyone else will pitch and help 
convert things over so the code cleanly compiles with both GCC and ARM.


Hope this helps.

Best,

Sterling

Re: [DISCUSS] A users@ mailing list for Apache Mynewt

[Wayne Keenan]

I think a user mailing list would be a GoodIdea(tm).

As a first time 'user' I was initially reluctant to post to the 'dev'
mailing list to ask a question which I thought wasn't strictly
'developer/design/architecture'
related.

It turned out your all a friendly and very helpful bunch, so all was cool
even after going thru what I thought was the wrong door :)

All the best
Wayne

On 19 May 2016 at 21:42, James Pace  wrote:

> I’d personally like to see these separated. Many of the comments that are
> coming in are routine (though very informative) and do not inform the
> design or development of Apache Mynewt.
>
> And, besides, it is likely that you will have “user” and “dev”  sourced to
> the same mailbox or mail filter!
>
> On May 19, 2016, at 11:12, p...@wrada.com wrote:
>
> > I¹d prefer to keep them together for now.  As this is new, I think that
> > developers are going to learn a lot from the users issues or questions,
> > and vice versa.  I agree that this will get too much at some point, but
> > I¹m really getting a lot from seeing the user and developer issues
> > together.
> >
> >
> > On 5/19/16, 11:08 AM, "aditi hilbert"  wrote:
> >
> >> Hi,
> >>
> >> With Mynewt attracting an increasing number of both users and developers
> >> of various levels, it might make practical sense to have a users@
> mailing
> >> list separate from dev@ mailing list. That way support questions about
> >> product usage, asks, needs etc can be separated from
> >> developer/design/architecture discussions. Of course, there has to be
> >> communication between the two groups to build truly useful and usable
> >> features, but we can bring some organization to it with the separate
> >> mailing lists. Please comment on the suggestion.
> >>
> >> Let¹s keep this thread open through the weekend to gauge the general
> >> response.
> >>
> >> thanks,
> >> aditi
> >
>
>