浮点数在内存中的存放形式

关键字volatile、const

1
2
3
4

#define     __I     volatile const        /*!< Defines 'read only' permissions */
#define     __O     volatile                       /*!< Defines 'write only' permissions */
#define     __IO    volatile                      /*!< Defines 'read / write' permissions */

这三个宏定义都是用来替换成volatile和coast的，所以我们先了解这两个关键字的作用。

volatile
** 简单的说，就是不让编译器进行优化，即每次读取或者修改值的时候，都必须重新从内测或者寄存器中读取或者修改**。
一般来说，volatile常用在如下的几个地方：
1、中断服务程序中修改的供有其它程序检测的变量需要加volatile；
2、多任务环境下各任务间共享标志应该加volatile；
3、存储器映射的硬件寄存器通常也要加volatile说明，因为每次对它的读写都可能有不同意义。

**CONST
** 只读变量，即变量保存在只读静态存储区。编译时，如何尝试修改只读变量，则编译器提示出错，就能防止误修改。const和define

​ 两者都是用来定义变量，但是const定义时，定义了常量的类型，所以更精确一些（其实const定义的是只读变量，而不是常量）。#define只是简单的文本替换，除了可以定义常量外，还可以用来定义一些简单的函数，有点类似内置函数。const和define定义的常量可以放在头文件里面。

I：输入口。既然是输入，那么寄存器的值就随时会外部修改，那就不能进行优化，每次都要重新从寄存器中读取。也不能写，即只读，不然就不是输入而是输出了。

O：输出口，也不能进行优化，不然你连续两次输出相同值，编译器认为没改变，就忽略了后面那一次输出，假如外部
在两次输出中间修改了值，那就影响输出。

__IO：输入输出口，同上。

浮点数在内存的存放

浮点数：NUM = (-1)^S * 1.M * 2^(E - 127)

image-20210806105937273

S：符号位，0代表为正数，1代表为负数

E：阶码位，如果是float型E = 8，double型E = 11

M：尾数位，如果是float型M = 23，double型M = 52

示例：求98.46在内存中的存储？

  • 第一步，将十进制转换成二进制

98.46 转换二进制：

image-20210806112008605

结果：1 100010 . 0110 0110 0110 0110 0110

  • 第二步，根据二进制数求S、E、M

由于98.46是正数：S = 0。

由于小数点向后移动了6位，所以6为阶数，1.M * 2^6，根据1.M * 2^(E - 127)，则有E - 127 = 6， 求得E = 133，二进制：E = 10000101。

M就是尾数，即1 100010 . 0110 0110 0110 0110 0110 ，去掉小数点的阶数，小数点向前移动阶数6，1 .100010 0110 0110 0110 0110 0110 ，即 M = 100010 0110 0110 0110 0110 0110（二进制） 。

  • 第三步，组合S、E、M得到98.46在内存的存储形式

S = 0，E = 10000101， M = 1000 1001 1001 1001 1001 10

内存储存形式：0 10000101 1000100110011001100110

浮点数的自增陷阱

1.++–适用于浮点数

2.实际不使用浮点数的++–

浮点数 包括float 、double、 long double等等都是近似存储
所以每一个浮点数的值都不是准确的
于是如果采取自加 在一些特殊情况下
a的近似值和a+1的近似值会等同
即自加完全没有效果

如果用在循环中 就有可能导致死循环.

1
2
3
4
5
6
7
8
9
10
11
#include <stdio.h>
  
int main(void) 
{
    // your code goes here
    float f=88888888.5;
    f++;
  
    printf("%f",f);//88888888.000000
    return 0;
}

double类型的数据用自增和自减没有啥意义，整型数据的自增和自减的意义是只需要一个指令就可以完成，执行的效率很高。浮点数比较复杂，不可能一个指令就能完成自增和自减，所以并不能提高执行效率

示例：

1
2
3
4
5
6
7
8
9
10
11
12
main()
{ 
  float x=1；
  int y；
  x++：
  y=x+l；
  printf(”x=％d，y=％f”，x，y)；
}
 
A)x=2，   y=3           B)x=2，y=3.0
 
C)x=2.0，  y=3          D)x=0，y=0.000000

float转int型，float x = 1，在内存中32位全部为0，x++后x = 2，在内存中0 00000001 00000000000000阶数为1， x再加1等于3，在内存中0 00000001 10000000000000阶数为1，将这段内存转换成int类型 0 00000001 10000000000000即y的值。

