时间触发系统中低速时序LCD如何操作?请傻孩子老师找个帖...

zyw19987

问题一：如题。详细如下
         1、比如液晶驱动有需要延时0.5MS这样的不足一般任务调度周期（10ms）时序改如何写底层？
         2、有朋友提议将这样的任务交给定时器中断处理，专门开一个定时器中断来处理这样的任务，开一个液晶对应的显示缓存，任务检测缓存数据有更新就刷屏。

问题二：前段时间看到论坛有一兄弟在研究这方面的东西，由于论坛现在搜索功能的现状，找了很久都没找到（唉！！！），该帖子里有傻孩子老师的指点（推荐了基本武功秘籍）谁知道这一帖子的兄弟在此留个地址，谢谢。

zyw19987

怎么看的人都没有呢？

cmdrainsy

0.5ms的延时相对10ms是可以接受的

zyw19987

cmdrainsy 发表于 2012-8-3 23:47
0.5ms的延时相对10ms是可以接受的

   如果是操作液晶屏，一个数据就需要0.5ms，对于一个12864的屏就有1024个数据，这个时间就不知道怎么处理了。对于这一类底层驱动在时间触发系统中是怎么处理的呢？

Gorgon_Meducer

不好意思现在才恢复你。虽然根据你提供的信息我暂时无法找出是哪个帖子，但我觉得根据你说的情况
结论应该是比较清楚的，既然操作系统是10ms显然只能在当前任务里面进行延时，并且要注意在延时
期间屏蔽系统调度。其实我关心的是，楼主为什么要问这个延时问题呢？我觉得你提供的问题后面可能
还有问题，否则直接屏蔽调度然后while算周期也不是难事。

zyw19987

Gorgon_Meducer 发表于 2012-8-6 22:01
不好意思现在才恢复你。虽然根据你提供的信息我暂时无法找出是哪个帖子，但我觉得根据你说的情况
结论应该 ...

一直在等傻孩子老师的出现，你猜的是对的。其实我问的问题是困扰我学习时间触发系统的“一类问题”并不是一个问题；
这一类问题存在的原因是：
1、现在的CPU速度是相当快，快到对于很多周边IC来说是“高速”尤其是对于通信时序要求比较高的；
2、既然想跑系统（应该也算不上是系统，只是一个多任务的调度器而已），肯定不允许while（1）；这样的写法；
3、既然是多个任务在跑，肯定不允许while（1）；因为很可能多个任务底层都有“低速”IC；
因为对系统，以及调度器等技术都是初学者，上面很可能有言词不正确的，请见谅；
不知道是否形容清楚我的问题所在

zyw19987

/********************************************************************************************************
*  Function: Ht9200SndByte                                                                                           
*  Object: 写入DTMF数字
*  输入： 待拨数字 123456
*  输出： 无                                              
*  备注:  将num的低5位发送出去，先发低，后发高
********************************************************************************************************/
void Ht9200SndByte(const unsigned char num)   
{   
   static unsigned char i,temp;
        temp = num;   
    for(i=0; i<5; i++)   
        {   
            temp=(num >> i);
            if((temp&0x01) == 1)
                {HT9200_Data_(1);} //DTMF_Data_Bit = 1 ;
           else   
        {HT9200_Data_(0);} //DTMF_Data_Bit = 0 ;
        _nop_();
        _nop_();       
        HT9200_Clk_(0);//DTMF_Data_Clk = 0 ;                  
        _nop_();
        _nop_();            
        HT9200_Clk_(1);//DTMF_Data_Clk = 1 ;
        }      
}
/********************************************************************************************************
*  Function: Ht9200_Send_DTMF                                                                                           
*  Object: 拨一位号         in 为要发送的数 0-15
*  输入： 待拨号
*  输出： 无                                              
*  备注:  硬件操作HT9200，更改忙标志位DTMF_usend_busy 1ms调用
********************************************************************************************************/
void Ht9200_Send_DTMF(unsigned char ip)
{
    static unsigned char state=0; //两毫秒
   static unsigned int Delay=0;
    static unsigned char num;
        switch(state)
        {   
                case CE9200State:
                {
                        DTMF_usend_busy = 1;//开始忙
                        HT9200_Clk_(1);//DTMF_Data_Clk=1;  
                                     HT9200_OE_(0);//DTMF_Data_OE=0;
                        state++;
                        Delay=10;
                }
                //break;
                case TxDataState:
                {
                        DTMF_usend_busy = 1;
                        if(!--Delay)
                        {
                        if( ip=='0' )   
                                       num = 0x0a;   
                                else if( ip=='*' )   
                                       num = 0x0b;   
                                else if( ip=='#' )   
                                      num = 0x0c;   
                                else   
                                      num=ip-'0';
                        Ht9200SndByte(num);  //发送出去
                        Delay=100;                         //DTMF持续时间
                        state++;
                        }
                }
                break;
                case TxStopState:
                {
                        DTMF_usend_busy = 1;
                        if(!--Delay)
                        {
                                 Ht9200SndByte(0xff); //发送结束标志
                                Delay=80;                         //结束符持续时间
                                state++;
                        }
                }
                break;
                case EndCE:
                {
                        DTMF_usend_busy = 1;
                        if(!--Delay)
                        {
                                 HT9200_OE_(1);//DTMF_Data_OE=1;
                                 state=0;
                                 DTMF_usend_busy = 0;//闲
                        }       
                }
            break;
                default:
                        HT9200_OE_(1);//DTMF_Data_OE=1;
                        state=0;
                        DTMF_usend_busy = 0;//闲
                break;
        }
}

