SDV1、SDV2、SDV2HC SD卡区别
作者 codercjg 在 1 四月 2016, 11:15 上午
如SD卡协议规范所写：
普通卡：2G, SDV2HC卡: 2G-32G，2G以内的卡，访问扇区时用32位地址，2G以上的卡访问扇区时用扇区号，就是扇区地址除以扇区大小512个字节
3.3 Card CapacityIn terms of capacity, two types of SD Memory Cards are defined:• Standard Capacity SD Memory Cards supports capacity up to and including 2 G bytes (231 bytes).All versions of the Physical Specifications define the Standard Capacity SD Memory Card.• High Capacity SD Memory Cards supports capacity more than 2 G bytes (231 bytes) and this versionof specification limits capacity up to and including 32 GB. High Capacity SD Memory Card is newlydefined from the Physical Layer Specification Version 2.00.Only hosts that are compliant to the Physical Layer Specification version 2.00 or higher and the SD FileSystem Specification Ver2.00 can access High Capacity SD Memory Cards. Other hosts fail to initializeHigh Capacity SD Memory Cards (See Figure 3-1).
3.4 Speed ClassFour Speed Classes are defined and indicate minimum performance of the cards• Class 0 – These class cards do not specify performance. It includes all the legacy cards prior tothis specification, regardless of its performance• Class 2 – Are more than or equal to 2 MB/sec performance.• Class 4 – Are more than or equal to 4 MB/sec performance.• Class 6 – Are more than or equal to 6 MB/sec performance.High Capacity SD Memory Cards shall support Speed Class Specification and have performance morethan or equal to Class 2.Note that the unit of performance [MB/sec] indicates 1000×1000 [Byte/sec] while the unit of data size[MB] indicates 1024×1024 [Byte]. This is because the maximum SD Bus speed is specified by themaximum SD clock frequency (25 [MB/sec] = 25000000 [Byte/sec] at 50 MHz) and data size is basedon memory boundary (power of 2).
4.3.14 Command Functional Difference in High Capacity SD Memory CardMemory access commands include block read commands (CMD17, CMD18), block write commands(CMD24, CMD25), and block erase commands (CMD32, CMD33).Following are the functional differences of memory access commands between Standard Capacity andHigh Capacity SD Memory Cards:• Command ArgumentIn High Capacity Cards, the 32-bit argument of memory access commands uses the memoryaddress in block address format. Block length is fixed to 512 bytes,In Standard Capacity Cards, the 32-bit argument of memory access commands uses thememory address in byte address format. Block length is determined by CMD16,i.e.:(a) Argument 0001h is byte address 0001h in the Standard Capacity Card and 0001h block inHigh Capacity Card(b) Argument 0200h is byte address 0200h in the Standard Capacity Card and 0200h block inHigh Capacity Card• Partial Access and Misalign AccessPartial access and Misalign access (crossing physical block boundary) are disabled in HighCapacity Card as the block address is used. Access is only granted based on blockaddressing.• Set Block LengthWhen memory read and write commands are used in block address mode, 512-byte fixedblock length is used regardless of the block length set by CMD16. The setting of the blocklength does not affect the memory access commands. CMD42 is not classified as a memoryaccess command. The data block size shall be specified by CMD16 and the block length canbe set up to 512 bytes. Setting block length larger than 512 bytes sets theBLOCK_LEN_ERROR error bit regardless of the card capacity.• Write Protected GroupHigh Capacity SD Memory Card does not support write-protected groups. Issuing CMD28,CMD29 and CMD30 generates the ILLEGAL_COMMAND error.
BLE Connection Interval
作者 codercjg 在 16 五月 2016, 11:45 上午
In a BLE connection between two devices, a frequency-hopping scheme is used, in that the two devices each send and receive data from one another on a specific channel, then “meet” at a new channel (the link layer of the BLE stack handles the channel switching) at a specific amount of time later. This “meeting” where the two devices send and receive data is known as a “connection event”. Even if there is no application data to be sent or received, the two devices will still exchange link layer data to maintain the connection. The connection interval is the amount of time between two connection events, in units of 1.25ms. The connection interval can range from a minimum value of 6 (7.5ms) to a maximum of 3200 (4.0s).
Different applications may require different connection intervals. The advantage of having a very long connection interval is that significant power is saved, since the device can sleep most of the time between connection events. The disadvantage is that if a device has data that it needs to send, it must wait until the next connection event.
The advantage of having a very short connection interval is that there is more opportunity for data to be sent or received, as the two devices will connect more frequently. The disadvantage is that more power will be consumed, since the device is frequently waking up for connection events.
Supervision Timeout – This is the maximum amount of time between two successful connection events. If this amount of time passes without a successful connection event, the device is to consider the connection lost, and return to an unconnected state. This parameter value is represented in units of 10ms. The supervision timeout value can range from a minimum of 10 (100ms) to 3200 (32.0s). In addition, the timeout must be larger than the effective connection interval (explained below).
Reducing the connection interval will:
- Increase the power consumption for both devices
- Increase the throughput in both directions
- Reduce the amount of time that it takes for data to be sent in either direction
Increasing the connection interval will: - Reduce the power consumption for both devices
- Reduce the throughput in both directions
- Increase the amount of time that it takes for data to be sent in either direction
Reducing the slave latency (or setting it to zero) will: - Increase the power consumption for the peripheral device
- Reduce the amount of time that it takes for data sent from the central device to be received by the peripheral device
Increasing the slave latency will: - Reduce power consumption for the peripheral during periods when the peripheral has no data to send to the central device
- Increase the amount of time that it takes for data sent from the central device to be received by the peripheral device
分类: ble低功耗蓝牙 | 评论
Data rates using BLE
作者 codercjg 在 16 五月 2016, 11:39 上午
Bluetooth Low Energy (BLE) is designed for low data rate applications, like control signals, sensor readings, etc. However, occasionally there is a need for higher data rates with BLE. The theoretical over-the-air data rate of BLE is 1 Mb/s, but that’s the PHY layer transfer rate between devices and doesn’t account for protocol overhead. The maximum achievable data rate is closer to 10kB/s but this is device dependent, as we’ll explain below.
Contents
[hide]
1 BLE Connection Parameters1.1 Connection Interval
1.2 Slave latency
1.3 Connection Supervision Timeout
1.4 Packets Per Connection Interval
2 Connection Parameters between two modules
3 Connection Parameters for iOS
4 Connection Parameters for Android
5 Graph of Throughput
BLE Connection Parameters
There are multiple connection parameters (defined in Bluetooth 4.0 specification, Volume 3, Part A, Section 4.20) that will determine the throughput. Keep in mind that higher throughput will result in more power consumption.
Connection Interval
This defines how often that the central communicates with the peripheral. There can be a maximum of four packets sent per connection interval, and each packet can have up to 20B of payload. According to the BLE specification, the allowable range for connection parameters is from 7.5mSec to 4000mSec. The Connection Interval is the parameter that most affects data rate. Think of the Connection Interval as the train schedule: for example, trains leave the station every half hour. Each train can have 1-4 cars, and each car can hold 0 to 20 bytes. So if you have a 20 ms Connection Interval, then the theoretical maximum for sending a message and receiving the ACK is 80 bytes (of data) in 40 mS (one Connection Interval to send, plus one Interval to receive the ACK). But trains leave whether full or not. So you might only send 20 bytes every 80 mS — or less.
Slave latency
This is the number of connection intervals that the slave is allowed to skip. For example, if the connection interval is 20mSec and slave latency is 4, then if the peripheral wants to then it only needs to answer the master every 80mSec. Slave latency is useful if you want to mostly stay asleep, but then burst out data at a faster rate occasionally. In this case, the peripheral only needs to respond to the master every 80mSec to keep the connection alive, but if it has a lot of data then it can send data every 20mSec. Slave Latency is any value between 0 and 499, though it cannot exceed: ((supervisionTimeout / connInterval) – 1)
Connection Supervision Timeout
This parameter specifies the maximum amount of time that either the master or slave can go before receiving a link-layer packet. Both slave and master device maintain their own “Supervision timer”, which resets to zero every time a packet is received. If supervision timer ever reaches the supervision timeout, the device considers the connection lost, and exits the connection state (returning to the advertising, scanning, or standby state). The Connection Supervision Timeout is in the range of 100ms and 32.0s. It Must be larger than (1 + slaveLatency) * (ConnInterval).
Packets Per Connection Interval
This is the number of packets that can be sent in each connection interval. According to the Bluetooth specification, the maximum packets per connection interval is 6, but iOS limits this to 4.
Connection Parameters between two modules
Here you may set the Connection Parameters to their maximum values, with a Connection Interval as low as 7.5mSec to give the highest throughput.
Connection Parameters for iOS
Recall earlier where we mentioned that the maximum achievable data rate is device dependent. According to the Apple, the connection parameters are restricted as follows:
Interval Max * (Slave Latency + 1) ≤ 2 seconds Interval Min ≥ 20 ms (not 7.5mSec)
Interval Min + 20 ms ≤ Interval Max Slave Latency ≤ 4 connSupervisionTimeout ≤ 6 seconds
Interval Max * (Slave Latency + 1) * 3 < connSupervisionTimeout
If Bluetooth Low Energy HID is one of the connected services of an accessory, connection interval down to 11.25 ms may be accepted by the Apple product.
Theoretical maximum throughput for iOS is: 80B per 40mSec, which results in 2kB/Sec. Using Notifications / Indications may increase this.
Connection Parameters for Android
Connection Parameters for Android are device dependent, but some devices can support a Connection Interval as short as 7.5mSec. YMMV.
Graph of Throughput
https://atmosphere.anaren.com/wiki/Data_rates_using_BLE
分类: ble低功耗蓝牙 | 评论
ble低功耗蓝牙走过的那些坑
作者 codercjg 在 13 五月 2016, 3:30 下午
硬件ATMLEL SAMB11 ble4.1评估板、android4.4手机、iphone5s,以及CC2540 USB dongle 蓝牙抓包工具
开发平台 ATMEL STUDIO, adt bundle for windows
首先要看下ble4.1规范，了解下ble基本知识和GATT协议以及数据包格式。
- ATMEL STUDIO自带SAMB11 ble协议栈，基本程序开发就是根据它的例子框架修改
- Android4.3以上手机才支持ble4.0,并且只能作为从设备，android5.0即可做从设备也可做主设备，iphone5主从都支持
3.通过SAMB11评估板向android手机发送notify时，最大为7Kb/s, 距离20米左右1kb/s
4.通过android手机write charatistic时，速度为200b/s, 没错就是200个字节每秒，经过抓包发现write时会先发写请求验证读写权限，然后才执行写操作, 差不多要60ms左右
分类: ble低功耗蓝牙 | 评论
ble低功耗蓝牙GATT应用协议
作者 codercjg 在 13 五月 2016, 3:18 下午
GATT
by Kevin Townsend
GATT is an acronym for the Generic Attribute Profile, and it defines the way that two Bluetooth Low Energy devices transfer data back and forth using concepts called Services and Characteristics. It makes use of a generic data protocol called the Attribute Protocol (ATT), which is used to store Services, Characteristics and related data in a simple lookup table using 16-bit IDs for each entry in the table.GATT comes into play once a dedicated connection is established between two devices, meaning that you have already gone through the advertising process governed by GAP.The most important thing to keep in mind with GATT and connections is that connections are exclusive. What is meant by that is that a BLE peripheral can only be connected to one central device (a mobile phone, etc.) at a time! As soon as a peripheral connects to a central device, it will stop advertising itself and other devices will no longer be able to see it or connect to it until the existing connection is broken.Establishing a connection is also the only way to allow two way communication, where the central device can send meaningful data to the peripheral and vice versa.
Connected Network Topology
The following diagram should explain the way that Bluetooth Low Energy devices work in a connected environment. A peripheral can only be connected to one central device (such as a mobile phone) at a time, but the central device can be connected to multiple peripherals. If data needs to be exchanged between two peripherals, a custom mailbox system will need to be implemented where all messages pass through the central device.Once a connection is established between a peripherals and central device, however, communication can take place in both directions, which is different than the one-way broadcasting approach using only advertising data and GAP.
GATT Transactions
An important concept to understand with GATT is the server/client relationship.The peripheral is known as the GATT Server, which holds the ATT lookup data and service and characteristic definitions, and the GATT Client (the phone/tablet), which sends requests to this server.All transactions are started by the master device, the GATT Client, which receives response from the slave device, the GATT Server.When establishing a connection, the peripheral will suggest a ‘Connection Interval’ to the central device, and the central device will try to reconnect every connection interval to see if any new data is available, etc. It’s important to keep in mind that this connection interval is really just a suggestion, though! Your central device may not be able to honour the request because it’s busy talking to another peripheral or the required system resources just aren’t available.The following diagram should illustrate to data exchange process between a peripheral (the GATT Server) and a central device (the GATT Client), with the master device initiating every transaction:
Services and Characteristics
GATT transactions in BLE are based on high-level, nested objects called Profiles, Services and Characteristics, which can be seen in the illustration below:
Profiles
A Profile doesn’t actually exist on the BLE peripheral itself, it’s simple a pre-defined collection of Services that has been compiled by either the Bluetooth SIG or by the peripheral designers. The Heart Rate Profile, for example, combines the Heart Rate Service and the Device Information Service. The complete list of officially adopted GATT-based profiles can be seen here: Profiles Overview.
Services
Services are used to break data up into logic entities, and contain specific chunks of data called characteristics. A service can have one or more characteristics, and each service distinguishes itself from other services by means of a unique numeric ID called a UUID, which can be either 16-bit (for officially adopted BLE Services) or 128-bit (for custom services).A full list of officially adopted BLE services can be seen on the Services page of the Bluetooth Developer Portal. If you look at the Heart Rate Service, for example, we can see that this officially adopted service has a 16-bit UUID of 0x180D, and contains up to 3 characteristic, though only the first one is mandatory: Heart Rate Measurement, Body Sensor Location and Heart Rate Control Point.
Characteristics
The lowest level concept in GATT transactions is the Characteristic, which encapsulates a single data point (though it may contain an array of related data, such as X/Y/Z values from a 3-axis accelerometer, etc.).Similarly to Services, each Characteristic distinguishes itself via a pre-defined 16-bit or 128-bit UUID, and you’re free to use the standard characteristics defined by the Bluetooth SIG (which ensures interoperability across and BLE-enabled HW/SW) or define your own custom characteristics which only your peripheral and SW understands.As an example, the Heart Rate Measurement characteristic is mandatory for the Heart Rate Service, and uses a UUID of 0x2A37. It starts with a single 8-bit value describing the HRM data format (whether the data is UINT8 or UINT16, etc.), and the goes on to include the heart rate measurement data that matches this config byte.Characteristics are the main point that you will interact with your BLE peripheral, so it’s important to understand the concept. They are also used to send data back to the BLE peripheral, since you are also able to write to characteristic. You could implement a simple UART-type interface with a custom ‘UART Service’ and two characteristics, one for the TX channel and one for the RX channel, where one characteristic might be configured as read only and the other would have write privileges.
https://learn.adafruit.com/introduction-to-bluetooth-low-energy/introduction
分类: ble低功耗蓝牙 | 评论