2005年08月03日

    上海华为把我给据了,可以分析的出其中的道理。面试的时候我的策略不大对头。惨啊5555555苦天抢地啊。我还是要继续找。这点是肯定的。

2005年07月29日

    不知道lp明天是否来的成。看着她又感冒又肚痛,真不忍心让她再在户宁线上煎熬6个多小时。而且真来了,在一起的真实时间也不过27个小时左右,分隔两地的不便可想而知。什么是距离,这个就是。
    华为不知道什么时候可以给答复。真去了,就得折腾一番。不过这样距离就可以消失。
    这个礼拜可以说比较郁闷,以前在实验室可以说基本没有什么压力。可工作了,自然而然得产生不少压力。smtpbatch其实花了我很少得时间,关键是以前他们得client和server实在写得乱得可以,费了我不少神。害得我只能把代码mail回家看。工作了,可不能象以前在实验室里那么混那么自由了,为了养活自己,为了学更多得东西要开始摆正自己得位置。
    今天down到TUN得代码(UML-user mode linux 中使用得用户层虚拟网卡设备。最近老板让看UML,可能他想用UML来测loadbalance内核部分,天知道他得内核搞定没,一定要抓个机会学点),看起来想LDD2中net虚拟设备,周末好好研究研究。主要是把linux协议栈弄弄清楚。还有就是继续看《计算机网络》,玩玩UML。
    下周应该发工资了。恩,第一份工资要用得有意义!

2005年07月02日

找工作要求高,我是出了名了。现在报应来了,去了lucent被安排在实验室做安装,调试,维护机器。我快疯了。看来要继续找工作了。报应啊报应。。。。。。大公司人多不重视人才啊。。。。

2005年04月17日

    还好,一切都从4/13日起有了转机。要不是触摸屏一开始就坏了,可能老张的自制控制器也可以跑了,心血也不用白费了,在这里仅代表项目组全体人员向老张同志默哀:)。
幸亏有了linux下的simulator帮我把前期的整个平台无关的代码跑成了,否则不知道现在会是个什么样。不过在虚拟器上跑的很正常的代码段,到板子上可能会出问题,这个大概是嵌入式开发最容易碰到的问题。一切都和时序,运行环境相关。
    现在我唯一有些遗憾的是LCD实在太差劲,显示效果极差,影响了GUI的演示效果。
    争取在这两天把演示程序完善一下,整理整理文档,搞定它!

2005年02月03日

移植UCOS到linux平台下倒是件费时的事情,本打算模拟一些API就行了,但google了一下,发现了这个移植版本。不错,省了偶不少力气。



address: http://www.it.fht-esslingen.de/~zimmerma/software/uCOS-II_LINUX.htm

Linux Port internals and Limitations

  • Task Scheduling

As LINUX does not allow application programs to bypass its own scheduler or provide
their own timers and interrupt handlers, uCOS-II scheduling and task managment functions
must be remapped to LINUX functions.

该移植版本并不是象for win32的移植版本那样有真实的时钟中断,而是将uCOS的调度及任务管理影射到linux本身的函数之上。可以看出来,该移植版本作了不少的内部手术。

The LINUX port is based on the WIN32 port of the same author, so in many points
a solution, which allowed to make the WIN32 and LINUX port match as closely as possible
instead of a more elegant LINUX solution was chosen. The WIN32 port uses WIN32 threads,
which are suspended and resumed via WIN32 API functions and scheduling is triggered by
WIN32 events. The LINUX port uses the same mechanisms with the system call clone() to
create threads and LINUX signals instead of WIN32 events.

LINUX 移植版本利用线程作为虚拟的进程,利用signal作为激活调度的出发事件。

uCOS-II tasks are mapped to LINUX threads. The mapping is done, when a task
is created in OSTaskCreateHook(). Additionally two special LINUX threads OSScheduleThread()
for thread scheduling handling and OSInterruptThread() for interrupt handling
are created in OSInitHookBegin(). The scheduling and the interrupt thread are created
with the a higher LINUX process priority. The threads associated with uCOS-II tasks
are created with a lower priority and set to suspended state (via signal SIGSTOP).

uCOS的任务被当作LINUX的线程,任务的调度则由OSScheduleThread函数负责,中断管理由OSInterruptThread管理。uCOS的任务在创建后,被作为最低优先级的挂起线程(SIGSTOP信号实现)

When the uCOS-II scheduler preempts a task and wants to switch context to a new uCOS-II task,
the uCOS-II context switch function OSCtxSw() or OSIntCtxSw() triggers the scheduler thread
via a signal hScheduleEvent (=SIGCONT). Because the scheduling thread OSScheduleThread() has
a higher LINUX priority than all the WIN32 threads associated with uCOS-II tasks, LINUX will
start the scheduling thread immediately. This thread will suspend the LINUX thread
associated with the preempted uCOS-II task and resume the LINUX thread
associated with the new uCOS-II task. Then the scheduler thread will wait for the next scheduler
event (via system call pause()). So always exactly one LINUX thread associated with a uCOS-II task will be ready to run,
all other uCOS-II task associated threads will be in LINUX suspended state. Thus this LINUX thread
will be invoked by the LINUX operating system’s internal
scheduler, once the OSScheduleThread() waits for the next scheduling event, and will remain running
until the uCOS-II scheduler is invoked the next time and retriggers the OSScheduleThread().

  • Time Tick Interrupts

