Skip to main content

Bluetooth low energy

SmartBond™: power, size and system cost without compromise

Bluetooth® low energy is the de facto low power standard for connecting devices to each other and to the cloud. Highly integrated, the SmartBond™ SoC family features the smallest, most power efficient Bluetooth low energy solutions available and enables the lowest system costs. An extensive suite of support tooling ensures ease of use and a fast route to market.

Latest News Success Stories

Bluetooth Low Energy
SmartBond™ Product Portfolio Download PDF
Part Number DA14699/7/5/1 DA14683 DA14682 DA14586 DA14585 DA14531/0 DA14531MOD
  Product Description The world’s most advanced wireless microcontroller product family Single-chip high-security Bluetooth 5 solution with expandable memory Small size, low power and most integrated Bluetooth 5 SoC The world’s smallest and lowest power Bluetooth 5.1 System-on-Chip which enables the next 1billion IoT devices The DA14531 SmartBond TINY™ Module, based on the world’s smallest and lowest power Bluetooth 5.1 system-on-Chip
TYPE
SoC      
SiP          
Module            
TECHNOLOGY
Bluetooth® LE 5.2 5.0 5.0 5.0 5.0 5.1 5.1
2.4 GHz proprietary            
CORE SYSTEM
CPU 96MHz Arm
Cortex-M33
Floating Point DSP Extension
96MHz Arm
Cortex-M0
96MHz Arm
Cortex-M0
16MHz Arm
Cortex-M0
16MHz Arm
Cortex-M0
16MHz Arm
Cortex-M0+
16MHz Arm
Cortex-M0+
RAM 512kB
384kB (691)
128kB 128kB 96kB 96kB 48kB 48kB
ROM
OTP
128kB
4kB
128kB
64kB
128kB
64kB
128kB
64kB
128kB
64kB
144kB
32kB
144kB
32kB
Flash QSPI Flash QSPI Flash 1024kB 256kB SPI Flash SPI Flash 128kB
Crystals 32MHz+32kHz 32/16MHz+32kHz 32/16MHz+32kHz 16MHz+32kHz 16MHz+32kHz 32MHz 32MHz
POWER
Internal DCDC Buck Buck Buck Buck&Boost Buck&Boost Buck&Boost Buck
External System Power Rails 2x1.8V, 1x3.3V 2x1.8V, 1x3.3V 2x1.8V, 1x3.3V        
Charger ● ● ● ○        
SECURITY
AES/SHA 256/512 256/512 256/512 128 128 128 128
ECC/TRNG ● ● ● ● ● ●     ○ ● ○ ●
Secure Key Handling        
RADIO
Frequency 2.4GHz 2.4GHz 2.4GHz 2.4GHz 2.4GHz 2.4GHz 2.4GHz
Tx Power 6dBm 0dBm 0dBm 0dBm 0dBm 2.5dBm 2.2dBm
Rx Sensitivity -97dBm -94dBm -94dBm -93dBm -93dBm -94dBm -94dBm
PERIPHERALS
UART/SPI/I2C 3/2/2 2/2/2 2/2/2 2/1/1 2/1/1 2/1/1 2/1/1
QSPI XiP
On-the-fly decryption
2/2/2/1
1
1
       
USB FS/HS 1 1 1        
Timers/PWM/RTC 4/4/1 3/3 3/3 4/2 4/2 3/2/1 3/2/1
I2S,PCM/PDM 8CH/2CH 8CH/2CH 8CH/2CH 8CH/2CH 8CH/2CH    
LCD ● ● ● ○            
Keyboard/QDEC/IR   ● ● ● ● ● ● ● ● ○ ● ● ○ ● ● ○ ● ● ○
ADC 8CH 10b
8CH 14b
8CH 10b 8CH 10b 4CH 10b 4CH 10b 4CH 10b 4CH 10b
LED driver 2 2 ○ ○ 3 3        
Temperature sensor    
Other Haptics / Motor Controller            
APPLICATIONS
Appliances
Asset Tracking    
Beacons      
Consumer Electronics
Direction finding            
Gaming and AR/VR        
Industrial Automation      
Medical and Healthcare
MESH networks        
PC Peripherals
Smart Home and Building
Wearables  
Wireless Ranging (WiRa)            
Smart door-locks        
IoT sensors
PACKAGES
Type#Pins (#GPIO)
Dimensions
VFBGA100 (55)
5x5 mm
(699/697)
WLCSP53 (21)
3.41x3.01 mm

AQFN60 (37)
AQFN60 (31)
6x6 mm
QFN40 (24)
5x5 mm
WLCSP34 (14)
2.40x2.66 mm

QFN40 (25)
WLCSP17 (6)
1.7x2.05 mm
(531 only)
MOD16 (9)
12.5x14.5 mm
Operating Temperature -40 to 85°C -40 to 85°C -40 to 85°C -40 to 85°C -40 to 85/105°C -40 to 85°C -40 to 85°C
Supply Voltage Range 2.4 to 4.75V 1.7 to 4.75V 1.7 to 4.75V 0.9 to 3.3V 0.9 to 3.3V 1.1 to 3.3V 1.8 to 3.3V
DEVELOPMENT KITS DA14695 PRO
DA14695 USB
DA14683 PRO
DA14683 USB
DA14683 PRO
DA14683 USB
DA14585 PRO
DA14585 BASIC
DA14585 PRO
DA14585 BASIC
DA14531/0 PRO DA14531 USB DA14531MOD PRO
Partner Modules
Read more
Product Security Vulnerabilities
Read more
Legacy Products
DA14680/1 Not Recommended for New Designs; For Improved Performance – See DA14682/3
DA14580/1/2/3 Not Recommended for New Designs; For Improved Performance – See DA14585/6 and DA14530/1

 

bleuio dongle

A faster way to new Bluetooth® applications

Swedish IoT company Smart Sensor Devices AB believes developing new Bluetooth applications should be as easy as using them. That’s why they created the BleuIO Bluetooth Low Energy USB dongle using Dialog’s Bluetooth SoCs– a smart, highly integrated device that lets developers create new Bluetooth LE 5.0 applications with minimal effort.

web_bluetooth_blog

Motion Aware Thin Bluetooth® Low Energy Beacon Solution for Smart Labels

A beacon is a tiny Bluetooth radio battery-powered transmitter. Beacons provide an inexpensive broadcasting solution capable of autonomous operation over very long periods of time. In this paper, we will show how beacons can support extended functionality by employing a range of peripherals to allow them to process and display data while maintaining autonomous operation.

