标签: memory

Here is my proposed definition of firmware:   ‘Firmware is the art of designing software that successfully controls and/or monitors the physical and natural world through electronics.’   It’s not your father’s definition is it? But I would argue the definition has actually changed over the years.   Words change their meaning when the old meaning no longer has value or is obsoleted by the modern world. This is called (yes there really is a name for this) etymology. For example computer used to mean a person who computes.   Argh! My ears cannot hear it! English!! Engineers hate English! It’s our kryptonite! Which is also why engineers hate writing things down or creating requirement documentation. But a poorly written requirement will wreak havoc and chaos on your project.   So does a poor definition wreak havoc!   So as much as we all profess our love of math and hate (ok have a strong distaste for) English, having no clear definition for what hundreds of thousands of engineers use to define their profession is not helpful.   What is the present definition of the word firmware you ask? Oh it’s a mess. I did some research on this. I’ve also done various surveys on the word through the firmware LinkedIn group. None of it’s pretty.   I went searching for the definition at IEEE’s standards definition database. Sound like the logical source right?   I found 11 different definitions.   Yes 11 variants of a definition that is no longer relevant. Regardless, the going theme seems to be software that resides in non-volatile storage that can be read only by a computer.   Really. Or should I say really not helpful.   How does this convey anything useful and distinguish it from software? Is this what you tell people when they ask you what firmware is? How is this definition really different then saying firmware is software? All that is added to the definition is the software’s residence -- that being non-volatile memory (well at least until you move said firmware into RAM, but I digress).   In an attempt to improve things, many have abandoned the use of the word firmware and replaced it with embedded software. Not sure how this solves anything. In fact I think it makes matters worse. It ties it even tighter to software and lessens the useful distinction.   Yet how many computer scientists do you know that write firmware? I’ve done studies on this and it’s very few. In a recent survey I did of degrees held by firmware engineers, I found that of 377 sampled, 13% held a bachelors in computer science. The great majority (43%) had a bachelor’s degree in electrical engineering. About 80% had an engineering degree of some kind. Clearly there is an important engineering role in firmware that is sorely missing from 1) your father’s definition, and 2) definitions characterizing it as software, which is not a field of engineering.   So firmware is a field of engineering. No, you can’t call it software engineering since this is the engineering of software itself. In fact I still fail to see how calling us ‘embedded software engineers’ is helpful since embedded just categorizes a field of software engineering.   Firmware engineers must have a strong grasp of engineering first and foremost. After that they need a good understanding of electronics. I say this because a well-written piece of firmware should have a driver layer that connects directly to electronic circuits. Also a well-written piece of firmware should also have some kind of device layer where the devices are often electronic sub-systems. For example if you are to measure voltage, you should understand at a high level the electronics that create that voltage. Much of the application layer must rely on engineering concepts. Similarly, if I am controlling a mechanical system through electronic stimulus, I need to have some understanding of both electrical and mechanical engineering.   Eventually you escape the engineering such as in a GUI implementation on a TFT LCD touchscreen. So at some point it departs from engineering yet remains a science -- computer science in fact. It is at this point where the ‘software’ that resides in the non-volatile storage really is purely software.   So which definition do you think would help clarify to friends and family, organizations, corporations, colleges and Universities?   ' Software that resides in non-volatile storage '?   Or…   ‘Firmware is the art of designing software that successfully controls and/or monitors the physical and natural world through electronics.’   Back to the trenches! Thanks for reading!   Bob Scaccia is President of USA Firmware, a Software, Hardware, Firmware and IoT Consulting and Design Services Company located in Brecksville, Ohio. Bob also runs the largest Embedded Software group on LinkedIn with 14,000 members and growing and has written articles on firmware curriculum, trends, best practices and using object oriented approaches in the C language.

