Okay thanks! I might use that later on.
I have finally found the solution to my writeRead acknowledges, it was the
ByteQueuePushByte(&i2c->rx_queue, 0x00) in i2c.c that I had removed because
it was bugging my bootup sequence. My fix was to put an external variable
"bootup" that I control in my main.c to put this stop byte after my bootup
was done, see code below. Now my App doesn't bug anymore and I can do
around 15 read bursts (1/75ms or 1/100ms) 22 times (so around 330 reads in
about 40 seconds), maybe I can do more using the Async(). Hope this post
will help someone! :)
case STATE_STOP_WRITE_ONLY:
if (reg->stat >> 15) { goto error; }
if(bootup==0)
ByteQueuePushByte(&i2c->rx_queue, 0x00);
goto done;
Le samedi 4 avril 2015 20:21:15 UTC+2, Ytai a écrit :
>
> 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]
> <javascript:>> 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] <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.
