大狗熊的博客

数码摄影入门之一 首先要清晰 什么叫清晰，这是不是一个绝对的概念，因为我们的要求不同，我们对清晰的概念也是不一样的。这里联系到3个概念，即对焦精度、景深选择和抖动。对焦精度，现在的dc都AF了没有什么可以说的，除非你要拍的主体不在相机的对焦范围里，或者现场极度昏暗，AF还是可以保证质量的。除非你有更高的要求，比如获得超焦距等等，这些是高级手法，应该在无忌里讨论这里不讨论。 其次是景深，说道景深就需要给出另一个概念：弥散圆，名词解释：弥散圆：弥散圆. 在焦点前后，光线不能汇聚到一个点，点的影象变成模糊的扩大的圆形光斑，这个光斑的外圈就叫做弥散圆。显然，当弥散圆的尺寸小到一定程度后，人眼将认为其是一个不可分辩的一个点。这时我们就会觉得在焦段前后一段距离里所有的像都是清晰的。这就产生了"景深"。景深内的弥散圆称为就称为容许弥散圆可见容许弥散圆的概念是一个随着人观察分辩力的变化变化的，景深是随弥散圆的可接受程度在变化。 最后是抖动, 说一个故事，15年前我初学摄影是在高中的兴趣小组，老师是印尼的归国华侨。那时的我根本没有兴趣听老师的理论课，仗着家境不错，就只会浪费胶片。在一段时间的拍摄后，一次少年宫有一个摄影比赛（俺那年代惨啊，这种机会是已经极难得的展示自己的机会了）黑白片子被要求必须放大到8寸以上才可以参加。在老师的放大机下，我的片子里的对焦不实和抖动被无情的放大到足够让我沮丧的的程度！这时我才知道老师说的那些"清规戒律"有多重要。 对持稳相机，我现在可以达到：相对135的50mm焦距下，手持1/4秒可能在LCD上看不出抖，手持1/30放大到7寸内看不出抖，手持1/125秒放大到A3幅面肯定看不出抖。正确的手持方法是用相机的眼平取景器，这时你的左手托住相机左肘紧紧的支撑在肋部形成一个3角，右手持握把手，右肘也紧紧的支撑在肋部也是一个3角，同时2支手臂也自然形成一个3角，有点物理知识的人应该已经感受到它的稳定了。手部动作：拇指控制多功能拨盘，食指轻轻放在快门上，调匀呼吸，就像扣动枪机，做到"有意瞄准，无意击发"此时高手已经达到人机合一的境界，十步一击，一击必杀！当然，绝对不抖是不可能，即使使用捷信，至少它还有按固有频率出现的震动吧，就看大家的要求了。 数码摄影入门之二 准确的曝光 曝光的定义，

