Hotspot anaysis

[Justin Mclean]

Hi,

A little off topic but may be of interest. I did some hotspot analysis on 
mynewt core for a talk I’m giving and you can find the draft here:

http://cssw.info.s3.amazonaws.com/Apache/hotspots/mynewt-core/index.html 


Click about to zoom in.

The redder area are hotspots i.e. files that have more changes and complexity 
than other files and are more likely to have bugs or be good candidates for 
extra testing or review. It generated from loc, simple complexity measures, and 
version control history.

May be a few false positives but I’d be interested to see if anyone finds that 
of use. It also give a nice birds eye view of the entire code base.

Thanks,
Justin

include files with the same name

[p...@wrada.com]

Hi all,

Just something I noticed here that I'll pass on to the group.

Mynewt has special directory structure to avoid name conflicts with header 
files.  For example,

Hal/hal_adc.h

And

Mcu/hal_adc.h

won't conflict because the user has to include the directory name in the path.

#include 
#include 

However, my editor conveniently creates the #ifndef __FNAME__ directives in the 
header files.
Without some care, the example above will have problems because they will both 
use
__HAL_ADC_H__ as their include prefix.

I think by convention we can fix this with using a longer namespace in the 
header includes.

#ifdef __MCU_HAL_ADC_H__
#ifdef __HAL_HAL_ADC_H__

Paul

Re: FYI: bletiny is over the nrf51 code size limit

[Christopher Collins]

The culprit is the security code that was recently added to the host.
This new code caused ~10kB of mbedtls code to get pulled in to the
image.

Since security support is incomplete, I have disabled the security
manager by default.  The latest code in the develop branch should fit on
the nRF51 once again.

This is obviously not a long term solution.  I think we will need to
look for ways to reduce the nimble host code size soon.

Chris

On Mon, Mar 28, 2016 at 09:52:09AM -0700, will sanfilippo wrote:
> Hello:
> 
> This is just an FYI: the nrf51 bletiny build is over the code size limit, so 
> if you pull develop and build this project it will not link. This will get 
> fixed today (hopefully).

sysid etc.

[p...@wrada.com]

This is a discussion on how we identify devices (peripherals or internal MCU 
devices) through the HAL (Hardware abstraction layer).

A picture is posted to jira here.

https://issues.apache.org/jira/secure/attachment/12795673/hal_drawing.pdf

Here is the gist of the design.

A BSP defines a set of SYSID (System IDS).  This is an enumeration of all the 
devices that the system has.  Remembers, the system includes the built in MCU 
peripherals and also the external peripherals.  The BSP puts these system ids 
into /hw/bsp/include/bsp/bsp_sysid.h

An Example for Arduino might be:

Enum SystemDeviceDescriptor {
 ARDUINO_ANALOG0,   ARDUINO_ANALOG1, ARDUINO_ANALOG2, 
ARDUINO_ANALOG3, ARDUINO_ANALOG4, ARDUINO_ANALOG5,
 ARDUINO_DIGITAL0, ARDUINO_DIGITAL1, ARDUINO_DIGITAL2, 
ARDUINO_DIGITAL3, ARDUINO_DIGITAL4, ARDUINO_DIGITAL5,
 ARDUINO_DIGITAL6, ARDUINO_DIGITAL7, ARDUINO_DIGITAL8, 
ARDUINO_DIGITAL9, ARDUINO_DIGITAL10, ARDUINO_DIGITAL11,
 ARDUINO_DIGITAL12, ARDUINO_DIGITAL13,
 ARDUINO_UART,
 ARDUINO_SPI,
 ARDUINO_PWM8, ARDUINO_PWM9, ARDUINO_PWM10, ARDUINO_PWM11, 
ARDUINO_PWM12, ARDUINO_PWM13,
}

An example for a fictitious weather monitor which has two analog temp sensors, 
flash storage, a SPI bus with two peripherals, a clock and a display each 
activate with a different digital chip select.  NOTE: Its likely this would 
have more digital lines for power saving, battery control etc.

Enum SystemDeviceDescriptor {
WEATHERMON_ANALOG_TEMP_INDOOR,
WEATHERMON_ANALOG_TEMP_OUTDOOR,
WEATHERMON_FLASH,
WEATHERMON_SPI,
WEATHERMON_DIG_CLOCK_CS,
WEATHERMON_DIG_DISPLAY_CS,
...
};