The dentist drill, so dreaded by some, may no longer be needed for tooth repair as a new technique has been developed at King’s College London.   It is called electrically accelerated and enhanced re-mineralization (EAER), and the inventors claim that it accelerates the natural movement of calcium and phosphate minerals into the damaged tooth. The technique employs a two-step process. First, the damaged area of enamel in the tooth is prepared, and then tiny electric current pulses are used to move the minerals needed for repair into the repair site. It is currently in development, and its developers suggest it could be available for general use in about three years.   To those of us with an interest in non-volatile (NV) memory, the process strikes a chord. The movement of material by electro-migration is a bane to developers of some types of emerging non-volatile memory, and the very driving force for others.   The building of links, usually conducting, by electro-migration-driven movement, by electro-chemical means (e.g., plating), by electro-crystallization, or by electric field, in a manner that can be reversed, are now all part of the emerging NV memory mix. Those same effects can also appear as reliability problems by shortening the life of some types of memory device as well as other solid-state devices.   The similarity between this new emerging dentistry and NV memory technology is illustrated in the two cross sections shown in the figure below. On the right-side is a cross section of a generic NV memory with the active material between two electrodes (green). The conducting link required to write the memory to one of its logic states grows from one electrode towards the other.   On the left side of the figure is the cross-section of a tooth undergoing repair with the electric pulses. The repaired tooth material is growing into the active material. The active material (shown in pink in the tooth cross-section) is what must be applied as part of the preparation process described as the first step. This will also need to have a sort of electrode in contact with it in order to apply the electric pulses. Unlike most non-volatile memory, the material deposited as the repair does not have to be conducting. But the pink preparation material will need to be (unless the process of moving the material is electric field driven, in which case it could be dielectric and more insulating). In the figure, we have assumed that a ground link to complete the circuit is through the body and gum.   Clearly, the dentists and their patients do not require the growth to be reversed, so perhaps in an electronics industry analogy, this process should be more accurately classified as one-time programmable memory (PROM). In any case, it is certainly an interesting development.   A new company named Reminova , based in Perth, Scotland, has been set up to commercialize the research and is in the process of seeking private investment to develop the EAER technology. It is the first company to emerge from the King's College London Dental Innovation and Translation Centre, which was set up to take novel technologies and turn them into new products and practices.   Ron Neale is an independent electrical/electronic manufacturing professional .

 当FreeRTOS每次创建任务，队列，互斥，软件定时器，信号量时分配相关的RAM。标准C函数库的malloc()和free()虽然有些情况下能用于分配内存与释放内存，但是它们却有如下的缺点： 1.在嵌入式系统中它们并不是都是有效的 2.它们占据了有效的代码空间 3.它们是不安全的线程 4.它们的执行时间是不确定的 ...因此为了解决这个问题需要另一种分配内存的方法被使用！ 嵌入式系统与实时系统有很多种不同规格的RAM和时间要求。因此往往单一的内存分配算法只能适用于单一的应用程序。 FreeRTOS为解决这个问题，当RTOS内核需要RAM时使用的是pvPortMalloc()而不是malloc()，当RTOS内核释放内存时使用的是pvPortFree()而不是free()。 FreeRTOS的源文件中有四个内存分配文件heap_1.c,heap_2.c,heap_3.c,heap_4.c。如有需要，其它的内存分配方式算法文件可以被添加。在一个工程中上面的四个文件只能使用一个文件。     Heap_1.c 这种方式的原理是将一个大的内存块按照每次的内存分配需求从里面划分出来。通过查看heap_1.c的源代码可知，分配内存前需要将要分配的大小按照微处理器的架构进行对齐，如16bit单片机是按双字节对齐的，之后还要确定内存的起始地址是边界对齐的(具体操作是对内存地址的操作)。同时每次分配前还要和空闲的内存大小作比较，如若有误可运行用户定义的钩子函数。在这种方式下每次内存分配的时间都是相同的，但是这种方式不能将已分配出去的内存进行回收。因为在这种方式下，内存分配的数据结构只是一个简单的数组，从原理上就不能提供这些灵活的功能，在Heap_2.c和Heap_4.c中采用的是链式算法，相比数组数据结构而言就具有了很高的灵活性。   Heap_3.c Heap_3.c没有什么特别之处，就是对编译器本身的malloc()和free()函数进行了重包装(simple wrapper)。这个包装只是简单的让malloc()和free()变得安全些(通过查看代码发现其实并未对这两个函数做很多的包装，所以估计这两个内存分配函数的线程也并不是很安全)。这种方式要求如下几点： 1.要求链接器自己建立内存空间(Heap),并且编译器要提供标准的malloc()与free()函数 2.由于是使用简单的malloc与free函数，所以执行时间同样也是不确定的 很有可能的会增加FreeRTOS的内核代码，所以在内存极其有限的硬件平台上就不能很好的使用。   Heap_2.c Heap_2.c使用了最匹配的算法，它允许被分配的内存能释放。它使用了单链表的数据结构，初始下内存的大小为可配置的最大值，然后在一步步划分出去。同样它也是从一个大的内存块中根据需要的内存大小而从里面划分出来的。但是它却不具有将连续相邻的空闲块联合成一个大块，而是采用将空闲块按照由小到大的顺序排列起来(排列的地方依旧在原来的的内存块中)，所以会让原来本是相邻的块变得不相邻，这就将造成内存碎片(即打破了原来的内存结构,有的部分是存了数据而有的部分又没有存数据)换句话说也就是它不具有"合并(coalescence)"算法。这种方式具有如下特点： 即使当应用程序不断的删除任务，队列，信号，互斥等等也能正常使用 当分配内存与释放内存的大小是随机的这种方式是一定不能使用的。 1.如果应用程序不断的动态创建或删除任务，但是每次改变的内存大小都是相同的，那么这种方式是可以使用的，因为由于每次分配的大小都是相同的，即使释放后按照由小到大的顺序来排列也是按原来的结构组织的，并且由于分配的内存大小是相同的不会分到下个区段里去。然而如果每次分配的内存大小不相同，那么一个大块将会被打断成许多的小块，造成了大量的内存碎片，然后如果还继续分配内存的话，就很有可能引起分配错误导致程序运行异常(比如，分配的内存大小超过了此空闲区段的大小而只能延伸到下个区段里去，但是极有可能下个区段已经被使用了)。同理，队列的分配与释放也如此！   2.如果应用程序是直接的调用pvPortMalloc()与pvPortFree()函数，而不是通过其它的API函数调用，在这种情况下是不能使用这种方式的。 2.1如果你的应用程序中的任务，队列，信号，互斥的顺序是不可预知的，那么就有可能出现内存碎片的情况。当然这种情况发生的概率会很低，但不可掉以轻心！ 2.2每次的执行时间是不确定的(因为使用了链式结构)，但是相比C库里的内存分配函数malloc与free却是具有高效率的。 Heap_2.c是适合于很多小型的实时系统的，这种实时系统往往会动态的创建与删除任务。   Heap_4.c   Heap_4.c也使用了最匹配的算法，它和Heap_2.c基本上是相似的，唯一不同的就是这种算法支持空闲块联合，这样就避免了内存碎片的出现。这种算法具有如下特点： 1.即使当应用程序不断的创建或删除任务，信号，队列等等情况下，也是能正常使用的 2.不会像Heap_2.c那样会产生大量的碎片，但在某些情况下也是会产生内存碎片的。 3.同样每次的执行时间也是不确定的 这种方式是针对想在应用程序中直接使用可移植层来分配内存的(可能翻译的不是很清楚，等以后具体应用在总结)。   FreeRTOS的代码编写风格与思路还是比较清晰的，可以读读原代码，值得我们学习与借鉴！

