Yes, I did start to upgrade to V5 firmware and V5 IOIOLib. This is what I meant by updating my Firmware files.
I will tell you with the status of my progress once I am done with the ugprade. For the sampling I will try to use the writeRead() calls only as you say. On Mon, Mar 23, 2015 at 9:46 PM, Ytai Ben-Tsvi <[email protected]> wrote: > There is no inherent timeout on the TWI calls. They will block forever if > the response never arrives (or the thread is interrupted). > In order to save everybody's time, I would suggest that you try getting > this piece of code to work with a stock v5.x firmware and stock v5 IOIOLib > and only once you've nailed down the software consider going back to custom. > > I have no explanation for the crashes. Let's try to get your software > right first and see if they still occur. > > If you're sampling every 100ms you should be perfectly OK using only > blocking calls. This will make you life a lot easier. Make sure to check > the return code of writeRead(). If it is false, the transaction failed > (e.g. NACKed), which means you should disregard any data in the response > buffer. > > On Mon, Mar 23, 2015 at 11:20 AM, Vincent Nadon < > [email protected]> wrote: > >> 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. >> > > -- > You received this message because you are subscribed to a topic in the > Google Groups "ioio-users" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/ioio-users/1eSftDUOSvo/unsubscribe. > To unsubscribe from this group and all its topics, 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. > -- Vincent Nadon Ph.D. candidate, M. A. Sc., B.Eng. Universiteit Gent *Belgian Mobile number*: *0 470 94 58 82* -- 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.
