[GitHub] vrahane closed pull request #1: Readme.md: Fix bad links in file README.md

2018-02-09 Thread GitBox
vrahane closed pull request #1: Readme.md: Fix bad links in file README.md
URL: https://github.com/apache/mynewt-mcumgr/pull/1
 
 
   

This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:

As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):

diff --git a/README.md b/README.md
index 4726883..cad3514 100644
--- a/README.md
+++ b/README.md
@@ -124,12 +124,12 @@ Information and documentation for mcumgr is stored within 
the source.
 
 For more information in the source, here are some pointers:
 
-- [cborattr](https://github.com/apache/mcumgr/tree/master/cborattr): Used for 
parsing incoming mcumgr requests.  Destructures mcumgr packets and populates 
corresponding field variables.
-- [cmd](https://github.com/apache/mcumgr/tree/master/cmd): Built-in command 
handlers for the core mcumgr commands.
-- [ext](https://github.com/apache/mcumgr/tree/master/ext): Third-party 
libraries that mcumgr depends on.
-- [mgmt](https://github.com/apache/mcumgr/tree/master/mgmt): Code implementing 
the `mgmt` layer of mcumgr.
-- [samples](https://github.com/apache/mcumgr/tree/master/samples): Sample 
applications utilizing mcumgr.
-- [smp](https://github.com/apache/mcumgr/tree/master/smp): The built-in 
transfer encoding: Simple management protocol.
+- [cborattr](https://github.com/apache/mynewt-mcumgr/tree/master/cborattr): 
Used for parsing incoming mcumgr requests.  Destructures mcumgr packets and 
populates corresponding field variables.
+- [cmd](https://github.com/apache/mynewt-mcumgr/tree/master/cmd): Built-in 
command handlers for the core mcumgr commands.
+- [ext](https://github.com/apache/mynewt-mcumgr/tree/master/ext): Third-party 
libraries that mcumgr depends on.
+- [mgmt](https://github.com/apache/mynewt-mcumgr/tree/master/mgmt): Code 
implementing the `mgmt` layer of mcumgr.
+- [samples](https://github.com/apache/mynewt-mcumgr/tree/master/samples): 
Sample applications utilizing mcumgr.
+- [smp](https://github.com/apache/mynewt-mcumgr/tree/master/smp): The built-in 
transfer encoding: Simple management protocol.
 
 ## Joining
 


 


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


Re: Mynewt OS and nimBLE on atmega

2018-02-09 Thread Priyanka Rajendran
Hello Will ,

Thanks for your support and info. If I succeed I will definitely let you
know. Is it possible to change the HCI -UART connection to HCI-SPI ?
Because , in our case SPI is the prefered interface.Since , SPI needs clock
rate and UART needs baudrate ,I expect it is not tough to handle. As you
said the existing HCI- SPI is a non-standard one, I think I can atleast
have some reference from that implemention.

Best regards,
Priyanka

On Wed, Feb 7, 2018 at 2:38 PM, Priyanka Rajendran <
priyankavelrajend...@gmail.com> wrote:

> Hello ,
>
> I am a student and I am new to BLE. I would like to know if the Mynewt OS
> and nimBLE host stack (protocol stack part only) can be ported to Atmega
> microcontroller with 256 kb flash and 32kb RAM.It is a 8-bit mcu and
> advanced RISC architecture Can I modify the host stack to access any
> controller of a BLE module.Ealier the HCI was in UART now,in the github I
> found there is also SPI for HCI. Could the porting be achieved?
>
> Thanks in advance
>


Re: Define __MYNEWT__ symbol for Mynewt build

2018-02-09 Thread Andrzej Kaczmarek
Hi Chris,

Indeed, now I see that you added this to newt tool ​recently - I was using
newt 1.3.0 :-)
I'm fine with MYNEWT=1 name. So in this case I'll just close my PR as it is
not applicable now.

Thanks!
Andrzej


On Fri, Feb 9, 2018 at 5:08 PM, Christopher Collins 
wrote:

> Hi Andrzej,
>
> The newt tool already adds the `-DMYNEWT=1` compiler flag during builds.
> Mynewt and newt are not part of the C implementation, so in my opinion
> they should not introduce identifiers in the reserved namespace (leading
> underscore).  I know opinions differ on this point, and I could probably
> be convinced otherwise :).
>
> Chris
>
> On Fri, Feb 09, 2018 at 04:03:24PM +0100, Andrzej Kaczmarek wrote:
> > Hi all,
> >
> > I created a PR which modifies all compiler packages by adding
> > -D__MYNEWT__=1 to compiler.flags.base, see here:
> > https://github.com/apache/mynewt-core/pull/803
> >
> > The reason for this is to have some common symbol which can be used to
> > distinguish between building code for Mynewt or for some other platform -
> > similar symbols are defined for other platforms. This will be especially
> > useful for components which have separate repository, e.g. mynewt-nffs or
> > upcoming mynewt-nimble which can be also ported to other platforms so may
> > use different set of headers or some porting layer.
> >
> > Best regards,
> > Andrzej
>


Re: Define __MYNEWT__ symbol for Mynewt build

2018-02-09 Thread Christopher Collins
Hi Andrzej,

The newt tool already adds the `-DMYNEWT=1` compiler flag during builds.
Mynewt and newt are not part of the C implementation, so in my opinion
they should not introduce identifiers in the reserved namespace (leading
underscore).  I know opinions differ on this point, and I could probably
be convinced otherwise :).

Chris

On Fri, Feb 09, 2018 at 04:03:24PM +0100, Andrzej Kaczmarek wrote:
> Hi all,
> 
> I created a PR which modifies all compiler packages by adding
> -D__MYNEWT__=1 to compiler.flags.base, see here:
> https://github.com/apache/mynewt-core/pull/803
> 
> The reason for this is to have some common symbol which can be used to
> distinguish between building code for Mynewt or for some other platform -
> similar symbols are defined for other platforms. This will be especially
> useful for components which have separate repository, e.g. mynewt-nffs or
> upcoming mynewt-nimble which can be also ported to other platforms so may
> use different set of headers or some porting layer.
> 
> Best regards,
> Andrzej


Define __MYNEWT__ symbol for Mynewt build

2018-02-09 Thread Andrzej Kaczmarek
Hi all,

I created a PR which modifies all compiler packages by adding
-D__MYNEWT__=1 to compiler.flags.base, see here:
https://github.com/apache/mynewt-core/pull/803

The reason for this is to have some common symbol which can be used to
distinguish between building code for Mynewt or for some other platform -
similar symbols are defined for other platforms. This will be especially
useful for components which have separate repository, e.g. mynewt-nffs or
upcoming mynewt-nimble which can be also ported to other platforms so may
use different set of headers or some porting layer.

Best regards,
Andrzej