标签: debug

随着科技的不断发展，无线功能在电脑产业中的应用已蔚为主流，无线技术的整合应用无疑为使用者带来了极大的便利。然而，在追求便利性的同时自然也伴随着一些潜在风险，特别是在无线效能方面；因此无线技术的可靠性绝对是一个不容忽视的问题。 举例来说，虽然无线连接提供了更灵活的使用场景，但信号稳定性和连接可靠性却容易受到外部干扰而产生影响。不论是电波干扰、无线信号干扰抑或是其他无线设备的竞争都可能导致连接质量上的不稳定，进而影响使用者体验。但是能检测出无线效能是否低落纯粹只是基本功，更重要的是如何找出真正的问题所在，并且针对问题进行改善及排除。接下来百佳泰将透过真实的量测案例，带领大家一步步地了解如何改善电脑无线效能低落的恼人问题 电脑无线效能低落，除错与改善实例分享 在百佳泰曾经合作的案例当中，曾有客户的电脑产品在上市后因为无线效能不佳，遭到大量客诉。客户在面对这样的紧急状况时十分需要像百佳泰这样的专业顾问团队协助问题的定位与厘清，并且希望能够从中给予提供第三方的客观建议，以协助他们及早进行产品修正及调整。 Step.1 Throughput实际量测：天线的VSWR(电压驻波比) 与Isolation(天线隔离度) 针对此次个案，百佳泰顾问团队首先协助客户进行Throughput的基本量测。经量测后确认，baseline的数据确实不佳；为了定位问题，百佳泰进一步进行天线的VSWR与Isolation量测，并得到以下结果。 ◆ VSWR(电压驻波比)，量测频率范围为2GHz~6GHz，红线是Wi-Fi操作频带，蓝线与绿线分别为主天线 (Main Antenna)及副天线(Aux Antenna)。 从VSWR的测试中我们可以看到主、副天线在2.5GHz区间皆超过一般业界标准3。至于在曲线图则可以看到设计的操作频率往低频偏移；而5GHz在之前的验证中因为在throughput没有问题，故我们不会在VSWR这边进行调整。因此，若是未来想让5GHz throughput的数值更好，VSWR仍是一个可以进行调整的部分。 接下来，我们来观察Isolation数据，看看是否有需要修正的问题。 ◆ Antenna Isolation(天线隔离度)，量测频率范围为2GHz~6GHz，红线是Wi-Fi操作频带。 Isolation(隔离度)于2.4GHz与2.5GHz频率分别为-11.23与-14.9dB，两者皆超过一般业界标准 -20~-30 dB，这恐会有隔离度不足而造成throughput性能不好的潜在风险。 综合以上天线的电压驻波比与隔离度测试结果，我们几乎可以断言， 此次实测的电脑产品在天线上存在一些设计疑虑，导致throughput下降 。 Step.2电脑无线性能改善实作：Isolation优化与Throughput验证 经过天线的基本量测后，我们将针对VSWR(电压驻波比)与Isolation(天线隔离度)问题着手进行调整与测试，由于VSWR必须对天线本体结构来进行调整，再加上在该客户表示 基于厂内原物料管控因素，故无法针对天线结构进行变更 ，因此百佳泰顾问团队便建议客户可从Isolation问题进行调整。 在先前的量测结果中，Isolation S21数值为-11.23dB@2.4GHz、-14.9dB@2.5GHz，我们从下图的天线位置中可以看到。两支天线不但都位于产品的正面右侧位置，且两支天线距离间隔不到3公分。因此综合天线实际位置与Isolation数值进行推测，百佳泰顾问团队合理假设， 两支天线有可能因彼此过于接近，造成throughput降低 。 为了验证此假设，我们将两天线中间放置两种隔离材料进行实验，从下图右方的网络分析仪画面中可以看到吸波材与铜箔皆可提高隔离度，2.4GHz Isolation从-12.23dB改善至-14dB；2.5GHz Isolation从-14.9dB改善至-16.5dB。 接下来我们直接用Throughput来验证隔离材料是否能改善效能，从下表可以看出隔离材料Channel 1于20m从23.05Mbps改善至37.52 ~ 47.38Mbps，100m则从6.5Mbps改善至11.24~18.32Mbps，双双验证了改善Isolation确实可提高Throughput性能。 经过以上的Isolation优化与Throughput验证，再次证明「两天线间的距离太近，进而造成Throughput数值低落」的假设是正确的。根据此验证结果，百佳泰建议客户变更天线位置，修改成前墙一支天线、后墙一支天线，此作法不仅可提高天线隔离度，同时也能提升天线可传输的覆盖范围。 待客户变更天线位置，调整成一前一后的天线设计后，百佳泰随即为客户进行Throughput测试确认修改后的效果。量测结果如下表所示。Throughput数据在更改天线位置后明显获得改善，RX(黄色底色) Channel 1，20m从27.73改善至74.07得到Pass结果，其他Channel与距离也都得到Throughput数值提升。 看完了今天的无线效能实测案例分享，相信大家可以发现，不论是天线设计的变更，天线本体与布局设计的好坏，都会直接影响到Throughput的测试结果。

