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] > <javascript:>> 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/que >>>>>>>> stions/28989176/android-app-stops-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] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> 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.