四、相机的镜头 　　镜头是照相机的主要部件，它在一架照相机中所起的作用占主导地位，有人将镜头比作照相机的"眼睛"。人们看见周围的景物，是因为能在视网膜上反映各种景物的影像，这种影像由视觉神经传到大脑，就可以看到各类事物。照相机的机能就类似人的眼睛，景物经过镜头形成影像，收录在机身内的胶片（或电子感光材料如CCD、CMOS）上，经过后期的技术处理而形成一幅可供欣赏的照片。 镜头属于光学部分，它起源于针孔成像原理，经过科学家的不断创造和发明，从最原始的单片透镜，到现代广泛使用的复式透镜，照片的影像变得越来越清晰。 镜头是由透明度高、纯洁、无色、质地均匀、具有良好析光能力的材料（如玻璃、塑脂）制成的。常用的镜头一般是由复式透镜4至7片凸凹透镜组成，透镜是两面或一面球面的透明体，被摄体的反射光线经过镜头透镜的会聚，便在像平面上结成原物的倒影。 认识照相机，需要了解一下参数： 光圈 光圈是镜头透光量的一个参数，其中光圈和以下两个量有关： （1） 口径 ：镜头的口径表示镜头的通光性能，好比室内的窗户，窗户大，通光多，室内就明亮；窗户小，通光少，室内就阴暗。口径大的镜头，即使在光线较弱的情况下，所摄照片的影调也较好。镜头口径的大小是固定的，称为镜头的最大口径，但镜头的通光量并不是恒定的。这就好比可以调节窗帘来调整进入房间的光量，在镜头内，也有类似的窗帘，该窗帘呈螺旋形的叶片，调节叶片，就可以控制进入镜头的光量。 （2） 焦距 ：照相机镜头上常见的另一数字有"F=50mm"或"F=28mm"，这一数字符号称为焦距，也就是无限远处射来的平行光束通过摄影镜头汇聚成焦点，从该点到镜头中心的长度就是该镜头的焦距。所以，从外观上来判断一个镜头的焦距的话，镜头筒越长的镜头，其焦距必然越长。 焦距是一个比较复杂的概念，因为它影响的因素比较多： A、 影响通光量 ：焦距长，通光量小；焦距短，通光亮大。（这点可以通过以下实验来理解：做两个长短不同的纸筒，光束从纸筒的一端射向另一端，很明显，纸筒越长，到达另一端的光量越小） B、 影响拍摄效果 ：焦距长，拍摄范围小，成像大；焦距短，拍摄范围大，成像小。（总的来说就是，焦距越长，越适合拍远处的物体，焦距越短，越适合拍近处的、大范围的物体 ） C、 影响视角 ：焦距长，视角小；焦距短，视

