example
ble_peripheral.end()
central.disconnect()

It would be nice if the readme could explain how to throw this bunch into the Arduino nightly IDE so I can use the latest stuff.

If I use CurieBLE to implement a Bluetooth profile and use the Adafruit neomatrix library in the same sketch I find that after my first interaction with the connected neomatrix panel, I no longer receive callbacks to functions from the BLE API and calls to loop() no longer take place. In short execution seems to have halted.

Is this an ISR related issue?

I've attached two sketches. One use the neomatrix library but with no Bluetooth, the other uses the neomatrix library in exactly the same way but is driven by writes to a Bluetooth characteristic. The former one works fine, the latter does not.

To recreate, load the neomatrixdemo sketch, then using any GATT client application like the nRF Master Control Panel app on an Android device, scan for the Genuino, connect to it and then write a value of 0x07 to the first characteristic (UUID: 74ED00018CA349464560B9FB911D898E). You should see a callback to neomatrixservice_StripControlcharacteristicWriteHandler. Now repeat the same test (or try a value of 0x08). You'll get no response and on investigation should find that loop() is no longer being called.

genuino101.zip

Hello! I am working on another issue, and decided to update my version. I was on 1.0.3 and I just realized y'all are on 1.0.6. I followed the directions on the git page and tried to compile my sketch, as well as the example Blink sketch. In both cases I get this error:

arc-elf32-g++: error: unrecognized argument in option ‘-mcpu=quarkse_em’
arc-elf32-g++: note: valid arguments to ‘-mcpu=’ are: ARC600 ARC601 ARC700 ARCv2EM ARCv2HS arc600 arc601 arc700 arcem archs
exit status 1
Error compiling for board Arduino/Genuino 101.

It looks like the issue may be in the platform.txt file, but I really don't know... is this a known problem?

Thanks!

If i2c bus is scanned for devices, reported results are unreliable

Modifying int TwoWire::endTransmission(uint8_t sendStop) in this way

err = i2c_readbyte();
// double check
if (err < 0) {
     err = i2c_readbyte();
}

we can get better results.

I believe that some flags (the ones reporting bus errors) are not cleared correctly and ss_i2c_err(uint32_t dev_id) callback is triggered more than needed

Klocwork found 2 issues in CurieEEPROM:

• CurieEEPROM.cpp (line 69):
  Array 'blockdata' of size 128 may use index value(s) 128..511

int blockIndex = address/4;
blockdata[blockIndex] = data;

Same issue on:

• CurieEEPROM.cpp (line 127):
• CurieEEPROM.cpp (line 132):

In BLE protocal, it is possible for a BLE peripheral to advertise data while connected to another central device.
Is it possible to modify the CurieBLE to allow BLE peripheral to at least keep advertise device name while connected to another central device?
As I trace BLEPeripheral.cpp, I found that the private function _startAdvertising will return in the beginning if the _state != BLE_PERIPH_STATE_READY, and the _state will be changed into BLE_PERIPH_STATE_CONNECTED after the device is connected. So is it possible to modify this part to allow BLE peripheral advertise while connected?

Thanks!

iOS doesn't see changes to Bluetooth services and characteristics between sketches

To duplicate

1. Run example CurieBle -> LED
2. Use LightBlue from iPhone to connect to LED
3. Run example CurieBle -> ButtonLED
4. Use LightBlue from iPhone to connect to ButtonLED (the old LED name will be show)

Problem: The old LED characteristics are also shown

5. Turn Bluetooth off and on on the iPhone
6. Use LightBlue from iPhone to connect to ButtonLED

The correct service and characteristics should now be shown

Background

The original problem was that descriptors (0x2901) added to existing sketches were not showing up in LightBlue. This has not been a problem when using other libraries such as BLEPeripheral or bleno. The steps above are an easier way to duplicate the issue without adding descriptors.

Software/Hardware

Arduino 101
Arduino IDE 1.6.7 on OS 10.10.5
iOS 9.2 (13C75) on iPhone 6s

Possible solution

iOS is expecting Service Changed 0x2a05 to be implemented on the Generic Attribute Service 0x1801.

Morning!

I am looking into what it takes to disable the I2C bus and am referencing the function DRIVER_API_RC ss_i2c_clock_disable(I2C_CONTROLLER controller_id) in ss_i2c_iface.c. The function looks like this, and I am interested in what the two WRITE_ARC_REG functions are doing.