M M32 MCU ToolB ox主要是协助F AE 解决、分析和追溯客户端的芯片的定位工具，也面向M M32 MCU 用户，方便M M32 MCU 用户快速定位程序进入 H ardfault的原因以及脱离I DE 对芯片进行出厂初始化操作、读取芯片信息以及读取flash信息等。 一 目的： 1、快速追溯芯片版本和出货时间等芯片信息； 基本信息： 内核版本 内核型号 UID 选项字节： RDP n BOOT 1 WRP 代码区块保护： 区块1、2、3、4 存储器和外设： FLASH SRAM 外设 T riming： HIS_3.3V HIS_5V T e mp Vref Volt ISP: ISP_DATA0 ISP_DATA1 2、快速定位M CU 进hardfault的原因，跟踪显示内核寄存器，方便根据内核信息获取程序运行状态，目前仅支持用户编程文件定位问题，针对用户操作R CC 等设置问题暂时还没想到方法支持； 3、针对芯片进行出厂格式化操作，目前支持对所有的芯片进行出厂格式化操作功能，后面会支持读取flash信息功能 二 支持芯片： 支持全系列M M32 MCU 芯片， m / n / o / p / q / s 版本芯片。 三 支持工具： 支持 J - link ，后续需M M32-LINK 驱动开放可以支持。

        大家都知道，越早发现BUG，修复BUG的成本也越低。40-60%的bug是由错误的需求引起的，而在测试阶段修正需求错误，无疑将花费高昂的金钱成本与时间成本，业界普遍希望能够在需求定义阶段发现问题而不是之后发现问题。         Debug Requirement是一个新颖的概念，也是业界一直期望具备的一个能力。一般来说，需求文档都是用自然语言书写的，通过人工方式进行检查会存在诸多缺陷。Stimulus是法国Argosim公司推出的一款需求建模和仿真分析工具，可以帮助用户检测模棱两可的、不正确的、丢失的、或相互冲突的需求。         如何通过Stimulus这款工具来Debug需求？下面的例子是一条关于车灯的简化需求：当车灯处于“自动”模式时，顶灯的开与关取决于环境光强度，并通过系统预设条件来避免顶灯出现频繁闪烁的状况。     ♦  REQ_003Aa  车灯开关拨到AUTO位置，且环境光强度≤70%，顶灯应保持ON状态或立即进入ON状态。光强度不超过70%，顶灯保持ON状态，车灯开关保持AUTO状态。     ♦  REQ_003Ab  车灯开关拨到AUTO位置，且环境光强度＞70%，顶灯应保持OFF状态或立即进入OFF状态。光强度不低于70%，顶灯保持OFF状态，车灯开关保持AUTO状态。     ♦  REQ_003B   车灯开关已在AUTO位置，而顶灯在OFF状态，且光强度低于60%，那么顶灯需在此条件下进入ON状态至少2秒。     ♦  REQ_003C   车灯开关已在AUTO位置，而头顶灯在ON状态，且光强度高于70%，那么顶灯需在此条件下进入OFF状态至少3秒。         这几条需求涉及到比较复杂的逻辑关系，人工检查可能要花费很长时间才能确定需求是否存在BUG。使用Stimulus这款工具对需求进行Debug后，可以清晰的看到，顶灯第一次进入OFF状态后，顶灯的开与关几乎变成了一个随机事件，需求中必然存在严重的逻辑缺陷。         Stimulus创造性的自然语言需求建模及仿真验证技术，使得在需求定义阶段即可对需求进行Debug，像Debug代码一样Debug需求，在第一时间发现需求文档中的错误。         Stimulus提供支持行业惯例的文本写作模型/模板，用户可以很容易的设计标准化的需求，同时支持共享清晰、易理解的需求。         用户可以使用生成的测试场景对需求进行仿真和调试，生成系统有可能出现的行为，通过观察发现不正确及不完整的需求。         一旦系统已经开发，需求仿真和调试时系统生成的一般测试场景即可被重用，用户可以将其导出生成测试用例，并在SIL环境中重新运行。         北京经纬恒润科技有限公司成功代理Argosim公司的Stimulus产品，成为Argosim公司的业务合作伙伴，并负责中国地区的推广工作，有任何的产品/方案咨询可联系010-64840808。 恒润科技  北京市海淀区知春路7号致真大厦D座5-10层 邮编：100191 电话：010-64840808-6214 网址：http://www.hirain.com

