New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Replace currantlabs dep with go-ble. #53
Conversation
I get this on my MacOS 10.13.1 from this branch: newtmgr -c named_oic --name ci res get public /oic/d |
Dont forget to update this projects readme doesnt need currantlabs ble anymore and any other dep changes. Also that PR you were waiting on is in |
Thanks, Jacob - correct on both points. By the way, I am pretty sure this is close to fixing the High Sierra issue. It has been a little while so my memory is hazy, but I recall the remaining issue being that some XPC IDs just need to be reverse engineered:
I don't recall which one it was, but at least one of these IDs has changed since Yosemite. I was going to figure out the IDs via trial and error on a High Sierra machine, but unfortunately I didn't get a chance. |
Ill take a look, I think some noble folks have gotten them close to reversed. Do you want to be using upstream go-ble now that the patch is in or are you trying to use your fork of it to lock the version |
I did give this branch a run along with Jacob's updates to this branch and to runtimeco/ble. While testing, I encountered a bug in OIC over BLE. Created a PR for that one. |
My readme update is using upstream go-ble, while revendor is using runtimeco/ble so that actually needs to be changed. |
Upstream This should be ready to merge now. |
Gave this a test myself after all these weeks and PRs. Working for me on high sierra:
|
I dont have a go script that does a full upload does anyone? Otherwise Ill manually try an upload on one of my nrf52 devices |
hrm. Might need some work yet. Havent succeeded to upload on like 10 attempts, but my chrome uploader succeeded the first time. Anyone remember the verbosity/debug flags?
|
I havent seen those disconnects happen again (on the nrf51 anyway.) Ive done a bunch of complete upload cycles and further Ive got a little bash script to upload a (large) loader over and over again that might be helpful for testing that hasnt failed yet. #!/bin/bash
# run an array of commands COUNTER times, exit if return code
declare -a arr=("newtmgr -c nimble_bleprph image erase" "newtmgr -c nimble_bleprph image list" "newtmgr -c nimble_bleprph image upload /Users/jacobrosenthal/Downloads/chippd3/bin/targets/split-microbit/loader/apps/bleprph/bleprph.img" "newtmgr -c nimble_bleprph image list")
COUNTER=20
while [ $COUNTER -gt 0 ]; do
for (( i = 0; i < ${#arr[@]} ; i++ )); do
printf "\n**** Running: ${arr[$i]} *****\n\n"
# i=0, erase commmand, always returns error code so dont respect
eval "${arr[$i]}"
if [ $? -ne 0 ] && [ $i -ne 0 ]
then
exit $?
fi
done
let COUNTER-=1
done LGTM |
On mac OS High Sierra, while doing a newtmgr image upload -c bleconn /path/to/nrf52_app/app/apps/bleprph/bleprph.img, I have a progress bar remaining at 0B, and an Error: disconnected: Any idea of where the problem is coming from? With the debug flag, I have:
|
Im tracking something similar here: |
This replaces the native BLE library github.com/currantlabs/ble with a better maintained one: github.com/go-ble/ble. The go-ble library has support for macOS 10.13 (High Sierra).