Success Stories banner

Smart devices that don’t need charging?

Smartcube Co. produces modular chips that convert everyday objects like sport shoes and ID badges into smart, connected IoT devices. Remarkably, they aim to produce chips that are so energy-efficient, the resulting devices never need charging! Dialog’s SmartBond Bluetooth low energy range is helping them achieve their power consumption goals at low cost while delivering excellent reliability.

Every quarter, we bundle up the best technical info on our products, software development topics, trainings, events and deliver it to your inbox.

Sign me up
Check out previous editions

Stay connected

Get in touch with us directly through our worldwide sales offices, or contact one of our global distributors and representatives.

Inquiries Distributors and Representatives Register for newsletters
Product ID Application Standard Memory size FLASH (Mb) Memory size ROM (kB) Memory size OTP (kB) Memory size RAM (kB) GPIOs (max) Power supply min (V) Power supply max (V) Tx current (mA) Rx current (mA) Output power (dBm) Sensitivity (dBm) Microcontroller Recommended for new Designs Package Max system clock (MHz) Flexible system clock Execute from FLASH HW crypto engine QSPI SPI UART I2C USB PDM Documents
                                                       
DA14580-01UNA Beacon & Proximity Health & Fitness Human Interface Devices Smart Home BLE 4.2 Core specification 0 84 32 50 14 0.9 3.6 4.8 5.1 0 -93 M0 No WL-CSP34,2.5*2.5*0.5mm 16 No No Yes 0 1 2 1 0 0 Documentation
DA14580-01AT2 Beacon & Proximity Health & Fitness Human Interface Devices Smart Home BLE 4.2 Core specification 0 84 32 50 24 0.9 3.6 4.8 5.1 0 -93 M0 No QFN40,5*5*0.9mm 16 No No Yes 0 1 2 1 0 0 Documentation
DA14580-01A32 Beacon & Proximity Health & Fitness Human Interface Devices Smart Home BLE 4.2 Core specification 0 84 32 50 32 0.9 3.6 4.8 5.1 0 -93 M0 No QFN48,6*6*0.9mm 16 No No Yes 0 1 2 1 0 0 Documentation
DA14581-00UNA Wireless Charging Host Controller Interface BLE 4.2 Core specification 0 84 32 50 14 0.9 3.6 4.8 5.1 0 -93 M0 No WL-CSP34,2.5*2.5*0.5mm 16 No No Yes 0 1 2 1 0 0 Documentation
DA14581-00000VRA Wireless Charging Host Controller Interface BLE 4.2 Core specification 0 84 32 50 14 0.9 3.6 4.8 5.1 0 -93 M0 No WL-CSP34,2.5*2.5*0.3mm 16 No No Yes 0 1 2 1 0 0 Documentation
DA14581-00AT2 Wireless Charging Host Controller Interface BLE 4.2 Core specification 0 84 32 50 24 0.9 3.6 4.8 5.1 0 -93 M0 No QFN40,5*5*0.9mm 16 No No Yes 0 1 2 1 0 0 Documentation
DA14583-01F01AT2 Beacon & Proximity Health & Fitness Human Interface Devices Smart Home BLE 4.2 Core specification 1 84 32 50 24 2.35 3.6 4.8 5.1 0 -93 M0 No QFN40,5*5*0.9mm 16 No No Yes 0 1 2 1 0 0 Documentation
DA14585-00000VV2* Beacon & Proximity Health & Fitness Human Interface Devices Smart Home Remote Controls with voice commands over BLE BLE 5.0 Core specification + supplemental features 0 128 64 96 14 0.9 3.6 4.8 5.1 0 -93 M0 Yes WL-CSP34,2.4*2.66*0.5mm 16 No No Yes 0 1 2 1 0 1 Documentation
DA14585-00000AT2* Beacon & Proximity Health & Fitness Human Interface Devices Smart Home Remote Controls with voice commands over BLE BLE 5.0 Core specification + supplemental features 0 128 64 96 25 0.9 3.6 4.9 5.3 0 -93 M0 Yes QFN40,5*5*0.9mm 16 No No Yes 0 1 2 1 0 1 Documentation
DA14586-00F02AT2* Beacon & Proximity Health & Fitness Human Interface Devices Smart Home Remote Controls with voice commands over BLE BLE 5.0 Core specification + supplemental features 2 128 64 96 24 1.8 3.6 4.9 5.3 0 -93 M0 Yes QFN40,5*5*0.9mm 16 No No Yes 0 1 2 1 0 1 Documentation
DA14680-01F08A92 Wearables Smart Home Apple HomeKit Human Interface Devices Other rechargeable device BLE 4.2 Core specification + optional features 8 128 64 128 31 1.7 4.75 5.2 6 0 -94 M0 No AQFN60,6*6*0.8mm 96 Yes Yes Yes 0 2 2 2 1 1 Documentation
DA14681-01000U2 Wearables Smart Home Apple HomeKit Human Interface Devices Other rechargeable device BLE 4.2 Core specification + optional features 0 128 64 128 21 1.7 4.75 5.2 6 0 -94 M0 No WL-CSP53,3.4*3.0*0.5mm 96 Yes Yes Yes 1 2 2 2 1 1 Documentation
DA14681-01000A92 Wearables Smart Home Apple HomeKit Human Interface Devices Other rechargeable device BLE 4.2 Core specification + optional features 0 128 64 128 37 1.7 4.75 5.2 6 0 -94 M0 No AQFN60,6*6*0.8mm 96 Yes Yes Yes 1 2 2 2 1 1 Documentation
DA14682* Wearables Smart Home Apple HomeKit Bluetooth mesh Cloud connected applications BLE 5 8 128 64 128 31 1.7 4.75 5.2 6 0 -94 M0 Yes AQFN60,6*6*0.8mm 96 Yes Yes Yes 0 2 2 2 1 1 Documentation
DA14683* Industrial Human Interface Devices Virtual reality remotes Banking BLE 5 0 128 64 128 37 1.7 4.75 5.2 6 0 -94 M0 Yes AQFN60,6*6*0.8mm 96 Yes Yes Yes 1 2 2 2 1 1 Documentation
DA14691-00000HQ2* Wearables Smart Home Apple HomeKit Bluetooth mesh Cloud connected applications BLE 5.0 Core specification + optional features Optional external 128 4 384 44 2.4 4.75 3.5 2.2 6 -97 M33 Yes VFBGA86, 6 x 6 x 0.55 mm 96 Yes Yes Yes 1 2 3 2 1 1 Documentation
DA14695-00000HQ2* Wearables Smart Home Apple HomeKit Bluetooth mesh Cloud connected applications BLE 5.0 Core specification + optional features Optional external 128 4 512 44 2.4 4.75 3.5 2.2 6 -97 M33 Yes VFBGA86, 6 x 6 x 0.55 mm 96 Yes Yes Yes 1 2 3 2 1 1 Documentation
DA14697-00000HR2* Wearables Smart Home Apple HomeKit Bluetooth mesh Cloud connected applications BLE 5.0 Core specification + optional features Optional external 128 4 512 55 2.4 4.75 3.5 2.2 6 -97 M33 Yes VFBGA100, 5 x 5 x 0.475 mm 96 Yes Yes Yes 2 2 3 2 1 1 Documentation
DA14699-00000HR2* Wearables Smart Home Apple HomeKit Bluetooth mesh Cloud connected applications BLE 5.0 Core specification + optional features Optional external 128 4 512 55 2.4 4.75 3.5 2.2 6 -97 M33 Yes VFBGA100, 5 x 5 x 0.475 mm 96 Yes Yes Yes 2 2 3 2 1 1 Documentation
DA14531 Disposables Beacons Asset tracking Connected health RCU BLE 5.1 Core specification + supplemental features 0 144 32 48 12 0.9 3.6 3.5 2.2 0 -94 M0 + Yes QFN24*2.2*3.04mm 16 Yes Yes Yes 0 1 2 1 0 0 Documentation

