Inline On Thu, Apr 2, 2015 at 9:31 AM, Vincent Nadon <[email protected]> wrote:
> Okay, I will try to ask more specific questions. I also saw that a similar > problem was reported here: Maximum TWI transaction size > <https://groups.google.com/forum/#!topic/ioio-users/HvqKBGH7wNE> . This > might be related? > > Questions: > > *1.* I cannot find the files for for previous versions of the Firmware. I > downloaded all the files contained in the GitHub. I would like to take a > look at the files of Firmware version IOIO0326 to compare them with my > slightly modified versions to see the differences. Especially the i2c.c/.h > and the protocol.c/.h. Is there a way to find such files somewhere else? > Everything is in the git history. Official releases are tagged. > > *2.* The problem I have seems to be related to latency or drops of bytes > (because of a full buffer?). Which lead to disconnection of the PIC IOIO > and freezing my App. I am able to receive the first few bytes and then > after a few writeRead() the PIC sends > a AppProtocolSendMessageWithVarArgSplit then the Android App > freezes. Obviously, now I get writeRead acknowledges for the correct reads, > when it drops I don't get the > aknowledge. This AppProtocolSendMessageWithVarArgSplit seems to occur > because of a latency problem which provokes a lost of bytes (0 bytes at > beginning and 183 bytes at the end? when I am supposed to have 4 bytes , > see screenshot attached). Please note that psd_buff_ptr contains the value > I'm reading (in my UART logging) and I am able to see this value appear in > my LogCat sometimes or partly see attached LogCat excerpt. > > I tried increasing Interrupt Priority level from 4 to 2, as you did in > the change from V3.x to V5.x of the Firmware. Then my Device seems to > bootup faster because of all my i2c calls which now have higher priority, > but my latency or dropout problem still occurs. As soon as I get the drop > and then reboot my App, my Device also reboots to reconnect with the App. > Please find my versions of i2c and protocol.c attached (based on V3.x), I > think the problem would mainly be there. Again I did compare these files > with the V5.x version and didn't see major changes other than optimization > of some functions like atomic16 and AssignMI2CxIF. The problem occurs no > matter if I use twi.writeRead() or twi.writeReadAsync(). > > Maybe I need a better explanation of how to use twi.writeRead() and > twi.writeReadAsync()? > If bytes are lost in the communication between the IOIO and the Android it totally doesn't matter what you do in your app. Everything is designed around the assumption that the channel is reliable. > Also explanation on the use of buffers RX_BUF_SIZE in i2c.c > and DEFINE_STATIC_BYTE_QUEUE in protocol.c could help me? Would it be > useful to clear these buffers after a few reads? > This again gets you to the lost bytes case. Doesn't seem like a viable approach. > I included an excerpt of the problematic code section of my Android App in > attachment. If I take out the writeRead() call everything is fine since the > i2c would not be used. > You've probably reduced the load on the buffers by doing that, so no more data gets discarded. > > *3.* I am starting to think that it could be the reading of the > DSP register that could cause the latency and crash the connection? > According to the 0 bytes received in the logging...What do you think? > I don't think latency has to do with it. > > I am deeply sorry if all my messages bother you. I am simply doing my best > to find the problem and solve it. > You're probably better off starting figuring out other ways to save RAM than messing with the one place where all data goes through. You can disable some features (e.g. UART, SPI) which also use RAM buffers. Also, I would slowly encourage you to keep the delta from stock firmware minimal (if at all) or otherwise really make sure you understand how the firmware works and what impact changes you make might have. > > Vincent > > Le mardi 31 mars 2015 19:04:51 UTC+2, Ytai a écrit : >> >> I don't see how I can effectively help you when you're running a modified >> version of the firmware that I am not familiar with and are unable to >> demonstrate the the problem originates from the standard codebase (not to >> say that it doesn't). >> You need to debug your code and figure out what's happening. If you get >> to a conclusion that some of the existing code is wrong, I would love to >> look into it. If you have specific question about the code or about how to >> debug I would love to help. >> >> On Tue, Mar 31, 2015 at 9:28 AM, Vincent Nadon <[email protected]> >> wrote: >> >>> *UPDATE*: I have found the problem related to the non responsive calls >>> of twi.readWrite() with my custom firmware (V3.x), this was due to some >>> modifications we did in the i2c.c file commenting all calls of rx_queue. >>> After uncommenting these lines, the Andrdoid App received the read >>> acknowledge (Result...). >>> >>> I still wasn't able to make V5.x *stock *firmware work on my custom >>> platform. As you say I would probably need to try it on a stock IOIO >>> hardware board, but at this time for me it is too complicated (buying a >>> IOIO, trying it, then trying to debug my custom board again) and it would >>> get me further from the problem that I already partly solved. >>> >>> *Now, I have two problems*: >>> >>> 1. After about 24 twi.readWrite() calls, my PIC restarts by itself >>> so I can only do 24 reads whether it is 1 every 100ms or 1 every 1second. >>> In my case I would like to do 22x 10 readings, 1 every 100ms. I had >>> previously decreased DEFINE_STATIC_BYTE_QUEUE to 128 instead of 8192 for >>> the rx to have enough memory space for proper functionnality of my DSPs. >>> I >>> tried to increase it to 2048, but then my audio signals didn't sound >>> right >>> in my DSP and also it didn't solve the problem that after 24 reads the >>> PIC >>> restarts. To me this seems to be some kind of buffer problem, when it >>> gets >>> full it crashes. I guess there could be a way to reset this buffer every >>> few calls, if we find this faulty buffer?? >>> 2. I cannot read the response value. I see in my PIC logging that >>> the command to read passes and the correct value is in the buffer in the >>> PIC, but it doesn't get in the Android App... >>> >>> >>> Le vendredi 27 mars 2015 11:22:59 UTC+1, Vincent Nadon a écrit : >>>> >>>> I'm only talking about the Hardware firmware now. I can't even try with >>>> my Android App since my hardware doesn't even boot and therefore doesn't >>>> establish the bluetooth or USB connection. As I said I am using the IOIO >>>> V5.x as plain as I can. I will try again without changing anything at all, >>>> but chances are there might be something that I need to modify that I don't >>>> see. >>>> >>>> As you say it is hard to find the problem since I have custom hardware >>>> and therefore need to modify the Firmware a bit. >>>> >>>> >>>> Le vendredi 27 mars 2015 08:43:31 UTC+1, Ytai a écrit : >>>>> >>>>> There are too many things that can go wrong in your setup: custom >>>>> IOIO, custom forward with changes that are very likely to break stuff and >>>>> a >>>>> fair amount of complexity in your app. >>>>> I recommend that you start by eliminating some possible causes (e.g. >>>>> test your app on a stock IOIO with stock firmware or run a rigorous test >>>>> on >>>>> your custom hardware/firmware, such as the IOIO torture test. >>>>> Otherwise you'd be wasting our time. >>>>> On Mar 26, 2015 9:30 AM, "Vincent Nadon" <[email protected]> >>>>> wrote: >>>>> >>>>>> >>>>>> - So I tried the V5.X firmware, as plain vanilla as I could. I >>>>>> have put some call for LEDs to light up during boot process and I >>>>>> connected >>>>>> an Arduino USB2Serial to monitor the logging. >>>>>> >>>>>> As it is, no LEDs light up and I don't see anything in the logging, >>>>>> no "***** Hello from app-layer! *******", nothing... Even my bluetooth >>>>>> dongle doesn't seem to light up anymore. >>>>>> >>>>>> >>>>>> >>>>>> I did configure everything to suit my hardware (PIC24FJ256DA206) and >>>>>> then also changed the pins for my UART according to what I had working in >>>>>> my previous firmware, and changed few pins for LEDs. I also configured >>>>>> the >>>>>> ENABLE_LOGGING in the pic30-gcc preprocessor macros. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> libusb, libconn, libbtstack, libadb, Bootloader and AppLayerV1 all >>>>>> build without errors. >>>>>> >>>>>> >>>>>> >>>>>> - I have also another question, in my previous firmware version I >>>>>> had to set Memory_Model to Large Data, Large code and small scalar. >>>>>> I also >>>>>> had to modify QUEUE_SIZE in protocol.c to 128 (instead of 8192) to >>>>>> fit the >>>>>> code to program my DSPs in the pic memory. Would you have a better >>>>>> suggestion to provide the memory space for DSP code? (I use the pic to >>>>>> program my DSPs at bootup) >>>>>> >>>>>> -- >>>>>> 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.
