The simplest way would be to just go to spi.c and make all the buffers really small.
On Fri, Apr 3, 2015 at 2:12 AM, Vincent Nadon <[email protected]> wrote: > 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]> >> 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. > -- 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.