*Recommended for new designs

Stay connected

Get in touch with us directly through our worldwide sales offices, or contact one of our global distributors and representatives.

Inquiries Distributors and Representatives Register for newsletters

Wearables

Wearable electronics is entering every facet of our daily life, giving us new ways to improve our lives: from productivity to health and lifestyle. Revealing previously unattainable information about ourselves and our surroundings, they help advise us.

SmartBond Solutions: DA14682/3, DA14585/6, DA1469x

Proximity & Asset Tracking

Proximity applications are based on knowing and alerting you of the distance between two devices, such as keys or wallets, if the label goes out of range. Proximity information can also be used in asset tagging for inventory and automated access control or monitoring in cold chain tracking.

SmartBond Solutions: DA1469x, DA14531

Connected Medical

Connected medical offers solutions in allowing patients to take care of their own health condition in monitoring, sending alerts and making drug delivery easy. Bluetooth low energy is the technology to connect health products to the cloud. Examples of connected medical products are blood pressure meters, heart rate monitors, glucose meters and patches, body temperature meters, virus testers and drug delivery with injectables or via patches through the skin.

SmartBond Solutions: DA14531, DA1469x

Smart Home & Buildings

Long dreamt of, the Smart Home is now becoming a reality. We can monitor and control our home security, lighting, appliances and heating, ventilation and air-conditioning (HVAC) from our smartphones and tablets – even remotely via the cloud.

SmartBond Solutions: DA14682/3, DA14585/6, DA14531

Computing & Gaming

Bluetooth has played a key role in connecting computing and gaming peripherals since its introduction. It provides a simple and proven connectivity option for a host of new and emerging peripherals, while securing access to the most personal data.

As electronic equipment becomes smarter and more mobile, the way we interact with it is changing. We want more control, more convenience and less clutter, which is driving huge growth in the wireless HID market. Bluetooth low energy is per default supported in recent versions of windows, which truly enables the wireless desktop.

SmartBond Solutions: DA14585/6, DA1469x

Stay connected

Get in touch with us directly through our worldwide sales offices, or contact one of our global distributors and representatives.

Inquiries Distributors and Representatives Register for newsletters
SmartBond™ SDK Overview Product Supported
SDK6 DA14585/6 + DA14531/0
SDK10 DA1469x
SDK1 DA14682/3

Also available for DA14680/1 but not recommended for new designs

SDK5 DA14580/1/3

Not recommended for new designs

 

SmartBond™ Development tools overview Product Supported
Dialog Smartbond Flash Programmer DA14531/0, DA1458x and DA1469x
SmartSnippets Toolbox All
SmartSnippets Studio All
Production Line Tool  

 

Stay connected

Get in touch with us directly through our worldwide sales offices, or contact one of our global distributors and representatives.

Inquiries Distributors and Representatives Register for newsletters

Social distancing

Embedded Software Applications for Social Distancing Applications

Read More

Bluetooth Low Energy Range Extender

The SmartBond™ BLE Range Extender reference design enables you to take full advantage of the output power of the Bluetooth low energy standard to extend the range of your applications.

Read more

Smart USB Dongle

The Smart USB Dongle device is a fully integrated USB to Bluetooth® LE solution, based on SmartBond™ DA14683 high-security Bluetooth LE SoC.

Read more

emWin

The emWin embedded graphics library developed by SEGGER Microcontroller is now offered by Dialog Semiconductor in library form for free commercial use with the SmartBond® DA1469x wireless microcontrollers.

Read more

Stay connected

Get in touch with us directly through our worldwide sales offices, or contact one of our global distributors and representatives.

Inquiries Distributors and Representatives Register for newsletters

Our SmartBond products are supported by development kits and a profiling to help you create applications that exploit the unique benefits of the SmartBond family to the fullest. These tools help you minimize your time to market.

Hardware Development Kits

DA14531 DA14531 - USB, DA14531 - Pro
DA14585 DA14585 - BasicDA14585 - Pro
DA14683 DA14683 - USBDA14683 - Pro
DA14695 DA14695 – USB, DA14695- Pro
All Bluetooth LE Products Production Line Tool

 

Application Focused Development Kits

 

Discontinued Kits

DA14583 DA14583 IoT Sensor Development Kit
The DA14585 IoT is an upgraded sensor development kit with more supported sensors and cloud connectivity
DA14681 DA14681 HomeKit Development Kit
DA14681 DA14681 Wearable Development Kit

 

Stay connected

Get in touch with us directly through our worldwide sales offices, or contact one of our global distributors and representatives.

Inquiries Distributors and Representatives Register for newsletters

Japan-based company mainly engaged in the manufacture and sale of electronic components and audio equipment. 

See More

Bithium - your partner in the design of innovative wireless embedded systems (firmware, hardware, software). Bithium keeps a clear focus on achieving project targets and customer satisfaction. 

See More

Cambridge Consultants is a premium multidisciplinary supplier of innovative product development engineering and technology consulting. We help clients deliver groundbreaking products to market fast, with cutting-edge technology that often results in new IP generation for our clients. 

