[jira] [Resolved] (MYNEWT-670) NMP: Make max chunk size configurable
[ https://issues.apache.org/jira/browse/MYNEWT-670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Collins resolved MYNEWT-670. Resolution: Fixed > NMP: Make max chunk size configurable > - > > Key: MYNEWT-670 > URL: https://issues.apache.org/jira/browse/MYNEWT-670 > Project: Mynewt > Issue Type: Improvement > Components: Newtmgr >Reporter: Christopher Collins >Assignee: Christopher Collins > Fix For: v1_1_0_rel > > > 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. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MYNEWT-669) SensorAPI: Change UNUSED_DATA indicator
[ https://issues.apache.org/jira/browse/MYNEWT-669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)
[jira] [Updated] (MYNEWT-670) NMP: Make max chunk size configurable
[ https://issues.apache.org/jira/browse/MYNEWT-670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Collins updated MYNEWT-670: --- Description: 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. was: Currently, the largest image or file chunk that a Mynewt device can receive is hardcoded at 400 bytes. 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 two new compile-time settings: * 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. Summary: NMP: Make max chunk size configurable (was: image / fs NMP: Make max chunk size configurable) > NMP: Make max chunk size configurable > - > > Key: MYNEWT-670 > URL: https://issues.apache.org/jira/browse/MYNEWT-670 > Project: Mynewt > Issue Type: Improvement > Components: Newtmgr >Reporter: Christopher Collins >Assignee: Christopher Collins > Fix For: v1_1_0_rel > > > 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. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (MYNEWT-670) image / fs NMP: Make max chunk size configurable
Christopher Collins created MYNEWT-670: -- Summary: image / fs NMP: Make max chunk size configurable Key: MYNEWT-670 URL: https://issues.apache.org/jira/browse/MYNEWT-670 Project: Mynewt Issue Type: Improvement Components: Newtmgr Reporter: Christopher Collins Assignee: Christopher Collins Fix For: v1_1_0_rel Currently, the largest image or file chunk that a Mynewt device can receive is hardcoded at 400 bytes. 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 two new compile-time settings: * 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. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MYNEWT-665) SensorAPI: Add TCS34725 Driver and color sensor support
[ https://issues.apache.org/jira/browse/MYNEWT-665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15925246#comment-15925246 ] ASF subversion and git services commented on MYNEWT-665: Commit fd20bc93e84b81cd9e4ff164f8ac976350c5bc50 in incubator-mynewt-core's branch refs/heads/develop from [~vrahane] [ https://git-wip-us.apache.org/repos/asf?p=incubator-mynewt-core.git;h=fd20bc9 ] MYNEWT-665 SensorAPI: Add TCS34725 Driver - reading from ATIME, control for AGAIN and ENABLE for state of the sensor instead of using varibales to store state. > SensorAPI: Add TCS34725 Driver and color sensor support > --- > > Key: MYNEWT-665 > URL: https://issues.apache.org/jira/browse/MYNEWT-665 > Project: Mynewt > Issue Type: New Feature >Reporter: Vipul Rahane >Assignee: Vipul Rahane > Fix For: v1_1_0_rel > > > Add TCS34725 color sensor driver and add support to the SensorAPI for > As part of this ticket also, creating devices in hal_bsp.c of the nrf52dk bsp > to be used as an example. It's conditionally compiled in based on the syscfg > setting. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MYNEWT-669) SensorAPI: Change UNUSED_DATA indicator
[ https://issues.apache.org/jira/browse/MYNEWT-669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15924848#comment-15924848 ] ASF subversion and git services commented on MYNEWT-669: Commit 20ffb7e4e23f9d3d78dde0dff27f326354f71a28 in incubator-mynewt-core's branch refs/heads/develop from [~vrahane] [ https://git-wip-us.apache.org/repos/asf?p=incubator-mynewt-core.git;h=20ffb7e ] MYNEWT-669 SensorAPI: Change UNUSED_DATA indicator - Please see description of the ticket for details Adding bitfields to indicate validity of data > 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)
[jira] [Created] (MYNEWT-669) SensorAPI: Change UNUSED_DATA indicator
Vipul Rahane created MYNEWT-669: --- Summary: 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)
[jira] [Closed] (MYNEWT-531) Add support for Segger RTT console
[ https://issues.apache.org/jira/browse/MYNEWT-531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcio Montenegro closed MYNEWT-531. Resolution: Fixed Fix Version/s: (was: WISHLIST) Issue closed.There is a now a test branch for Segger SystemView and RTT.See comments an mailing list. > Add support for Segger RTT console > -- > > Key: MYNEWT-531 > URL: https://issues.apache.org/jira/browse/MYNEWT-531 > Project: Mynewt > Issue Type: New Feature > Components: OS >Affects Versions: WISHLIST > Environment: Mac OSX ,Linux >Reporter: Marcio Montenegro >Assignee: Christopher Collins >Priority: Minor > > Sometimes UART console is not available and you can use j-link console. > https://www.segger.com/j-link-rtt.html -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (MYNEWT-531) Add support for Segger RTT console
[ https://issues.apache.org/jira/browse/MYNEWT-531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15923911#comment-15923911 ] Marcio Montenegro edited comment on MYNEWT-531 at 3/14/17 10:04 AM: Message from Michał Narajowski : I'm replying to the mailing list too because it is important. Yes, it is possible to use SEGGER RTT console with SEGGER SystemView. SystemView is using a different channel than the console. And you can use it on my branch because SystemView was added on top of RTT. The branch for SystemView and RTT is: https://github.com/michal-narajowski/incubator-mynewt-core/tree/systemview. Closing issue. was (Author: mtuxpe): Message from Michał Narajowski : I'm replying to the mailing list too because it is important. Yes, it is possible to use SEGGER RTT console with SEGGER SystemView. SystemView is using a different channel than the console. And you can use it on my branch because SystemView was added on top of RTT. The branch for SystemView and RTT is: https://github.com/michal-narajowski/incubator-mynewt-core/tree/systemview. > Add support for Segger RTT console > -- > > Key: MYNEWT-531 > URL: https://issues.apache.org/jira/browse/MYNEWT-531 > Project: Mynewt > Issue Type: New Feature > Components: OS >Affects Versions: WISHLIST > Environment: Mac OSX ,Linux >Reporter: Marcio Montenegro >Assignee: Christopher Collins >Priority: Minor > Fix For: WISHLIST > > > Sometimes UART console is not available and you can use j-link console. > https://www.segger.com/j-link-rtt.html -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MYNEWT-531) Add support for Segger RTT console
[ https://issues.apache.org/jira/browse/MYNEWT-531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15923911#comment-15923911 ] Marcio Montenegro commented on MYNEWT-531: -- Message from Michał Narajowski : I'm replying to the mailing list too because it is important. Yes, it is possible to use SEGGER RTT console with SEGGER SystemView. SystemView is using a different channel than the console. And you can use it on my branch because SystemView was added on top of RTT. The branch for SystemView and RTT is: https://github.com/michal-narajowski/incubator-mynewt-core/tree/systemview. > Add support for Segger RTT console > -- > > Key: MYNEWT-531 > URL: https://issues.apache.org/jira/browse/MYNEWT-531 > Project: Mynewt > Issue Type: New Feature > Components: OS >Affects Versions: WISHLIST > Environment: Mac OSX ,Linux >Reporter: Marcio Montenegro >Assignee: Christopher Collins >Priority: Minor > Fix For: WISHLIST > > > Sometimes UART console is not available and you can use j-link console. > https://www.segger.com/j-link-rtt.html -- This message was sent by Atlassian JIRA (v6.3.15#6346)