To generate the uCOS-II time tick, a LINUX timer is used. Theoretically this timer
provides a 10ms resolution (LINUX internal time tick). Therefore
your application should set OS_TICKS_PER_SECOND to not more than 100 ticks per second (i.e.
to a tick period of 10ms min.). The timer will be started automatically via OSStartHighRdy()
and OSTimeTickInit(), once your application starts uCOS-II multitasking by calling OSStart().

关键的是时钟中断,也就是控制抢占内核行为的核心驱动,在该移植版本里利用LINUX的定时器实现。ticker为10ms。

LINUX periodically invokes a the signal handler OSTimeTickCallback() for the timer signal SIGALARM,
which triggers the signal hInterruptEvent. Due to this signal, LINUX immediately invokes
the interrupt thread OSInterruptThread(), because this thread has a higher process
priority than all uCOS-II task related threads. As expected by uCOS-II, the interrupt thread
calls OSTimeTick(), which may reschedule another uCOS-II task. Then the interrupt thread
waits for the next interrupt event.

uCOS-II’s critical sections normally disable interrupts. LINUX application programs, however,
cannot disable interrupts. This issue is resolved by LINUX suspending the interrupt thread
instead, once a uCOS-II critical section is entered by OS_ENTER_CRITICAL().

  • Limitations

uCOS-II provides several hook functions to allow applications to modify the uCOS internal
behaviour. Some of these hook functions are used to interact with the LINUX operating
system in the LINUX port. Thus the following hooks MUST NOT be used by your application:

	    OSInitHookBegin(), OSTaskCreateHook(), OSTaskIdleHook()

If your application must execute own code when uCOS-II calls these hooks, you should
add this code in file os_cpu_c.c. The appropriate points are marked in the code by

	    //ADD YOUR OWN HOOK CODE HERE IF NECESSARY

All other hook functions can be redefined by your application directly if you set OS_HOOKS_EN = 0,
as described in the uCOS-II documentation.

uCOS-II tasks are mapped to LINUX threads. These threads use their own LINUX stacks rather
than the ‘normal’ uCOS-II task stacks. Stack size
and stack management during context switches are automatically handled by LINUX. Nevertheless for
compatibility reasons, when a uCOS-II task is created, a uCOS-II stack must be provided. Only a few
bytes of this stack will be initialized, but this stack will not really be used by the running tasks.
If you plan to test your application under LINUX and then port it to an embedded system, you
***CANNOT*** use the LINUX simulation to find out the necessary stack size. Your uCOS-II LINUX application
should not rely on the uCOS-II stack checking and clearing functions and should not use
any stack related programming tricks.


每个任务的指定STACK,在移植版本中意义不大,因为每个任务都是一个线程,有自己的线程堆栈,并由LINUX控制。


2005年01月29日

长达4个月的漫长的找工作历程到1.19号截止了。至于是9月几号开始动手做简历的,我已记不起来了。反正是为了瑞晟。1.19号我接到lucent的电话后,我才完全的放松了下来。
    9月的瑞晟、10月的MS笔试、凌阳面试、trend笔试、lucent面试,11月的trend面试、华为的面试、华为3COM的笔试、神游面试、中兴笔试面试,再到12月的雅讯面试、LG面试、启基面试、clearpipe面试,最后到1月的clearpipe再面,安讯面试。走过了那么多场子,经历了那么多次笔试、面试。多的我都有点遗忘了。当然成果还是不错的,拿到的offer有:凌阳、trend(该死的,黄了!不说了)、lucent(卖给它了)、华为、神游、雅讯、启基、clearpipe、安讯。最满意的是lucent和trend还有华为。
    但也有很多的遗憾。trend应该是最大的一个。雅讯其实是个很对口的,我很喜欢的工作,但地点实在不好。clearpipe搞定的好像太轻松了,而且自己要价低了,但职位挺喜欢。华为南研所放弃了。
    还有很多的不顺和苦恼。当然最大的是trend的跳票!害得我等它等的放弃了很多,包括MOTO、华为、华为3COM、西门子。lucent的拖踏的录用方式,从10月底一直到现在!freescale及瑞晟对本科生的拒绝!
    当然最终的结果还是满意的。留在南京,独立生活上几年,对于老是依赖家庭心智低下的我来说未必不是件好事情!