A few NOTES.   This is not necessarily a mapping of PINS.  For example, the 
UART uses D0 and D1.  PWM8 Uses D8 etc. SO there will be conflicts if apps try 
to use certain combinations.  We haven't designed a pinmux API, but I think 
that will live underneath this.   In general though, the BSP designer will be 
making the tradeoffs about which devices are used in the system.  Since this 
largely depends on how the pins of the MCU are assigned, there won't be too 
many overlaps with this list, but in general, there will be some.

It was a design decision to include all the system devices within a single 
SYSID space (just one enum).  An alternative could have had a separate enum for 
each HAL.  This decision was made for two reasons. One, to keep all the BSP 
devices easily accessible in the same place. This means that APP designers 
don't need to learn or know that much to use the devices.  The tradeoff here is 
that is may not be as obvious which device is which HAL.   The convention to 
make device identification easier is to use descriptive names like above.  Two, 
to make it clear that in a BSP (as opposed to MCU), the BSP designer is making 
tradeoffs to support only some functionality depending on the schematic.  
Generally, the MCUs have tons of pinmux flexibility with more internal devices 
than there are accessible pins.

The SYSID is used in only one place in the HAL.  Each HAL interface has a 
hal_xxx_init function which takes the SYSID of the device and returns a device 
object to the application.  The benefit of this is that the application does 
not need to statically pick a specific MCU object. This allows the application 
or library flexibility to work across multiple different platforms (which is 
the main goal of a HAL).

The rest of the HAL interface is invisible to the application or library.  
Below is a description of how its recommended to work for the MCU or peripheral 
designer but is a convention only.

The MCU or peripheral implementation implements the hal_xxx_int.h driver API 
plus one extra function.   By convention the prototype for this function is 
stored in mcu/hal_xxx.h or periph/hal_xxx.h

