I think I might have found something related to the problem while I was
updating my Firmware files. I saw that all calls with rx_queue in i2c.c
were commented, I don't remember why we did this, but it would explain why
the waitReady() and all calls waiting for an answer through TWI would
crash.
Do you think this would be a possible explanation?
I am continuing to update all my Firmware and Android IOIO libs. I should
be able to give some news about the progress during the week.
Le lundi 23 mars 2015 12:47:50 UTC+1, Vincent Nadon a écrit :
>
> 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-st
>>>>>>>>>>>>>>> ops-i2c-bluetooth-communication-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.
