明确目的以及不要过早优化

  上周的嵌入式实验课做了一个关于ADC的实验,即用从5V中用变阻器分出一部分电压,用ADC采样量化作为输入信号,要求是使LED闪烁频率随这个信号限值(包括上限A和下限A)的幅度的增大而变快。

  设输入信号幅度是A,一个思路是用延时,A-A 
越大,两次亮灯之间的延时越小,这样也就是闪得越快了。低于下限的时候同理。不过这篇随笔主要不是讲这个思路有多好(一般都能想到这个思路),而是要说它的实现。

  

  先说说当时是怎么做的吧。。由于已经给了例程,一般情况下为了图方便省事是直接修改,或者调用里面的函数(而且是只看接口不看内部)。一般情况下都有这么一个Delay的函数

<main.c>中


extern __IO uint32_t TimingDelay;

void Delay(__IO uint32_t nTime)
{
TimingDelay = nTime;

while(TimingDelay != 0);

}

在写中断源文件<stm32f10x_it.c>中


__IO uint32_t TimingDelay = 0;

void SysTick_Handler(void)
{
TimingDelay--;
}

当然还要配置SysTick,打开定时器,这样才能进入SysTick_Handler中断

可是上面这些都配置好了以后,这个Delay函数只能在main.c 中调用,但问题是 LED亮灭(闪烁)本身就是在中断里面完成的


void ADC1_2_IRQHandler(void)
{
/* Toggle LED1 */
STM_EVAL_LEDOn(LED1);
printf("interrupt occur\r");
STM_EVAL_LEDOff(LED1);
printf(" \r");

/* Clear ADC1 AWD pending interrupt bit */
ADC_ClearITPendingBit(ADC1, ADC_IT_AWD);
}

如果在stm32f10x_it.c中调用Delay,即


void ADC1_2_IRQHandler(void)
{
/* Toggle LED1 */
STM_EVAL_LEDOn(LED1);
Delay(500);
printf("interrupt occur\r");
STM_EVAL_LEDOff(LED1);
Delay(500);
printf(" \r");

/* Clear ADC1 AWD pending interrupt bit */
ADC_ClearITPendingBit(ADC1, ADC_IT_AWD);
}

显示结果就是灯一直亮,也就是说进入
Delay(包括SysTick)以后就出不来了。。再转电位器也无济于事。这其中可能有很多原因,比如中断嵌套,优先级,标志位或者什么地方没有设置好,反正就是得不到想要的结果。由于机房的环境以及时间捉急(还有没法上网百度谷歌),越搞越搞不出来。

(下面才是本文重点要说的)

  这时候朱哥提醒了我,要不用for循环来做延时得了。一试如梦初醒茅塞顿开!然后一下子有了很多想法(主要是反思)思维又被限制了好吗!

来整理一下:

1.


//说明:ADC给过来的值的范围A是0~4096,A是2816,A是768
//   系统晶振是25M
//   3000是放大因子

void ADC1_2_IRQHandler(void)
{
/* Toggle LED1 */
int i=0;

STM_EVAL_LEDOn(LED1);
if(ADC_GetConversionValue(ADC1)>2000){
for(i=ADC_GetConversionValue(ADC1)*3000;i<12500000;i++);
}else{
for(i=(2000-ADC_GetConversionValue(ADC1))*6000;i<12500000;i++);
}
printf("interrupt occur\r");

STM_EVAL_LEDOff(LED1);
if(ADC_GetConversionValue(ADC1)>2000){
for(i=ADC_GetConversionValue(ADC1)*3000;i<12500000;i++);
}else{
for(i=(2000-ADC_GetConversionValue(ADC1))*6000;i<12500000;i++);
}
printf(" \r");

/* Clear ADC1 AWD pending interrupt bit */
ADC_ClearITPendingBit(ADC1, ADC_IT_AWD);
}

试验效果OK,达到要求。

