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