See More

Cloud2GND is a global engineering services firm specializing in standards-based wireless connectivity solutions. Our clients range from innovative start-ups to large semiconductor companies and standards organizations. We offer deep domain knowledge in embedded systems, especially around Bluetooth technology, where we provide consulting, design, development, test, deployment and maintenance services for our clients and their customers. Our engineering services division offers a flexible engagement model acting as a specialized team of standards experts or a complete engineering team able to manage your project needs to completion.

See more

Lauterbach is the leading manufacturer of complete, modular and upgradeable microprocessor development tools worldwide with experience in the field of embedded designs since 1979. The engineering team develops and produces highly proficient and specialized Development Tools, which are utilized all over the world under the brand TRACE32®.

LitePoint is the leading provider of test solutions for the world's leading manufacturers of wireless

See more

Murata is a global leader in the design, manufacture and supply of advanced electronic materials, leading edge electronic components, and multi-functional, high-density modules.

See more

Panasonic Industrial Devices Sales Company of America. Many products sold by Fortune 500 companies are in fact Powered by Panasonic technology, and we are proud to provide manufacturers with the performance, quality, and reliability that are synonymous with the Panasonic brand. The Power of Panasonic Industrial Devices brings strategic innovations to our customers’ product development process.

See more

TDK is one of the largest electronic components manufacturers in the world.

See more

Tieto is the leading product development services company enabling semiconductor, connected device and communication infrastructure manufacturers, build next generation connected devices & things, cars and networks.

See more

Wireless technology experts. Xtel's core competency is technology development, which makes up a substantial part of its business. It utilizes state-of-the-art technologies to create the next product or technical platform for its partners. Among its clients, it counts some of the world’s leading tech innovators. It is typically tasked with the development of wireless technology, protocols, and ultralow power designs and products. Xtel has in-depth knowledge of the product development and maturation of wireless technologies. It typically uses proven and tested standard components or platforms, helping its partners to reduce time to market. Where a technology boost is needed, it develops complete products or assist a development team in the company. Its technological solutions and innovative skills are recognized by its partners.

See more

Quuppa is a leading technology provider for real-time locating systems (RTLS) and indoor positioning systems (IPS). The company was established in 2012 by a team of experienced engineers and scientists as a spin-off from Nokia Research Center and has since successfully commercialised its offering, creating a complete product platform: the Quuppa Intelligent Locating System™, a one-size-fits-all technology platform for location-based services and applications. Our platform offers companies a complete software suite of tools for planning, simulating and commissioning projects, that can be used as a solid and scalable foundation for building various location-based solutions. The open API makes it fast and easy to take the platform into use. To date, the Quuppa Ecosystem has more than 200 partners around the world who use Quuppa’s open, versatile and reliable positioning platform to deliver accurate, real-time and cost-effective location solutions to companies in a range of industries, including manufacturing and logistics, retail, healthcare, sports, law enforcement and security, government, asset tracking.

See more

 

Stay connected

Get in touch with us directly through our worldwide sales offices, or contact one of our global distributors and representatives.

Inquiries Distributors and Representatives Register for newsletters
Back to results

DA14585 and DA14586

1 week ago

Upgrading the Blinky example with the I2C

Posted by mu234 230 points 13 replies
0 upvotes

Hello all,

in previous post the hardware I2C connection was established ... indeed, I could see the "value" in the LightBlue app. However, I am after more dynamic approach, will return to the BLE latter.

Therefore, I have picked up a simple BLINKY example that comes with the latest SDK6 and I am using the Basic DEV KIT with the connected proximity sensor.

In general, I have simply used the I2C suggestions as given in the example Basic I2C connection with a sensor | Dialog (dialog-semiconductor.com) and hoped to compile the program, however, I got stuck with the Configuration structure for the I2C within the periph_setup.c (indeed, something else my be included) :

// Configuration structure for I2C
static const i2c_cfg_t i2c_cfg = {
    .clock_cfg.ss_hcnt = I2C_SS_SCL_HCNT_REG_RESET,
    .clock_cfg.ss_lcnt = I2C_SS_SCL_LCNT_REG_RESET,
    .clock_cfg.fs_hcnt = I2C_FS_SCL_HCNT_REG_RESET,
    .clock_cfg.fs_lcnt = I2C_FS_SCL_LCNT_REG_RESET,
    .restart_en = I2C_RESTART_ENABLE,
    .speed = I2C_SPEED_MODE,
    .mode = I2C_MODE_MASTER,
    .addr_mode = I2C_ADDRESS_MODE,
    .address = I2C_SLAVE_ADDRESS,
    .tx_fifo_level = 1,
    .rx_fifo_level = 1,
};

 

and the compilation errors are here:

Build started: Project: blinky
*** Using Compiler 'V5.06 update 7 (build 960)', folder: 'C:\Keil_v5\ARM\ARMCC\Bin'
Build target 'DA14585'
compiling user_periph_setup.c...
..\src\user_periph_setup.c(68): error:  #20: identifier "i2c_cfg_t" is undefined
  static const i2c_cfg_t i2c_cfg = {
KB: Unexpected type: 0
error type>(73): error:  #20: identifier "I2C_RESTART_ENABLE" is undefined
      .restart_en = I2C_RESTART_ENABLE,
..\src\user_periph_setup.c(74): error:  #20: identifier "I2C_SPEED_FAST" is undefined
      .speed = I2C_SPEED_MODE,
..\src\user_periph_setup.c(75): error:  #20: identifier "I2C_MODE_MASTER" is undefined
      .mode = I2C_MODE_MASTER,
..\src\user_periph_setup.c(76): error:  #20: identifier "I2C_ADDRESSING_7B" is undefined
      .addr_mode = I2C_ADDRESS_MODE,
..\src\user_periph_setup.c(100): warning:  #223-D: function "i2c_init" declared implicitly
          i2c_init(&i2c_cfg);
..\src\user_periph_setup.c: 1 warning, 5 errors
".\out_DA14585\Objects\blinky_585.axf" - 5 Error(s), 1 Warning(s).
Target not created.
Build Time Elapsed:  00:00:01

 

To goal is to eventually printout the value of the sensor on the UART... anyway, sorry, if this question is stupid, I have just started.

Any idea, help is much appreciated.

Best.

 

 

 

 

1 week ago

AA_Dialog

Hi mu234,

Thank you for your forum question.

The error messages that you are receiving are because you haven’t defined some of the I2C parameters and you haven’t added the sdk I2C parameters to your project. What you need to do to avoid these errors are:

  1. Add the I2C driver by right clicking the folder sdk_driver on Keil Project window

   

and selecting Manage Project Items. In Manage Project items highlight sdk_driver and press Add Files

 

navigate to …\Your_SDK\6.0.16.1144\sdk\platform\driver\i2c and add i2c.c.
 

Then in file user_periph_setup.c  include the i2c library

#include "i2c.h"
  1. Add the following lines to user_periph_setup.h
#define I2C_SLAVE_ADDRESS           0x18                  // Set slave device address
#define I2C_SPEED_MODE              I2C_SPEED_FAST        // Speed mode: I2C_SPEED_FAST (400 kbits/s)
#define I2C_ADDRESS_MODE            I2C_ADDRESSING_7B     // Addressing mode: I2C_ADDRESSING_7B
#define I2C_ADDRESS_SIZE            I2C_1BYTES_ADDR       // Address width:   I2C_1BYTE_ADDR

 

The blinky example is very simple but it lacks some of the configuration files found in other examples. It might be more straightforward to start from an empty_peripheral_template project and build on from there.

Kind regards, AA_Dialog

1 week ago

Thank you! Works, btw meanwhile I got the Sensor Library for C and C++,

I guess I should be able now to add those files to the "user_app" and use it? However, I am not really sure how to add the files properly? For example, I can add them via the right hand mouse button on user_app and add existing files to the group... is this the right way ? For example, should the folder with the sensor name be created and the files could be stored there?

Or should it be added via Manage project items?

Regarding the empty_peripheral_template project, somewhere I have read that it may be easier to start with already compiled but simple projects :) hence I have picked up Blinky, anyway, will definitely return to this subject of creating my own program from scratch...