2.

  刚学51的时候,郭天祥老师的书上教了两种延时的方法:可以直接在其中用for循环来耗掉时间,这种方法中间不能做其他事,而且不是很精确;


//<新概念51单片机C语言教程>中用来延时n毫秒的方法
//当然也可以只用一个for
void delay_ms(uint n)
{
uint x,y;
for(x=0;x<n;x++)
for(y=0;y<120;y++);
}

也可以用中断来实现,这样可以在期间做其他事情,既保证了效率又可以更精确计时。

  但是,并非所有场合都必须要用中断!在要求不高(时间精度或者功耗要求等)的场合,for延时够用了!简单方便,测试看延时的效果够用了。

要把学过的东西融汇贯通,思维不要被约束和限制,明确目的!这里的目的首先是要达到要求,其次才是看你会不会正确用中断什么的

3.

3.1

  《黑客与画家》的译者总结,原著作者Paul Graham有一套完整的创业哲学,他的创业公式是:

  (1)搭建原型

  (2)上线运营(别管bug)

  (3)收集反馈

  (4)调整产品

  (5)成长壮大

  Paul
Graham还指出,不要过早优化你的产品,在这次实验中也有异曲同工之妙。先完成作业要求,而不要一开始就想着出一个完美的作品,然后再进一步优化,至少在完成要求后心态更好头脑清晰不会有焦虑之急,有利于优化工作的进行。

3.2

  看上去更近的路不一定是捷径(比如直接从另一个工程里面把与Delay函数有关的的抄过来,在这里就是用不了),绕远路可能更快,这样的例子在生活中很常见。

  至少需要先思考一下再行动,大脑这个智能CPU不是白给的。

  

明确目的以及不要过早优化

时间: 2024-11-07 19:49:56

明确目的以及不要过早优化的相关文章

【开发模式】项目过早优化现象:处女座专属鸡汤

最近在Coursera上看机器学习,顺便梳理了下算法体系. 其中Andrew Ng就有提到一个"过早优化"的观点非常喜欢:         与其将大把时间花费在挑选学习算法.更换模型上,然后花费6.7个月收集数据,(潜台词:这是愚蠢的做法,bad idea) 不如         凭直觉先随意挑个算法.用少量数据在1,2天内进行实现,然后通过学习曲线.误差分析来调整这个学习算法,并判断特征是否足够区分,是否需要加入新的特征变量,直到有证据表明目前特征适合且只欠缺样本量/数据后再开始收集

过早优化是万恶之源

今天早上考虑了一些问题,觉得有些地方按自己的设想会导致效率下降,如果改了可能把自己的架构搞乱.纠结了半天,领悟到这么一点: 架构.设计完成后,就这样做,觉得有地方可以修改,可以记录下来,以后优化时再修改.因为按照自己的架子来搭建程序的话,开发效率会很高,后期汇总了所有可优化的地方,再来修改也会很有针对性.如果一边写,一边改,一方面是让开发效率下降,还可能让自己的设计思路变得混乱,严重可能导致错误,甚至停止不前.所以,优化一定放在最后再来做!!! 同时,看lua文章时,看到一句话: Knuth有句

nginx之旅(第六篇):nginx优化--nginx优化目的、工作进程优化、长连接设置、数据压缩、客户端缓存

一.Nginx优化目的 标准情况下,软件默认的参数都是对安装软件的硬件标准来设置的,目前我们服务?的硬件资源远远大于要求的标准,所以为了让服务?性能更加出众,充分利用服务?的硬件资源,我们一般需要优化APP的并发数来提升服务器?的性能. 二.工作进程优化 1) worker_processes worker_processes指Nginx的工作进程,这个值是直接受到服务器CPU核数量影响的(当然也有其他影响),Nginx默认配置为auto,意思是会自动检测CPU核做修改,建议worker_pro

Java性能优化指南系列(一):概述和性能测试方法