The header file includes a single function to create a device of this type and 
the configuration structure to go with it.  Typically, this function will take 
some configuration options which are typically a constant structure (so it 
doesn't use any RAM space).  For example, for an ADC device it might look like 
this.  This configuration structure is where pin mappings or choices would go 
(if there are any).


/* this structure is passed to the BSP for configuration options */
enum samd_adc_reference_voltage {
DEVICE_ID_ADC_REFERENCE_INT1V,
DEVICE_ID_ADC_REFERENCE_INTVCC0,
DEVICE_ID_ADC_REFERENCE_INTVCC1,
DEVICE_ID_ADC_REFERENCE_AREFA ,
DEVICE_ID_ADC_REFERENCE_AREFB,
};

/* this device supports 6 channels */
enum samd_adc_analog_channel {
ANALOG_CHANNEL_0 = 0,ANALOG_CHANNEL_1,ANALOG_CHANNEL_2,
ANALOG_CHANNEL_3,ANALOG_CHANNEL_4,ANALOG_CHANNEL_5,ANALOG_CHANNEL_5,
ANALOG_CHANNEL_6, ... , ANALOG_CHANNEL_18, ANALOG_CHANNEL_19, 
ANALOG_CHANNEL_20, ANALOG_CHANNEL_TEMP, ANALOG_CHANNEL_DAC,
};

struct samd21_adc_config {
enum samd_adc_analog_channelanalog_channels;
enum samd_adc_refer

[ANNOUNCE] Apache Mynewt Apache Mynewt 0.8.0-b2-incubating released

[Christopher Collins]

Hello all,

The Apache Mynewt team is pleased to announce the release of Apache Mynewt
0.8.0-b2-incubating.

Apache Mynewt is a community-driven module OS for constrained, embedded
applications.  Mynewt provides a real-time operating system, flash file
system, network stacks, and support utilities for real-world embedded
systems.

The release is available here:
http://www.apache.org/dyn/closer.lua/incubator/mynewt/apache-mynewt-0.8.0-b2-incubating

For full release notes, please visit the Apache Mynewt Wiki:
https://cwiki.apache.org/confluence/display/MYNEWT/Release+Notes

For information about bugs fixed in beta 2, please view the Issue
Tracker Summary:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12319221&version=12334805

This is the first source release of the "New" Newt.  More information on
the genesis of Newt, and a description can be found at:
http://mail-archives.apache.org/mod_mbox/incubator-mynewt-dev/201603.mbox/%3C56E21C13.9050303%40apache.org%3E

We welcome your help and feedback. For more information on the project
and how to get involved, visit the project website at
http://mynewt.incubator.apache.org/

Regards,
The Apache Mynewt team

Disclaimer:
Apache Mynewt is an effort undergoing incubation at The Apache Software
Foundation (ASF) sponsored by the Apache Incubator PMC. Incubation is
required of all newly accepted projects until a further review
indicates that the infrastructure, communications, and decision making
process have stabilized in a manner consistent with other successful
ASF projects. While incubation status is not necessarily a reflection
of the completeness or stability of the code, it does indicate that
the project has yet to be fully endorsed by the ASF.

Re: more ADC hal discussion

[Sterling Hughes]

On 3/28/16 9:44 AM, p...@wrada.com wrote:
> Thanks for the reviews.
> 
> 1) regarding names.  I can shorten.  I really like having the units in the
> names, but can shorted to
> 
> hal_adc_refmv();
> hal_adc_bits();

OK.

I'm fine if we chose milivolts as our primary unit.  But if we believe
MV will always be sufficient, why include it in the name?  If we don't
think it will always be sufficient, we should have a generic call, i.e.
I think:

rc = hal_adc_ref(HAL_ADC_MV, &v);

is equally clear, and saves multiple functions for multiple unit types.

> 
> As far as convert.  To convert from adc output to molts requires the
> resolution and the reference voltage.  I agree though that
> This should be a helper and not a driver Api.  I’ll create a function
> 
> hal_adc_util_to_mv(int val, int ref, int res);
> 
>

Why not just hal_adc_convert (or convertmv), and don't make it a driver
function?

> As far as macros versus enums, I think either can do
> 
> Enum val {
> #ifdef SYSTEM_DEV_ENABLED_ADCS
>   SYSID_ADC_TEMP,
>   SYSID_ADC_VOLTAGE,
> 
> #endif
> ...
> };
> 
> I personally like enums because there is warnings when case statements
> don’t address them and there are not as many compile time errors.
> 

It looks to me like what you're proposing above is to have two sets of
defines.  Whereas if you made those '#defines' you'd have one set.

Anyhow, I don't feel too strongly on this one.  This definitely fits the
definition of an enum, so I can see the logic.

Sterling

FYI: bletiny is over the nrf51 code size limit

[will sanfilippo]

Hello:

This is just an FYI: the nrf51 bletiny build is over the code size limit, so if 
you pull develop and build this project it will not link. This will get fixed 
today (hopefully).

Re: more ADC hal discussion

[p...@wrada.com]

Thanks for the reviews.

1) regarding names.  I can shorten.  I really like having the units in the
names, but can shorted to

hal_adc_refmv();
hal_adc_bits();

As far as convert.  To convert from adc output to molts requires the
resolution and the reference voltage.  I agree though that
This should be a helper and not a driver Api.  I’ll create a function

hal_adc_util_to_mv(int val, int ref, int res);


As far as macros versus enums, I think either can do

Enum val {
#ifdef SYSTEM_DEV_ENABLED_ADCS
 SYSID_ADC_TEMP,
 SYSID_ADC_VOLTAGE,

#endif
...
};

I personally like enums because there is warnings when case statements
don’t address them and there are not as many compile time errors.


I’ll comment on the pins and sys ids in a separate email thread.

Paul

On 3/28/16, 7:07 AM, "will sanfilippo"  wrote:

>I will second the motion to abbreviate things more :-) While I do like
>the simplicity of the mbed HAL I do realize that it does not support
>everything we want the HAL to do. And unless I am mistaken, it shouldnt
>be hard to map between the two. So I guess this means a +1 from me.
>
>Will
>
>> On Mar 27, 2016, at 2:29 PM, Sterling Hughes 
>>wrote:
>> 
>> Hey Paul,
>> 
>> I read through the APIs, I think they look good.  I made a few comments,
>> entirely coding standards related.
>> 
>> There are a few other things I'd like to understand/discuss, which I'll
>> post to dev@:
>> 
>> - Can you post a description of how pins are mapped across MCU, BSP and
>> Application?  I think I followed it, but want to make sure we have a
>> record.
>> 
>> - Should system device descriptor be preprocessor directives rather than
>> an enum.  Would there be a case where you'd want to do:
>> 
>> #ifdef SYSTEM_DEV_ADC5
>> /* do X */
>> #else
>> /* do Y */
>> #endif
>> 
>> - hal_adc_get_reference_voltage_mvolts i feel could be shortend to
>> hal_adc_refv() or hal_adc_refmv().  Shouldn't this just take a
>>resolution.
>> 
>> - hal_adc_val_convert_to_mvolts(), should this just be hal_adc_convert()
>> and take a resolution.
>> 
>> Cheers,
>> Sterling
>> 
>> On 3/25/16 4:52 PM, Paul Dietrich wrote:
>>> This new implementation is posted as
>>> 
>>> https://github.com/apache/incubator-mynewt-core/pull/25
>>> 
>>> Take a look and let me know what you think.  Without negative feedback,
>>> I’ll commit on Monday/Tuesday
>>> 
>>> Paul
>>> 
>>> On 3/25/16, 2:58 PM, "Paul Dietrich"  wrote:
>>> 
 Just updating the group with my plan
 
 Folks commented offline that they didn¹t like that the mbed hal
doesn¹t
 allow multiple kinds of devices with the same HAL API at the same
time.
 
 But they liked the pin mapping and init function that tied it to a
pin.
 
 So the new API will combine the best of hal_adc3 and hal_adc2.  I¹ll
 hopefully post the pull request by the COB or during the weekend.
 
 One NOTE.  The memory (RAM) issues of hal_adc2 will be addressed by
 getting the device initializer from the BSP.  So the BSP may malloc
memory
 for these to be efficient.
 
 
 
 
> 
 
 
>>> 
>>> 
>

Re: more ADC hal discussion

[will sanfilippo]

I will second the motion to abbreviate things more :-) While I do like the 
simplicity of the mbed HAL I do realize that it does not support everything we 
want the HAL to do. And unless I am mistaken, it shouldnt be hard to map 
between the two. So I guess this means a +1 from me.

Will

> On Mar 27, 2016, at 2:29 PM, Sterling Hughes  wrote:
> 
> Hey Paul,
> 
> I read through the APIs, I think they look good.  I made a few comments,
> entirely coding standards related.
> 
> There are a few other things I'd like to understand/discuss, which I'll
> post to dev@:
> 
> - Can you post a description of how pins are mapped across MCU, BSP and
> Application?  I think I followed it, but want to make sure we have a
> record.
> 
> - Should system device descriptor be preprocessor directives rather than
> an enum.  Would there be a case where you'd want to do:
> 
> #ifdef SYSTEM_DEV_ADC5
> /* do X */
> #else
> /* do Y */
> #endif
> 
> - hal_adc_get_reference_voltage_mvolts i feel could be shortend to
> hal_adc_refv() or hal_adc_refmv().  Shouldn't this just take a resolution.
> 
> - hal_adc_val_convert_to_mvolts(), should this just be hal_adc_convert()
> and take a resolution.
> 
> Cheers,
> Sterling
> 
> On 3/25/16 4:52 PM, Paul Dietrich wrote:
>> This new implementation is posted as
>> 
>> https://github.com/apache/incubator-mynewt-core/pull/25
>> 
>> Take a look and let me know what you think.  Without negative feedback,
>> I’ll commit on Monday/Tuesday
>> 
>> Paul
>> 
>> On 3/25/16, 2:58 PM, "Paul Dietrich"  wrote:
>> 
>>> Just updating the group with my plan
>>> 
>>> Folks commented offline that they didn¹t like that the mbed hal doesn¹t
>>> allow multiple kinds of devices with the same HAL API at the same time.
>>> 
>>> But they liked the pin mapping and init function that tied it to a pin.
>>> 
>>> So the new API will combine the best of hal_adc3 and hal_adc2.  I¹ll
>>> hopefully post the pull request by the COB or during the weekend.
>>> 
>>> One NOTE.  The memory (RAM) issues of hal_adc2 will be addressed by
>>> getting the device initializer from the BSP.  So the BSP may malloc memory
>>> for these to be efficient.
>>> 
>>> 
>>> 
>>> 
 
>>> 
>>> 
>> 
>>