问题背景
最近有一个新项目（车载项目），板子上除了原来的ARM + STM32F030K6Tx又多了一个8bit的mcu的单片机，这可真是嵌入式全家福了。
系统的主要核心工作是由arm来完成，但是在开机早期及休眠、唤醒等过程是由stm32来控制完成的。
开机过程中的ACC打火检测、高低压检测，同时也是为了保证休眠的时候整块板子的的低功耗（休眠时只有rtc有电及stm32处于深度休眠，其他全部掉电）。
最近添加了一颗tw8836mcu，主要是为了快速开机出预览，因为我的linux系统开机起来出摄像头预览需要11s左右，客户需求开机2s内出预览画面，
这种速度只能依赖屏驱芯片（或者更换成rtos）来实现，所以我们又多了一颗屏驱芯片，其作用就是在上电开机的时候快速输出摄像头预览，等arm开机起来之后接受来自arm的lvds信号切换显示arm输出的内容。
考虑到开发费用，没有采用由芯片厂来完成tw8836的程序开发的合作方式，有考虑到开发时间问题，也没有自己去重新学习这块mcu的编程，而是通过iic方式刷参数实现。
开机第一阶段
stm32通过iic给tw8836刷参数，显示摄像头数据，然后交出tw8836的控制权
开机第二阶段
arm启动完成，由arm通过iic给TW8836刷参数，显示arm输出的lvds信号。
在我开始写stm32代码之前，公司有一份成熟的代码实现的是开机、休眠、唤醒、升级等功能，这部分代码已经有人一直在维护。
我需要完成的是加上tw8836这部分功能，以及lcd的控制逻辑。
代码模块有以下：
1、iic通讯，由于所接的两个io口不是硬件iic，所以需要写一个模拟iic通讯。
2、部分io口控制功能。
3、pwm控制lcd背光亮度。
4、光感模块的adc值检测。
为了避免新功能与旧逻辑的干扰，我这边没有在他们的代码基础上去修改，而是重头写了一份全新的，待我验证ok后再交给另外一个维护的同事合并验证。
————————————————————————————————————————————————————————————————————
上周五把验证ok的代码交给同事合并验证，搞了一天说跑不了，用在线调试，经常停在某处不返回，没办法这周叫他吧整个工程代码撸过来瞧一瞧。
经过调试验证确实后莫名死在某处不出来，不知道是掉坑里了还是逛窑子去了。
有以下几个地方会无返回，也有可能还会有其他地方。
RCC_AHBPeriphClockCmd(RCC_AHBPeriph_GPIOB, ENABLE);
/* * 函数名：Delay_5us * 描述: 5us延时函数 单位为5us * 输入： nTime * 输出：无 * 调用： Delay_5us(1)实现的延时为5us * 外部调用 */ void Delay_5us(__IO uint32_t nTime) { TimingDelay = nTime; while(TimingDelay != 0); }
/*
* 函数名：TimingDelay_Decrement
* 描述：获取节拍程序
* 输入：无
* 输出：无
* 调用：在SysTick 中断函数SysTick_Handler()调用
*/
void TimingDelay_Decrement(void)
{
if (TimingDelay != 0x00)
{
TimingDelay--;
}
}
这些诡异的不返回和滴答定时器的初始化使能有关。
/* * 函数名：SysTick_Init * 描述：配置并启动系统滴答定时器SysTick * 输入：无 * 输出：无 * 调用：外部调用 */ void sys_tick_init(void) { RCC_ClocksTypeDef RCC_Clocks; RCC_GetClocksFreq(&RCC_Clocks); /* SystemFrequency / 1000 1msÖжÏÒ»´Î * SystemFrequency / 100000 10usÖжÏÒ»´Î * SystemFrequency / 1000000 1usÖжÏÒ»´Î */ if (SysTick_Config(/*SystemCoreClock*/RCC_Clocks.HCLK_Frequency / 200000)) // ST3.5.0¿â°æ±¾,5us/tick { /* Capture error */ while (1); } }
我的代码系统时钟是采用pll倍频道72M的，滴答定时器原始的中断函数如下：
/** * @brief This function handles SysTick Handler. * @param None * @retval None */ void SysTick_Handler(void) { TimingDelay_Decrement(); }
旧代码系统时钟没有配置，采用默认的48M，合并代码后采用了我这边的时钟配置，提高到72M。
旧代码systick中断是设置的1ms一次，合并后采用5us的中断（因为模拟iic需要用的us级别的精准延时函数），
最终合并了旧程序的逻辑后中断函数变成了如下，增加了一大堆用来做状态机的标志：
/** * @brief This function handles SysTick Handler. * @param None * @retval None */ void SysTick_Handler(void) { TimingDelay_Decrement(); sysTickCtrl++; /* 2MS LOOP */ if(!(sysTickCtrl%COUNT_2MS_MAX)) { F_SYS_2MS=1; } /* 4MS LOOP */ if(!(sysTickCtrl%COUNT_4MS_MAX)) { F_SYS_4MS=1; } /* 8MS LOOP */ if(!(sysTickCtrl%COUNT_8MS_MAX)) { F_SYS_8MS=1; } /* 12MS LOOP */ if(!(sysTickCtrl%COUNT_12MS_MAX)) { F_SYS_12MS=1; } /* 12MS LOOP */ if(!(sysTickCtrl%COUNT_40MS_MAX)) { F_SYS_40MS=1; } /* 100MS LOOP */ if(!(sysTickCtrl%COUNT_100MS_MAX)) { F_SYS_100MS+=1; } }
于是上面所述的诡异问题就产生了。
经过进一步验证，如果在初始化systick的时候设置中断时间大于10us程序就可以正常运行。
void sys_tick_init(void) { RCC_ClocksTypeDef RCC_Clocks; RCC_GetClocksFreq(&RCC_Clocks); /* SystemFrequency / 1000 1msÖжÏÒ»´Î * SystemFrequency / 100000 10usÖжÏÒ»´Î * SystemFrequency / 1000000 1usÖжÏÒ»´Î */ if (SysTick_Config(/*SystemCoreClock*/RCC_Clocks.HCLK_Frequency / 200000)) // ST3.5.0¿â°æ±¾,5us/tick { /* Capture error */ while (1); } }
想来想去不应该是中断频率太高导致的，由此想到了linux系统内核中的中断处理函数的几点说明。
内核里面的中断处理函数：
1、不能做延时delay操作。
2、不能做耗时过长的操作。
3、最好不用打印（调用printf打印其实也是很费时间的操作）
4、不能用死循环等待。
所以在内核驱动里面一般都是采用中断上下午来处理，中断上文唤醒处理线程，下午都在线程里干活。
这条铁律同样适用于单片机，即时——中断处理函数一定不能做耗时较长的操作。
现在中断函数里面进行了一大堆的取模运算，这是耗时比较长（相对而言）的运算。据此提出以下猜想：
中断函数耗时太长，在中断频率又高的时情况下占据了大部分cpu资源。
验证
将中断后面部分的操作屏蔽，将中断时间调整到5us 1us都没问题。
/** * @brief This function handles SysTick Handler. * @param None * @retval None */ void SysTick_Handler(void) { TimingDelay_Decrement(); sysTickCtrl++; /*only for test */ return; /* 2MS LOOP */ if(!(sysTickCtrl%COUNT_2MS_MAX)) { F_SYS_2MS=1; } ............. }
所以真音就是；中断函数耗时较长占据了大部分cpu。
解决方法：优化中断处理函数
——————————————————————————————
有关加减乘除运算耗时的说明：
了解汇编的人应该都知道加减乘除中的加减运算是比较快的，但是要实现乘除运算需要n多条指令才能实现，这是一种效率比较低下的操作，所以在可以的情况下尽量避免乘除运算，或者转换成效率较高的移位运算（<< >>）
例如
/*乘除预算装换移位运算 *、 num * 8 ==> num << 3 num / 8 ==> num >> 3
移位运算相对于乘除运算效率高的多得多。
2018年6月26
深圳南山科技工业园