zyw19987

Gorgon_Meducer 发表于 2012-8-6 22:01
不好意思现在才恢复你。虽然根据你提供的信息我暂时无法找出是哪个帖子，但我觉得根据你说的情况
结论应该 ...

上面是我现在的做法，类似这类延时，该如何写这种底层的东西呢，我现在把这个“底层”的东西做成任务，应用层和这个底层得用队列的方式来通信；当系统中有很多这样的“底层”任务那就很麻烦了。真不知道该怎么做

owen.lee

可以自己分析優先順序, 若DTMF_send > LCD refresh > Key scan > etc .....那就超時吧. 也不過是20ms.
或是改了結構. 例如每次trigger, 就while(task()). 那state machine就可以很多變化. 可以多個wait_timer, wait_xxx. 然後state = next_state.
這個10ms就是sender專屬. 就算轉了一圈, 還是可以繼續處理.

多底層就看重不重要而以, 不然OS為何多個優先級. 能拖能拉的輪了一圈再處理. 急的趕的拆不開的一次搞完.
底層用了state machine, 那你的app layout呢? 也搞一個machine?? 是不是太複雜了.

我翻了一下HT9200 DTMF datasheet. 似乎延時要求不大啊.
而且可以傳送Multi Bytes. 應該可以再改善流程.

既然要用state machine. 那麼state應該要明確指示.
state++; 指誰??????
state = TxStopState;

state = 0;
state = CE9200State;


唔, 去看看pthread.

zyw19987

owen.lee 发表于 2012-8-7 22:46
可以自己分析優先順序, 若DTMF_send > LCD refresh > Key scan > etc .....那就超時吧. 也不過是20ms.
或是 ...

//拨号状态
enum{
        CE9200State,
        TxDataState,
        TxStopState,
        EndCE                
       };

owen.lee

今天你會用 state++;
明天你就會用state--;
下週你就會用 state +=2;
明年你就會用 state/3 + idx;
如果你能理解什麼叫簡單直觀明瞭, 那也沒必要放出enum了.
為什麼會用OS? state machine? time driven? event driven? 還不就為了簡單直觀.

再挑個骨頭.
我認為初始化是件很非常重要的事.
CE9200State = 0,

zyw19987

owen.lee 发表于 2012-8-8 15:56
今天你會用 state++;
明天你就會用state--;
下週你就會用 state +=2;

给点实际思路啊，暂时还没有那么全面的规划能力；

owen.lee

你曾分析過每個task運行所需時間嗎??
為什麼要用10ms為間隔?
是因為大家都如此? 或是符合需求??

時間觸發設計模式, Chapter 14, 合作式調度器, 有詳細的時間規劃說明.
或是修改SCH_Dispatch_Tasks()配合task.
方法很多, 看你怎麼發揮想像力了.

