background processing and mergBLE

Anything beyond the basics in using the LiveCode language. Share your handlers, functions and magic here.

Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, robinmiller

dougr
Posts: 14
Joined: Thu Oct 14, 2010 10:58 pm

background processing and mergBLE

Post by dougr » Fri Apr 06, 2018 9:29 pm

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.

dougr
Posts: 14
Joined: Thu Oct 14, 2010 10:58 pm

background processing and mergBLE

Post by dougr » Fri Apr 06, 2018 9:31 pm

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.

dunbarx
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 9578
Joined: Wed May 06, 2009 2:28 pm
Location: New York, NY

Re: background processing and mergBLE

Post by dunbarx » Fri Apr 06, 2018 10:00 pm

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:

Code: Select all

wait 1 with messages
allow your app to "listen" to these other processes of which you speak?

Craig Newman

bwmilby
Posts: 438
Joined: Wed Jun 07, 2017 5:37 am
Location: Henrico, VA
Contact:

Re: background processing and mergBLE

Post by bwmilby » Sat Apr 07, 2018 12:45 am

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.)
Brian Milby

Script Tracker https://github.com/bwmilby/scriptTracker

bn
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 3990
Joined: Sun Jan 07, 2007 9:12 pm
Location: Bochum, Germany

Re: background processing and mergBLE

Post by bn » Sat Apr 07, 2018 9:14 am

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

bogs
Posts: 5435
Joined: Sat Feb 25, 2017 10:45 pm

Re: background processing and mergBLE

Post by bogs » Sat Apr 07, 2018 12:59 pm

Both good points Brian.
Image

bogs
Posts: 5435
Joined: Sat Feb 25, 2017 10:45 pm

Re: background processing and mergBLE

Post by bogs » Sat Apr 07, 2018 1:16 pm

bn wrote:
Sat Apr 07, 2018 9:14 am
Monte is not regularly scanning the Forum.
My bad, I know I've seen him answer here, while I didn't think he was regularly on I did figure he was at least a once in a while visitor :oops:

Thanks Bernd!
Image

dunbarx
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 9578
Joined: Wed May 06, 2009 2:28 pm
Location: New York, NY

Re: background processing and mergBLE

Post by dunbarx » Sat Apr 07, 2018 5:02 pm

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:

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
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

dougr
Posts: 14
Joined: Thu Oct 14, 2010 10:58 pm

Re: background processing and mergBLE

Post by dougr » Sat Apr 07, 2018 11:48 pm

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"

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
...   
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")

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
...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.

dougr
Posts: 14
Joined: Thu Oct 14, 2010 10:58 pm

Re: background processing and mergBLE

Post by dougr » Sat Apr 07, 2018 11:55 pm

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

bwmilby
Posts: 438
Joined: Wed Jun 07, 2017 5:37 am
Location: Henrico, VA
Contact:

Re: background processing and mergBLE

Post by bwmilby » Sun Apr 08, 2018 1:14 am

In your second code block, you are missing with messages on the wait.

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

dunbarx
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 9578
Joined: Wed May 06, 2009 2:28 pm
Location: New York, NY

Re: background processing and mergBLE

Post by dunbarx » Sun Apr 08, 2018 1:18 am

Yes,

Without "with messages", that command is blocking.

Craig

dougr
Posts: 14
Joined: Thu Oct 14, 2010 10:58 pm

Re: background processing and mergBLE

Post by dougr » Sun Apr 08, 2018 1:22 am

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!

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 9802
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Re: background processing and mergBLE

Post by FourthWorld » Sun Apr 08, 2018 1:45 am

Duplicate threads merged.

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

bwmilby
Posts: 438
Joined: Wed Jun 07, 2017 5:37 am
Location: Henrico, VA
Contact:

Re: background processing and mergBLE

Post by bwmilby » Sun Apr 08, 2018 2:29 am

dougr wrote:
Fri Apr 06, 2018 9:29 pm
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.

[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.
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).
Brian Milby

Script Tracker https://github.com/bwmilby/scriptTracker

Post Reply

Return to “Talking LiveCode”