So I tried with the waitReady() and it freezes as soon as I call it...
See code:
> public void onFinish() {
> iWrite("Read ack? :" + read_ack_bool);
>
> try {
> read_ack = twi.writeReadAsync(addressDSP1, false, stim_off,
> stim_off.length, null, 0);
>
> read_ack_bool = read_ack.waitReady();
>
> iWrite("Read ack? :" + read_ack_bool);
>
> } catch (ConnectionLostException e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> } catch (InterruptedException e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> }
> iWrite("Stim stopped");
> }
Le lundi 23 mars 2015 11:47:04 UTC+1, Vincent Nadon a écrit :
>
> 1. I am using IOIOlib version 3.30, is it considered too old? I am using
> this version because it is compatible with my firmware in my PIC, according
> to what you are saying I might have to upgrade everything (PIC firmware and
> IOIOlib) which might be a bit difficult for me since I have to put back all
> the modifications I did in the firmware until now. If I have to do it I
> will do it, but of course I would like to avoid this trouble.
>
> 2. I will try that.
>
> 3. I need to read the DSP register every 100ms for 10 consecutive reads
> (total 1 second). Then calculate the average of these register values and
> show it to the user on the Android UI screen. After that I put the
> stim_off, to stop the stimuli procedure. In the code I attached I removed
> the averaging part since I had to give you the minimal code showing the
> problem. I am open for suggestions to find a better way to do what I need
> to do.
>
>
> Thanks!
>
> Vincent
>
> Le lundi 23 mars 2015 06:01:34 UTC+1, Ytai a écrit :
>>
>>
>> 1. Are you using a very old version of IOIOLib? Looks like you're
>> hitting a bug that has been resolved long ago.
>> 2. You're not using the result correctly. You should call waitReady()
>> on it, as well as check the return value for success.
>> 3. You seem to still be generating a lot of async requests writing to
>> the same result buffer.
>>
>> What are you actually trying to achieve? You seem to be reading data and
>> then not using it at all. There's probably a better and simpler way to do
>> what you want.
>>
>> On Thu, Mar 19, 2015 at 11:47 AM, Vincent Nadon <[email protected]>
>> wrote:
>>
>>> I printed the LogCat outpout related to the App crash, you can find it
>>> attached to this post . I don't know exactly what you mean by stack trace,
>>> I hope it is contained inside the LogCat messages... or did you mean
>>> another Log file? I am not familiar with all the Logs...
>>>
>>> I tried to wait completion of Async() with the returned object as
>>> follows, but it still crashes before I see message "Stim stopped" because
>>> of the following twi call which doesn't work :
>>>
>>> public class dataRecCountDownTimer extends CountDownTimer {
>>>> public dataRecCountDownTimer(long startTime, long interval) {
>>>> super(startTime, interval);
>>>> }
>>>> @Override
>>>> public void onTick(long millisUntilFinished) {
>>>> try {
>>>> read_ack = twi.writeReadAsync(addressDSP3, false, RB,
>>>> RB.length, response,
>>>> response.length);
>>>>
>>>> } catch (ConnectionLostException e) {
>>>> // TODO Auto-generated catch block
>>>> e.printStackTrace();
>>>> }
>>>> }
>>>> @Override
>>>> public void onFinish() {
>>>> if(read_ack.equals(1))
>>>> {
>>>> try {
>>>> twi.writeReadAsync(addressDSP1, false, stim_off,
>>>> stim_off.length, null, 0);
>>>>
>>>> } catch (ConnectionLostException e) {
>>>> // TODO Auto-generated catch block
>>>> e.printStackTrace();
>>>> }
>>>> iWrite("Stim stopped");
>>>> }
>>>> }
>>>> }
>>>
>>>
>>> When I try with the synchronous method writeRead() it completely freezes
>>> my Android App:
>>>
>>> public class dataRecCountDownTimer extends CountDownTimer {
>>>> public dataRecCountDownTimer(long startTime, long interval) {
>>>> super(startTime, interval);
>>>> }
>>>> @Override
>>>> public void onTick(long millisUntilFinished) {
>>>>
>>>> try {
>>>> read_ack = twi.writeRead(addressDSP3, false, RB, RB.length, response,
>>>> response.length);
>>>> } catch (ConnectionLostException e) {
>>>> // TODO Auto-generated catch block
>>>> e.printStackTrace();
>>>> } catch (InterruptedException e) {
>>>> // TODO Auto-generated catch block
>>>> e.printStackTrace();
>>>> }
>>>>
>>>> }
>>>> @Override
>>>> public void onFinish() {
>>>> if(read_ack == true)
>>>> {
>>>>
>>>> try {
>>>> twi.writeRead(addressDSP1, false, stim_off,
>>>> stim_off.length, null, 0);
>>>> } catch (ConnectionLostException e) {
>>>> // TODO Auto-generated catch block
>>>> e.printStackTrace();
>>>> } catch (InterruptedException e) {
>>>> // TODO Auto-generated catch block
>>>> e.printStackTrace();
>>>> }
>>>>
>>>> iWrite("Stim stopped");
>>>> }
>>>> }
>>>> }
>>>
>>>
>>>
>>> Le mercredi 18 mars 2015 01:24:36 UTC+1, Ytai a écrit :
>>>>
>>>> When an Android app crashes, an error message an stack trace gets
>>>> written to the log. What's in your log?
>>>> Also, in order to wait for completion just call writeRead() instead of
>>>> Async(). Another option is using the object returned from Async() to await
>>>> completion.
>>>> On Mar 17, 2015 7:22 AM, "Vincent Nadon" <[email protected]> wrote:
>>>>
>>>>> So I included back the call of twi to read RB and put it in "response"
>>>>> buffer (see attached code) to make the App crash. Now, when I start my
>>>>> timer it starts stim_on and after a few seconds the App crashes, in the
>>>>> LogCat I see IOIOthread is exiting.
>>>>>
>>>>> Le lundi 16 mars 2015 19:20:13 UTC+1, Vincent Nadon a écrit :
>>>>>>
>>>>>> The App doesn't crash anymore when I take out the twi call for RB
>>>>>> buffer. When it crashes it starts my stim_on (so I hear sounds with my
>>>>>> device) and then it tells me that Unfortunately the App has stopped. I
>>>>>> can
>>>>>> confirm to you tomorrow more precisely how...
>>>>>>
>>>>>> How can I make sure to wait for the transaction to complete? with
>>>>>> delays? I think this might be a problem like you say. Also, you say
>>>>>> calling
>>>>>> multiple functions subsequently with calls to twi shouldn't be a problem?
>>>>>>
>>>>>>
>>>>>>
>>>>>> Le lundi 16 mars 2015 19:08:39 UTC+1, Ytai a écrit :
>>>>>>>
>>>>>>> You should be able to use the entire API concurrently with no
>>>>>>> problem. It is all thread safe.
>>>>>>> How exactly does it crash when it does?
>>>>>>> Also, you seem to be clobbering the "response" buffer from multiple
>>>>>>> requests and you also seem to be reading from it without waiting for
>>>>>>> the
>>>>>>> transaction to complete.
>>>>>>>
>>>>>>> On Mon, Mar 16, 2015 at 10:54 AM, Vincent Nadon <
>>>>>>> [email protected]> wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I am sorry about that. I understand that debugging a lot of code is
>>>>>>>> time consuming. Here attached is a version that I debugged step by
>>>>>>>> step. I
>>>>>>>> found that I had calls to functions which might call the
>>>>>>>> twi.writeReadAsync
>>>>>>>> simultaneously, removing these calls made my app responsive to
>>>>>>>> subsequent
>>>>>>>> calls of my stim_on and stim_off. Moreover, calling the
>>>>>>>> twi.writeReadAsync
>>>>>>>> for the RB buffer at multiple places as you mentioned seemed to cause
>>>>>>>> the
>>>>>>>> App to crash after a second call of my stim_on and stim_off. Removing
>>>>>>>> all
>>>>>>>> calls to twi.writeReadAsync for RB buffer solved the problem for the
>>>>>>>> moment.
>>>>>>>>
>>>>>>>> I figured that I need to keep the screen alive (as I used to do) so
>>>>>>>> that after my Timer is up my stim_off is executed, otherwise it is not
>>>>>>>> executed.
>>>>>>>>
>>>>>>>> I also have a problem that is persisting, I cannot call my stim_on
>>>>>>>> with my button on my screen more than 8 times precisely, is that
>>>>>>>> related to
>>>>>>>> some buffer or something?
>>>>>>>>
>>>>>>>> I would like to know how I can make sure that I can call
>>>>>>>> the twi.writeReadAsync in multiple functions, sequentially (one after
>>>>>>>> the
>>>>>>>> other). For example, DSP_button1(); followed by DSPbutton2(); and
>>>>>>>> DSPbutton3(); each containing calls of twi.writeReadAsync .
>>>>>>>>
>>>>>>>> Thanks again for your help!
>>>>>>>>
>>>>>>>> Le samedi 14 mars 2015 00:11:28 UTC+1, Ytai a écrit :
>>>>>>>>>
>>>>>>>>> I think you misunderstood what I meant by "minimal code". What I
>>>>>>>>> meant is that you provide me with minimum code that actually does
>>>>>>>>> build and
>>>>>>>>> run and exhibits your problem and that is as small as possible.
>>>>>>>>> Reading
>>>>>>>>> through your 300 or so lines of code trying to figure out what's
>>>>>>>>> going on
>>>>>>>>> is a pretty time-consuming task. It is very likely that in the
>>>>>>>>> process of
>>>>>>>>> trying to strip down your code you'll find out the problem yourself.
>>>>>>>>> Otherwise, you'd be at least able to explain it more precisely.
>>>>>>>>>
>>>>>>>>> As for the asynchronous calls, if you actually care about what's
>>>>>>>>> in the buffer, you shouldn't share it across concurrent calls.
>>>>>>>>> Otherwise,
>>>>>>>>> why are you passing it in the first place?
>>>>>>>>>
>>>>>>>>> On Fri, Mar 13, 2015 at 5:04 AM, Vincent Nadon <
>>>>>>>>> [email protected]> wrote:
>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> I trimmed it a bit more again, I haven't tested this code because
>>>>>>>>>> I would have to put some code back in... but it should show the
>>>>>>>>>> problem. I
>>>>>>>>>> have shown where "response" is defined in this version. I am
>>>>>>>>>> comfortable
>>>>>>>>>> sharing across asynchronous calls since these calls are supposed to
>>>>>>>>>> be
>>>>>>>>>> sequential if I see it right and also it is simply a read data
>>>>>>>>>> buffer.
>>>>>>>>>>
>>>>>>>>>> Thanks for further help :)
>>>>>>>>>>
>>>>>>>>>> Le jeudi 12 mars 2015 22:00:50 UTC+1, Ytai a écrit :
>>>>>>>>>>>
>>>>>>>>>>> Is that really the minimum required, in the sense that anything
>>>>>>>>>>> you'd remove would make the problem disappear? Also some things are
>>>>>>>>>>> missing, e.g. where the response buffer being defined and why are
>>>>>>>>>>> you
>>>>>>>>>>> comfortable sharing it across asynchronous calls.
>>>>>>>>>>> On Mar 12, 2015 7:06 AM, "Vincent Nadon" <[email protected]>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> Here is the trimmed down file that should illustrate the
>>>>>>>>>>>> problem. I think it mainly comes from my threads (timers) and the
>>>>>>>>>>>> IOIO
>>>>>>>>>>>> management...
>>>>>>>>>>>>
>>>>>>>>>>>> Hope you guys can help me out :)
>>>>>>>>>>>>
>>>>>>>>>>>> See attached file!
>>>>>>>>>>>>
>>>>>>>>>>>> Le jeudi 12 mars 2015 05:28:13 UTC+1, Ytai a écrit :
>>>>>>>>>>>>>
>>>>>>>>>>>>> There's nothing special about the loop() method, it is mostly
>>>>>>>>>>>>> a convenience feature. You may call IOIO APIs from any thread
>>>>>>>>>>>>> including the
>>>>>>>>>>>>> UI thread (which includes all sorts of GUI listeners).
>>>>>>>>>>>>> The code you posted on stackoverflow doesn't have anything
>>>>>>>>>>>>> that's related to IOIO on it, so I don't think you'd get much
>>>>>>>>>>>>> help there. I
>>>>>>>>>>>>> recommend you to make a copy of your problematic app, trim it
>>>>>>>>>>>>> down to the
>>>>>>>>>>>>> bare minimum that illustrates the problem and then post it here.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Wed, Mar 11, 2015 at 11:48 AM, Vincent Nadon <
>>>>>>>>>>>>> [email protected]> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> I am having the following problem : http://stackoverflow.com/
>>>>>>>>>>>>>> questions/28989176/android-app-stops-i2c-bluetooth-communicat
>>>>>>>>>>>>>> ion-ioio
>>>>>>>>>>>>>> and I think it's because all my code to call the
>>>>>>>>>>>>>> twi.WriteReadAsync is outside the loop() function.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Le mercredi 11 mars 2015 18:55:55 UTC+1, Vincent Nadon a
>>>>>>>>>>>>>> écrit :
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> How does the Android IOIO App loop() function work? Is there
>>>>>>>>>>>>>>> a way to create functions in the Looper class which are called
>>>>>>>>>>>>>>> inside this
>>>>>>>>>>>>>>> loop() according to a listener on a Button or a Spinner? This
>>>>>>>>>>>>>>> way it would
>>>>>>>>>>>>>>> simplify my code since I need to send a lot of twi commands in
>>>>>>>>>>>>>>> the loop()
>>>>>>>>>>>>>>> based on the user input in my Android UI Menu.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> You received this message because you are subscribed to the
>>>>>>>>>>>>>> Google Groups "ioio-users" group.
>>>>>>>>>>>>>> To unsubscribe from this group and stop receiving emails from
>>>>>>>>>>>>>> it, send an email to [email protected].
>>>>>>>>>>>>>> To post to this group, send email to
>>>>>>>>>>>>>> [email protected].
>>>>>>>>>>>>>> Visit this group at http://groups.google.com/group/ioio-users
>>>>>>>>>>>>>> .
>>>>>>>>>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>> You received this message because you are subscribed to the
>>>>>>>>>>>> Google Groups "ioio-users" group.
>>>>>>>>>>>> To unsubscribe from this group and stop receiving emails from
>>>>>>>>>>>> it, send an email to [email protected].
>>>>>>>>>>>> To post to this group, send email to [email protected].
>>>>>>>>>>>> Visit this group at http://groups.google.com/group/ioio-users.
>>>>>>>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>> You received this message because you are subscribed to the
>>>>>>>>>> Google Groups "ioio-users" group.
>>>>>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>>>>>> send an email to [email protected].
>>>>>>>>>> To post to this group, send email to [email protected].
>>>>>>>>>> Visit this group at http://groups.google.com/group/ioio-users.
>>>>>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>> You received this message because you are subscribed to the Google
>>>>>>>> Groups "ioio-users" group.
>>>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>>>> send an email to [email protected].
>>>>>>>> To post to this group, send email to [email protected].
>>>>>>>> Visit this group at http://groups.google.com/group/ioio-users.
>>>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "ioio-users" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>>> an email to [email protected].
>>>>> To post to this group, send email to [email protected].
>>>>> Visit this group at http://groups.google.com/group/ioio-users.
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "ioio-users" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to [email protected].
>>> To post to this group, send email to [email protected].
>>> Visit this group at http://groups.google.com/group/ioio-users.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
--
You received this message because you are subscribed to the Google Groups
"ioio-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/ioio-users.
For more options, visit https://groups.google.com/d/optout.