Java性能分析是一门艺术和科学:科学指的是性能分析一般都包括大量的数字.测量和分析.绝大多数的性能工程师都有科学背景,运用科学的严谨是获取最大性能的重要组成部分.艺术部分指的是什么呢?性能调优是部分科学部分艺术的观点是很早就有的,但是关于性能的主题很少会给定特定的知识,这就是艺术的部分了,它和我们平常接受到的培训是不一样的,培训是确定了的.还有部分原因是对于某些人来说,性能调优是建立在深入的知识和经验上面的.这里艺术就是知识.经验和直觉的使用. 这本书不能帮助我们提升经验和直觉,但是可以帮助我

GPU 优化总结

前面说了对我这一年多的工作进行一个总结,由于工作比较紧,加上本人比较懒,一直没能抽出时间来写,最近稍微闲下来了.先写一篇GPU优化的,后续的文章希望能慢慢补齐.这些基本都是我个人优化的实际经验,也参考了一些文章,我都放在后面引用 部分了,感兴趣的可以深入研究.个人理解可能有问题,如有不正确的还请指正,下面进入正题. 由于图形引擎的复杂性,瓶颈可能发生在CPU.GPU.,也可能发生在CPU与GPU的传输数据与交互之中.这里我们只假设瓶颈在GPU上,讨论GPU的优化方法. Premature opt

性能优化指南:性能优化的一般性原则与方法

作为一个程序员,性能优化是常有的事情,不管是桌面应用还是web应用,不管是前端还是后端,不管是单点应用还是分布式系统.本文从以下几个方面来思考这个问题:性能优化的一般性原则,性能优化的层次,性能优化的通用方法.本文不限于任何语言.框架,不过可能会用Python语言来举例. 不过囿于个人经验,可能更多的是从Linux服务端的角度来思考这些问题. 本文地址:http://www.cnblogs.com/xybaby/p/9055734.html 一般性原则 依据数据而不是凭空猜测 这是性能优化的第一

程序优化

在大的系统,或者或者需要处理大量数据的系统中,我们需要关注产生性能瓶颈症状,这些问题再规模上会影响app的响应性,如装箱操作.字符串操作.LINQ和Lambda表达式.缓存async方法.缓存缺少大小限制以及良好的资源释放策略.使用Dictionay不当.以及到处传递结构体等.在优化我们的应用程序的时候,需要时刻注意之前提到过的四点: 不要进行过早优化——在定位和发现问题之后再进行调优. 专业测试不会说谎——没有评测,便是猜测. 好工具很重要.——下载         PerfView,然后去看

唯快不破:Web 应用的 13 个优化步骤

时过境迁,Web 应用比以往任何时候都更具交互性.搞定性能可以帮助你极大地改善终端用户的体验.阅读以下的技巧并学以致用,看看哪些可以用来改善延迟,渲染时间以及整体性能吧! 更快的 Web 应用 优化 Web 应用是一项费劲的工作.Web 应用不仅处于客户端和服务器端的两部分组件当中,通常来说也是由多种多样的技术栈构建而成:数据库,后端组件(一般也是搭建在不同技术架构之上的),以及前端(HTML + JavaScript + CSS + 转译器).运行时也是变化多端的:iOS,Android,Ch

web 前端优化-戈多编程

大家好,我是戈多,从事web开发工作接近三年了,今天来归纳下web前端优化的解决方案(码农搬砖工,来自各网络汇总) 1.减少Http请求 http请求越多,那么消耗的时间越多,如果在加上网络很糟糕,那么问题就更多了.且如果网页中的图片.css文件.js文件很多甚至有音乐文件时,这势必会造成负担. (1)图片地图 即多个图片排成一行作为链接到其他页面的按钮,我们当然可以使用五福图片,发送5个http请求,但是这是不合适的. 我们可以选择使用图片地图,即只用一张图片,然后使用<map>属性通过控制