In this story, I will tell how I solved an intermittent RAM semiconductor memory problem using music. In 1978, I met three brothers who owned a large machine shop in Ottawa, and they agreed to test a computer-controlled milling machine for me. I designed and built a self-programmable, point-to-point, numerical control (NC) system for a two axis Excello 602 milling machine. The system used closed loop stepper motors in the X and Y axis to keep the servos honest, and the Z axis used an air operated quill, which had a rotating cutter attached to it. Memory was programmed at the machine tool using a small keyboard, which was unheard of at that time. A magnetic digital cassette unit stored the programs for future production runs. No paper tape was used. The plan was for all four of us to get into business to manufacture these systems. I had started this project on my own in my flat, and now moved to the machine shop to finish it. I had no staff and very limited funds. The it. All went well until we started testing the machine. It would work smoothly for a while, but then it would intermittently mill faulty aluminium parts, or suddenly miss a step, or cut an incorrect hole in the work piece. Sometimes it would even threaten to cut into the milling machine table! This appeared to be a memory problem, but I didn't know how to fix it. Yet, I had to solve this problem or the project would fail. I only had a 10MHz dual trace oscilloscope and a 4 digit DVM. So, what was the problem? Was it system timing, or bad chips? The memory board used 32 static RAM ICs, so locating the faulty one was going to be challenging. A 1024 x 32bit word static RAM memory (2102s) was the heart of the system. This was new technology at the time. The NC system used BCD (binary coded decimal) numbers programmed into the memory that advanced through it to fabricate the parts. If the memory information was faulty, the machine would make scrap pieces. My partners running the machine shop wanted results, and I did not have a lot of time to convince them that this system was a viable product. The solution came from my childhood musical training, which gave me an idea—play music through the system! The NC system had a programmable audio tone generator, which was used to alert the operator to change parts when fabrication was completed, so it could be programmed to play a song. Musical patterns are similar to machine instructions. All the system timing stayed the same so it was a realistic test. RAM chips were quite expensive so there were few spares. I picked the song "Raindrops Keep Falling on My Head" because it was long enough to fill the memory and the tone generator could handle the range. It was a popular song at the time, so the operators would know if it sounded okay, or not. When humans listen to music they can detect a small error right away. When I played the song, I found the problem quite soon because the machine played wrong notes where the memory was faulty. I just had to go to that area of the music in the program RAM to find it. This saved a huge amount of time and expense trying to find the faulty memory. Later, when the NC system was introduced to the production floor, the machinists were fascinated by the music. Music became part of the diagnostic routines every day to test the memory. Everyone was happy with the machine and my partners gained a lot of machining contracts. Machine shop customers were thrilled by the musical milling machine. The NC machine worked flawlessly for a very long time after this, and to this day, I remember the feelings of excitement and pride the building of this machine and my creative solution gave me. John Barnhardt/VE3ZOV is a seasoned electronics designer (14 years)—avionics (Computing Devices), test engineering, and Lottario terminal manager (Consolidated Computer) and NC control designer (Campagna Brothers Machine Shop). He went to sales management for 18 years (Motorola Semiconductor, Ontario Centre for Microelectronics, CTS Corp.) and Component Engineering (JDS Uniphase). He submitted this article as part of Frankenstein's Fix, a design contest hosted by EE Times (US).  

In the past years, I've seen about a bunch of really great April Fools' day spoofs. Who amongst us could forget the classic WOM (write-only memory), which first saw the light of day as a Signetics pseudo-product from 1972 (check out this Signetics 25000 Series 9C46XN datasheet). And then, of course, there was the infamous Black Noise Generator circuit, which purported to be of use when setting up high-end sound systems. Recently, I learned about a smoke re-contractor that can be used to refurbish blown electronic components (I really should have held that back for today, but it was too good not to use). As an aside, the "too good not to use" makes me think of the Queeq episode from the British science fiction sitcom Red Dwarf , but we digress... All of this got me to thinking that there must be myriad April Fool's spoofs of which I remain blissfully unaware. So, what's the very best electronics-related April Fools' joke you've seen in a magazine or with which you have had personal experience?