In my previous blog , I gave an overview of what the PICAXE system comprises and an account of my first forays into programming the beast. As I noted, I wanted to go a bit further into the capabilities of the development environment and the PICAXE processor. In Part 1 , I referred to the naming restrictions on variables and input/output ports. To make your programs easier to understand, you can use the "SYMBOL" command to give a less cryptic name to any of these. For example: This statement associates the name "DELAY" with byte variable "b0." Once you've made this association, you can use statements like the following: You can do the same type of thing with port names for the inputs and outputs. The programming editor contains a "SIMULATE" function, which enables you to single-step through a program and see what the outputs would do. I tried it on my counter program and it worked fine, opening a new window with a picture of the chip, showing the LED pins going on and off as the program stepped through the statements. You don't need to be plugged into a board to do this—it's an offline simulator. My next task was to start using the analogue-to-digital converter (ADC). PICAXE processors contain 10bit ADCs. I thought that using this feature would entail some setup and configuration, but not so! There is a "READADC (port)" command that sets up the specified port for ADC use, reads the ADC on the specified port, and presents the eight most significant bits for use (if you wish to access the full 10 bits, you can use the "READADC10" command). As I was using a small PICAXE that can only display three or four bits on LEDs, I wondered if I could use the three LEDs on my board to display the most-significant three bits of the 8bit value. My board has an LDR (light-dependent resistor) on one ADC port to give a convenient way of getting a variable voltage on that pin. To see if this was working properly I used the debug function. You just insert the "DEBUG" statement into your program, run it, open the debug function in the editor, and you can see the values of all variables. So I wrote a small program as follows:   When I ran this program and opened the debug window, I could see the value of the ADC output as variable "b0." Happily, with the ambient light in my office, this was around 125-126. If I covered the LDR with my finger it would go down to almost 0; if I shone a torch (flashlight) on it, it went up to around 240. So I knew I was reading the input value OK. Now, you can access the bit values of variable "b0" using the variables "bit0" to "bit7." Thus it was easy to access the most-significant three bits and use them to drive the LEDs as follows:   Wow! I had my 3bit ADC working! This whole process was absurdly easy and took far less time to actually do than it did to write about it here. The next thing I decided to experiment with was some PWM (pulse-width modulation). The PICAXE has a "PWMOUT" command in the following form: In this case, "period" is a variable in milliseconds from 0-255, while "duty cycle" is a value from 0 to 1023. You can use "period" to set the frequency (1/period) if that's important, and then a "duty cycle" of 100% is roughly 4x the "period" value. Don't worry if this sounds complicated because the editor has a Wizard to work everything out for you:   This Wizard helpfully gives you the command to use at the bottom, and you can also copy the command and paste it into your program. I had fun making the LED on output 2 (my only PWM output on this chip) "breathe" (gradually fade up and down). Again, the PICAXE makes all this really easy and the command reference is detailed and easy to follow. David Ashton Jack of All Trades  