运行结果：以上答案全都不正确

image-20210806125634013

浮点数判断与0的大小

无论 是float还是double类型的变量，都有精度限制。

其中EPSINON是允许的误差（即精度）。

1
2
3
4
5
6
#define EPSILON 1e-6 // 即时0.000001

if ((x >= -EPSINON) && (x <= EPSINON))
{
    
}

为什么浮点数的精度是0.000001？

因为浮点数在内存中：尾数M最大用23位表示。

单精度8位阶码，1位符号，剩下23位尾数，算出2的负23次方，得到0.00000011920928955078125。

双精度11位阶码，1位符号，剩下52位尾数，算出2的负52次方，得到0.00000000000000022204460492503130808472633361816。

前面0有多少个，就表示能精确到哪一位。

展开全文 >>

从各层实现的对象上来看分层思想

从各层实现的对象上来看分层思想

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
/* 底层驱动设备对象 */
struct stm32_uart
{
    UART_HandleTypeDef handle;
    struct stm32_uart_config *config;  // stm32串口的差异化特性，与其它MCU的串口不同的地方：比如串口的寄存器地址、配置串口时操作的寄存器代码

#ifdef RT_SERIAL_USING_DMA
    struct
    {
        DMA_HandleTypeDef handle;
        rt_size_t last_index;
    } dma_rx;
    struct
    {
        DMA_HandleTypeDef handle;
    } dma_tx;
#endif
    rt_uint16_t uart_dma_flag; // dma也是差异化代码
    
    struct rt_serial_device serial; // 设备框架层基类：是所有串口设备的共性
};

/* 串口设备框架对象 */
struct rt_serial_device
{
    struct rt_device          parent; /* 设备基类：所有设备都具有的共性，不管是串口设备，spi设备、iic设备都有 */

    const struct rt_uart_ops *ops; // 串口都有getc、putc等操作方法
    struct serial_configure   config; // 串口都有配置串口的信息：波特率、是否奇偶校验等配置

    void *serial_rx;
    void *serial_tx;
};
typedef struct rt_serial_device rt_serial_t;

/* 设备对象 */
struct rt_device
{
    struct rt_object          parent;                   /**< inherit from rt_object */

    enum rt_device_class_type type;                     /**< device type */
    rt_uint16_t               flag;                     /**< device flag */
    rt_uint16_t               open_flag;                /**< device open flag */

    rt_uint8_t                ref_count;                /**< reference count */
    rt_uint8_t                device_id;                /**< 0 - 255 */

    /* device call back */
    rt_err_t (*rx_indicate)(rt_device_t dev, rt_size_t size);
    rt_err_t (*tx_complete)(rt_device_t dev, void *buffer);

    const struct rt_device_ops *ops;

    void                     *user_data;                /**< device private data */
};

IO设备管理层、设备驱动框架层、设备驱动层：三层定义的对象是一级一级增大，从抽象到具体，设备的实例化必须在最底层进行也就是驱动层，底层初始化好设备的差异性，然后通过注册的形式给到上层，上层在初始化本次的差异性，然后再通过注册给到上层，上层再初始化，初始化是一级一级从下往上初始化，最终这个设备就初始化好了，应用程序就可以使用这个设备了。

  • 对象基类和父类首地址相同的使用
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
// 孙类最大占用空间，派生了 struct yl_led_device 基类
struct hw_chip_device
{
    struct yl_led_device            led_device;
    struct rt_spi_device *          rt_spi_device;
    struct chip_ops *               ops;
    void *                          user_data;
};

// 子类，派生了 struct rt_device  基类
struct yl_led_device
{
    struct rt_device                obj_device;
    void *                          user_data;
};

// 父类最小占用空间
struct rt_device
{
    struct rt_object          parent;                   /**< inherit from rt_object */

    enum rt_device_class_type type;                     /**< device type */
    rt_uint16_t               flag;                     /**< device flag */
    rt_uint16_t               open_flag;                /**< device open flag */

    rt_uint8_t                ref_count;                /**< reference count */
    rt_uint8_t                device_id;                /**< 0 - 255 */

.......

    void                     *user_data;                /**< device private data */
};

