标签: GUI

        GUI 在有交互的产品设计中相对来说是占得比例算是比较大，主要作用是提供给用户端一目了然的操作界面，方便修改参数及实时显示运行状况。          最近利用空余时间，跟着一个开源项目,学习工控技术，在此非常感谢各位的热情指导，TKS。           msOS 系统是作者项目发展需要而完善的最新开源系统在STM32 上，此版本整合了ucos,灵活的运用结构体及链表，完美的实现中等工控项目软件开发需求，简单易用的GUI 设计及按键处理，参数修改，参数保存功能。          作者GUI 是采用面向对象，组件方式来实现的，像VB 那样添加组件来实现一个界面，作者在GUI.C主要实现了组件有 Chart、 Label、TextBox，灵活的运行三个组件可以构成丰富的Form，其中Chart 可以灵活绘画出图形，Label 主要是显示一些参数名称，TextBox 即是一些可供用户修改的变量，详细界面实现见Mmi.c,很方面的实现一个界面。           msOS 是如何实现界面显示及数据刷新的呢？         在初始化void InitializeGui(void) 函数中的MenuTask 调用了Update() 函数来实现显示内存与硬件驱动链接及数据刷新，通过创建任务实时的刷新界面函数如下： System.Os.CreateTask( System.Gui.MenuTask, MenuTaskStack );   Remark:本人从毕业到现在一直从事测试工作，兴趣爱好广泛，爱好编程，一直没有找到好的导师，被挡在程序之门外，最近跟着学习开源项目msOS,在群里的各位朋友热情帮助下，总算自我感觉入了软件行业门道，再此再次感谢帮助我的朋友。

Not quite long ago, my modest home-alarm system had some of I/O lines fried by lighting so I had to change it. No big deal, I figured, and I was in luck: the very same control board I purchased five years ago was still available, and for a fair price. But then I remembered what I did not like about the unit: first, it had what seemed to be hundreds of arcane, incomprehensible options which the user—usually an alarm professional—could invoke ("turn alarm on but ONLY IF the wind is from the south AND doors 1, 3, and 5 are open"; "time out for 2 seconds IF the alarm condition is met BUT the phone line is busy AND Zone 4 is winking at you"); second, it was almost impossible for anyone to actually initialize and program. I recall that I spent hours going over the set-up and programming manual to figure out which of those few initialization options I actually needed, then a few more hours trying to figure out how to actually set them. The programming was done via the user panel and in a quasi-assembly language style with some binary BCD number-coding format to add to the mix, and there was no good way to read back what you had set into the various memory locations; it was like old joke of a "write-only memory"—except that this was no joke. Nor was there a basic PC-connection with an application/set-up program, as logical as that seems, and no way to store and recall your setup outside of the control board itself. (If you want to experience this for yourself, download their manual here and go to section VI.) Even worse, some of the mistakes you could easily make would actually lock you out of further access, analogous to inadvertently overwriting the password without realizing it. In the end, I got so frustrated with all this studying, and fearful of completely messing it up, that I gave up, despite my engineering imperative. I found a local installer with some experience to do the set-up for me in his office, for a small fee—and well worth it. Since it is now five years later, I was happy that the same board was available, but shocked that it had not been updated to provide some semblance of connectivity to a PC and programming support. I foolishly assumed that the vendor had perhaps upgraded the design (backwards-compatible, I hoped) with a USB port and maybe even a GUI for the programming. Wrong again: all they had was a crude, line-entry, text-only software package for a PC, and it needed a serial port (umm...lots of PCs no longer have those); plus you also had to buy a special adapter to interface that serial port to the proprietary three-wire interface of their control panel. Overall, I felt as if I had fallen through a portal to the 1990s: no/poor PC connectivity, arcane instructions, and an emphasis on the wired-phone landline for audio-message alarm reporting, without texting/emailing/browser notification of alarms. Well, I thought, "fool me once, shame on you; fool me twice, shame on me"—I'll look for an entirely new unit from another vendor that has decent connectivity and set-up support. Wrong again: the major competitors don't have anything much better, it seems. Whether this is because they want set up barriers to the purchase, installation, and use by home do-it-yourself types instead of alarm professionals, or because they simply want to keep making the same old product for which all costs have been amortized, I don't know. So how does my modest tale of woe end? Luckily, I found my good notes from the previous time (documentation is a virtue, right?), and the name of the installer who helped me out. I called him, he is still in business, and sort-of remembers helping me out—and is willing to help me again. I asked him if this sort of arcane, stone-age set-up and connectivity had improved, maybe I am missing something? And he said, no, it's still the same, hard to believe but true. I am not saying that every "older" product needs an upgrade; some clearly don't, nor have they received one, see here . But it appears that even in our fast-changing technology world, some things do remain the same even when they shouldn't. Have you ever had a similar experience, of putting too much time into bells and whistles, and features and options, and not enough on making the product usable? Or do you know of a long-standing product or design that could really use an upgrade to the 21 st century, but which hasn't gotten it?