Best.

1 week ago

AA_Dialog

Hi mu234,

Adding the files on either user_app folder or on a new folder with the sensor name should work. You can choose the one that is preferable for your needs.

Please keep in mind that if you create a new folder then you will have to add its location to the include paths in Keil. You can do that by navigating to
Options for Target-> C/C++-> Include Paths-> New (Insert)

and inserting the folder containing your library files.

Kind regards, AA_Dialog

1 week ago

Hello AA and thank you!

Added , works either via add exiting files or via creating a new folder with paths, compiles with errors, for example, where can I find the  "typedefinition" used in the eg. DA14585? Have looked the SDK doc but cannot get the doxygen going...

Anyway what should be used here:

//MCU specific types. Depending on the plattform which is used. 
typedef uint8_t Byte;    //what to use here? only int or anything else?
typedef uint16_t Word; 
typedef uint32_t uint_32;
typedef int int_32;

BTW why cannot the uint8_t be used? For example, when the int is typed the list of different types is given, however, I cannot see the right ... this is the closest __UINT8_TYPE__ 

Interestingly, if I do the same in the main.c and when int is typed the list of the needed types is given, wondering why I cannot do that over there as well? Did I added, created the folder OK? Is this related? For example, what does the "star" mean on the DA14585 target and VCNL4035 group that I am working on ?

star

Btw what type of language should I aim to use, C or C++? I guess the interaction among them works, indeed, it depends on the project, anyway, the idea is to eventually use the BLE, any ideas?

Best.

1 week ago

AA_Dialog

Hi mu234,

Integer type definitions reside in file stdint.h. You will need to include this system header file in your library by adding the command

#include <stdint.h>

After the above step you should be able to see all the different int types in your library.

The SDK 6.0.16 and examples are built on C. Keil should be capable of compiling C++ so you can try it, but I am not able to provide any details on how you can use C++ or any limitations there might be. Compiling C++ code together with the SDK 6.0.16 is a scheme that is neither tested nor supported by Dialog.

Kind regards, AA_Dialog

1 week ago

Hi AA

Works, thank you, now I need to add the MCU specific API, namely where to find the I2C API code of Dialog MCU ? I need to add this into the I2C_Functions.c/cpp or I2C_Functions.h within the #ifdef #endif identifier statement of the DA14585 MCU. I also have to ensure that the restart condition is implemented correctly for the I2C read command, I guess this is already provided within the i2c.c driver that we have added few days ago, however, not sure how to sort this out?

Was thinking in this lines below and got an interesting compilation errors and warnings, however, see attached I am not really sure what can be done in terms of errors ...  probably a factor of declarations? 

#pragma once

#include <stdio.h>
#include <stdlib.h>
#include "typedefinition.h"
#include <stdint.h>

//Include I2C Library for DA14585
#ifdef DA14585
  #include "i2c.h" //have simply to include the DA SDK I2C, is this ok?
#endif

//Include I2C Library for PSoC Cypress MCU
#ifdef Cypress
	#include "project.h"
#endif

//Include I2C Library for STM32F
#ifdef STM32F
	#include "stm32f4xx_hal.h"
#endif


//Struct TransferData Member Definition
struct TransferData
{
	uint8_t RegisterAddress;
	uint8_t WData[2];
	uint8_t RData[2];
	uint8_t length;
	uint8_t Slave_Address;
	uint8_t Select_I2C_Bus;
}; //Struct variables will be declared separately in Sensor API and I2C_Functions.cpp/c

//Struct TransferData Member Definition
struct GestureTransferData
{
	uint8_t RegisterAddress;
	uint8_t WData[2];
	uint8_t RData[6];
	uint8_t length;
	uint8_t Slave_Address;
	uint8_t Select_I2C_Bus;
}; //Struct variables will be declared separately in Sensor API and I2C_Functions.cpp/c

//Function Prototypes For I2C_Functions.cpp/c
int ReadI2C_Bus(struct TransferData *Data);
int WriteI2C_Bus(struct TransferData *Data);
int ReadI2C_Bus_Gesture_Mode(struct GestureTransferData *Data);

 

Best.

Attachment Size
Compilations-errors. 10.1 KB

4 days ago

AA_Dialog

Hi mu234,

The i2c api code can be found in file i2c.c. I am not sure what you mean by the restart condition being implemented correctly. You can check the following examples on i2c sensor interfacing with the da14585

https://github.com/dialog-semiconductor/BLE_SDK6_examples/tree/main/connectivity/ble_temperature_ntf

https://github.com/dialog-semiconductor/BLE_SDK6_examples/tree/main/interfaces/accel-Sensor

as a reference.

From what I can see all the compilation errors and warnings derive from your added library code, so please check it on your side for syntax errors.

If you have more questions about the SDK and provided examples, we will be more than happy to help.

