[GitHub] ccollins476ad closed issue #3: Unable to compile sample on zephyr 1.11

[GitBox]

ccollins476ad closed issue #3: Unable to compile sample on zephyr 1.11
URL: https://github.com/apache/mynewt-mcumgr/issues/3
 
 
   


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

[GitHub] ccollins476ad commented on issue #2: Image upload broken

[GitBox]

ccollins476ad commented on issue #2: Image upload broken
URL: https://github.com/apache/mynewt-mcumgr-cli/issues/2#issuecomment-402248195
 
 
   The fix to newtmgr will be automatically included in mcumgr.  By the way, 
the fix was just merged to the newtmgr repo.


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

[GitHub] carlescufi commented on issue #7: Upstreaming of Zephyr downstream modifications

[GitBox]

carlescufi commented on issue #7: Upstreaming of Zephyr downstream modifications
URL: https://github.com/apache/mynewt-mcumgr/pull/7#issuecomment-402234451
 
 
   @utzig thanks!


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

[GitHub] utzig closed pull request #7: Upstreaming of Zephyr downstream modifications

[GitBox]

utzig closed pull request #7: Upstreaming of Zephyr downstream modifications
URL: https://github.com/apache/mynewt-mcumgr/pull/7
 
 
   

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/Kconfig b/Kconfig
index 83eaeaa..15b546e 100644
--- a/Kconfig
+++ b/Kconfig
@@ -19,12 +19,10 @@ config MCUMGR
 bool
 prompt "mcumgr Support"
 select TINYCBOR
-default n
 help
   This option enables the mcumgr management library.
 
 if MCUMGR
-source "ext/lib/mgmt/mcumgr/mgmt/port/zephyr/Kconfig"
 source "ext/lib/mgmt/mcumgr/cmd/Kconfig"
 
 config APP_LINK_WITH_MCUMGR
diff --git a/cmd/fs_mgmt/Kconfig b/cmd/fs_mgmt/Kconfig
index ccbcf17..dae3ad7 100644
--- a/cmd/fs_mgmt/Kconfig
+++ b/cmd/fs_mgmt/Kconfig
@@ -19,7 +19,6 @@ menuconfig MCUMGR_CMD_FS_MGMT
 bool
 prompt "Enable mcumgr handlers for file management"
 depends on FILE_SYSTEM
-default n
 help
   Enables mcumgr handlers for file management
 