DRIVER_API_RC ss_i2c_clock_disable(I2C_CONTROLLER controller_id)
{
    i2c_info_pt dev = &i2c_master_devs[SS_CTRL_ID(controller_id)];
    uint32_t saved;

    /* Protect registers using lock and unlockl of interruptions */
    saved = interrupt_lock();

    /* disable clock to peripheral */
    WRITE_ARC_REG(READ_ARC_REG((volatile uint32_t)(AR_IO_CREG_MST0_CTRL)) & ~( 1 << dev->creg_i2c_clk_ctrl),
                                   (volatile uint32_t)(AR_IO_CREG_MST0_CTRL));
    /* disable device */
    WRITE_ARC_REG(READ_ARC_REG((volatile uint32_t)(dev->reg_base+I2C_CON)) & ~(I2C_ENABLE_MASTER),
                                   (volatile uint32_t)(dev->reg_base+I2C_CON));
    interrupt_unlock(saved);
    return DRV_RC_OK;
}

The first looks like it is writing to the CREG control register, in order to disable the clock. It takes a 1, shifts it to the left until it gets to either the I2C0, or I2C1 control bit, negates it, and then it is ANDed with what was originally in the CREG register.

The second function changes the I2C Control Register. It uses I2C_ENABLE_MASTER which is defined in i2c_priv.h as:
#define I2C_ENABLE_MASTER (1 << 0)
So we are putting a 1 in the 0 bit, turning it into a 0 (which disables I2C), ANDing it with the control register, and writing it to the control register.

I got confused when I noticed that my bits were not being flipped as I had intended in the CREG control register. According to documentation for the register:

(Bit 30) I2C1_CLK_GATE (I2C1_CLK_GATE)
When I2C1_CLK_GATE is 1 it indicates that the I2C 1 peripheral is inactive and its clock can be gated.

It seems to me that the first write will always write a '0' to the bit(s) that disables one of the I2C clocks, however, I thought that it needed to be a '1' to disable...
The second write does the same thing, but I am assuming here that because we are looking at an 'ENABLE' bit, that 0 is disabled, and 1 is enabled... we are good.

Any thoughts on this? Did I just come up with a fuzzy explanation to confuse myself? I'm trying to understand what exactly I need to write to the registers to disable the bus but this is the opposite of what I had worked out... thanks in advance!

Sorry for the long explanation, helps me work it out :-)

The Processing-based orientation visualizer examples doesn't display properly. Pitch and roll are only shown independently when yaw is 0 or 180 degrees. When yaw is 90 degrees, they display the same!

I made this video demo to show the problem:

https://www.youtube.com/watch?v=SHJ2n1Kwe58

Here is the page where the orientation visualizer code appears.

https://www.arduino.cc/en/Tutorial/Genuino101CurieIMUOrientationVisualiser

I need more functionality from the BMI160 than the Curie board library makes available. I also prefer /require access to several methods from the BMI160 class that the CurieIMU class now wraps/hides.

I am requesting that the following functions be made protected to allow for CurieIMU subclassing:

uint8_t reg_read (uint8_t reg);
void reg_write(uint8_t reg, uint8_t data);
void reg_write_bits(uint8_t reg, uint8_t data, unsigned pos, unsigned len);
uint8_t reg_read_bits(uint8_t reg, unsigned pos, unsigned len);

int serial_buffer_transfer(uint8_t *buf, unsigned tx_cnt, unsigned rx_cnt);

In addition, I am requesting that any BMI160 class functions the CurieIMU class wraps/hides be made accessible (rename, etc.). Examples include:

float getFreefallDetectionThreshold();
...
void setDoubleTapDetectionDuration(int duration);

I'm sure some people find the CurieIMU wrapper useful. It would be nice if the direct access to the BMI160's registers (albeit incomplete) was still available for those who want it. I'd prefer to add on to the libraries you provide, not replace/Frankenstein them.

hi, when i use an arduino101 to controlling LED by PWM via the internal IMU . i find PWM is not work,i could not figure it out ,could you help me?

To effectively use the i2c bus users need a way to programmatically change the I2C bus speed. Currently this is implemented for most of the Arduino boards like the mega as well as the teesnsy. Many sensors that would be connected to the bus would benefit from this ability.