Recently, I had to change my modest home-alarm system as some of I/O lines were seemingly fried by lighting. No big deal, I figured, and I was in luck: the very same control board I purchased five years ago was still available, and for a fair price. But then I remembered what I did not like about the unit: first, it had what seemed to be hundreds of arcane, incomprehensible options which the user—usually an alarm professional—could invoke ("turn alarm on but ONLY IF the wind is from the south AND doors 1, 3, and 5 are open"; "time out for 2 seconds IF the alarm condition is met BUT the phone line is busy AND Zone 4 is winking at you"); second, it was almost impossible for anyone to actually initialize and program. I recall that I spent hours going over the set-up and programming manual to figure out which of those few initialization options I actually needed, then a few more hours trying to figure out how to actually set them. The programming was done via the user panel and in a quasi-assembly language style with some binary BCD number-coding format to add to the mix, and there was no good way to read back what you had set into the various memory locations; it was like old joke of a "write-only memory"—except that this was no joke. Nor was there a basic PC-connection with an application/set-up program, as logical as that seems, and no way to store and recall your setup outside of the control board itself. (If you want to experience this for yourself, download their manual here and go to section VI.) Even worse, some of the mistakes you could easily make would actually lock you out of further access, analogous to inadvertently overwriting the password without realizing it. In the end, I got so frustrated with all this studying, and fearful of completely messing it up, that I gave up, despite my engineering imperative. I found a local installer with some experience to do the set-up for me in his office, for a small fee—and well worth it. Since it is now five years later, I was happy that the same board was available, but shocked that it had not been updated to provide some semblance of connectivity to a PC and programming support. I foolishly assumed that the vendor had perhaps upgraded the design (backwards-compatible, I hoped) with a USB port and maybe even a GUI for the programming. Wrong again: all they had was a crude, line-entry, text-only software package for a PC, and it needed a serial port (umm...lots of PCs no longer have those); plus you also had to buy a special adapter to interface that serial port to the proprietary three-wire interface of their control panel. Overall, I felt as if I had fallen through a portal to the 1990s: no/poor PC connectivity, arcane instructions, and an emphasis on the wired-phone landline for audio-message alarm reporting, without texting/emailing/browser notification of alarms. Well, I thought, "fool me once, shame on you; fool me twice, shame on me"—I'll look for an entirely new unit from another vendor that has decent connectivity and set-up support. Wrong again: the major competitors don't have anything much better, it seems. Whether this is because they want set up barriers to the purchase, installation, and use by home do-it-yourself types instead of alarm professionals, or because they simply want to keep making the same old product for which all costs have been amortized, I don't know. So how does my modest tale of woe end? Luckily, I found my good notes from the previous time (documentation is a virtue, right?), and the name of the installer who helped me out. I called him, he is still in business, and sort-of remembers helping me out—and is willing to help me again. I asked him if this sort of arcane, stone-age set-up and connectivity had improved, maybe I am missing something? And he said, no, it's still the same, hard to believe but true. I am not saying that every "older" product needs an upgrade; some clearly don't, nor have they received one, see here . But it appears that even in our fast-changing technology world, some things do remain the same even when they shouldn't. Have you ever had a similar experience, of putting too much time into bells and whistles, and features and options, and not enough on making the product usable? Or do you know of a long-standing product or design that could really use an upgrade to the 21 st century, but which hasn't gotten it?  