其实GUI的基本骨架中,GDI的调试是最为轻松的,而且也是最为重要的。GDI的调试好坏直接关系到今后的USER层的调试。毕竟动态的窗口管理及事件处理没有GDI的外部表现,实在是一头扎进了数据堆里,调试时爬也爬不出来啊。
    原先计划是让zzzzzz和沈一起做在WINDOWS下的simulator。但发现,一个是WINDOWS下的项目管理实在太糟糕了,对于层的测试(需要不断调整项目工程的数据结构及文件结构)VC或者其他IDE都力不从心,最重要的是我们的API是和WINDOWS WIN32基本兼容,当然防止重定义就是个非常麻烦的事情!还有就是我极度想玩玩linux下的program。所以在作了可行性评估后,马上接手这个事情,让沈调试TOUCH PANEL去。在linux下写个simulator测试,直接用makefile控制项目结构轻松的一腿,再加上Xlib的仿真LCD,效果非常棒!
    直到今天为止,GDI的测试完成。测试中暴露了很多问题,大多都是某些特殊结构在普遍结构处理中未特殊化,或者数据的有效性为ASSERT,这些可能是我写程序那么多年的通病了,就是不细心,考虑不周。逻辑问题其实没有多少。一切似乎比较顺利。接下来开始搞定Message Engine,这个东西又要像测试region和clipping那样分析数据了。
    真的是没有测试经验,应该有很多测试方法,至少有些捷径能走,偶都不知道。测试手段比较原始。不过一边测,一边学习GDB及MAKEFILE的编写,挺有乐趣的。
    linux下开发和WINDOWS大相径庭,暂且不说用kdevelop这种IDE的开发。一个vim,一个gdb和make完全够用(有时可能要CVS,diff),节俭、方便。项目结构一个makefile就可以清晰表示,vi+ctag+make直接查询函数连接,编译错误定位,编译都可以搞定。而且项目结构调整实在是轻而易举。一个字,爽!
    马上测消息引擎了。希望能顺利!

2004年11月30日

不知道感冒意味着什么,自从我开始正式加入找工作这个团伙时,我就一直象个瘟鸡一样的感冒,期间有几天的好转,不知何时又不停的咳嗽……自从10.7号放假回来我就没有歇过,微软、东软、凌阳、lucent、华为、趋势、神游、诚挚、中兴、盛大……我已经开始觉得疲倦了,不是因为没本事,拿不到offer。而是百般挑剔,眼光高。其实这样也没什么不对,毕竟宁缺勿烂,自我向往才行。到现在整整2个月过去了,我依然没有兑现早点卖身的承诺,依然在混沌中等待,依然笔试、面试,但以无先前那种热情。
我搞不清楚这样能算顺利吗?很多人都羡慕我这样的情况。但我不,正因为这样,我陷入了尴尬的境地:我委婉的拒了凌阳;华为南研说给我留个位置,而我把他当作保底;中兴如果不给研发,拒;lucent本本的offer还没发出,希望挺大,我期待;趋势要等下礼拜才有正式结果是否录取我;神游这个礼拜4也才有结果;盛大不知道给不给面试机会……找工作的战线实在拉的有些长,连我自己都受不了。这些日子的精神状态不佳,不知道自己未来的去向,也不想去想。自从被freescale无端的鄙视开始,先后有:realsil、infinone、诚致 这样一些欧美、台湾地区的IC企业轻视本科生,一点机会都不给大家,笔试后无面试。我这才体会到学历的重要性,中国人多,研究生多,本科的地位确实有点低。连江苏移动也点名要研究生,我开始觉得好笑了。不过社会就是这样,争辩也是无稽的。
Waitting……虽然有点精神上的折磨,但需要坚持和执着。光明就在前面了,我是这么想的。要学会忍耐和坚持,更好的机会在后面。

2004年11月15日

最近忙找工作,liteGUI可以说进度放的很慢。其实我打算在12月将代码全部搞定应该是没问题的。可……我又想骂人了。那家伙到底在干吗?难道还要我接着催?算了,我也没空跟他说,到是见了面,和他摊牌吧:你干还是不干?!!哈哈,当然没那么狠,我希望话里可以刺激刺激他。其实我是希望他不要干的好,毫无兴趣还来干吗,而且我还要和你协调,协调、讨论他也从来不发表自己意见,只会哦哦哦哦,我要这样的人在小组中干吗呢。被动、无主见(我不是鄙视,很多人都这么说)、无兴趣。大不了自己干!BBS上弟兄也多呢,怕什么!
GDI还剩下BITMAP那块,可能需要花点时间,好好研究一下。GDI完成后,我还需要和zzzzzz商量一下模拟器的事情,可以尽量快的将GDI在模拟器上跑起来,测试起来。板子呢?我等待的可爱的板子!学校里是没救了,项目的核心部分到现在还批不下来。哎……

不就冲了个冷水澡吗?那还是10月初啊!害的我感冒到现在,虽说还未痊愈,但感觉也差不多了。再不行,真要挂了!!
我总是把这样的情况归结为缺乏运动,的确如此。大一时,基本没感冒过,天天打球的。大二也还行,每个礼拜总要玩3、4吧。到了大三,衰样百出,一次感冒3礼拜!最长之记录!我快疯了,那时人也基本不动,整天看书,看屏幕的。现在……怎么说呢,有运动的环境(本部多好)但已经懒的动了,危机感四伏啊!得逼自己动动了,起码等工作落实后。
瞧,我又要找借口了。哈哈。