diff --git a/cmd/fs_mgmt/port/zephyr/src/zephyr_fs_mgmt.c 
b/cmd/fs_mgmt/port/zephyr/src/zephyr_fs_mgmt.c
index 754d3c3..231a0f8 100644
--- a/cmd/fs_mgmt/port/zephyr/src/zephyr_fs_mgmt.c
+++ b/cmd/fs_mgmt/port/zephyr/src/zephyr_fs_mgmt.c
@@ -45,7 +45,7 @@ int
 fs_mgmt_impl_read(const char *path, size_t offset, size_t len,
   void *out_data, size_t *out_len)
 {
-fs_file_t file;
+struct fs_file_t file;
 ssize_t bytes_read;
 int rc;
 
@@ -109,7 +109,7 @@ int
 fs_mgmt_impl_write(const char *path, size_t offset, const void *data,
size_t len)
 {
-fs_file_t file;
+struct fs_file_t file;
 int rc;
  
 /* Truncate the file before writing the first chunk.  This is done to
diff --git a/cmd/img_mgmt/Kconfig b/cmd/img_mgmt/Kconfig
index 3a581c6..73f0df0 100644
--- a/cmd/img_mgmt/Kconfig
+++ b/cmd/img_mgmt/Kconfig
@@ -21,9 +21,6 @@ menuconfig MCUMGR_CMD_IMG_MGMT
 select FLASH
 select MPU_ALLOW_FLASH_WRITE if CPU_HAS_MPU
 select IMG_MANAGER
-select MCUBOOT_IMG_MANAGER
-
-default n
 help
   Enables mcumgr handlers for image management
 
diff --git a/cmd/log_mgmt/Kconfig b/cmd/log_mgmt/Kconfig
index 9373571..201c6e0 100644
--- a/cmd/log_mgmt/Kconfig
+++ b/cmd/log_mgmt/Kconfig
@@ -18,8 +18,6 @@
 menuconfig MCUMGR_CMD_LOG_MGMT
 bool
 prompt "Enable mcumgr handlers for log management"
-depends on MDLOG
-default n
 help
   Enables mcumgr handlers for log management
 
diff --git a/cmd/os_mgmt/Kconfig b/cmd/os_mgmt/Kconfig
index 10f0abc..4be58ba 100644
--- a/cmd/os_mgmt/Kconfig
+++ b/cmd/os_mgmt/Kconfig
@@ -19,7 +19,6 @@ menuconfig MCUMGR_CMD_OS_MGMT
 bool
 prompt "Enable mcumgr handlers for OS management"
 select REBOOT
-default n
 help
   Enables mcumgr handlers for OS management
 
diff --git a/cmd/stat_mgmt/Kconfig b/cmd/stat_mgmt/Kconfig
index 3688ed1..9c5ae18 100644
--- a/cmd/stat_mgmt/Kconfig
+++ b/cmd/stat_mgmt/Kconfig
@@ -19,7 +19,6 @@ menuconfig MCUMGR_CMD_STAT_MGMT
 bool
 prompt "Enable mcumgr handlers for statistics management"
 depends on STATS
-default n
 help
   Enables mcumgr handlers for statistics management.
 


 


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

[GitHub] carlescufi commented on issue #2: Image upload broken

[GitBox]

carlescufi commented on issue #2: Image upload broken
URL: https://github.com/apache/mynewt-mcumgr-cli/issues/2#issuecomment-402202003
 
 
   @ccollins476ad thanks for the info. We'll wait until that PR is merged to 
close this.


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

[GitHub] JoeHut commented on issue #7: Upstreaming of Zephyr downstream modifications

[GitBox]

JoeHut commented on issue #7: Upstreaming of Zephyr downstream modifications
URL: https://github.com/apache/mynewt-mcumgr/pull/7#issuecomment-402200028
 
 
   Looks like that is everything :+1: 
   
   ```
   $ diff -r mynewt-mcumgr zephyr/ext/lib/mgmt/mcumgr 
   Only in mynewt-mcumgr/cborattr: pkg.yml
   Only in mynewt-mcumgr/cborattr: syscfg.yml
   Only in mynewt-mcumgr/cborattr: test
   Only in mynewt-mcumgr/cmd/fs_mgmt: pkg.yml
   Only in mynewt-mcumgr/cmd/fs_mgmt/port: mynewt
   Only in mynewt-mcumgr/cmd/fs_mgmt: syscfg.yml
   Only in mynewt-mcumgr/cmd/img_mgmt: pkg.yml
   Only in mynewt-mcumgr/cmd/img_mgmt/port: mynewt
   diff -r mynewt-mcumgr/cmd/img_mgmt/src/img_mgmt_state.c 
zephyr/ext/lib/mgmt/mcumgr/cmd/img_mgmt/src/img_mgmt_state.c
   254,258c254
   < /*
   <  * We add 1 to the 32-byte hash buffer as _cbor_value_copy_string() 
adds
   <  * a null character at the end of the buffer.
   <  */
   < uint8_t hash[IMAGE_HASH_LEN + 1];
   ---
   > uint8_t hash[IMAGE_HASH_LEN];
   Only in mynewt-mcumgr/cmd/img_mgmt: syscfg.yml
   Only in mynewt-mcumgr/cmd/log_mgmt/port: mynewt
   Only in mynewt-mcumgr/cmd/os_mgmt: pkg.yml
   Only in mynewt-mcumgr/cmd/os_mgmt/port: mynewt
   Only in mynewt-mcumgr/cmd/os_mgmt: syscfg.yml
   Only in mynewt-mcumgr: .git
   Only in mynewt-mcumgr: .gitignore
   Only in mynewt-mcumgr/mgmt: pkg.yml
   Only in mynewt-mcumgr/mgmt: syscfg.yml
   diff -r mynewt-mcumgr/README.md zephyr/ext/lib/mgmt/mcumgr/README.md
   19,20c19,20
   < * [Mynewt](README-mynewt.md)
   < * [Zephyr](README-zephyr.md)
   ---
   > * README-mynewt.md
   > * README-zephyr.md
   Only in mynewt-mcumgr: repository.yml
   Only in mynewt-mcumgr: samples
   Only in mynewt-mcumgr/smp: pkg.yml
   ```


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

[GitHub] ccollins476ad commented on issue #2: Image upload broken on Windows

[GitBox]

ccollins476ad commented on issue #2: Image upload broken on Windows
URL: https://github.com/apache/mynewt-mcumgr-cli/issues/2#issuecomment-402198760
 
 
   I believe this is an issue that was recently introduced into newtmgr (and 
therefore mcumgr-cli).  The problem is that the CLI tool recently starting 
including a 32-byte hash in the first upload chunk.  On systems with a limited 
maximum ATT MTU, this doesn't leave enough room for a "complete" set of image 
data in the request.  The first request of an upgrade is required to have at 
least 32 bytes of image data to be valid (it must contain the full image 
header).
   
   There is a PR that fixes this issue that is ready to be merged: 
https://github.com/apache/mynewt-newtmgr/pull/92


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

[GitHub] carlescufi commented on issue #2: Image upload broken on Windows

[GitBox]

carlescufi commented on issue #2: Image upload broken on Windows
URL: https://github.com/apache/mynewt-mcumgr-cli/issues/2#issuecomment-402196482
 
 
   Not sure if this is an MCUmgr or MCUboot issue actually. For now I will keep 
it here, but there is something definitely broken. @sjanc could you also test 
for me with MCUboot built with Zephyr and the latest MCUboot that you get with 
`go get`?


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

[GitHub] carlescufi opened a new pull request #7: Upstream of Zephyr downstream modifications

[GitBox]

carlescufi opened a new pull request #7: Upstream of Zephyr downstream 
modifications
URL: https://github.com/apache/mynewt-mcumgr/pull/7
 
 
   


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

[GitHub] carlescufi commented on issue #7: Upstream of Zephyr downstream modifications

[GitBox]

carlescufi commented on issue #7: Upstream of Zephyr downstream modifications
URL: https://github.com/apache/mynewt-mcumgr/pull/7#issuecomment-402194450
 
 
   CC @utzig @ccollins476ad @JoeHut 


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

[GitHub] JoeHut commented on issue #5: cmd: img_mgmt: Add an extra byte to the 'hash' buffer

[GitBox]

JoeHut commented on issue #5: cmd: img_mgmt: Add an extra byte to the 'hash' 
buffer
URL: https://github.com/apache/mynewt-mcumgr/pull/5#issuecomment-402156773
 
 
   @carlescufi Sure.


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: 1 Wire HAL

[Kevin Townsend]

Hi Marko,

That sounds sensible to me, with timer+GPIO beind the sensible place to 
start in my opinion with UART an interesting second option if you have a 
free UART HW block available.


I'm happy to contribute one or two drivers for common 1-wire sensors or 
devices, and help out implementing/testing some of the common glue code, 
but in order to remain consistent with the rest of the Mynewt APIs and 
goals I'd prefer to defer the implementation decisions about the common 
API to the larger community who are more active in mynewt-core and I can 
design some drivers around that to test it out with real HW.


Happy to help in any capacity, though!

K.


On 03/07/18 14:44, marko kiiskila wrote:

Hi Kevin,

I was thinking separate packages for different implementations, and
then syscfg knobs inside the respective ones. E.g. GPIO/timer and UART 
selection.
These packages would implement the ‘1-wire’ API, and chip drivers would then
depend on that API.

The PJRC API is simple, which I like. Seems like a good starting point.


On Jul 3, 2018, at 3:31 PM, Kevin Townsend  wrote:

Hi Marko,

IMHO, The PJRC lib is a sensible basis for a Mynewt 1-Wire package since it's 
seen a fair amount of real-world use, and the underlying implementation could 
be configured via the syscfg.yml file (timer+GPIO or something else like UART 
if you have one free)?

Kevin


On 03/07/18 12:07, marko kiiskila wrote:

Sounds like a candidate for driver interface, not HAL. I agree with Miguel.
User could pick the implementation which uses UART, or one which
uses hal_timer with hal_gpio.

However; Sam, you don’t think a generic driver interface makes sense?
If you had driver package which implemented an API similar to this:
One-Wire Library,  https://www.pjrc.com/teensy/td_libs_OneWire.html 
,
would you have been able to use it?


On Jul 3, 2018, at 3:11 AM, Sam Lewis  wrote:

It might be more difficult to make a generic driver for but I've had some
great success using a UART peripheral to read/write 1 wire devices. There's
a good writeup of how this works in this app note:
https://www.maximintegrated.com/en/app-notes/index.mvp/id/214

The benefit is less CPU time needed for bit banging but you need to make
sure your 1 wire device fits the timing constraints of your UART peripheral.

Just thought it was worth mentioning, might be something to consider.

Sam



On Tue., 3 Jul. 2018, 6:11 am Kevin Townsend, 
wrote:


Hi Miguel,

Good to hear!

Yeah, GPIO is the only way I've ever implemented this and I think a
simple SW implementation is the way to go here.

K.


On 02/07/18 21:39, Miguel Azevedo wrote:

Hi Kevin,
I actually do have some code for 1-wire I implemented a few days ago.
AFAIK most MCUs we support don't have 1-wire specific hardware, so why
not have a general implementation(using hal_timer) instead of one
implementation per MCU?

Thanks,

Miguel
On Mon, Jul 2, 2018 at 8:10 PM Kevin Townsend
 wrote:

Is there any interest is discussing how to add Dallas 1-Wire support to
the HAL? https://en.wikipedia.org/wiki/1-Wire

It's a bit of a niche item, but an interesting protocol (you can power
some devices from the single GPIO line) and there are some very common
and cheap waterproof temp sensors and a few other common items that are
only available in 1 wire.

I'm happy to put one or two test drivers together for common items like
the DS18B20 (https://www.adafruit.com/product/381) ... but the HAL
implementation is something that should probably be discussed with the
wider community first.

Kevin

Re: 1 Wire HAL

[marko kiiskila]

Hi Kevin,

I was thinking separate packages for different implementations, and
then syscfg knobs inside the respective ones. E.g. GPIO/timer and UART 
selection.
These packages would implement the ‘1-wire’ API, and chip drivers would then
depend on that API.

The PJRC API is simple, which I like. Seems like a good starting point.

> On Jul 3, 2018, at 3:31 PM, Kevin Townsend  wrote:
> 
> Hi Marko,
> 
> IMHO, The PJRC lib is a sensible basis for a Mynewt 1-Wire package since it's 
> seen a fair amount of real-world use, and the underlying implementation could 
> be configured via the syscfg.yml file (timer+GPIO or something else like UART 
> if you have one free)?
> 
> Kevin
> 
> 
> On 03/07/18 12:07, marko kiiskila wrote:
>> Sounds like a candidate for driver interface, not HAL. I agree with Miguel.
>> User could pick the implementation which uses UART, or one which
>> uses hal_timer with hal_gpio.
>> 
>> However; Sam, you don’t think a generic driver interface makes sense?
>> If you had driver package which implemented an API similar to this:
>> One-Wire Library,  https://www.pjrc.com/teensy/td_libs_OneWire.html 
>> ,
>> would you have been able to use it?
>> 
>>> On Jul 3, 2018, at 3:11 AM, Sam Lewis  wrote:
>>> 
>>> It might be more difficult to make a generic driver for but I've had some
>>> great success using a UART peripheral to read/write 1 wire devices. There's
>>> a good writeup of how this works in this app note:
>>> https://www.maximintegrated.com/en/app-notes/index.mvp/id/214
>>> 
>>> The benefit is less CPU time needed for bit banging but you need to make
>>> sure your 1 wire device fits the timing constraints of your UART peripheral.
>>> 
>>> Just thought it was worth mentioning, might be something to consider.
>>> 
>>> Sam
>>> 
>>> 
>>> 
>>> On Tue., 3 Jul. 2018, 6:11 am Kevin Townsend, 
>>> wrote:
>>> 
 Hi Miguel,
 
 Good to hear!
 
 Yeah, GPIO is the only way I've ever implemented this and I think a
 simple SW implementation is the way to go here.
 
 K.
 
 
 On 02/07/18 21:39, Miguel Azevedo wrote:
> Hi Kevin,
> I actually do have some code for 1-wire I implemented a few days ago.
> AFAIK most MCUs we support don't have 1-wire specific hardware, so why
> not have a general implementation(using hal_timer) instead of one
> implementation per MCU?
> 
> Thanks,
> 
> Miguel
> On Mon, Jul 2, 2018 at 8:10 PM Kevin Townsend
>  wrote:
>> Is there any interest is discussing how to add Dallas 1-Wire support to
>> the HAL? https://en.wikipedia.org/wiki/1-Wire
>> 
>> It's a bit of a niche item, but an interesting protocol (you can power
>> some devices from the single GPIO line) and there are some very common
>> and cheap waterproof temp sensors and a few other common items that are
>> only available in 1 wire.
>> 
>> I'm happy to put one or two test drivers together for common items like
>> the DS18B20 (https://www.adafruit.com/product/381) ... but the HAL
>> implementation is something that should probably be discussed with the
>> wider community first.
>> 
>> Kevin
>> 
 
>> 
> 

Re: 1 Wire HAL

[Kevin Townsend]

Hi Marko,

IMHO, The PJRC lib is a sensible basis for a Mynewt 1-Wire package since 
it's seen a fair amount of real-world use, and the underlying 
implementation could be configured via the syscfg.yml file (timer+GPIO 
or something else like UART if you have one free)?


Kevin


On 03/07/18 12:07, marko kiiskila wrote:

Sounds like a candidate for driver interface, not HAL. I agree with Miguel.
User could pick the implementation which uses UART, or one which
uses hal_timer with hal_gpio.

However; Sam, you don’t think a generic driver interface makes sense?
If you had driver package which implemented an API similar to this:
One-Wire Library,  https://www.pjrc.com/teensy/td_libs_OneWire.html 
,
would you have been able to use it?


On Jul 3, 2018, at 3:11 AM, Sam Lewis  wrote:

It might be more difficult to make a generic driver for but I've had some
great success using a UART peripheral to read/write 1 wire devices. There's
a good writeup of how this works in this app note:
https://www.maximintegrated.com/en/app-notes/index.mvp/id/214

The benefit is less CPU time needed for bit banging but you need to make
sure your 1 wire device fits the timing constraints of your UART peripheral.

Just thought it was worth mentioning, might be something to consider.

Sam



On Tue., 3 Jul. 2018, 6:11 am Kevin Townsend, 
wrote:


Hi Miguel,

Good to hear!

Yeah, GPIO is the only way I've ever implemented this and I think a
simple SW implementation is the way to go here.

K.


On 02/07/18 21:39, Miguel Azevedo wrote:

Hi Kevin,
I actually do have some code for 1-wire I implemented a few days ago.
AFAIK most MCUs we support don't have 1-wire specific hardware, so why
not have a general implementation(using hal_timer) instead of one
implementation per MCU?

Thanks,

Miguel
On Mon, Jul 2, 2018 at 8:10 PM Kevin Townsend
 wrote:

Is there any interest is discussing how to add Dallas 1-Wire support to
the HAL? https://en.wikipedia.org/wiki/1-Wire

It's a bit of a niche item, but an interesting protocol (you can power
some devices from the single GPIO line) and there are some very common
and cheap waterproof temp sensors and a few other common items that are
only available in 1 wire.

I'm happy to put one or two test drivers together for common items like
the DS18B20 (https://www.adafruit.com/product/381) ... but the HAL
implementation is something that should probably be discussed with the
wider community first.

Kevin

[GitHub] carlescufi commented on issue #2: Image upload broken on Windows

[GitBox]

carlescufi commented on issue #2: Image upload broken on Windows
URL: https://github.com/apache/mynewt-mcumgr-cli/issues/2#issuecomment-402137495
 
 
   @utzig thanks! I now realize I get this error on Linux as well after 
updating `mcumgr`, so this is not a Windows issue. Here's the log:
   
   [log.txt](https://github.com/apache/mynewt-mcumgr-cli/files/2159232/log.txt)
   


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

[GitHub] carlescufi commented on issue #2: Image upload broken on Windows

[GitBox]

carlescufi commented on issue #2: Image upload broken on Windows
URL: https://github.com/apache/mynewt-mcumgr-cli/issues/2#issuecomment-402133202
 
 
   @ccollins476ad I would report the exact mcumgr version, but it simply shows:
   
   ```
   C:\Users\Carles\go\bin>mcumgr version
   mcumgr 0.0.0-dev
   ```
   
   I ran ` go get -u github.com/apache/mynewt-mcumgr-cli/mcumgr` before testing


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

[GitHub] carlescufi commented on issue #2: Image upload broken on Windows

[GitBox]

carlescufi commented on issue #2: Image upload broken on Windows
URL: https://github.com/apache/mynewt-mcumgr-cli/issues/2#issuecomment-402132372
 
 
   I wonder what `Error 3` means?


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

[GitHub] carlescufi commented on issue #2: Image upload broken on Windows

[GitBox]

carlescufi commented on issue #2: Image upload broken on Windows
URL: https://github.com/apache/mynewt-mcumgr-cli/issues/2#issuecomment-402132221
 
 
   CC @ccollins476ad @utzig @sjanc @lemrey


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

[GitHub] carlescufi opened a new issue #2: Image upload broken on Windows

[GitBox]

carlescufi opened a new issue #2: Image upload broken on Windows
URL: https://github.com/apache/mynewt-mcumgr-cli/issues/2
 
 
   Running `mcumgr` on Windows with the following settings:
   
   ```
   C:\Users\Carles\go\bin>mcumgr conn show com3
   Connection profiles:
 com3: type=serial, connstring='dev=COM3,baud=115200'
   ```
   
   Every time I try to send an image to MCUboot in recovery mode:
   
   ```
   C:\Users\Carles\go\bin>mcumgr image upload 
c:\Users\Carles\shared\signed_smp_svr_12_06_2018_8h30m.bin -c com3 -e
0 / 110780 
[---]
   0.00%Error: 3
   ```
   


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

[GitHub] carlescufi commented on issue #1: Error: errno 0 when running cross-compiled executable on Yocto ARM system

[GitBox]

carlescufi commented on issue #1: Error: errno 0 when running cross-compiled 
executable on Yocto ARM system
URL: https://github.com/apache/mynewt-mcumgr-cli/issues/1#issuecomment-402131783
 
 
   CC @ccollins476ad @utzig 


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

[GitHub] carlescufi commented on issue #6: BLE reassembly support

[GitBox]

carlescufi commented on issue #6: BLE reassembly support
URL: https://github.com/apache/mynewt-mcumgr/issues/6#issuecomment-402130885
 
 
   Note that this is required for interaction with Android phones version 5 and 
below, since they don't support big ATT_MTUs (I am told by @philips77)


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

[GitHub] carlescufi commented on issue #5: cmd: img_mgmt: Add an extra byte to the 'hash' buffer

[GitBox]

carlescufi commented on issue #5: cmd: img_mgmt: Add an extra byte to the 
'hash' buffer
URL: https://github.com/apache/mynewt-mcumgr/pull/5#issuecomment-402118844
 
 
   @Olivier-ProGlove @JoeHut will you send a PR to Zephyr to update with this 
version?


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

[GitHub] utzig closed pull request #4: Readme.md: Link OS-specific documentation

[GitBox]

utzig closed pull request #4: Readme.md: Link OS-specific documentation
URL: https://github.com/apache/mynewt-mcumgr/pull/4
 
 
   

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 1f202b3..3aa6df9 100644
--- a/README.md
+++ b/README.md
@@ -16,8 +16,8 @@ both the Apache Mynewt and Zephyr operating systems.
 For tips on using mcumgr with your particular OS, see the appropriate file from
 the list below:
 
-* README-mynewt.md
-* README-zephyr.md
+* [Mynewt](README-mynewt.md)
+* [Zephyr](README-zephyr.md)
 
 ## Dependencies
 


 


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: 1 Wire HAL

[marko kiiskila]

Sounds like a candidate for driver interface, not HAL. I agree with Miguel.
User could pick the implementation which uses UART, or one which
uses hal_timer with hal_gpio.

However; Sam, you don’t think a generic driver interface makes sense?
If you had driver package which implemented an API similar to this:
One-Wire Library,  https://www.pjrc.com/teensy/td_libs_OneWire.html 
,
would you have been able to use it?

> On Jul 3, 2018, at 3:11 AM, Sam Lewis  wrote:
> 
> It might be more difficult to make a generic driver for but I've had some
> great success using a UART peripheral to read/write 1 wire devices. There's
> a good writeup of how this works in this app note:
> https://www.maximintegrated.com/en/app-notes/index.mvp/id/214
> 
> The benefit is less CPU time needed for bit banging but you need to make
> sure your 1 wire device fits the timing constraints of your UART peripheral.
> 
> Just thought it was worth mentioning, might be something to consider.
> 
> Sam
> 
> 
> 
> On Tue., 3 Jul. 2018, 6:11 am Kevin Townsend, 
> wrote:
> 
>> Hi Miguel,
>> 
>> Good to hear!
>> 
>> Yeah, GPIO is the only way I've ever implemented this and I think a
>> simple SW implementation is the way to go here.
>> 
>> K.
>> 
>> 
>> On 02/07/18 21:39, Miguel Azevedo wrote:
>>> Hi Kevin,
>>> I actually do have some code for 1-wire I implemented a few days ago.
>>> AFAIK most MCUs we support don't have 1-wire specific hardware, so why
>>> not have a general implementation(using hal_timer) instead of one
>>> implementation per MCU?
>>> 
>>> Thanks,
>>> 
>>> Miguel
>>> On Mon, Jul 2, 2018 at 8:10 PM Kevin Townsend
>>>  wrote:
 Is there any interest is discussing how to add Dallas 1-Wire support to
 the HAL? https://en.wikipedia.org/wiki/1-Wire
 
 It's a bit of a niche item, but an interesting protocol (you can power
 some devices from the single GPIO line) and there are some very common
 and cheap waterproof temp sensors and a few other common items that are
 only available in 1 wire.
 
 I'm happy to put one or two test drivers together for common items like
 the DS18B20 (https://www.adafruit.com/product/381) ... but the HAL
 implementation is something that should probably be discussed with the
 wider community first.
 
 Kevin
 
>>> 
>> 
>> 

[GitHub] carlescufi opened a new issue #6: BLE reassembly support

[GitBox]

carlescufi opened a new issue #6: BLE reassembly support
URL: https://github.com/apache/mynewt-mcumgr/issues/6
 
 
   The BLE transport supports segmentation (i.e. splitting SMP reponses into 
multiple ATT_MTU-sized notifications) but not reassembly (i.e. reassembling SMP 
requests that have been split across multiple ATT_MTU-sized Write Commands).
   
   CC @ccollins476ad @nvlsianpu @philips77 


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

[GitHub] carlescufi commented on issue #3: Unable to compile sample on zephyr 1.11

[GitBox]

carlescufi commented on issue #3: Unable to compile sample on zephyr 1.11
URL: https://github.com/apache/mynewt-mcumgr/issues/3#issuecomment-402069628
 
 
   @ccollins476ad this seems to be obsolete, mind closing it?


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

[GitHub] carlescufi commented on issue #4: Readme.md: Link OS-specific documentation

[GitBox]

carlescufi commented on issue #4: Readme.md: Link OS-specific documentation
URL: https://github.com/apache/mynewt-mcumgr/pull/4#issuecomment-402069439
 
 
   CC @ccollins476ad. This looks good, can you merge this?


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