Okay, in this case how do I disable the SPI to save the RAM ressources? Since I am using the UART, but not the SPI, I think it would be a really good idea to disable it if I can save a good amount of bytes (8000 bytes?).
Thanks! Le jeudi 2 avril 2015 20:19:31 UTC+2, Ytai a écrit : > > Inline > > On Thu, Apr 2, 2015 at 9:31 AM, Vincent Nadon <[email protected] > <javascript:>> 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] <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.
