[
https://issues.apache.org/jira/browse/MYNEWT-669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15925430#comment-15925430
]
ASF subversion and git services commented on MYNEWT-669:
--------------------------------------------------------
Commit 78946572ddbf9489b47206ab42bb9bc348b7f008 in incubator-mynewt-core's
branch refs/heads/develop from [~ccollins476]
[ https://git-wip-us.apache.org/repos/asf?p=incubator-mynewt-core.git;h=7894657
]
MYNEWT-669 NMP: Make max chunk size configurable.
Currently, the largest image or file chunk that a Mynewt device can
receive is hardcoded at 400 bytes. Furthermore, the largets CBOR
attribute that we can decode is 300 bytes long.This is not great because
this number is independent of the transport MTU, so the client has no
way of knowing the limit.
The fix is to create three new compile-time settings:
* CBORATTR_MAX_SIZE
* FS_UPLOAD_MAX_CHUNK_SIZE
* IMGMGR_MAX_CHUNK_SIZE
and set them to 512 by default. This value is large enough to
accommodate full-size BLE packets.
This is still not a perfect solution because these values are not tied
to the MTU in any way. One way to truly solve this would be to have an
"NMP MTU" that the client can discover. That would be a pretty big
change.
> SensorAPI: Change UNUSED_DATA indicator
> ---------------------------------------
>
> Key: MYNEWT-669
> URL: https://issues.apache.org/jira/browse/MYNEWT-669
> Project: Mynewt
> Issue Type: Improvement
> Reporter: Vipul Rahane
> Assignee: Vipul Rahane
> Fix For: v1_0_0_rel
>
>
> For unused data, UNUSED_DATA constant was being used which would be set to a
> value which is not used by the sensor data. Downside to this is:
> Eg: If it is defined to be -1 and for some reason sensor data is exactly -1,
> the data would get ignored by the SensorAPI.
> There are two ways to deal with this:
> 1. Use bit fields:
> Use bit fields for ensuring validity of the data. I use it for color sensor
> data. As compared to flags and the earlier constant data approach, this is
> very specific and can be used flexibly.
> 2. Use flags:
> Using flags is the same as using bit fields, the only downside is the bitwise
> comparison in if statements.
> My preferred approach:
> 1. Use bit fields.
> This is because of the advantages it has over flags and the constant data
> approach.
> Disadvantage:
> Over the air using bit fields might be a bit problematic, but the sensors
> data structures are internal and over the air we would not send the data
> structure itself(hopefully) but it would most probably be mapped to some
> other resource in an application protocol.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
