Ideas and opportunities for the development of electronics in Russia
Sometimes I come up with interesting ideas about what kind of device it would be possible to develop if there were a customer and a consumer. Sometimes it's about once an hour. These ideas do not let me sleep, do not let me work. I am making inhuman efforts to stay within the scope of the tasks for which the contracts were concluded. I used different ways to distract myself from these ideas: I told them the biggest criticism of those that I know; I forced myself to calculate in detail the cost of implementing each new idea, put old MCS51s under my pillow ... but nothing helps.
And now I want to try out another way: to tell about my ideas and thoughts on Habré.
')
Hi Habr!
Good news! Now we can produce printed circuit boards of the 5th accuracy class in Russia. Why is this so important? Because if you want to make something new, interesting and modern, then you cannot do without the 5th grade of accuracy. Almost any BGA chip requires a motherboard of grade 5 accuracy. Cell phones, tablets, SSD-drives, electronic readers - all of these devices contain, for example, mass storage chips (Mass Storage). Now on the market there are two types of chips for this purpose - NAND and eMMC. NAND is very difficult to use and even dangerous in the case of poorly written service software, but eMMC is just an SD card in a BGA package. T.ch. NANDs can now be seen except in cheap Chinese tablets and video recorders.
It is the capabilities of our domestic manufacturers of PP for a long time made it difficult to use BGA chips in Russia.
Indeed, why do we need RAM? Why not keep all data (including running processes) in non-volatile memory? How convenient it would be: the power was gone - the processor stopped, the power appeared - the processor continued to perform the tasks further with the instruction on which it stopped. Instant Hibernate / Wakeup! How many problems would immediately disappear. For example, journaling file systems in many tasks would simply not be necessary!
Of course, we are stopped by the speed of all available non-volatile data storage methods. However, there is good news: magnetoresistive memory has been developed for more than ten years. The speed and number of rewriting cycles - as in operational, independence from external power - as in NVM. Not so long ago, samples of this memory appeared on the market, allowing to assemble an array of 8–16 MB. This makes it possible now to deploy Linux in this memory and begin work on its adaptation to the new conditions, so that by the time the magnetoresistive memory is equal in price to the usual operational memory, be on a horse and with a weapon. And now you can begin to apply this technology in those tasks where a graphical interface is not required (for example, a router with ever-living Linux on board looks very good).
How much time the embedded programmers spend on developing code on the old, inconvenient and dangerous C. But ... again the good news! Matz has released mruby, which has virtually no external dependencies, is written in C and is easily embedded anywhere. One Japanese fan presented a report on Ruby Conf 2012, in which he described his experience of embedding the interpreter of this wonderful programming language on Wednesday with 1 MiB of code memory and 128 KiB of data memory! Processors with such characteristics cost a measly $ 3- $ 4 (for mass production). At the same time, the speed and safety of development increase significantly. You can even build some kind of operating systems, because Ruby has no pointers and the task of controlling access there is solved by itself (at the level of a programming language!).
Many people believe that embedded and interpreted high-level programming languages ​​are mutually exclusive concepts. But it is not so! I can give an example from my own life as an example. We developed a smart flash drive. In addition to the data storage functions, the device had a special logic implemented by the customer. The USB stack and its profile - Mass Storage - implemented themselves. Before passing, we checked read and write speeds many times, and optimized processes. As a result, they achieved 14 MiB / sec for reading raw data and 10 for writing. For those who are not very oriented, I will say that this is almost the limit of what can be implemented on USB 2.0 Highspeed without using ASIC. When the project was handed over and the customer began to develop his own logic for the device, it turned out that the encryption speed (it was GIS) was very low. We tried for a long time to find out what the matter was, until we found out that we forgot to unscrew the processor frequency to the maximum: it worked at 60 MHz, instead of 180, and this did not affect the read / write speeds . Why is this happening? Yes, because 95% of the standard firmware code for a well-designed actuator is usually administrative work: setting up registers, issuing commands to start procedures, error handling, etc. All in-line operations should perform (ideally) specialized modules. The processor should not be engaged in non-intellectual work - it should organize the process, and the non-intelligent module should do the nailing, which can do nothing except its special work, but does this work with maximum speed and, most importantly, parallel to all other processes in the chip! So, the performance of these organizational processes is a non-critical parameter. Even if they suddenly begin to be performed 10 times slower, this is unlikely to affect the overall speed of the device. But it is precisely this organizational activity that is the most difficult-to-design node; it is on it that most of the code goes. So why not be interpreted by this code for the sake of speeding up development and taking care of the developer's nerves?
We are now just doing research in this area, and if we see from the comments that it’s not just our interest, we’ll publish the results. We embed mruby in the NXP LPC18xx.
Since we have completed our first project, in which it was necessary to develop a flash-like device, I haven't let go of the idea that a flash drive with a lot of non-standard functions might be useful to many. Here are some of these features:
Unfortunately for the development of this device such a team as we need to spend about six months. And despite the fact that we already have extensive experience in developing devices of this class. Without investments, this cannot be done, and investors find something interesting in this idea. But if someone implements this idea - I will only be glad, for that I write about it here.
Do you like the picture quality of your car video recorder? I do not. I have seen many DVRs (including from the inside), and they all have one major drawback: due to the use of lossy compression algorithms under certain conditions (at dusk or shaking), it is impossible to even see the number of the 10-15 vehicle on the screen meters away But this is one of the most important purposes of the DVR: to record the number of the car or the person / signs of the person who participated in the DT or other incident. Why it happens?
All DVRs compress video stream. To compress can be done on the fly, use hardware codecs. To develop such a codec even by the existing mathematical algorithm is an incredibly difficult task, feasible only for the colossus of the electronics industry. The colossi, as you know, DVRs do not produce (by the way, I wonder why? I know that in many countries car DVRs have not received such widespread use as in China). Fortunately, there are several hardware platforms produced by the daughters of these colossi (or with their support). DVR developers take as a basis such a software and hardware platform, pack it into a case (often without even re-splitting the board!), Configure it, glue their nameplates, and sell it. For example, the well-known DOD F900LHD is built on a Yamaha platform widely known in narrow circles with an Ambarella processor.
Thus, the developers of video recorders themselves are not involved in the development of the main function of their device, and sometimes they cannot even correct the configuration of the codec (not to mention seriously modifying the implementation of the algorithm). They are forced to use what they have, they have no other way out (unless they deviate from the adopted design of the DVR). The situation is aggravated by the fact that most manufacturers are guided by the low-cost segment and therefore do not intentionally twist the quality to the maximum - the DVR will not be omnivorous with respect to SD cards. In addition, video codec configuration involves focusing on a specific parameter. For example, it will either be well seen at night, but the picture will become unhappy, or vice versa. And it is not always possible to change these parameters - as the codec manufacturer has set, it usually works. I talked with one of the participants in the so-called market. "Russian" DVRs; I got an energetic enough person who was not too lazy to beat his Chinese suppliers, what does he want them to correct in the codec settings. Those in turn made a request to the developers of the device, which (apparently), turning to the developers of the basic hardware platform, found out how much a simple editing of the configuration can cost. The final sum was the number of six zeros (not RMB). And this configuration would still not lead to a breakthrough, just some function would work a little better.
So, the developers of video recorders have to compress the video stream so much that it often does not matter how many megapixels you have a camera, what is its viewing angle, etc. Only the general course of events is visible, but no details are visible at all. But you can store on the card 8 hours of your trips from home to work and from work to home ... And why not give up the recording duration in favor of quality? Why not write to the RAM?
Take 8 GiB of RAM. What is the duration of the video resolution of 720 Ă— 480 can be recorded in the RAM of this volume? 3 bytes per pixel x 720 Ă— 480 x 25 frames per second = 26 MiB / s. More than 5 minutes of crystal clear pictures. You have often met an accident, the history of which began earlier than 3 minutes, and the development of which would take more than 1 minute? And after the accident happened, you can take another, for example, a minute, and then transfer everything to an eMMC or SD card.
What is interesting - it is quite possible that such a DVR can be quickly developed in Russia. The fact is that the most difficult part of all DVRs are hardware video codecs. These codecs are proprietary and require a license purchase; you must pay deductions from each device sold, but this is not even the greatest difficulty. The biggest difficulty lies in the fact that developers who have not provided guarantees for millions of copies of their products will simply not be contacted ...
I described my ideas very briefly. In fact, from each of them you can make a whole post. But where to get time for this? So, if anyone has an interest in one of the topics covered in this post, I will be happy to discuss your thoughts in the comments. In addition, it would be interesting to hear about what the iron developer can tell.
I did not think up in which hubs to add my post. If the “Development of hardware” hub were added, “Programming microcontrollers” would be somewhat wrong (although the audience is almost the right kind), “DIY or DIY” is not at all. I would be grateful for the hint.
______________________
And now I want to try out another way: to tell about my ideas and thoughts on Habré.
')
Hi Habr!
Now we can do much more!
Good news! Now we can produce printed circuit boards of the 5th accuracy class in Russia. Why is this so important? Because if you want to make something new, interesting and modern, then you cannot do without the 5th grade of accuracy. Almost any BGA chip requires a motherboard of grade 5 accuracy. Cell phones, tablets, SSD-drives, electronic readers - all of these devices contain, for example, mass storage chips (Mass Storage). Now on the market there are two types of chips for this purpose - NAND and eMMC. NAND is very difficult to use and even dangerous in the case of poorly written service software, but eMMC is just an SD card in a BGA package. T.ch. NANDs can now be seen except in cheap Chinese tablets and video recorders.
It is the capabilities of our domestic manufacturers of PP for a long time made it difficult to use BGA chips in Russia.
RAM - we need it?
Indeed, why do we need RAM? Why not keep all data (including running processes) in non-volatile memory? How convenient it would be: the power was gone - the processor stopped, the power appeared - the processor continued to perform the tasks further with the instruction on which it stopped. Instant Hibernate / Wakeup! How many problems would immediately disappear. For example, journaling file systems in many tasks would simply not be necessary!
Of course, we are stopped by the speed of all available non-volatile data storage methods. However, there is good news: magnetoresistive memory has been developed for more than ten years. The speed and number of rewriting cycles - as in operational, independence from external power - as in NVM. Not so long ago, samples of this memory appeared on the market, allowing to assemble an array of 8–16 MB. This makes it possible now to deploy Linux in this memory and begin work on its adaptation to the new conditions, so that by the time the magnetoresistive memory is equal in price to the usual operational memory, be on a horse and with a weapon. And now you can begin to apply this technology in those tasks where a graphical interface is not required (for example, a router with ever-living Linux on board looks very good).
Ruby into every chip
“It's half past five in the morning ... Do you know where your stack pointer is now?”
Author unknown (discovered on Habré)
“Writing in C or C ++ is like working with a chainsaw without any protection.”
Bob Gray. Writer.
How much time the embedded programmers spend on developing code on the old, inconvenient and dangerous C. But ... again the good news! Matz has released mruby, which has virtually no external dependencies, is written in C and is easily embedded anywhere. One Japanese fan presented a report on Ruby Conf 2012, in which he described his experience of embedding the interpreter of this wonderful programming language on Wednesday with 1 MiB of code memory and 128 KiB of data memory! Processors with such characteristics cost a measly $ 3- $ 4 (for mass production). At the same time, the speed and safety of development increase significantly. You can even build some kind of operating systems, because Ruby has no pointers and the task of controlling access there is solved by itself (at the level of a programming language!).
Many people believe that embedded and interpreted high-level programming languages ​​are mutually exclusive concepts. But it is not so! I can give an example from my own life as an example. We developed a smart flash drive. In addition to the data storage functions, the device had a special logic implemented by the customer. The USB stack and its profile - Mass Storage - implemented themselves. Before passing, we checked read and write speeds many times, and optimized processes. As a result, they achieved 14 MiB / sec for reading raw data and 10 for writing. For those who are not very oriented, I will say that this is almost the limit of what can be implemented on USB 2.0 Highspeed without using ASIC. When the project was handed over and the customer began to develop his own logic for the device, it turned out that the encryption speed (it was GIS) was very low. We tried for a long time to find out what the matter was, until we found out that we forgot to unscrew the processor frequency to the maximum: it worked at 60 MHz, instead of 180, and this did not affect the read / write speeds . Why is this happening? Yes, because 95% of the standard firmware code for a well-designed actuator is usually administrative work: setting up registers, issuing commands to start procedures, error handling, etc. All in-line operations should perform (ideally) specialized modules. The processor should not be engaged in non-intellectual work - it should organize the process, and the non-intelligent module should do the nailing, which can do nothing except its special work, but does this work with maximum speed and, most importantly, parallel to all other processes in the chip! So, the performance of these organizational processes is a non-critical parameter. Even if they suddenly begin to be performed 10 times slower, this is unlikely to affect the overall speed of the device. But it is precisely this organizational activity that is the most difficult-to-design node; it is on it that most of the code goes. So why not be interpreted by this code for the sake of speeding up development and taking care of the developer's nerves?
We are now just doing research in this area, and if we see from the comments that it’s not just our interest, we’ll publish the results. We embed mruby in the NXP LPC18xx.
Swiss flash drive system administrator
Since we have completed our first project, in which it was necessary to develop a flash-like device, I haven't let go of the idea that a flash drive with a lot of non-standard functions might be useful to many. Here are some of these features:
- Configurable number of LUNs . LUNs are logical partitions of the device at the Mass Storage driver level. For the end user, LUNs look like standalone physical disks . For example, several LUNs usually have card readers: one LUN per slot. For each LUN, you can provide a media type setting: a regular hard disk, CD, removable / non removable, etc. For each disc, you can provide the task access mode: RW / R. This is all convenient, for example, when some old program wants to work only with an inserted CD with the correct serial number. You can split our Swiss flash drive into two LUNs: one for this CD, the second for the usual removable media.
- RAID modes . On the device, you can place not one, but several memory chips and implement RAID0 / 1 modes. And it can be done in such a way that one LUN is RAID0, the second is RAID1, the third is the usual “flash drive”, and the fourth is generally a CD ...
- Non-standard interfaces . Sometimes the system administrator has to take in the hands ... USB-Floppy. Why not pick up a flash drive that can disguise itself as a floppy disk?
- Programmable buttons and display . It would be convenient to have several job profiles and be able to quickly switch between them. To do this, you can provide several buttons on the case and a display to display the current profile. In addition, buttons can be made fully programmable: for example, assign one of the key combinations to a complete destruction of data on the device. Well, you understand about the application in which area I speak ..
- USB 3.0 and> 100 MiB / sec for reading. Not so much a feature as just a requirement of time.
- Work as a beer bottle opener . And what, unless the system administrator does not need such a function?
Unfortunately for the development of this device such a team as we need to spend about six months. And despite the fact that we already have extensive experience in developing devices of this class. Without investments, this cannot be done, and investors find something interesting in this idea. But if someone implements this idea - I will only be glad, for that I write about it here.
High Definition Video Recorder
Do you like the picture quality of your car video recorder? I do not. I have seen many DVRs (including from the inside), and they all have one major drawback: due to the use of lossy compression algorithms under certain conditions (at dusk or shaking), it is impossible to even see the number of the 10-15 vehicle on the screen meters away But this is one of the most important purposes of the DVR: to record the number of the car or the person / signs of the person who participated in the DT or other incident. Why it happens?
All DVRs compress video stream. To compress can be done on the fly, use hardware codecs. To develop such a codec even by the existing mathematical algorithm is an incredibly difficult task, feasible only for the colossus of the electronics industry. The colossi, as you know, DVRs do not produce (by the way, I wonder why? I know that in many countries car DVRs have not received such widespread use as in China). Fortunately, there are several hardware platforms produced by the daughters of these colossi (or with their support). DVR developers take as a basis such a software and hardware platform, pack it into a case (often without even re-splitting the board!), Configure it, glue their nameplates, and sell it. For example, the well-known DOD F900LHD is built on a Yamaha platform widely known in narrow circles with an Ambarella processor.
Thus, the developers of video recorders themselves are not involved in the development of the main function of their device, and sometimes they cannot even correct the configuration of the codec (not to mention seriously modifying the implementation of the algorithm). They are forced to use what they have, they have no other way out (unless they deviate from the adopted design of the DVR). The situation is aggravated by the fact that most manufacturers are guided by the low-cost segment and therefore do not intentionally twist the quality to the maximum - the DVR will not be omnivorous with respect to SD cards. In addition, video codec configuration involves focusing on a specific parameter. For example, it will either be well seen at night, but the picture will become unhappy, or vice versa. And it is not always possible to change these parameters - as the codec manufacturer has set, it usually works. I talked with one of the participants in the so-called market. "Russian" DVRs; I got an energetic enough person who was not too lazy to beat his Chinese suppliers, what does he want them to correct in the codec settings. Those in turn made a request to the developers of the device, which (apparently), turning to the developers of the basic hardware platform, found out how much a simple editing of the configuration can cost. The final sum was the number of six zeros (not RMB). And this configuration would still not lead to a breakthrough, just some function would work a little better.
So, the developers of video recorders have to compress the video stream so much that it often does not matter how many megapixels you have a camera, what is its viewing angle, etc. Only the general course of events is visible, but no details are visible at all. But you can store on the card 8 hours of your trips from home to work and from work to home ... And why not give up the recording duration in favor of quality? Why not write to the RAM?
Take 8 GiB of RAM. What is the duration of the video resolution of 720 Ă— 480 can be recorded in the RAM of this volume? 3 bytes per pixel x 720 Ă— 480 x 25 frames per second = 26 MiB / s. More than 5 minutes of crystal clear pictures. You have often met an accident, the history of which began earlier than 3 minutes, and the development of which would take more than 1 minute? And after the accident happened, you can take another, for example, a minute, and then transfer everything to an eMMC or SD card.
What is interesting - it is quite possible that such a DVR can be quickly developed in Russia. The fact is that the most difficult part of all DVRs are hardware video codecs. These codecs are proprietary and require a license purchase; you must pay deductions from each device sold, but this is not even the greatest difficulty. The biggest difficulty lies in the fact that developers who have not provided guarantees for millions of copies of their products will simply not be contacted ...
Conclusion
I described my ideas very briefly. In fact, from each of them you can make a whole post. But where to get time for this? So, if anyone has an interest in one of the topics covered in this post, I will be happy to discuss your thoughts in the comments. In addition, it would be interesting to hear about what the iron developer can tell.
I did not think up in which hubs to add my post. If the “Development of hardware” hub were added, “Programming microcontrollers” would be somewhat wrong (although the audience is almost the right kind), “DIY or DIY” is not at all. I would be grateful for the hint.
______________________
The text was prepared in the Habr Editor from © SoftCoder.ru
Source: https://habr.com/ru/post/224749/
All Articles