While cruising the show floor at ESC last year, I became much more aware of how important an effective, clear and unambiguous user interface (UI) is in embedded designs, despite the many articles I had read and edited.   But despite the many articles published on GUI design and hardware design in general, I did not realise just how seldom real users (including those "users from hell" who don't read documentation and believe a few minutes of use is all that is necessary ) are involved in evaluating such designs before they get to market.   As I pointed out in " It's usability testing, stupid ," I do not think enough effort is made to find such users in the environments where they normally use the devices and monitor how they really use them.   But it was at the ESC show in Boston last 2010 that I thought of a possible answer to this lack of meaningful user from hell input into such designs. There, a number of companies showed me tools they had designed to aid in the development of many of these new UI enabled embedded applications.   One that caught my eye, and caused an immediate visceral response to it, was the Mentor Graphics Ready Start Platform and its Inflection Interface runtime engine for 2D and 3D graphics and wired and wireless connectivity middleware. It incorporated ready to use applications and configurations designed to shorten significantly the time to develop medical, industrial, automotive and consumer devices.   The example they showed me was of the setup for designing a glucose monitoring device. I am a diabetic whose life is sometimes made miserable by badly configured and provisioned medical devices, and I itched to get my hands on a real design on the platform and make half dozen significant changes and many minor ones.   I do not expect the tools such as I saw at the show, designed primarily for developers, to be used in this way. But the companies developing such tools should think about coming up with variations specifically designed to aid them or their customers in getting real, meaningful input from the actual "in the wild" users of the many such GUI-enabled embedded devices we can expect in the future.   It is an area that deserves further exploration and I would like to see more from you on this issue and others relating to embedded user interface design and testing. It is a topic that will become increasingly important as embedded devices become more wired and wirelessly connected and permeate our lives even more.    

  The 80486 project After being spoiled by the facilities of the 68332 project, the next one was somewhat of a letdown. This time, we were back, at least initially, to the hardware guy/software guy sort of mentality. It was a pretty big project, and I was building only two or three "apps" in the system. By the time I arrived on the scene, lots of decisions had already been made. These included the choice of the processor, the I/O devices, the C language, the development tools, and the RTOS. So, for that matter, was the program architecture. There were a lot of I/O signals, mostly analog, so the architecture was designed around a input buffer array that cycled through the A-to-D channels in a specific order. The job of our apps was to read the data at the proper time, process it, and send the results out again. Some of the data went back out to devices again, but most just went to graphic and numeric displays.   Originally, we had planned to use an industrial-quality C compiler designed for real-time, embedded applications. But for preliminary development, we agreed to use the Microsoft C compiler. In time, however, the "preliminary" part morphed into "forever."   This decision was to lead to some consternation, because we knew that the floating-point routines in Microsoft's math library weren't reentrant. To use their compiler in production, we all had to agree not to use floating point. This decision made the problem much harder.   Later, we realized that the problem was not a problem, as long as one task using the floating point processor didn't get interrupted by another, also using it. Getting around this limitation was as easy as splitting the f.p. computations up into small sets, and disabling interrupts while processing each set. Or, even easier, simply agree that only one app got to use floating point.   Although the development system for this job was capable enough, it was definitely a step down from the 68332 project. There was not even the pretense of the features of an IDE—we used separate Windows and MSDOS apps for code development, testing, downloading, and testing. We had no ICE, relying instead on remote hex debugging.   Despite the step down in our development system's capabilities, this was one of the most fun projects of my young life. That's because I got to—perhaps "was forced to" would be more accurate—use my skills from so many different technical disciplines.   My boss was a big believer in the generalist, as opposed to spe******t, philosophy. He was adament that we not be divided into "hardware guys" and "software guys," but rather know and understand all aspects of the system. Whenever I asked a question about how some gadget in the hardware worked, he'd bark "Get out the schematic and see for yourself!"   At one point, he had me checking a new circuit board to make sure it matched the schematic. There I sat, a Ph.D. physicist "software guy" and an expert on embedded software development, using a multimeter to buzz out the copper traces on a PC board.   I grumbled, "Dammit, Jim, I'm a software engineer, not a lab tech." To myself, I thought, "Man, at the salary this guy's paying me, this has got to be the most expensive circuit board validation in history."   In the end, though, I learned that the boss was absolutely right. The system was entirely too embedded, too tightly married to the hardware, to divide it into software, hardware, and systems pieces. Or control pieces or algorithmic pieces. It all had to play nicely together, and that took someone who understood the funcionality of all the pieces.   Now, I love electronics; it was key in my Master's thesis. I also love microprocessors, having been in on the ground floor. And I love digital logic. And math algorithms. And physics. And software engineering. It's not often I get to use skills in all these disciplines on any one job. But to make this job work, I had to dredge up everything I'd learned in all these disciplines, plus quite a few more.   Once I got over the shock of being yanked out of my comfort zone, I didn't just accept the boss's notion of doing it all; I jumped in with both feet.   Like any high-tech company, ours had an electronics lab, and a "chief hardway guy" working in it. But he was always in the greatest of demand, and I didn't want to wait for him to have time to talk to me. Anyhow, I got tired of going into the lab to ask, "Where did the Phillips go?" or "May I borrow the multimeter?"   So I went to Radio Shack and bought myself a CARE package: A set of hand tools, a soldering station and soldering aids, a multimeter, a logic probe, and various electronic components. My desk drawer began to look more and more like my partner's briefcase.   In the end, I found myself not just involved in all aspects of the program. I was, quite literally, embedded in them. At one end of my desk was the software development system and the UUT. At the other end was an oscilloscope, multimeter, signal generator, and logic probe. Later, it included precision thermometers, air and vacuum pumps, and more. In my desk drawer were the circuit components and tools. Below that were a few custom test gadgets I'd built myself. Not far away was a PROM burner, FPGA burner, logic design software, and support software. Standing in the corner were a couple of tanks of nitrous oxide.   In the last system I built for that company, I got to exercise all my skills and then some. I had a lot of help designing the more complex parts of the circuitry, but I was involved in every other aspect. When the prototype circuit board proved to be too noisy, I found myself sitting next to the PC layout guy, showing him how best to route the power, ground, and signal lines, and where to put the isolation caps. When our first board got populated, I was the one who did it. One step at a time, testing all the way (unit testing, remember?).   When one of our fabricators got chips upside down, I was the one that found them. When a part failed, I found that too. When the pressure control system proved to be unstable, I found that too, and redesigned it. And when we learned that the sensing device required a lot of digital logic, I worked with the sensor's vendor to work out a fix. I picked the serial PROM that solved the problem. Then I designed the logic and burned the FPGA.   And I loved every minute of it.   Today's development systems Until a few years ago, I used to attend the Embedded Systems Conference every year. I watched with interest as the capabilities of chips and systems improved, and the development systems and software got so very much better.   No more SneakerNet for these systems. No more hex debuggers either. It seemed that almost any device that involved digital logic, also had a C compiler and a symbolic debugger. Often the toolsets was the GNU toolset. Not my first choice, because I'm a GUI/IDE sort of person. but still very capable, and familiar to virtually everyone.   Today, there's been yet another dramatic shift in development environments. Today, emphasis has shifted from the GNU toolset to custom toolsets based on Visual Studio. Some vendors actually use Visual Studio, some use its look feel. But all are tightly integrated into proper IDEs, with excellent support for cross-compiling for an embedded system. Far from SneakerNet, modern systems talk to the IDE through high-speed connections.   As I sit here typing this, there a tiny PC board, about 2 x 3", plugged into my USB port. This is not just the core processor, mind you. It's the core processor plus its evaluation board, with a fast CPU and more memory than I used to have in my hard drive. It came with a very complete Visual Studio IDE, and a built-in RTOSes. I can choose from a bewindering array of pre-built software modules.   There's a second board plugged into my Ethernet port. Running their IDEs is as simple as clicking on an icon in Windows, and if their user interfaces aren't Visual Studio, they're close enough for me.   With systems like this, I'm back down to creating a new build in seconds. Awesome.   I chose three of these systems for nostalgia's sake. One has my favorite 68332 chip; two more have Z80-like processors. I can get away with choosing them this because, now that I'm retired, I don't have to explain to my motives to anyone.   A whole set of gadgets is based on Parallax's wierd and wonderful Propeller chip.   I have one more system to buy. That will be my only concession to leading-edge technology: A high-end ARM system.   Let me see, now. Where did I put that logic probe?