// 由于各个基类在类的结构体都是在第一个位置，所以以上三个类的实例化对象地址一样，但类型不一样
// 只有父类注册到了obj容器，所有站到obj里面的对象，强制转换下对象类型就可以得到各个对象
rt_size_t _write(rt_device_t dev, rt_off_t pos, const void *buffer, rt_size_t size)
{
    struct hw_chip_device * chip_dev = (struct hw_chip_device *)dev; // 地址一样，类型不一样：从obj父对象转换成 hw_chip_device 孙对象，可直接操作孙对象里面的所有成员
    
    _chip_write(chip_dev, buffer, size);
    
    return RT_EOK;
}

展开全文 >>

嵌入式基础--日志模块

嵌入式基础–日志模块

大家晚上好。今天来讲讲调试程序的重要方法：打印日志。无论开发何种程序，单片机，手机APP，电脑客户端，还是服务器，日志都是最基础也是最重要的调试手段。

手机APP，电脑客户端和服务器的开发环境往往提供了功能丰富的日志接口。比如linux的syslog模块提供如下日志函数：

1
2
3
void openlog(const char *ident, int logopt, int facility);
void closelog(void);
void syslog(int priority, const char *message, arguments...);

其记录的每条日志包含时间，级别，来源和内容，可根据配置过滤低级别的日志。下图中的日志，红框是时间，黄框是来源，绿框是内容。image-20210804204336483单片机的开发则大不相同，其开发环境中往往不会提供日志接口。单片机的驱动库往往只提供基础的操作外设的接口，如uart，i2c，spi，而不提供高层次的SDK。这就需要我们自己来设计。

单片机日志接口比较简单的实现，是将日志从串口输出，在电脑上可通过诸多串口软件来查看。向串口输出字符嘛，看着简单，其实大有文章。简陋的设计与精心周全的设计将使日后的代码开发和调试产生巨大差异。

简陋的设计

先看一个简陋至极的接口：

1
2
3
4
5
6
void drv_uart_send(uart_t *uart, void *buf, int len);

void log_print(char *buf , unsigned int len)
{
    drv_uart_send(&uart1, buf, len);
}

log_print将buf的前len字节的内容输出到调试串口(uart1)，其实就是对串口输出函数进行简单的封装，使用户在输出日志时不需要传入串口实例。

大家觉得这个日志接口有没有问题，好不好用呢？

该接口很简陋，这是毫无疑问的。不仅如此，它存在一个非常不合理的设计：既然是打印字符串，那就不需要len参数。因为字符串以’\0’结尾，log_print内部完全可以判断字符串的长度。如果要传字符串长度的话，在调用时会非常尴尬。比如，在网络初始化成功后，想打印”network initialize succeed”，该怎么调用呢？

下面这种调用显然有问题，引入了重复代码。当需要修改日志内容时，需要修改两处，容易遗漏。