Because the variables txPin and rxPin are defined as global variables in SoftwareSerial.cpp (/CurieSoftwareSerial/SoftwareSerial.cpp) they cannot be used in sketches. This is going to break a lot of existing sketches since they are commonly used variable names in sketches. Please make these variables private or prepend an underscore (_txPin) or make them more specific (curieSwSerialTXPin) or other convention to differentiate.

Why are the uploader script paths in platform.txt hard-coded for only version '1.6.4+1.0'?

platform.txt line #84:
tools.eduload.cmd.path.linux="{runtime.tools.sketchUploader-1.6.4+1.0.path}/clupload/cluploadEDU_linux.sh"

The uploader script cannot be found if sketchuploader is any version other than 1.6.4+1.0

I think that, starting from commit d85aa96, an updated ViperOS fw is needed for the core to work properly, because neither Blink executes.
Sharing here and on Basecamp to reach a quick solution 😄

Hello! I am experimenting with reading the contents of various registers and came across something weird. I am not sure if it is just a simple programming issue that I overlooked... I hope so! I am trying to read the contents of the ARC_CTRL register and get back two different values depending on if I am inside of a new function, or inside of my setup function.

uint32_t creg, saved;
void setup() {

  Serial.begin(115200);
  while(!Serial);

  adc_normal_wo_calib_REFERENCE();

  creg = READ_ARC_REG(ADC_CTRL);

  Serial.print("In SETUP ADC_CTRL after norm wo calib ");
  Serial.print(creg, BIN);
  Serial.println();

  disableADC();

  creg = READ_ARC_REG(ADC_CTRL);

  Serial.print("In SETUP ADC_CTRL after disableADC() ");
  Serial.print(creg, BIN);
  Serial.println();
}

And these are the values that I get. The first two 32bit numbers come from the function that I call (adc_normal_wo_calib_REFERENCE()). The function to read the register is the exact same in all cases.

ADC_CTRL after write: 10000000000000010101000000000011
ADC_CTRL in CREG after write: 10000000000000010101000000000011
**In SETUP ADC_CTRL after norm wo calib 111100000100**
ADC_CTRL reg before disabling ADC 111100000100
ADC_CTRL reg after disabling ADC 111100000100
In SETUP ADC_CTRL after disableADC() 111100000100

The first truncated value is what I expect to see in the first two printed out values but 32 bit.

Does anyone know why the values may be different? And why it seems that in the read that happens in the setup() function, the value is truncated?

Any help or insight would be greatly appreciated. Thanks!
--c

Am using Arduino-101 and I'm trying to broadcast my messages through BLE. Is there any possible way to broadcast the message without pairing or connecting to central device, so that all available devices can receive my message?

the callbacks

Wire.onReceive(receiveData);

and

Wire.onRequest(sendData)

are missing compare to previous versions. Now it is not possible to setup arduino 101 as slave to enable communications with other devices such as Raspberry or similar

Some overloads for method "begin" are also missing

error: no matching function for call to 'TwoWire::begin(int)'

According to the BMI160 datasheet:

low-g interrupt trigger threshold according to Val(int_low_th<7:0>) * 7.81 mg for Val(int_low_th<7:0>) >0 and 3.91 mg for Val(int_low_th<7:0>)=0. The range of the threshold is from 3.91 mg to 2.000 g; the default value corresponds to an acceleration of 375 mg

Based on that, a value of 1 would make the threshold 7.81. Plugging in the default value (0x30), we get 374.88.

The implementation of getFreefallDetectionThreshold() and setFreefallDetectionThreshold(), however, returns Val(int_low_th<7:0>) * 7.81 mg + 3.91 for Val(int_low_th<7:0>) > 0. This would mean that for a value of 1, we would get 11.72 mg, and for the default value (0x30), we would get 378.79, which doesn't match the datasheet.

I put this in the place of the 1.0.4/ board folder and when I hit 'verify' I get this:

Error compiling.```

Not really too sure what I'm doing wrong :/

https://forum.arduino.cc/index.php?topic=391836.0

Having same issue but with extensive CurieBLE usage...

In testing how much memory I could use on the Arduino 101 I found that I was limited to ~8KB instead of the 24KB of SRAM advertised. I opened a post on the Arduino forums explaining the details of my findings (linked here: http://forum.arduino.cc/index.php?topic=406411.0), but I was referred to the Intel Github after being told that it could be an issue with the linker using DCCM instead of SRAM. Do you know if the linker has this bug, or how I could fix it?

CurieIMU allows the gyroscope measurement rate to be controlled with these functions:

https://www.arduino.cc/en/Reference/CurieIMUsetGyroRate
https://www.arduino.cc/en/Reference/CurieIMUgetGyroRate

However, there does not appear to be any API for an Arduino sketch to actually read the data at the proper rate. Functions like readGyro() return the stored data from hardware registers. If called rapidly, readGyro() will return the same data many times.

Normally Arduino libraries provide an available() function, to indicate whether (or how much) new data is available, which hasn't already been read.

Acquiring gyroscope data at the correct rate is particularly important. Gyroscopes measure angular velocity. Converting this to angular position with a Kalman or other filter algorithm involves integrating the angular velocity with respect to time.

If an Arduino sketch re-reads the same data, because it can't reliably know when the sensor has produced a new measurement, and it passes that data to a Kalman or similar integrating filter, the short-term rotational motion will be overestimated. The result is sketches using CurieIMU must resort to very poor design practice. For example, the Orientation Visualizer uses this kludge factor:

int factor = 800; // variable by which to divide gyroscope values, used to control sensitivity
// note that an increased baud rate requires an increase in value of factor

Obviously this is terrible design. The computed angular position depends heavily on the Curie's CPU speed, by how quickly it can run the loop() function. If you run the visualizer and vigorously shake the Arduino 101 board for several seconds and then let it rest, you'll see the visualizer almost always stops in a very wrong orientation, and then very slowly corrects itself over about a minute as the filter uses the accelerometer data to gradually correct for the massive errors caused by incorrect rate & improperly scaled gyroscope data.

The example must be similar to the one shipped in the standard Arduino core. In particular Serial must be initialized instead of Serial1 and the

Wire.requestFrom(8, 6,false); // request 6 bytes from slave device #8

must not have the additional false parameter

Is such a big blocking time expected?

I am trying to run a sketch using the c++ lib vector (#include ) but there seems to be a conflict with CurieBLE. The sketch works fine without the include . Any suggestions would be appreciated.

Here is a list of the error messages:

Arduino: 1.6.7 (Windows 10), TD: 1.27, Board: "Arduino/Genuino 101"

C:\Users\CyberPalin\Documents\Arduino\Arduino101\Arduino101_CRP_v2\Arduino101_CRP_v2\Arduino101_CRP_v2.ino: In function 'void setup()':

Arduino101_CRP_v2:71: error: 'blePeripheralConnectHandler' was not declared in this scope

   blePeripheral.setEventHandler(BLEConnected, blePeripheralConnectHandler);

                                               ^

Arduino101_CRP_v2:72: error: 'blePeripheralDisconnectHandler' was not declared in this scope

   blePeripheral.setEventHandler(BLEDisconnected, blePeripheralDisconnectHandler);

                                                  ^

Arduino101_CRP_v2:75: error: 'rxCharacteristicWritten' was not declared in this scope

   rxCharacteristic.setEventHandler(BLEWritten, rxCharacteristicWritten);

                                                ^

C:\Users\CyberPalin\Documents\Arduino\Arduino101\Arduino101_CRP_v2\Arduino101_CRP_v2\Arduino101_CRP_v2.ino: In function 'void loop()':

Arduino101_CRP_v2:148: error: 'closeConnection' was not declared in this scope

       closeConnection(parser.getPfodAppStream());

                                                ^

exit status 1
'blePeripheralConnectHandler' was not declared in this scope

  This report would have more information with
  "Show verbose output during compilation"
  enabled in File > Preferences.

I posted this on the arduino101 forum but no takers. The sketch can be downloaded from the [forum](Conflict between Include and CurieBLE.h)

Thanks
Mike

It would be a great feature to add the BLE 4.0 Scan Response capabilities as described there: http://www.argenox.com/bluetooth-low-energy-ble-v4-0-development/library/a-ble-advertising-primer/

I have extensive code that is in c99.
I have look thru the boards.txt file and can not find a way to turn on c99.
Note that no version of c++ can do what c99 does, so I really need to turn on c99 for this board.
Thanks, Jim

In cores/arduino/stdlib_noniso.cpp (line 153):

function 'sprintf' possibly accepts format string that may be influenced by user, causing format string vulnerability. Undefined string lengths can lead to buffer overflows and potential exploitation by attackers. Use a defined value for string lengths.

char *dtostrf (double val, signed char width, unsigned char prec, char *sout) {
   ...
   sprintf(sout, fmt, val);

I found a bug in "setGyroOffset" function.

`void CurieIMUClass::setGyroOffset(int axis, int offset)
{
if (axis == X_AXIS) {
setXGyroOffset(axis);
} else if (axis == Y_AXIS) {
setYGyroOffset(axis);
} else if (axis == Z_AXIS) {
setZGyroOffset(axis);
}

setGyroOffsetEnabled(true);

}`

Instead of "axis", "offset" should be written. Otherwise, the offset is set wrongly.
The same bug is also present in the "setAccelerometerOffset".
The bug can be solved as below (it is necessary also to cast int into int8_t).

`void CurieIMUClass::setAccelerometerOffset(int axis, int offset)
{
if (axis == X_AXIS) {
setXAccelOffset((int8_t)offset);
} else if (axis == Y_AXIS) {
setYAccelOffset((int8_t)offset);
} else if (axis == Z_AXIS) {
setZAccelOffset((int8_t)offset);
}

setAccelOffsetEnabled(true);

}`

Hi,

I am following the CurieIMU examples for calibration on power up, and comments saying
call setAccelerationOffset() and setGyroOffset() instead.

The values I write to the Curie's EEPROM as the result of the last calibration are not being
used after master reset (a new startup, which could occur after the device has been calibrated
once initially). I load them from the EEPROM, verify that they are the exact same values produced
by the last run calibration routine, and set them to the CurieIMU with the public methods given.

The 's' key produces the same generally "uncalibrated" values you get before calibration, even
after loading and setting as the program shows.

Please verify what I am saying using the attached source:

CurieIMU.DefectDemo.ino.txt

It uses the serial interface and 's' key to sample the IMU at will. Uses the 'c' key to calibrate the IMU and store the results. On reset, just not working like expected!

Are the values I'm trying to set being rejected by code in CurieIMU.cpp:

int bmiOffset = offset / 0.061;

if (bmiOffset < -512) {
    bmiOffset = -512;
} else if (bmiOffset > 511) {
    bmiOffset = 511;
}

Also, if you don't mind me saying so, seems like you are really counting on the
floating point division producing the correct range of integer values without an
explicit conversion.

Thanks,
-Matt

I tried to port a library to Arduino101. This library was written for AVR and depended upon <avr/interrupt.h>, but I wanted to see if I could use #ifdef to swap in Arduino101-specific replacement routines. I looked around but could not figure out which #ifdef to use! I tried to export the cross-compiler's built-in #defines to see if I could detect the ARC architecture, but the export failed.

I ended up writing my own library which only works on Arduino101, but it still might be nice to use an #ifdef to warn users who aren't using Arduino101 that the library might not work.

Do you have a recommendation for an Arduino101-specific #ifdef that could be used for compatibility purposes?

On line 40 of BLECharacteristic.cpp, the code in the constructor is "malloc(_value_length)". However _value_length was initialized to 0. I believe the code should read "malloc(_value_size)" which was just calculated. Testing indicates that malloc(0) seems to round up to 16 bytes of allocation, because any BLE message of 16 bytes or less works fine. Messages longer than this overflow the buffer into whatever was allocated next from the heap.

Issue opened by @VisualMicro in arduino/Arduino#4952

Running windows and 1.6.9.
I just installed the 1.0.5 Intel core. The previous 1.0.4 was ok.
McAffee report attached.

I want to modify the BLEWrite's value from 0x02 to 0xFEC9

the wechat airsync protocol require the ble device provide Write & Indicate Characteristic,the Write Characteristic 's value must be 0xFEC9,and Indicate Characteristic's value must be 0xFEC7.

I have modify the BLECharacteristic.h file like this :
`enum BLEProperty {
// broadcast (0x01) not supported

BLERead                      = 0xFEC9,

BLEWriteWithoutResponse     = 0x04,

BLEWrite                    = 0xFEC7,

BLENotify                 = 0x10,

BLEIndicate               = 0xFEC8

};`

but it doesn't work

Can someone give me help?

I'm running the UART (Serial1) port for a length of time, then turning it off and trying to use it as an output, but this fails silently. I expect to be able to set the mode to OUTPUT and write values to it after Serial1.end() has been called.

The reason that this fails is that UARTClass::init includes this code:

SET_PIN_MODE(17, UART_MUX_MODE); // Rdx SOC PIN (Arduino header pin 0)
SET_PIN_MODE(16, UART_MUX_MODE); // Txd SOC PIN (Arduino header pin 1)

Notably, this doesn't update ulPinMode in g_APinDescription[0] and g_APinDescription[1].

pinMode() does contain code that is supposed to change the MUX mode back to the correct value:

if (p->ulPinMode != GPIO_MUX_MODE) {
    SET_PIN_MODE(p->ulSocPin, GPIO_MUX_MODE);
    p->ulPinMode = GPIO_MUX_MODE;
}

Unfortunately, this code assumes that ulPinMode is up-to-date. In combination with the missing update in UARTClass::init, this means that pinMode() falsely assumes that it doesn't need to change the MUX mode of the pin.

Expected behavior: pinMode should change the MUX mode of a pin, even if it was previously used by the UART.
Suggested fix, if I understand correctly: Update g_APinDescription[0].ulPinMode and g_APinDescription[1].ulPinMode in UARTClass::init.

I'm testing implementing and testing various standard Bluetooth profiles on the Genuino 101. I'm proceeding in alphabetical order.... naturally. Alert Notification was OK. But... Automation IO revealed a problem which seemed to relate to descriptors. Basically the device does not start advertising. I stripped my code right down and isolated the problem to a degree.

@sandeepmistry went somewhat further and says "I've tracked it now to this line returning 0x285 instead or 0:

https://github.com/01org/corelibs-arduino101/blob/master/libraries/CurieBLE/src/BLECharacteristic.cpp#L205

"

Here's some code to illustrate the issue

// DOES NOT ADVERTISE

unsigned char AutomationIO_Digital_props = BLEWrite | BLEWriteWithoutResponse | 0;
unsigned char AutomationIO_Analog_props = BLEWrite | BLEWriteWithoutResponse | 0;
unsigned char AutomationIO_Aggregate_props = BLEWrite | BLEWriteWithoutResponse | 0;

// Services and Characteristics
BLEService AutomationIO("1815");
BLECharacteristic AutomationIO_Digital("2A56", AutomationIO_Digital_props, 20);
BLEDescriptor AutomationIO_Digital_CharacteristicPresentationFormat("2904", "0");

// Note I also tried:
// BLEDescriptor AutomationIO_Digital_CharacteristicPresentationFormat("2904", 0);
// and
// BLEDescriptor AutomationIO_Digital_CharacteristicPresentationFormat("2904", 0 , 1);
// and
// unsigned char buffer[7]={0x00,0x00,0x00,0x00,0x00,0x00,0x00};
// BLEDescriptor AutomationIO_Digital_CharacteristicPresentationFormat("2904", buffer, 7);


// GAP properties
char device_name[] = "My Device";

void setup() {

// set advertising packet content

  blePeripheral.setLocalName(device_name);

// add services and characteristics
  blePeripheral.addAttribute(AutomationIO);
  blePeripheral.addAttribute(AutomationIO_Digital);
  blePeripheral.addAttribute(AutomationIO_Digital_CharacteristicPresentationFormat);
// begin advertising
  blePeripheral.begin();
}

// ADVERTISES if I use a different descriptor instead
unsigned char AutomationIO_Digital_props = BLEWrite | BLEWriteWithoutResponse | 0;
unsigned char AutomationIO_Analog_props = BLEWrite | BLEWriteWithoutResponse | 0;
unsigned char AutomationIO_Aggregate_props = BLEWrite | BLEWriteWithoutResponse | 0;

// Services and Characteristics
BLEService AutomationIO("1815");
BLECharacteristic AutomationIO_Digital("2A56", AutomationIO_Digital_props, 20);
BLEDescriptor tempDescriptor = BLEDescriptor("2901", "Temp Celsius");

// GAP properties
char device_name[] = "My Device";

void setup() {

// set advertising packet content

 blePeripheral.setLocalName(device_name);

// add services and characteristics
  blePeripheral.addAttribute(AutomationIO);
  blePeripheral.addAttribute(AutomationIO_Digital);
  blePeripheral.addAttribute(tempDescriptor);
// begin advertising
  blePeripheral.begin();
}

I am using the 101 to drive Neopixel LED array. Each LED requires 3 bytes of RAM, and there are overall 20000 LEDs that I am working with. I am using the Adafruit Neopixel library to drive these Neopixel LEDs. I am able to allocate memory for 1024 LEDs at a time and the Arduino 101 then runs out of memory.
To solve this problem, I connected 1024 LEDs per GPIO pin on the Arduino 101 and I am allocating the memory for the LEDs connected to the individual GPIO pins during run time. This lets me work with 1024X14 (since there are 14 GPIOs) LEDs at a time, but every time I address LEDs connected to a particular GPIO pin I need to free the memory held by the LEDs connected to the a different GPIO pin, and reallocate this memory for the LEDs connected to the current GPIO pin. This causes the LEDs to flicker slightly. The program I am using is:

Adafruit_NeoPixel leds = Adafruit_NeoPixel();

Depending on the LED that I want to talk to, I set the length of the array and the pin as follows:

leds.updateLength(1024);
leds.updateType(NEO_GRB + NEO_KHZ800);
leds.setPin(pin_number);

This allocates memory for 1024 leds connected to the pin specified in the setPin function. The update length function frees memory(if any) held by the neopixels and allocates the memory for neopixels connected to the pin specified in the setPin function.

I wanted to know if it is possible to expand the SRAM or if there is any way I could drive 20000 LEDs using one Arduino 101 without the LEDs flickering?

after the other Wire/i2c issues have been closed ( #166 etc), and the speed got better, some I2C devices started working with the 101.

However, it's still far from really working. Basically, in practice I2C is not usable on the 101 - it's slow, unreliable. Code / hardware that works with all other Arduinos, does not work with the 101.

I have multiple I2C devices here which work on all official Arduinos, except the 101.

BTW I'm using the latest code from this repo.

We're the manufacturer of the Tentacle Shields, these are isolation shields for sensor circuits made by Atlas Scientific. E.g. the pH sensor circuit: https://www.atlas-scientific.com/_files/_datasheets/_circuit/pH_EZO_datasheet.pdf

Schematics of the shield mentioned above is here: https://github.com/whitebox-labs/tentacle-mini-oshw/blob/master/hardware/T2_mini_schematic.pdf

@bigdinotech your fix did help somewhat, but unfortunately Wire is still unreliable. If someone's working on this, I can send i2c devices to test, if needed.

Recommend a example sketch be provided for zero motion detection using the CurieIMU. Would be advantages to for trying to get odometry implemented.

Not sure if this is the correct place to report this but...

In the file arduino101_firmware_source-v1/arduino101_firmware/bsp/bootable/bootloader/chip/intel/quark_se/defu_desc.c, lines 211-216:

{
        .bLength = sizeof("QRK_SE-Dev1.0") * 2,
        .bDescriptorType = UDESC_STRING,
        .bString = { 'A', 0, 'T', 0, 'P', 0, '-', 0, 'D', 0,
            'e', 0, 'v', 0, '1', 0, '.', 0, '0', 0 }
},

.bLength is based of the string "QRK_SE-Dev1.0", whereasbString is set to "ATP-Dev1.0".

I just picked up an Arduino 101 and tried to run a sketch a bit more complicated than blink...

First off - I get an error trying to load Board Support via the Arduino Board Manager to 1.0.5 because of this error:

Error downloading https://github.com/01org/corelibs-arduino101/archive/1.6.4+1.68.zip

That's pointing to this repo.... and to a file that does not exist. Any ideas on how to fix this?

This issue was brought to light by the following question;
#220

The current length limitation may be blocking when trying to implement some Bluetooth services including utf8 formatted strings characteristics.

in BLECommon.h:

/* Theoretically we should be able to support attribute lengths up to 512 bytes
 * but this involves splitting it across multiple packets.  For simplicity,
 * we will just limit this to 20 bytes for now, which will fit in a single packet
 */
#define BLE_MAX_ATTR_DATA_LEN 20

Please consider adding APIs for Arduino users to get properly scaled data, with the conversion factor done inside the CurieIMU library. There are at least two reasons why I hope you'll do this:

1. The library can "know" which range is in use, to automatically perform the scaling correctly. In the examples, like File > Examples > CurieIMU > Accelerometer, if a novice Arduino user edits line 36 to configure a wider range, they must also know/remember to edit line 69 to agree with their range setting. While this isn't very difficult for experienced programmers, reducing the possibility for things to go wrong, to make everything "just work" as simply as possible is the design style that makes Arduino so successful.

2. Over the long-term, this API is likely to be used with other sensors which are likely to have different scaling. By abstracting these hardware specific details and avoiding them within the user's code, the API can be much more useful over the very long term.

Probably the simplest approach would be functions with the same names which take references to float, and populate the floats with data properly scaled.

Currently the connection interval is hard-coded in ble_client.c to a min value of 80ms and a max value of 150ms.

I have found by logging (via PacketLogger) and changing the min and max connection values in ble_client.c that the final interval that gets set seems to always match the max interval of 150ms. This means that the fastest a user can read an analog input or blink an LED for example is at an interval of 150ms which is a bit long.

Is there a specific reason that the connection interval range is set to 80ms - 150ms?

I've tried a much lower range [7.5ms - 30ms] and did not encounter any issues. This would enable me to read or write at a frequency of 30ms (since it seems MAX is always used). I understand this may be too fast (and thus consume too much battery) for some applications, but for others (if battery is less of an issue vs responsiveness of a physical UI) it makes sense to have a faster interval.

What would be ideal is for the user to be able to set the interval range. It could default to 80 / 150 as it currently does, but could be overridden. A set of absolute min / max would still need to be applied behind the scenes but it would at least enable the user to have a choice per their particular application.

Hello,
I'm using the CURIE_IMU_ZERO_MOTION and I think there is an error at line 769 in CurieIMU.cpp file. Please see the case CURIE_IMU_ZERO_MOTION in the following code.
Regards,
Giuseppe

void CurieIMUClass::setDetectionDuration(int feature, float value)
{
    switch (feature) {
        case CURIE_IMU_FREEFALL:
            setFreefallDetectionDuration(value);
            break;

        case CURIE_IMU_SHOCK:
            setShockDetectionDuration(value);
            break;

        case CURIE_IMU_MOTION:
            setMotionDetectionDuration(value);
            break;

        case CURIE_IMU_TAP_SHOCK:
            setTapShockDuration(value);
            break;

        case CURIE_IMU_ZERO_MOTION:
            // ************************************************
            // setZeroMotionDetectionThreshold(value); 
            // The above line should be replaced with the following:  
            setZeroMotionDetectionDuration(value);
            break;

        case CURIE_IMU_TAP_QUIET:
            setTapQuietDuration(value);
            break;

        case CURIE_IMU_DOUBLE_TAP:
            setDoubleTapDetectionDuration(value);
            break;

        case CURIE_IMU_TAP:
        case CURIE_IMU_STEP:
        case CURIE_IMU_FIFO_FULL:
        case CURIE_IMU_DATA_READY:
        default:
            break;
    }
}

Hello! I received my first Arduino101 in the mail yesterday, and when trying to add the board via the Boards Manager, I see the error "Error downloading https://github.com/01org/corelibs-arduino101/archive/1.6.4+1.68.zip".

Is this an error with how the code is structured here at Github, or is it an error with the information stored in the boards manager?

Thank you!

Hello! I am going through trying to disable the SPI bus and am diving into the SPI control and enable registers. I am using the SPIClass.end() function as my reference for what I need to do to accomplish this. I am trying to understand what bits are being changed and have confused myself... can anyone clarify this for me? Thanks in advance!

scss_registers.h
#define PERIPH_CLK_GATE_CTRL            (SCSS_REGISTER_BASE + 0x018)
/* SPI */
#define SOC_MST_SPI1_REGISTER_BASE      (0xB0001400)

SPIClass.h only touches SPI1 so I am assuming that SPI0 is what the BMI160 is using.
So if we look at the bit that the clock gate control is being defined as it is 0x018 = 24. However, the documentation shows that it should be at bit 28 (or 29 if we are starting at 1).

2.1.6.86 CREG register detailed description
2.1.6.87 IO_CREG_MST0_CTRL (IO_CREG_MST0_CTRL)
MEM Offset(80018000)

31 AD_CLK_GATE
30 I2C1_CLK_GATE
29 I2C0_CLK_GATE
28 SPI1_CLK_GATE
27 SPI0_CLK_GATE
26:20 ADC CALIBRATION VALUE

The specific code that I am looking at lives in SPI.cpp (SPIClass.end())

SPI1_M_REG_VAL(SPIEN) &= SPI_DISABLE;
MMIO_REG_VAL(PERIPH_CLK_GATE_CTRL) &= DISABLE_SPI_MASTER_1;

Disabling the SPI seems ok, but when we disable the clock, I'm confused as to what bit is being changed. Am I missing something obvious here?