background processing and mergBLE
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, robinmiller
background processing and mergBLE
Since BLE is not an ACK/NAK protocol, I need to "simulate" such an interface. In principle, it is quite easy and straightforward. For every time you write out from Livecode iOS to the receiving BLE device (an Arduino Adafruit Bluefruit module, in this case) via mergBLE, the Arduino "sees" the incoming data and replies with (literally) and "ACK".
The problem I am having (which is related to my experiences (of lack thereof) with mergBLE), is that the BLE card doesn't "run" in the background. in other words, the incoming ACK from the Arduino is only made available to the LC stack when the stack "goes idle" ... as good a term as I can invent for the message-passing methodology of a LC process. The incoming (to LC) ACK isn't lost... the hardware buffers it just fine, it's just that I need a way to get LC to "see" the ACK as soon as possible after the LC write... and that's just doesn't happen in "real time".
I know about putting a Group into the background... but that isn't the same sort of background I need... I need to be able to either:
- detach / fork / job (chose one depending on your big-system experience) a code segment/card/stack into the background .... I know iOS (since iOS 8, I think) can handle background processing ... BUT just how to do so in LC is unknown to me. If possible I'd run the whole BLE card in the background.
- somehow (without necessarily pushing a process into the background) trigger the current stack to READ the incoming message acquired by the mergBLE message handler "mergBLEPeripheralDidUpdateValueForCharacteristic".
The relation of this subject to my previous post regarding mergBLE is that since I cannot find a way to "use" individual aspects of the mergBLE "toolkit", I can't seem to find a way to call/invoke/trigger some other part of my LC code to fetch the incoming message.
Interestingly, if I "pause" my stack with an LC "answer" command, the incoming ACK mergBLE message gets processed by the BLE card as soon as the ANSWER window appears. I remember (I think... getting old!) reading that "ANSWER" is actually a separate stack (?sub-stack?)... I am guessing here but it seems like the act of waiting for a button push in an ANSWER invocation, it what allows the mergBLE card to run it's own message handlers and retrieve my ACK. Hopefully THAT makes sense to the reader.
So if someone could assist me in recommending a way to "simulate" what ANSWER does WITHOUT waiting for a user input/action, that would likely solve this particular problem.
ps: I know about using a looping command/function with a "send <message to myself> in <time>" as a way to produce a "semi-detached" process ... but that doesn't help unless it "allows" the BLE card to process its incoming messages. Tried it, doesn't do what I need.
The problem I am having (which is related to my experiences (of lack thereof) with mergBLE), is that the BLE card doesn't "run" in the background. in other words, the incoming ACK from the Arduino is only made available to the LC stack when the stack "goes idle" ... as good a term as I can invent for the message-passing methodology of a LC process. The incoming (to LC) ACK isn't lost... the hardware buffers it just fine, it's just that I need a way to get LC to "see" the ACK as soon as possible after the LC write... and that's just doesn't happen in "real time".
I know about putting a Group into the background... but that isn't the same sort of background I need... I need to be able to either:
- detach / fork / job (chose one depending on your big-system experience) a code segment/card/stack into the background .... I know iOS (since iOS 8, I think) can handle background processing ... BUT just how to do so in LC is unknown to me. If possible I'd run the whole BLE card in the background.
- somehow (without necessarily pushing a process into the background) trigger the current stack to READ the incoming message acquired by the mergBLE message handler "mergBLEPeripheralDidUpdateValueForCharacteristic".
The relation of this subject to my previous post regarding mergBLE is that since I cannot find a way to "use" individual aspects of the mergBLE "toolkit", I can't seem to find a way to call/invoke/trigger some other part of my LC code to fetch the incoming message.
Interestingly, if I "pause" my stack with an LC "answer" command, the incoming ACK mergBLE message gets processed by the BLE card as soon as the ANSWER window appears. I remember (I think... getting old!) reading that "ANSWER" is actually a separate stack (?sub-stack?)... I am guessing here but it seems like the act of waiting for a button push in an ANSWER invocation, it what allows the mergBLE card to run it's own message handlers and retrieve my ACK. Hopefully THAT makes sense to the reader.
So if someone could assist me in recommending a way to "simulate" what ANSWER does WITHOUT waiting for a user input/action, that would likely solve this particular problem.
ps: I know about using a looping command/function with a "send <message to myself> in <time>" as a way to produce a "semi-detached" process ... but that doesn't help unless it "allows" the BLE card to process its incoming messages. Tried it, doesn't do what I need.
background processing and mergBLE
Since BLE is not an ACK/NAK protocol, I need to "simulate" such an interface. In principle, it is quite easy and straightforward. For every time you write out from Livecode iOS to the receiving BLE device (an Arduino Adafruit Bluefruit module, in this case) via mergBLE, the Arduino "sees" the incoming data and replies with (literally) and "ACK".
The problem I am having (which is related to my experiences (of lack thereof) with mergBLE), is that the BLE card doesn't "run" in the background. in other words, the incoming ACK from the Arduino is only made available to the LC stack when the stack "goes idle" ... as good a term as I can invent for the message-passing methodology of a LC process. The incoming (to LC) ACK isn't lost... the hardware buffers it just fine, it's just that I need a way to get LC to "see" the ACK as soon as possible after the LC write... and that's just doesn't happen in "real time".
I know about putting a Group into the background... but that isn't the same sort of background I need... I need to be able to either:
- detach / fork / job (chose one depending on your big-system experience) a code segment/card/stack into the background .... I know iOS (since iOS 8, I think) can handle background processing ... BUT just how to do so in LC is unknown to me. If possible I'd run the whole BLE card in the background.
- somehow (without necessarily pushing a process into the background) trigger the current stack to READ the incoming message acquired by the mergBLE message handler "mergBLEPeripheralDidUpdateValueForCharacteristic".
The relation of this subject to my previous post regarding mergBLE is that since I cannot find a way to "use" individual aspects of the mergBLE "toolkit", I can't seem to find a way to call/invoke/trigger some other part of my LC code to fetch the incoming message.
Interestingly, if I "pause" my stack with an LC "answer" command, the incoming ACK mergBLE message gets processed by the BLE card as soon as the ANSWER window appears. I remember (I think... getting old!) reading that "ANSWER" is actually a separate stack (?sub-stack?)... I am guessing here but it seems like the act of waiting for a button push in an ANSWER invocation, it what allows the mergBLE card to run it's own message handlers and retrieve my ACK. Hopefully THAT makes sense to the reader.
So if someone could assist me in recommending a way to "simulate" what ANSWER does WITHOUT waiting for a user input/action, that would likely solve this particular problem.
ps: I know about using a looping command/function with a "send <message to myself> in <time>" as a way to produce a "semi-detached" process ... but that doesn't help unless it "allows" the BLE card to process its incoming messages. Tried it, doesn't do what I need.
The problem I am having (which is related to my experiences (of lack thereof) with mergBLE), is that the BLE card doesn't "run" in the background. in other words, the incoming ACK from the Arduino is only made available to the LC stack when the stack "goes idle" ... as good a term as I can invent for the message-passing methodology of a LC process. The incoming (to LC) ACK isn't lost... the hardware buffers it just fine, it's just that I need a way to get LC to "see" the ACK as soon as possible after the LC write... and that's just doesn't happen in "real time".
I know about putting a Group into the background... but that isn't the same sort of background I need... I need to be able to either:
- detach / fork / job (chose one depending on your big-system experience) a code segment/card/stack into the background .... I know iOS (since iOS 8, I think) can handle background processing ... BUT just how to do so in LC is unknown to me. If possible I'd run the whole BLE card in the background.
- somehow (without necessarily pushing a process into the background) trigger the current stack to READ the incoming message acquired by the mergBLE message handler "mergBLEPeripheralDidUpdateValueForCharacteristic".
The relation of this subject to my previous post regarding mergBLE is that since I cannot find a way to "use" individual aspects of the mergBLE "toolkit", I can't seem to find a way to call/invoke/trigger some other part of my LC code to fetch the incoming message.
Interestingly, if I "pause" my stack with an LC "answer" command, the incoming ACK mergBLE message gets processed by the BLE card as soon as the ANSWER window appears. I remember (I think... getting old!) reading that "ANSWER" is actually a separate stack (?sub-stack?)... I am guessing here but it seems like the act of waiting for a button push in an ANSWER invocation, it what allows the mergBLE card to run it's own message handlers and retrieve my ACK. Hopefully THAT makes sense to the reader.
So if someone could assist me in recommending a way to "simulate" what ANSWER does WITHOUT waiting for a user input/action, that would likely solve this particular problem.
ps: I know about using a looping command/function with a "send <message to myself> in <time>" as a way to produce a "semi-detached" process ... but that doesn't help unless it "allows" the BLE card to process its incoming messages. Tried it, doesn't do what I need.
-
- VIP Livecode Opensource Backer
- Posts: 9663
- Joined: Wed May 06, 2009 2:28 pm
- Location: New York, NY
Re: background processing and mergBLE
I know little of these early 60's sitcoms of which you speak.
Sorry.
I know little of the particulars of which you speak.
But broadly, would sprinkling in a lot of:
allow your app to "listen" to these other processes of which you speak?
Craig Newman
Sorry.
I know little of the particulars of which you speak.
But broadly, would sprinkling in a lot of:
Code: Select all
wait 1 with messages
Craig Newman
Re: background processing and mergBLE
This post really should be a continuation of your original query to keep the information together. I’m not sure if a moderator can merge them though.
Can we see some of your code? It is very hard to answer your question in general terms, especially since I don’t have any experience with BLE. But, if I can see what you are doing that does/does not work I may be able to spot something. (And probably more for the more experienced around here.)
Can we see some of your code? It is very hard to answer your question in general terms, especially since I don’t have any experience with BLE. But, if I can see what you are doing that does/does not work I may be able to spot something. (And probably more for the more experienced around here.)
Brian Milby
Script Tracker https://github.com/bwmilby/scriptTracker
Script Tracker https://github.com/bwmilby/scriptTracker
-
- VIP Livecode Opensource Backer
- Posts: 4002
- Joined: Sun Jan 07, 2007 9:12 pm
- Location: Bochum, Germany
Re: background processing and mergBLE
Hi Doug,
unfortunately I can not help with mergBLE but maybe this can help you.
Monte is not regularly scanning the Forum. But as you might have found out already he has a web-site dedicated to the merg externals.
http://mergext.com/home/mergble/
I suggest that you contact him directly via
http://goulding.ws/consulting/about/
just point him to your forum posts.
Or another possibility is to go to the use-list where a lot of advanced Livecode developers are.
(You have to apply to gain access to the use-list)
http://lists.runrev.com/mailman/listinfo/use-livecode
Here is what a quick search of the use-list returned
https://www.mail-archive.com/search?q=m ... runrev.com
I hope this helps.
Kind regards
Bernd
unfortunately I can not help with mergBLE but maybe this can help you.
Monte is not regularly scanning the Forum. But as you might have found out already he has a web-site dedicated to the merg externals.
http://mergext.com/home/mergble/
I suggest that you contact him directly via
http://goulding.ws/consulting/about/
just point him to your forum posts.
Or another possibility is to go to the use-list where a lot of advanced Livecode developers are.
(You have to apply to gain access to the use-list)
http://lists.runrev.com/mailman/listinfo/use-livecode
Here is what a quick search of the use-list returned
https://www.mail-archive.com/search?q=m ... runrev.com
I hope this helps.
Kind regards
Bernd
Re: background processing and mergBLE
Both good points Brian.
-
- VIP Livecode Opensource Backer
- Posts: 9663
- Joined: Wed May 06, 2009 2:28 pm
- Location: New York, NY
Re: background processing and mergBLE
I suspect I am not understanding your problem, but is it that you are trying to "listen" for another message while a handler is running, or while LC is quiescent? I am interested in that sort of thing in general, as a matter of knowing more about how LC thinks. So if you have a button and a field on a card, and in the button script:
This is basic stuff. If you click on the button, the field increments via a running handler. If you press the commandKey, you are able to insinuate another "process" into the mix. Does this have anything at all to do with your question? In other words, can you set up a case where LC either "listens" or "interrogates" itself to detect this ACK thingie?
Craig
Code: Select all
on mouseUp
put 0 into fld 1
runProcess
end mouseUp
on runProcess
if the optionKey is down then exit to top
listenForOtherStuff
add 1 to fld 1
wait 10 with messages
runProcess
end runProcess
on listenForOtherStuff
if the commandKey is down then put 0 into fld 1
end listenForOtherStuff
Craig
Re: background processing and mergBLE
Thanks to all (so far .. keep 'em coming!) for the replies... first to bogs and bmilby ... I kept the two threads separate because although they both relate to mergBLE, they really are two separate topics and issues. Additionally, the first thread was getting so long, I didn't want readers to nod off getting to the end. I have added an additional discovery relevant to the "disconnect and re-connect to MergBLE" thread (I can now close/stop the connection but I still cannot re-start it).
Thanks, Craig... but I've done that sort of thing in several places within my code ... to no avail. I'm beginning to think I'm discovered a Copenhagen quantum wave function collapse condition in LC. If I don't try to look for the ACK, it appears in both fields I've coded the BLE_Card to put it:
- field "debugField" of card "anycaster_card1"
and
- field "fromAnycaster" of card "anycaster_card1"
If, on the other hand, I "wait" for the ACK to appear, it does not appear... until... ("on checkFrom" is located in the main (one and only) stack to ensure it is seen in the message pathway. It is called by a "mouseUp" handler on a scrollbar object located on my main card ... "doCheck" global variable is set to "true" before the call to "checkFrom")
...until ... And to reiterate a point, when the loop fails to find the ACK, the very act of "posting" an ANSWER cause the ACK to appear in the fields... the wave function collapses. Hence my need to an "ANSWER" type "pause" WITHOUT the required user interaction.
Thanks, Craig... but I've done that sort of thing in several places within my code ... to no avail. I'm beginning to think I'm discovered a Copenhagen quantum wave function collapse condition in LC. If I don't try to look for the ACK, it appears in both fields I've coded the BLE_Card to put it:
- field "debugField" of card "anycaster_card1"
and
- field "fromAnycaster" of card "anycaster_card1"
Code: Select all
on mergBLEPeripheralDidUpdateValueForCharacteristic pPeripheral, pCharacteristic, pValue, pError
...
switch
case pCharacteristic is fld "notify" of card "BLE_Card"
--put true into BLESrc
put interpret_incoming(pValue) after field "debugField" of card "anycaster_card1"
...
-------------------
function interpret_incoming intake
if intake contains "ACK" then
put intake into field "fromAnycaster" of card "anycaster_card1"
return intake
exit interpret_incoming
end if
...
Code: Select all
on checkFrom
if doCheck is true then
put 20 into x
repeat until ((field "fromAnycaster" of card "anycaster_card1" contains "ACK") or (x < 1))
wait for 100 milliseconds
subtract 1 from x
end repeat
if x < 1 then
answer "timed out waiting for an ACK"
else
put "OK" into field "verifyField" of card "anycaster_card1"
end if
end if
put false into doCheck
end checkFrom
Re: background processing and mergBLE
That's HUGE assist, Bernd!! I will follow your advice. I feel like I'm on the verge of success with this code if I can only get a bit more info about how mergBLE was implemented and how it interacts with LC
I will reply once I've managed to find more in info... as I'm sure this will be valuable to others.
Cheers! ... Doug
I will reply once I've managed to find more in info... as I'm sure this will be valuable to others.
Cheers! ... Doug
Re: background processing and mergBLE
In your second code block, you are missing with messages on the wait.
One other way to structure that loop:
One other way to structure that loop:
Code: Select all
local sWaitCounter
on checkFrom
if (field "fromAnycaster" of card "anycaster_card1" contains "ACK") then
put "OK" into field "verifyField" of card "anycaster_card1"
put 0 into sWaitCounter
exit checkFrom
end if
add 1 to sWaitCounter
if sWaitCounter > 20 then
answer "timed out waiting for an ACK"
put 0 into sWaitCounter
exit checkFrom
end if
send "checkFrom" to me in 100 milliseconds
end checkFrom
Brian Milby
Script Tracker https://github.com/bwmilby/scriptTracker
Script Tracker https://github.com/bwmilby/scriptTracker
-
- VIP Livecode Opensource Backer
- Posts: 9663
- Joined: Wed May 06, 2009 2:28 pm
- Location: New York, NY
Re: background processing and mergBLE
Yes,
Without "with messages", that command is blocking.
Craig
Without "with messages", that command is blocking.
Craig
Re: background processing and mergBLE
I've sent to message off to Monte begging for help (I ain't proud!). In the meantime, I went through every posting you extracted for me:
" ... Or another possibility is to go to the use-list where a lot of advanced Livecode developers are.
(You have to apply to gain access to the use-list)
http://lists.runrev.com/mailman/listinfo/use-livecode
Here is what a quick search of the use-list returned
https://www.mail-archive.com/search?q=m ... runrev.com ..."
AND the bottom line is:
... a BLE for Android is greatly desired ... are ya listening LC?
... no one is that whole list has done any significant work with mergBLE that they've noted or posted about.
now, I could be wrong about these interpretations but if anyone can prove otherwise, I'd be more than happy to kowtow!
" ... Or another possibility is to go to the use-list where a lot of advanced Livecode developers are.
(You have to apply to gain access to the use-list)
http://lists.runrev.com/mailman/listinfo/use-livecode
Here is what a quick search of the use-list returned
https://www.mail-archive.com/search?q=m ... runrev.com ..."
AND the bottom line is:
... a BLE for Android is greatly desired ... are ya listening LC?
... no one is that whole list has done any significant work with mergBLE that they've noted or posted about.
now, I could be wrong about these interpretations but if anyone can prove otherwise, I'd be more than happy to kowtow!
-
- VIP Livecode Opensource Backer
- Posts: 9837
- Joined: Sat Apr 08, 2006 7:05 am
- Location: Los Angeles
- Contact:
Re: background processing and mergBLE
Duplicate threads merged.
Going forward please post only one thread on a given topic so everyone can find the answers in one place.
Going forward please post only one thread on a given topic so everyone can find the answers in one place.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
Re: background processing and mergBLE
Based on these 2 statements, I still think there is a logic issue with how you are attempting to structure the code. LiveCode runs on an event loop and responds to messages. If you try to run your own event loop, you are just going to end up blocking messages (which is what your checkFrom code does). The loop you describe in your PS would just be the timeout check (which is how I rewrote your checkFrom). The actual work should be done based on events coming back from the mergBLE code (on mergBLEPeripheralDidUpdateValueForCharacteristic).dougr wrote: ↑Fri Apr 06, 2018 9:29 pmInterestingly, if I "pause" my stack with an LC "answer" command, the incoming ACK mergBLE message gets processed by the BLE card as soon as the ANSWER window appears. I remember (I think... getting old!) reading that "ANSWER" is actually a separate stack (?sub-stack?)... I am guessing here but it seems like the act of waiting for a button push in an ANSWER invocation, it what allows the mergBLE card to run it's own message handlers and retrieve my ACK. Hopefully THAT makes sense to the reader.
[SNIP]
ps: I know about using a looping command/function with a "send <message to myself> in <time>" as a way to produce a "semi-detached" process ... but that doesn't help unless it "allows" the BLE card to process its incoming messages. Tried it, doesn't do what I need.
Brian Milby
Script Tracker https://github.com/bwmilby/scriptTracker
Script Tracker https://github.com/bwmilby/scriptTracker