1
log_print("network initialize succeed\n", strlen("network initialize succeed\n");

要不这样？这简直就是掩耳盗铃。看似没有重复代码，实则并没有解决重复代码引发的问题。当内容长度变化时，还是得更新长度参数。

1
log_print("network initialize succeed\n", 26);

各位不要笑，上面这种调用方法绝非笔者杜撰出来，而是在笔者近期接手的一个项目中大量出现的。

那这样呗？这是没啥问题了，不过在打印日志前，还得定义一个变量，是不是相当麻烦？

1
2
const char *str = "network initialize succeed\n";
log_print(str, strlen(str));

上述三种调用方法，前两者均存在问题，第三种也很尴尬。问题的根源出在log_print接口的设计上，想要避免尴尬，还得从源头解决。其实很简单：

1
2
3
4
5
6
7
8
9
10
void drv_uart_send_str(uart_t *uart, const char *str)
{
    drv_uart_send(uart, str, strlen(str));
}

void log_print(char *buf)
{
    drv_uart_send_str(&uart1, buf);
    drv_uart_send_str("\n");
}

做了两项修改：

  1. 在串口层面添加打印字符串的函数，从而使log_print不需要长度参数。
  2. log_print在输出日志内容之后自动换行，从而避免每条日志中都要加’\n’。

现在打印日志就舒服多了：

1
log_print("network initialize succeed");

非常简单的修改，就可极大改善调用体验。人生而懒惰，懒惰不一定有大问题，问题在于，要懒惰得恰到好处。如果在设计底层接口时偷懒，则日后写应用层代码时将堕入万劫不复之深渊。如果想在调用时舒服些，那就需要在设计底层时多花些心思。

使用printf

修改过后的log_print不再丑陋，但依然很简陋。如果想打印动态的内容，如数字时，还是比较麻烦。比如打印网络信号质量(rssi为int型变量，值为信号质量)：

1
2
3
char buffer[64];
snprintf(buffer, sizeof(buffer), "rssi:%d", rssi);
log_print(buffer);

简单打印一个数字却需要三行代码，非常不便。这时我们可以呼叫printf函数：

1
printf("rssi:%d\n", rssi);

相信大家肯定对printf并不陌生，这可是学习C语言时经常用到的函数，其将内容打印到标准输出。单片机SDK并没有指定标准输出，若想将printf的内容输出到指定串口，则需要实现printf所依赖的底层函数。在gcc编译环境中（stm32cube，TRUEStudio，Code Compose Studio等均使用gcc编译器），需要实现_write函数：

1
2
3
4
5
int _write(int fd, char *str, int len)
{
    drv_uart_send(&dbg_uart, str, len);
    return len;
}

drv_uart_send为笔者封装的串口发送函数，dbg_uart指向调试串口。

_write为C库中定义的系统函数之一。_write实现的其实是将数据写入文件，fd为文件号。由printf调用_wirte时，传入的fd为1，即标准输出stdout。其他函数，如fprintf，fwrite也会调用_write，它们传入的fd指向相关文件。所以上述_write函数的实现并不严谨，它忽略了fd参数，不管是什么文件的写操作，均输出到调度串口。

严谨的设计应该这样：

1
2
3
4
5
6
7
8
9
int _write(int fd, char *str, int len)
{
    if (fd == stdout->_file)
    {
        drv_uart_send(&dbg_uart, str, len);
    }

    return len;
}

不过在不使用文件系统的情况下，也不会操作其他文件，这个懒也可以偷。

添加更多的信息

使用printf已经比之前的log_print方便许多，不过仍然有改进的空间。

快速打开或关闭日志

在调试阶段，可能需要打印较多的日志来观察效果和跟踪问题。由于过多的日志可能降低程序的实时性，也暴露了实现的细节，所以在正式运行时（比如商用交付或者比赛验收）需要关闭全部或者大部分日志。如果写了大量的printf语句的话，一个个注释掉显然是件麻烦的事情。我们需要有一个能够快速打开或关闭日志的功能。

时间信息

有时我们不仅想要知道程序运行的结果，还想观察关键步骤执行的时间。比如某步执行了多长时间，某个定时任务执行的周期是否正确。如果日志中包含时间信息（比如从启动到现在所经过的毫秒）就会很方便观察。

1
2
3
4
5
6
[10.011] schedule task1
[12.011] schedule task1
[12.015] schedule task2
[14.011] schedule task1
[16.011] schedule task1
[16.015] schedule task2

来源和级别

当日志较多时，如果能打印日志的来源（文件名或模块名，函数名，代码行数），则更方便查看和定位问题。在多人合作开发时，这点尤为重要。

如果根据日志内容的重要性对日志分级，以不同的颜色来显示不同级别的内容，则更容易观察。

下图中：

  • 白色为verbose级别，一般用于打印码流。
  • 蓝色为debug级别，包含了大量的调试信息。
  • 绿色为info级别，通常打印关键步骤的结果。
  • 红色为error级别，打印错误信息。

下图红框中为日志来源，由模块名和代码行数组成。image-20210804204321595

正式运行时，往往不需要verbose和debug日志，保留info和error日志。

实现

实现上述功能会稍微复杂些，下面做一些简单的介绍。

定义日志级别：

1
2
3
4
5
6
7
/* Debug level */
#define LOG_LEVEL_FATAL         0
#define LOG_LEVEL_ERROR         1
#define LOG_LEVEL_WARN          2
#define LOG_LEVEL_INFO          3
#define LOG_LEVEL_DEBUG         4
#define LOG_LEVEL_VERBOSE       5

定义宏LOG_D以打印调试级别的日志：

1
2
3
4
5
#if LOG_LEVEL >= LOG_LEVEL_DEBUG
#define LOG_D(fmt, ...) logger_output(LOG_LEVEL_DEBUG, LOG_TAG, __LINE__, fmt, ##__VA_ARGS__)
#else
#define LOG_D(fmt, ...)
#endif

解释几点内容：

  • LOG_LEVEL为当前日志级别，其可以控制是否打印调试级别的日志。此宏在用户代码中定义，而不是头文件这中。这样一来，不同的代码文件可以单独控制自己日志的级别。有些开发完毕的文件可调高日志级别（数值越小，级别越高）以精简日志，而开发中的文件可调低日志级别。
  • …用于接收变长参数，编译器做宏替换时，会将…接收的参数集替换到__VA_ARGS__所在位置。
  • ##为标识连接符，这里是用于处理变长参数集为空的场景。此时，##会吞噬前面的逗号。
  • LOG_D在进行宏替换时，会加上日志级别（调试级别），标签名（LOG_TAG，同样在用户代码中定义），代码行数信息。

每一个用户代码在导入日志模块头文件时，需要指定标签名称和日志级别：

1
2
3
#define LOG_TAG  "app"
#define LOG_LEVEL LOG_LEVEL_DEBUG
#include "logger.h"

使用起来很简单，当printf使用即可，比如：

1
2
LOG_D("this is a debug log");
LOG_D("rssi:%d", 30);

如果刚才没有理解…和##的话，这里结合示例再说明下。

上述示例中，LOG_D("rssi:%d", 30)中的"rssi:%d"是格式化字符串，对应于LOG_D(fmt, ...)中的fmt参数，30则属于变长参数。为了便于理解，笔者给出中间替换结果，即LOG_LEVEL_DEBUG之类的不替换：

1
logger_output(LOG_LEVEL_DEBUG, LOG_TAG, __LINE__, "rssi:%d", 30);

至于LOG_D("this is a debug log"),如果没有##的话，将被替换为：

1
logger_output(LOG_LEVEL_DEBUG, LOG_TAG, __LINE__, "this is a debug log", );

有没有注意最右边有一个单独的逗号？##的作用就是在这种情况下把逗号给吃掉。

logger_output的实现如下，先打印时间和来源，之后调用了va_list版本的snprintf，即vsnprintf，以打印用户传递的格式化字符串和变长参数。关于va_list，改天单独出篇文章讲解。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
void logger_output(int level, const char *tag, int line_num, const char *fmt, ...)
{
    static char buf[LOG_BUF_SIZE];

    va_list args;
    int idx = 0;
    uint32_t tick = sys_get_time();

    level = MATH_MAX(0, level);
    level = MATH_MIN(level, ARRAY_SIZE(LEVEL_PREFIX) - 1);
    idx += snprintf(buf + idx, sizeof(buf) - idx, "[%lu.%03lu] [%s:%d] %s",
            tick / 1000, tick % 1000, tag, line_num, LEVEL_PREFIX[level]);

    va_start(args, fmt);
    idx += vsnprintf(buf + idx, sizeof(buf) - idx, fmt, args);
    va_end(args);

    idx += snprintf(buf + idx, sizeof(buf) - idx, "\r\n" NOR);

    drv_uart_send(&dbg_uart, buf, idx);
}

其他级别的日志接口，如LOG_I，LOG_W等，日志接口的详细实现与使用示例，参见笔者基于stm32f407创建的demo工程：

地址：https://gitee.com/njupt_elec/demo

代码：utils/logger.h, utils/logger.c

调用示例：examples/01_log/example.c，使用时需要打开examples/examples.h中的EXAMPLE_SHOW_LOG。

下图为examples/01_log/example.c的效果，想要看到彩色的日志的话，可使用Tera Term或SecureCRT这两款串口软件。image-20210804204257516

转载原文链接：https://mp.weixin.qq.com/s/bnubhKoyIIfGxyvG0G8dhw

展开全文 >>

tag:

    缺失模块。
    1、请确保node版本大于6.2
    2、在博客根目录（注意不是yilia-plus根目录）执行以下命令：
    npm i hexo-generator-json-content --save

    3、在根目录_config.yml里添加配置： 

      jsonContent:
    meta: false
    pages: false
    posts:
      title: true
      date: true
      path: true
      text: false
      raw: false
      content: false
      slug: false
      updated: false
      comments: false
      link: false
      permalink: false
      excerpt: false
      categories: false
      tags: true

从事嵌入式开发