Kind regards, AA_Dialog

3 days ago

Thanks AA!

Would you please let me know what the following folders actually contain, in basic simple words... what are they used for in relation to the DA14585?

Project

Indeed, I am particularly interested into the user_config, user_custom_profile, user_platform and user_app. I guess I should be aiming to "setup" the sensor in one of this folder, rather than in main.c

Anyway, I would like to read more about the whole structure of the "project", like how it is organized ... I am not sure, if I should be looking at the uVision manual for this, however, I guess the above sdk_ ... folders rather refer to the DA SDK.

Any help, comments are much appreciated.

Best.

 

3 days ago

AA_Dialog

Hi mu234,

  • The user_config folder contains files that must be included in a user project structure. It contains configuration files for the DA14585.
  • The user_platform folder also must be included in a user project and contains files related to the hardware setup of the DA14585.
  • The user_custom_profile is a folder that contains the declarations and configurations for a user custom BLE profile. It can be omitted when the user is not using a custom profile in his application.
  • The user_app folder is where the user application code resides.

If you are interested in understanding the SDK and examples architecture, the SDK6 Tutorial is a great introduction to the SDK structure and application examples  

http://lpccs-docs.dialog-semiconductor.com/Tutorial_SDK6/initial_project.html

I would also recommend the following

http://lpccs-docs.dialog-semiconductor.com/UM-B-119_DA14585-DA14531_SW_Platform_Reference/index.html

which is a comprehensive reference manual for the system architecture and software architecture of the DA14585/586/531.

Kind regards, AA_Dialog

2 days ago

Hi AA , 

thank you, will have a closer look at the links ...

btw in a project when there is not such a folder, it has to be created and include the needed files ? I guess this is a matter of a project requirement, hence the "blinky example" does not contain those files?

For example, if I look at the "blinky example" only the sdk_boot , sdk_driver and user_app are included.

 

Best.

2 days ago

Hello AA

It seems I have to add the code to read and write I2C from the Dialog . So I have looked at the I2C.c in the SDK_driver folder and I am not really sure what to use hmm can you help?

For more see the picture below as an example how other's uC i2c read and write is used:

example of read write i2c command

Best.

2 days ago

AA_Dialog

Hi mu234,

The blinky example doesn’t use any ble functionality. It runs a simple main that initializes the system and then calls the blinky_test function. BLE applications instead use arh_main.c which contains a scheduler that handles the different messages and functions required by the BLE protocol. All in all blinky is a very simple example and not necessarily made to be easily extendable with ble functionality. The user_empty_peripheral_template is a much better starting point for building a project with ble functionality.

In file i2c.h you can find the declarations for all the functions implemented by Dialog’s i2c library for DA14585 along with brief comments on what they do. I would recommend determining what the functionality of the highlighted command is for the other microcontroller and then trying to find the corresponding i2c command provided by Dialog. If you have any questions on any particular Dialog i2c command, please feel free to ask.

Best regards, AA_Dialog  

5 hours ago

Hi AA and thank you for your reply. 

Indeed, I am in the "empty_periph..._template" ... project now, namely in the sdk_arch, arch_main.c where thei2c.h is included, I guess this is the "main" of this project? BTW How to make a copy of this project into a "demo copy" so that I will work on it without worrying ?

Ok, in general I need to add the code of the Dialog library for reading/writing on the i2c bus. For example, see below the example how it is done for two alternative uCs.

//STM32F specific I2C API call
#ifdef STM32F
	//All of the I2C API functions (For Example: HAL_I2C_Master_Transmit()) are being called from stm32f4xx_hal.h

	//hi2c1 - The variable to the I2C handler which is needed later in the Write and Read I2C function.
	//hi2c1 is defined in the stm32f4xx_hal.h and being called here via extern I2C_HandleTypeDef hi2c1;.
	extern I2C_HandleTypeDef hi2c1;

	//Master sends I2C write command via pointer *Data from the Sensor API.
	//The function returns HAL_OK (=0) when there is no error and -1 when there is an error.
	int WriteI2C_Bus(struct TransferData *Data)
	{
		//Initialization of intial Error = 0
		int Error = 0;

		//Define an array of 3 Bytes to be sent as I2C Write Command as shown in Fig. 10 in the Datasheet Page 7
		uint8_t WData[3]={Data->RegisterAddress, Data->WData[0], Data->WData[1]};

		//Send I2C Write Command as shown in Fig. 10 in the Datasheet Page 7 with Error checking.
		/*Format defined by STM:
		*HAL_I2C_Master_Transmit(I2C_HandleTypeDef *hi2c, uint16_t DevAddress, uint8_t *pData, uint16_t Size, uint32_t Timeout).
		*HAL_I2C_Master_Transmit() is used for transmitting data to the I2C device. It takes following arguments:
		*
		*I2C_HandleTypeDef *hi2c - is the pointer to the i2c handler. hi2c1 is defined in the stm32f4xx_hal.h and being called here via extern I2C_HandleTypeDef *hi2c1;.
		*uint16_t DevAddress - is the Address of the I2C device (Need to be shifted by 1 to left since the input of function expects 8 bits).
		*uint8_t *pData  - is the pointer to the data to be transmitted.
		*uint16_t Size  - is the size of the transmitted data in bytes.
		*uint32_t Timeout - timeout in millisecond in case of any error.
		*Return Error.
		*/
		Error = HAL_I2C_Master_Transmit(&hi2c1, (Data->Slave_Address)<<1, WData, 3, 100);

		//Return -1 when there is error and return HAL_OK (= 0) when no error
		if (Error != HAL_OK)
		{
			return -1;
		}
		else
		{
			return HAL_OK;
		}
	}

	//Master sends I2C Read command and save the read data via pointer *Data.
	//The function returns HAL_OK (=0) when no error and -1 when there is error.
	int ReadI2C_Bus (struct TransferData *Data)
	{
		//Initialization of intial Error = 0
		int Error = 0;

		//Send I2C Read Command as shown in Fig. 10 in the Datasheet Page 7 with Error checking.
		/*Format defined by STM:
		*HAL_I2C_Mem_Read(I2C_HandleTypeDef *hi2c1, uint16_t DevAddress, uint16_t MemAddress, uint16_t MemAddSize, uint8_t *pData, uint16_t Size, uint32_t Timeout).
		*HAL_I2C_Mem_Read () is used for reading data from the I2C device. It has been used instead of HAL_I2C_Master_Receive() because it sends restart condition
		*while the latter which sends stop condition and thus not working. It takes following arguments:
		*
		*I2C_HandleTypeDef *hi2c - is the pointer to the i2c handler.
		*uint16_t DevAddress - is the Address of the I2C device (Need to be shifted by 1 to left since the input of function expects 8 bits).
		*uint16_t MemAddress - is the Internal memory address in the slave which is the register address.
		*uint16_t MemAddSize - the size of memory address (in Byte) which is the size of register address (In the case of Vishay's Sensor always 1 Byte).
		*uint8_t *pData  - is the pointer to the data to be received.
		*uint16_t Size  - is the size of the received data in bytes.
		*uint32_t Timeout - timeout in millisecond in case of any error.
		*Return Error.
		*
		*/
		Error = HAL_I2C_Mem_Read(&hi2c1, (Data->Slave_Address)<<1, Data->RegisterAddress, 1,Data->RData,2,100);

		//Return -1 when there is error and return HAL_OK (= 0) when no error
		if (Error !=HAL_OK)
		{
			return -1;
		}
		else
		{
			return HAL_OK;
		}
	}

	//Master sends I2C Gesture Read command and save the read data via pointer *Data.
	//The function returns HAL_OK (=0) when no error and -1 when there is error.
    int ReadI2C_Bus_Gesture_Mode(struct GestureTransferData *Data)
	{
		//Initialization of intial Error = 0
		int Error = 0;

		//Send I2C Gesture Read Command as shown in the Application Note Page 19 with Error checking.
		/*Format defined by STM:
		*HAL_I2C_Master_Receive(I2C_HandleTypeDef *hi2c, uint16_t DevAddress, uint8_t *pData, uint16_t Size, uint32_t Timeout).
		*HAL_I2C_Master_Receive () is used for reading data from the I2C device. It has been used instead of HAL_I2C_Mem_Read() because no restart condition is *needed.
		*It takes following arguments:
		*
		*I2C_HandleTypeDef *hi2c - is the pointer to the i2c handler. hi2c1 is defined in the stm32f4xx_hal.h and being called here via extern I2C_HandleTypeDef *hi2c1;.
		*uint16_t DevAddress - is the Address of the I2C device (Need to be shifted by 1 to left since the input of function expects 8 bits).
		*uint8_t *pData  - is the pointer to the data to be received.
		*uint16_t Size  - is the size of the received data in bytes (For Gesture Stream 6 Bytes are needed).
		*uint32_t Timeout - timeout in millisecond in case of any error.
		*Return Error.
		*
		*/
		Error = HAL_I2C_Master_Receive(&hi2c1,(Data->Slave_Address)<<1,Data->RData,6,100);

		//Return -1 when there is error and return HAL_OK (= 0) when no error
		if (Error != HAL_OK)
		{
			return -1;
		}
		else
		{
			return HAL_OK;
		}
	}
