Smart Bluetooth Forum Discussions

I am updating my database from a structure received via SPI.  After receiving, I update all of the characteristics using the corresponding store_in_db calls.  I'm finding that it's taking far longer than I expect to accomplish this and am concerned about taking up all this time in a timer callback context.

16 characterisitcs are written.  All are mix of UINT8 and UINT16 values (28 bytes total).  10 are notifiable and the other 6 are not.  In the traces I am measuring between the last two FC (Flow Control) toggles as they occur just before and just after the database update calls in my code.  I am using the fine timer @ 20ms to kick off the updates which accounts for the N-N-N case being so high.  Device is not connected during test.

Clean builds between measurements.  Traces enabled/disabled from makefile via BLE_TRACE_DISABLE.  Write and notify flags controlled by arguments to store_in_db calls.

Trace=Y Write=Y Notify=Y: 166ms

Trace=N Write=Y Notify=Y:  74ms

Trace=N Write=Y Notify=N:  69ms

Trace=N Write=N Notify=N  18ms

Taking out the 18ms gives:

Y-Y-Y: 148ms

N-Y-Y:  56ms

N-Y-N:  51ms

Which means that it takes approximately 2ms to write a byte of data to GATT.  What is the bleprofile_WriteHandle function doing?  Is it committing every value to NVRAM under the hood?  As expected, the trace calls have a significant overhead and there is no way of completely shutting them off in ROM functions, correct?

Is there anything I can do to optimize my writes or make this process more efficient (other than queuing up each attribute and processing them individually, one per fine timer tick)?

What's the consequences of taking 50-100ms in a timer callback?

In the SDK, I copied the WICED_Sense folder under 'Apps' to another folder  under Apps, which I called AC_WICED_Sense.  Then I created another make target named AC_WICED_Sense, and hacked the code:

In wiced_sense.h, I changed all 'Features' from 1 to 0.  (Top 15 or so lines of the file.)

It seems to build and download my AC_WICED_Sense app ok, but all the sensors are still working (I can view them in the demo phone app).  In other words, I think it is SAYING that my modified code was downloaded, but I don't think it is running my code on the device.

What gives?  I just want to make sure it really is my code that is running, so I can then go play with the LEDs and buzzer and things.

Any ideas?

-AC

I used the below to set up PUART flow control,

     puart_selectUartPads(((bleprofile_puart_p_cxfg->rxpin / 16) << 5) | (bleprofile_puart_p_cfg->rxpin % 16),

               ((bleprofile_puart_p_cxfg->rxpin / 16) << 5) | (bleprofile_puart_p_cfg->rxpin % 16),

               3, 1);

     puart_init();

     puart_flowOn();

and the WP pin of my test platform is set to P32.

There are only 16 bytes of data received and some data lost when transferring over 16 bytes of data.

The RTS pin of the PUART seems not work.

Thanks!

Jack Huang

The central can call blecen_Conn() to connect a peripheral which is in advertisement.

Can the peripheral device directly reconnect to central which is paired before?

If yes, which function call can do it?

Thanks!

Jack Huang

From below discussion, it seems that user app occupy the upper 26k(or 30k) byte of the IRAM.

BCM20732 Memory Map Architecture

But from the build log of hello_sensor app in wiced 2.1.1, the patch+app space was not in the area mentioned above.

The RAM space from 0x204568 to 0x204568+6005 reside in the "DATA ONLY" area which should be only for the stack.

Patches start at                  0x00204568 (RAM address)

Patches end at                    0x002052D0 (RAM address)

Application starts at             0x00204F70 (RAM address)

Application ends at               0x00205CDD (RAM address)

Patch size (including reused RAM)       3432 bytes

Patch size                              2568 bytes

Application size                        3437 bytes

                                      ------

Total RAM footprint                     6005 bytes (5.9kiB)

Can anyone correct my understanding?

thanks.

Roger

Can anyone tell me if you can get access to the TP3,4,5,6,7 from the WICED Sense platform board and use them as for GP outputs? Can you crack open the case, and easily get to them?

Are there other options to get GPIO?  Can you run commercial USB to GPIO cables that are available (and do we have the drivers available)?

I just downloaded the Android code and started reviewing it.  One question that also comes to mind, what causes the sensor tag to send the measurements?  Is there some kind of message sent to the sensor tag to get a response, or does the sensor tag use a fixed timer to send periodic measurement reports once paired with a BLE device?

In general, there doesn't seem to be a comprehensive interface document that rigorously defines what goes between the sensor tag and the application.

So, I have the WICED SMART IDE Eclipse environment installed, and have even been able to build the WICED Sense app within it.

Now I want to play with the demo phone app source code for Android and IOS.

Can I put these demo apps into the same Eclipse environment?   (Should I?)

I'm not an expert in Eclipse, and its not clear to me if the embedded WICED Sense stuff and phone app stuff can, or should, share the same Eclipse.  But intuitively, it seems silly to make a separate one for the phone apps.

-AC

After following the videos to install IDE and SDK, I'm getting:

09:50:35 **** Build of configuration Release for project WICED-Smart-SDK ****

"C:\\Users\\acowan\\Documents\\WICED\\WICED-Smart-SDK-2.1.1\\WICED-Smart-SDK\\make.exe" WICED_Sense download

Makefile:194: *** Platform makefile not found: Platforms//.mk.  Stop.

09:50:35 Build Finished (took 110ms)

Anybody know how to fix this?

-AC