Recently, I observed someone typing a lengthy analysis in response to an email. What a sight it was: fingers blazing, keys clicking, and that poor "delete/backspace" key getting an Olympic-class workout. And no, it was not just a case of poor typing skills. It was a case of typing and untyping over and over, like being stuck in a "do...while" loop without any exit. Each word, phrase, sentence, and even paragraph was done and redone and redone—all at high speed, of course, which word processing makes so easy. I estimate that the ratio of entered keystrokes to final ones actually used was about 10:1. Some thinking begins Then I wondered, what would it have been like to do that by hand, or even with that now-obsolete instrument, the typewriter? Of course, if you were doing this by hand or with a typewriter, you wouldn't have the "luxury" of such ease of do, delete, and re-do. Now, it's so easy to jump in and get going, and keep going, that there's little need to stop first and think, or so it seems. After all, you can correct, edit, re-do, and re-arrange almost ad infinitum , if not ad nauseum . It's as if the movie Groundhog Day met the cliché from those old movies about newspaper reporters, where the grizzly veteran editor yells "get me rewrite." The effect doesn't apply just to writing, either. I like to watch a TV show called The Woodwright's Shop , where the host uses only hand tools from about 1850 or earlier, mostly planes, saws, chisels, scrapers, and dividers (but no sandpaper). What always impresses me, besides his sheer skills and apparent ease while doing a project in a 25-minute block straight through, is how much thought he puts into each step before he does it. Mistakes are fairly rare. When you think about this, it makes sense. If you ruin a piece of standard lumber these days, you just run over to the nearby building-supply store and get another, no big deal. But "back in the day", a ruined piece was a major problem, as replacement material had to be sawn, planed, squared and trued, all of which took a lot of time and raw effort. Much better to get it right the first time, if at all possible. (The same consideration applies to writing with quill pens and costly paper or parchment, as all were very precious; you likely even had to make your own ink.) The engineering aspect It's not just personal projects which now have this "do it fast, and do it over (and over)" mode. The relative ease with which we can now write code, then execute it, test it, edit it, and re-execute it can discourage proper planning, despite all the formal coding procedures which software engineers claim they follow. The excellent book Digital Apollo details how the code which the programmers of the moon project created was actually transformed into executable instructions for the processor. I mean this literally: the 1s and 0s of the coded instructions were set by hand into core memory strings, a process which took weeks for each revision. If there was a bug or problem, then the entire lengthy process had to begin again. You can be sure that these programmers didn't just bang out their software; they analyzed it long and hard first, since the debug and edit process was so painful. Today's pressures don't allow for much of the "first, stop and think" or even "first, slow it down" approach. Plus, the tools we have encourage the "do it fast, then fix" approach. It takes real discipline to not be driven by the pressure from management, especially when it aided by the programming tools which are literally at our fingertips. Too much of a good thing? Maybe this pace is actually counterproductive, and we should remember that sometimes it's better to go slow and careful, than go fast but have to do it over and over again—and the appearance of non-stop activity on a project is not the same as actual progress. Have you seen instances where going slower and steadier would have been better and actually resulted in a project finished sooner?