#endif

//Cypress specific I2C API call
#ifdef Cypress
	//All of the I2C API functions (For Example: I2C_1_MasterSendStart()) are being called from project.h
	//#include "project.h"

	//Master sends I2C write command via pointer *Data from the Sensor API.
	//The function returns 0 when no error and -1 when there is error.
	int WriteI2C_Bus(struct TransferData *Data)
	{
		//Initialization of intial Error loop counting = 0
		int i = 0;
		//Initialization of intial Error = 0
		int Error = 0;

		//Wait for Master to be ready.
		/*I2C_1_MasterStatus() returns the master’s communication status.
		*I2C_1_MODE_COMPLETE_XFER = 0x00.
		*As long as I2C_1_MasterStatus() returns nonzero value (means master is busy or there is error), the loop remains.
		*/
		while (I2C_1_MasterStatus()!= I2C_1_MODE_COMPLETE_XFER){}

		//Send I2C Write Command as shown in Fig. 10 in the Datasheet Page 7 with Error checking.
		//Step 1) Send Start condition, Slave Address and Write bit.
		/*Format defined by Cypress:
		*I2C_1_MasterSendStart(uint8_t SlaveAddress,uint8_t W_nR);.
		*uint8_t SlaveAddress - is the Address of the I2C device (7 Bits).
		*uint8_t W_nR - Write/Read Bit. Write I2C_1_WRITE_XFER_MODE for write and I2C_1_READ_XFER_MODE for read.
		*/
		I2C_1_MasterSendStart(Data->Slave_Address, I2C_1_WRITE_XFER_MODE);

		//Step 2) Send Register Address.
		/*Format defined by Cypress:
		*I2C_1_MasterWriteByte(uint8_t theByte);.
		*uint8_t theByte - is the Address of the Register to be written (1 Byte) for this case to fulfill I2C Write Command as shown in Fig. 10 in the Datasheet *Page 7.
		*/
		I2C_1_MasterWriteByte(Data->RegisterAddress);

		//Step 3) Send I2C Write data to the slave with error checking
		for(i=0;i<2;i++)
		{
			//Write data to be written to the above register address.
			/*Format defined by Cypress:
			*I2C_1_MasterWriteByte(uint8_t theByte);.
			*uint8_t theByte - is the Data to be written to the above register address (1 Byte for each loop) for this case to fulfill I2C Write Command as shown *in Fig. 10 in the Datasheet Page 7.
			*This function returns uint8_t error status. Expect I2C_1_MSTR_NO_ERROR (=0) for no error, otherwise, there is an error.
			*/
			Error = I2C_1_MasterWriteByte(Data->WData[i]);

			//Return -1 when there is error
			if(Error != I2C_1_MSTR_NO_ERROR)
			{
				return -1;
			}
		}

		//Step 4) Send Stop Condition
		I2C_1_MasterSendStop();

		//Wait for Master to finish communicating with the Sensor.
		/*I2C_1_MasterStatus() returns the master’s communication status.
		*I2C_1_MODE_COMPLETE_XFER = 0x00.
		*As long as I2C_1_MasterStatus() returns nonzero value (means master is busy or there is error), the loop remains.
		*/
		while(I2C_1_MasterStatus() != I2C_1_MODE_COMPLETE_XFER ){}

		//Clear the buffer
		I2C_1_MasterClearWriteBuf();

		return 0;
	}

	//Master sends I2C Read command and save the read data via pointer *Data.
	//The function returns 0 upon completion.
	int ReadI2C_Bus(struct TransferData *Data)
	{
		//Initialization of intial Error = 0
		int Error = 0;

		//Wait for Master to be ready.
		/*I2C_1_MasterStatus() returns the master’s communication status.
		*I2C_1_MODE_COMPLETE_XFER = 0x00.
		*As long as I2C_1_MasterStatus() returns nonzero value (means master is busy or there is error), the loop remains.
		*/
		while (I2C_1_MasterStatus() != I2C_1_MODE_COMPLETE_XFER){}

		//Send I2C Read Command as shown in Fig. 10 in the Datasheet Page 7 with Error checking.
		//Step 1) Send Start condition, Slave Address and Write bit.
		/*I2C_1_MasterSendStart(uint8_t SlaveAddress,uint8_t W_nR);.
		*uint8_t SlaveAddress - is the Address of the I2C device (7 Bits).
		*uint8_t W_nR - Write/Read Bit. Write I2C_1_WRITE_XFER_MODE for write and I2C_1_READ_XFER_MODE for read
		*/
		I2C_1_MasterSendStart(Data->Slave_Address, I2C_1_WRITE_XFER_MODE);

		//Step 2) Send Register Address.
		/*I2C_1_MasterWriteByte(uint8_t theByte);.
		*uint8_t theByte - is the Address of the Register to be written (1 Byte) for this case to fulfill I2C Read Command as shown in Fig. 10 in the Datasheet *Page 7.
		*/
		I2C_1_MasterWriteByte(Data->RegisterAddress);

		//Step 3) Send Restart condition, Slave Address and Read bit.
		/*I2C_1_MasterSendRestart(uint8_t SlaveAddress,uint8_t W_nR);.
		*uint8_t SlaveAddress - is the Address of the I2C device (7 Bits).
		*uint8_t W_nR - Write/Read Bit. Write I2C_1_WRITE_XFER_MODE for write and I2C_1_READ_XFER_MODE for read.
		*This function returns uint8_t error status.
		*/
		Error = I2C_1_MasterSendRestart(Data->Slave_Address, I2C_1_READ_XFER_MODE);

		//Return -1 when there is error
		if(Error != I2C_1_MSTR_NO_ERROR)
		{
			return -1;
		}

		//Step 4) Read from the Data Register of the Sensor (2 Bytes array)
		/*I2C_1_MasterReadByte(uint8_t acknNak);.
		*The function returns 1 Byte of Data and the function expects acknowledge or no acknowledge from the Sensor .
		*uint8_t acknNak - The function read whether acknowledge (I2C_1_ACK_DATA) or no acknowledge (I2C_1_NAK_DATA)has been sent from the Sensor.
		*/
		Data->RData[0]  = I2C_1_MasterReadByte(I2C_1_ACK_DATA);
		Data->RData[1]  = I2C_1_MasterReadByte(I2C_1_NAK_DATA);

		//Step 5) Send Stop Condition
		I2C_1_MasterSendStop();

		//Wait for Master to finish communicating with the Sensor.
		/*I2C_1_MasterStatus() returns the master’s communication status.
		*I2C_1_MODE_COMPLETE_XFER = 0x00.
		*As long as I2C_1_MasterStatus() returns nonzero value (means master is busy or there is error), the loop remains.
		*/
		while(I2C_1_MasterStatus() != I2C_1_MODE_COMPLETE_XFER ){}

		//Clear the buffer
		I2C_1_MasterClearReadBuf();

		return 0;
	}

	//Master sends I2C Gesture Read command and save the read data via pointer *Data.
	//The function returns 0 upon completion.
	int ReadI2C_Bus_Gesture_Mode(struct GestureTransferData *Data)
	{
		//Initialization of intial Error = 0
		int Error = 0;

		//Wait for Master to be ready.
		/*I2C_1_MasterStatus() returns the master’s communication status.
		*I2C_1_MODE_COMPLETE_XFER = 0x00.
		*As long as I2C_1_MasterStatus() returns nonzero value (means master is busy or there is error), the loop remains.
		*/
		while (I2C_1_MasterStatus() != I2C_1_MODE_COMPLETE_XFER){}

		//Send I2C Gesture Read Command as shown in the Application Note Page 19.
		//Step 1) Send Start condition, Slave Address and Read bit.
		/*I2C_1_MasterSendStart(uint8_t SlaveAddress,uint8_t W_nR);.
		*uint8_t SlaveAddress - is the Address of the I2C device (7 Bits).
		*uint8_t W_nR - Write/Read Bit. Write I2C_1_WRITE_XFER_MODE for write and I2C_1_READ_XFER_MODE for read.
		*This function returns uint8_t error status.
		*/
		Error = I2C_1_MasterSendStart(Data->Slave_Address, I2C_1_READ_XFER_MODE);

		//Return -1 when there is error
		if(Error != I2C_1_MSTR_NO_ERROR)
		{
			return -1;
		}

		//Step 2) Read from the Data Register of the Sensor (6 Bytes array).
		/*I2C_1_MasterReadByte(uint8_t acknNak);.
		*The function returns 1 Byte of Data and the function expects acknowledge or no acknowledge from the Sensor.
		*uint8_t acknNak - The function read whether acknowledge (I2C_1_ACK_DATA) or no acknowledge (I2C_1_NAK_DATA)has been sent from the Sensor.
		*/
		Data->RData[0]  = I2C_1_MasterReadByte(I2C_1_ACK_DATA);
		Data->RData[1]  = I2C_1_MasterReadByte(I2C_1_ACK_DATA);
		Data->RData[2]  = I2C_1_MasterReadByte(I2C_1_ACK_DATA);
		Data->RData[3]  = I2C_1_MasterReadByte(I2C_1_ACK_DATA);
		Data->RData[4]  = I2C_1_MasterReadByte(I2C_1_ACK_DATA);
		Data->RData[5]  = I2C_1_MasterReadByte(I2C_1_NAK_DATA);

		//Step 3) Send Stop Condition
		I2C_1_MasterSendStop();

		//Wait for Master to finish communicating with the Sensor.
		/*I2C_1_MasterStatus() returns the master’s communication status.
		*I2C_1_MODE_COMPLETE_XFER = 0x00.
		*As long as I2C_1_MasterStatus() returns nonzero value (means master is busy or there is error), the loop remains.
		*/
		while(I2C_1_MasterStatus() != I2C_1_MODE_COMPLETE_XFER ){}

		//Clear the buffer
		I2C_1_MasterClearReadBuf();

		return 0;
	}
#endif

Therefore, I am looking at the i2c.h to spot the functions to use the i2c straight forward, but not really sure what is there to use it straightforward?

 

Can you help with an example , or type of hint how to get going? 

 

Best.