Gorgon_Meducer

一旦底层用了状态机，基本上上层也必须是状态机了。
如果是全状态机开发，根本不需要多余的10ms问题……并不是所有任务都是基于时间来触发的。
你应该把所有任务的触发源弄清楚，该时间触发的就用定时器中断来动态生成一个任务或者设置
信号量；不该时间触发的就根据对应的事件来动态生成任务或者设置信号量。

zyw19987

Gorgon_Meducer 发表于 2012-8-9 10:37
一旦底层用了状态机，基本上上层也必须是状态机了。
如果是全状态机开发，根本不需要多余的10ms问题……并 ...

感谢你的指点，帖子我找到了。http://www.amobbs.com/forum.php? ... B%E5%AD%A9%E5%AD%90，问题移植到这帖子里去讨论。

eddia2012

我的用法是：状态机+时间触发

zyw19987

eddia2012 发表于 2012-10-17 09:43
我的用法是：状态机+时间触发

当一些低速时序中也用状态机的话，哪就很复杂了。

Gorgon_Meducer

zyw19987 发表于 2012-10-17 09:50
当一些低速时序中也用状态机的话，哪就很复杂了。

非也，非也。状态机开发有他自己的方法论，不能用普通的开发思维和工具去看待——看起来复杂，其实用专门的方法和手段，还是很简单的。

zyw19987

没找到合适的例子，一直没学会。

Etual

问题貌似还没有解决。

zyw19987

Etual 发表于 2012-11-13 14:31
问题貌似还没有解决。

是的，你有好的方法吗？

Etual

我正想来求好办法 ...... 最简单的办法就是2个CPU，主CPU搞主任务，计算什么的，用rtos，次CPU主要做外设的处理，例如按键扫描，LCD刷新等操作 ....

又或者直接死等算了。这里什么架构都不要用，对于液晶显示的情况，慢慢送数据就是了，100ms扫描完也没问题。重点是处理好实时事件，用中断。

mcu_lover

Etual 发表于 2012-11-13 17:00
我正想来求好办法 ...... 最简单的办法就是2个CPU，主CPU搞主任务，计算什么的，用rtos，次CPU主要做外设的 ...

你的想法是对的。
对于GUI 以及按键接口应该放到一个MCU里面来做。
以前MCU比较贵，现在便宜，资源丰富，用一个MCU专门做人机交互，正是时候，这也是我思考几年的一点想法。
现在正在研发基于MCU的接口设计。用一颗通用MCU负责驱动液晶，按键等等。
所有界面都可以直接在上位机上完成，另外负责交互的MCU可以提供宏功能。对外可以提供RS232 SPI I2C 等接口。
可以大大缩短开发时间，你需要的只是增加一个MCU的成本，不到十块钱。
十块钱可以将你彻底解放出来，对UI的操作，如同操作一个简单的外设，仅此而已。

Gorgon_Meducer

mcu_lover 发表于 2012-11-13 21:47
你的想法是对的。
对于GUI 以及按键接口应该放到一个MCU里面来做。
以前MCU比较贵，现在便宜，资源丰富， ...

听起来类似南北桥啦。为1.5$的解放，顶！

Etual

mcu_lover 发表于 2012-11-13 21:47
你的想法是对的。
对于GUI 以及按键接口应该放到一个MCU里面来做。
以前MCU比较贵，现在便宜，资源丰富， ...

所见略同，双CPU编程问题不大，只是生产有点麻烦

fengyuganyu

我认为在目前嵌入式行业，对于拥有OS的MCU去控制实时性比较强的外设，无疑是比较苦恼，我们要用过多的信号量、互斥量和任务管理来实现，这样会加重产品的
程序架构，导致很多莫名奇妙的BUG。使用双MCU来处理，可以大大减少隐患和实现分模开发，减少开发周期。我已经用这种双MCU方案开发有几年了，效果还是很不错。

zyw19987

fengyuganyu 发表于 2012-11-14 08:48
我认为在目前嵌入式行业，对于拥有OS的MCU去控制实时性比较强的外设，无疑是比较苦恼，我们要用过多的信号 ...

你做什么产品啊，都是双核？