　现在，把大型软件项目分解为一些相交互的小程序似乎变得越来越普遍，程序各部分之间的通讯可使用某种类型的通讯协议，这些程序可能运行在不同的机器上、不同的操作系统中、以不同的语言编写，但也有可能只在同一台机器上，实际上，这些程序可看成是同一程序中的不同线程。而本文主要讨论C++/CLI程序间的通讯，当然，在此是讨论进程间通讯，而不是网络通讯。 　　 简介 　　试想一个包含数据库查询功能的应用，通常有一个被称为服务端的程序，等待另一个被称为客户端程序发送请求，当接收到请求时，服务端执行相应功能，并把结果（或者错误信息）返回给客户端。在许多情况中，有着多个客户端，所有的请求都会在同一时间发送到同一服务端，这就要求服务端程序要更加高级、完善。 　　在某些针对此任务的环境中，服务端程序可能只是众多程序中的一个程序，其他可能也是服务端或者客户端程序，实际上，如果我们的数据库服务端需要访问不存在于本机的文件，那么它就可能成为其他某个文件服务器的一个客户端。一个程序中可能会有一个服务线程及一个或多个客户线程，因此，我们需小心使用客户端及服务端这个术语，虽然它们表达了近似的抽象含义，但在具体实现上却大不相同。从一般的观点来看，客户端即为服务端所提供服务的"消费者"，而服务端也能成为其他某些服务的客户端。 　　 服务端套接字 　　让我们从一个具体有代表性的服务端程序开始（请看例1）,此程序等待客户端发送一对整数，把它们相加之后返回结果给客户端。 　　例1： using namespace System; using namespace System::IO; using namespace System::Net; using namespace System::Net::Sockets; int main(array<String^>^ argv) { if (argv->Length != 1) { Console::WriteLine("Usage: Server port"); Environment::Exit(1); } int port = 0; try { port = Int32::Parse(argv[0]); } catch (FormatException^ e) { Console::Wri

程式写完后，还要加工成为可执行的套装软件(Package),一般说来，即使是可以执行的程式，一点错误都没有，离套装软件的程度，却还有一段距离。     当然，程式侦错也是必经过程之一，有时侦错与程式写作可以同时进行。但有经验的程式师，对全面有了充份的认识，往往会等到程式联接后再行侦错。     程式完成后的全面侦错，最好不要依靠写程式的人。因为程式师经常不是使用者，他们仅在自己设计的条件下，依其理念进行侦错。当然这种错误必须更正，但最容易发生的错误，却是使用者不小心在输入时，或运用指令时，违背了程式师的理念。这种错误的发生，是不能原谅的，程式本来就是为使用者设计的，如果令使用者不便，程式就失去了应有的价值。     程式的品管，就在于检测程式是否符合使用者的需求。一般说来，应有专人负责，也有让写作手册的人，兼做品管的工作。这样可以同时对照手册所描述的功能及操作方法，检查两者之间是否一致。     还有一种常见的品管方式，是在产品完成时，交给完全没有参与程式设计的第三者，在客观的立场，作全面的试用，并提出测试报告或建议书。     品管合格了，才是包装、手册等最后的工作。这并不是说包装和手册要最后才做，相反的，尤其是使用手册，经常要在程式设计的同时，准备妥当，如此程式师才不会任意所之，脱离主题。     第一节  测试侦错     不论使用什么工具，侦错时一定要有清晰的头脑，根据所设定的方式，一步一步地查看流程及指令。     每个人都会有独特的习惯性错误，最好每次将自己发生的错误记下来，不仅错误会渐渐减少，且在错误发生时，很容易就能找到。     测试侦错是非常重要的手段，有人认为第一流的程式师不应该犯错，即使犯错，也错得很少。我的看法不一样，并非因为我经常犯错，而且错得离谱。真正的理由是为了适时掌握正确的思考方向，在编程时，有意无意地忽略一些细节，这样反而能一气呵成，不致于再而竭三而衰。     这就像画图一样，有人喜欢先作草图，有人则习惯由细部画起。不论个人的风格如何，重要的是最后的成果。     我在写程式之前，首先考虑全体的结构，再把各处的支架备妥，然后考虑有共同特性之处，便一口气写完。而且写时力求快速，以免失去当时的感觉。等到结构大体完成了，最后才去填补一些不太重要的细节。至于正确与否，则全靠测试侦错来修正、弥补。     这种写法要有很强的整体观念

本讲主要概述 Linux 设备驱动框架、驱动程序的配置文件及常用的加载驱动程序的方法；并且介绍Red Hat Linux 安装程序是如何加载驱动的，通过了解这个过程， 我们可以自己将驱动程序放到引导盘中；安装完系统后，使用kudzu自动配置硬件程序。  Linux 设备驱动概述  1. 内核和驱动模块  操作系统是通过各种驱动程序来驾驭硬件设备，它为用户屏蔽了各种各样的设备，驱动硬件是操作系统最基本的功能，并且提供统一的操作方式。正如我们查看屏幕上的文档时,不用去管到底使用nVIDIA芯片，还是ATI芯片的显示卡，只需知道输入命令后，需要的文字就显示在屏幕上。硬件驱动程序是操作系统最基本的组成部分，在 Linux 内核源程序中也占有较高的比例。  Linux 内核中采用可加载的模块化设计（LKMs ，Loadable Kernel Modules），一般情况下编译的 Linux 内核是支持可插入式模块的，也就是将最基本的核心代码编译在内核中，其它的代码可以选择是在内核中，或者编译为内核的模块文件。  如果需要某种功能，比如需要访问一个NTFS分区，就加载相应的NTFS模块。这种设计可以使内核文件不至于太大，但是又可以支持很多的功能，必要时动态地加载。这是一种跟微内核设计不太一样，但却是切实可行的内核设计方案。  我们常见的驱动程序就是作为内核模块动态加载的，比如声卡驱动和网卡驱动等，而 Linux 最基础的驱动，如CPU、PCI总线、TCP/IP协议、APM（高级电源管理）、VFS等驱动程序则编译在内核文件中。有时也把内核模块就叫做驱动程序，只不过驱动的内容不一定是硬件罢了，比如ext3文件系统的驱动。  理解这一点很重要。因此，加载驱动时就是加载内核模块。下面来看一下有关模块的命令，在加载驱动程序要用到它们：lsmod、modprob、insmod、rmmod、modinfo。  lsmod 列出当前系统中加载的模块，例如：     #lsmod （与cat /proc/modules 得出的内容是一致的） Module Size Used by Not tainted radeon 115364 1  agpgart 56664 3  nls_iso8859-1 3516 1 (autoclean) loop 12120 3 (autoclean) s

fcntl文件锁有两种类型： 建议性锁 和 强制性锁     建议性锁是这样规定的：每个使用上锁文件的进程都要检查是否有锁存在，当然还得尊重已有的锁。内核和系统总体上都坚持不使用建议性锁，它们依靠程序员遵守这个规定。     强制性锁是由内核执行的。当文件被上锁来进行写入操作时，在锁定该文件的进程释放该锁之前，内核会阻止任何对该文件的读或写访问，每次读或写访问都得检查锁是否存在。     系统默认fcntl都是建议性锁，强制性锁是非POSIX标准的。如果要使用强制性锁，要使整个系统可以使用强制性锁，那么得需要重新挂载文件系统，mount使用参数 -0 mand打开强制性锁，或者关闭已加锁文件的组执行权限并且打开该文件的set-GID权限位。     建议性锁只在cooperating processes之间才有用，对cooperating process的理解是最重要的，它指的是会影响其它进程的进程或被别的进程所影响的进程，举两个例子：（1）我们可以同时在两个窗口中运行同一个命令，对同一个文件进行操作，那么这两个进程就是cooperating processes；（2）cat file| sort，那么cat和sort产生的进程就是使用了pipe的cooperating processes。     使用fcntl文件锁进行I/O操作必须小心：进程在开始任何I/O操作前如何去处理锁，在对文件解锁前如何完成所有的操作，是必须考虑的。如果在设置锁之前打开文件，或者读取该锁之后关闭文件，另一个进程就可能在上锁/解锁操作和打开/关闭操作之间的几分之一秒内访问该文件。当一个进程对文件加锁后，无论它是否释放所加的锁，只要文件关闭，内核都会自动释放加在文件上的建议性锁（这也是建议性锁和强制性锁的最大区别）,所以不要想设置建议性锁来达到永久不让别的进程访问文件的目的(强制性锁才可以)^_^；强制性锁则对所有进程起作用。      fcntl使用三个参数 F_SETLK /F_SETLKW，F_UNLCK和F_GETLK,来分别要求、释放、测试record locks，record locks是对文件一部分而不是整个文件的锁，这种细致的控制使得进程更好地协作以共享文件资源。fcntl能够用于读取锁和写入锁，read lock也叫shared lock（共享锁）,因为多个coop

我们通常把 一些公用函数 制作成函数库，供其它程序使用。 函数库分为静态库和动态库两种。 静态库在程序编译时会被连接到目标代码中，程序运行时将不再需要该静态库。 动态库在程序编译时并不会被连接到目标代码中，而是在程序运行是才被载入，因此在程序运行时还需要动态库存在。 本文主要通过举例来说明在 Linux 中如何创建静态库和动态库，以及使用它们。 在创建函数库前，我们先来准备举例用的源程序，并将函数库的源程序编译成.o文件。 第1步：编辑得到举例的程序--hello.h、hello.c和main.c； hello.h(见程序1)为该函数库的头文件。 hello.c(见程序2)是函数库的源程序，其中包含公用函数hello，该函数将在屏幕上输出"Hello XXX!"。 main.c(见程序3)为测试库文件的主程序，在主程序中调用了公用函数hello。  程序1: hello.h  #ifndef HELLO_H  #define HELLO_H    void hello(const char *name);    

基本概念 库有动态与静态两种，动态通常用.so为后缀，静态用.a为后缀。 例如：libhello.so libhello.a 为了在同一系统中使用不同版本的库，可以在库文件名后加上版本号为后缀,例如： libhello.so.1.0,由于程序连接默认以.so为文件后缀名。所以为了使用这些库，通常使用建立符号连接的方式。 ln -s libhello.so.1.0 libhello.so.1 ln -s libhello.so.1 libhello.so 1、使用库 当要使用静态的程序库时，连接器会找出程序所需的函数，然后将它们拷贝到执行文件，由于这种拷贝是完整的，所以一旦连接成功，静态程序库也就不再需要了。然 而，对动态库而言，就不是这样。动态库会在执行程序内留下一个标记指明当程序执行时，首先必须载入这个库。由于动态库节省空间， Linux 下进行连接的缺省操作是首先连接动态库，也就是说，如果同时存在静态和动态库，不特别指定的话，将与动态库相连接。 现在假设有一个叫hello的程序开发包，它提供一个静态库libhello.a 一个动态库libhello.so,一个头文件hello.h,头文件中提供sayhello()这个函数 /* hello.h */ void sayhello(); 另外还有一些说明文档。 这一个典型的程序开发包结构 与动态库连接 Linux 默认的就是与动态库连接，下面这段程序testlib.c使用hello库中的sayhello()函数 /*testlib.c*/ #include <> #include <> int main() {    sayhello();    return 0; } 使用如下命令进行编译 $gcc -c testlib.c -o testlib.o 用如下命令连接： $gcc testlib.o -lhello -o testlib 连接时要注意，假设libhello.o 和libhello.a都在缺省的库搜索路径下/usr/lib下，如果在其它位置要加上-L参数 与与静态库连接麻烦一些，主要是参数问题。还是上面的例子： $gcc testlib.o -o testlib -WI,-Bstatic -lhello 注：

引言 　　美国WindRiver公司的实时嵌入式系统VxWorks和美国Motorola公司MPC860系列处理器已经广泛的应用在通信行业的通信产品中，在用VxWorks系统进行开发时，会生成两个文件，一个是BootRom文件，此文件类似Windows中的BIOS，是引导文件，完成内存初始化，内核初始化，基本硬件的初始化并最终引导VxWorks系统启动，另外一个是VxWorks文件，此文件中包括VxWorks系统内核及上层应用程序，而这两个文件在MPC860的开发中一般都存储在两片不同的Flash上，及BootRom存储在BOOT Flash，而VxWorks存储在Flash上。 　　产品需要 　　实际开发中，生成的没有压缩的BootRom大小一般为512K左右，在VxWorks 5.4中是460K左右，而在VxWorks 5.5中是540K左右，一般存储BootRom的Flash只需要512K大小，因为即使540K的 BootRom也可以截成512K。 　　在硬件开发Flash选型时，BOOT Flash芯片一般采用SST公司的28VF040、29VF040等，Flash芯片一般会采用Intel、AMD公司的，根据需要可能会采用容量为4M、8M、16M、32M大小不等。从节省成本的角度考虑，是不是可以将BootRom直接装载到Flash中并引导呢，这样不是可以省掉一片BOOT Flash吗？ 　　VxWorks系统中，加上上层应用程序的生成的VxWorks文件一般为3M左右，所以不管你采用4M、8M或者更大容量的Flash，同时装载BootRom、VxWorks文件也是绰绰有余的。 　　实际情况 　　我和一个做硬件的朋友曾经做过这样的测试，直接从Flash引导BootRom，并引导VxWorks系统，实际上是可行的。 要解决此问题，实际上只要将Flash的地址稍做处理就可以的。 　　我们将Flash地址映射成两个地址段，一段用做BootRom，一段用做VxWorks使用，用做BootRom的地址段为0xFFF00000~0xFFF80000，另外一段用做VxWorks的地址段为0x04080000~0x04800000（假设此Flash大小为8M大小），在0xFFF00000~0xFFF80000地址段写入BootRom，在0x04080000~