|
BLOG OF WHY WE DESIGNED SOMETHING A PARTICULAR WAY
This blog will explain why we picked the STM32H743 for the CS7000 M17 PLUS and not continue with the STM32F405 used in the CS7000 M17.
The answer lies in the objective we were trying to achieve and over 50 years of experience with computers and software.
The objective was to make a radio that can not only do M17 but also do all the other digital formats used in modern radios such as P25, NXDN, Fusion, DMR and others. There are two issues to achieve that objective. The first issue is the amount of program memory needed and the second issue is the speed of the computer.
We know that the DMR radios with all the features available take about one megabyte of memory. If you leave out many of the features, you can get the memory size down to 500K. If you now have eight different digital protocols, you could be looking at close to 8 megabytes of program memory. That could be reduced somewhat because you have many common routines with the different protocols.
We know that DMR radios work just fine with the STM32F405 radios running at 168 MIPS. However, those radios have a baseband chip which greatly reduces the speed requirements. We also know the M17 radio works with the STM32F405. What we do not know is what speed do we need for some of the other formats.
?
The STM32F405 uses up nearly all its ram memory and program memory for doing DMR and Analog. So obviously that part will not work for multiple protocols. However, if we take out many of the DMR features, we might be able to accommodate another digital format such as M17 or Fusion. The STM32H743 has double the code memory and three times the RAM memory so we might be able to fit most of the protocols in that chip. However, that is not enough because the objective is fit all the protocols in the radio. We also need more memory for features that have not even been contemplated.
The solution was developed over 50 years ago by IBM and possibly others. They called the solution ¡°overlays¡±. Microsoft later gave it a fancy name called ¡°virtual memory¡±. The first time I have seen it was in an IBM 1130 minicomputer over fifty years ago. This computer had eight thousand words of memory. The more expensive version of the IBM 1130 had sixteen thousand words of memory. The programs that I used sometimes needed hundreds of thousand words of memory. The hardware was primitive and did not have floating point support.
The solution was clever. You saved some space in RAM for code memory. If you needed to do a floating-point multiply operation, you found the routine on its disk and put it in RAM and executed it. If you next needed to do a floating-point divide, you found the routine on its disk and put it in the same location in RAM memory and executed it. Because of the very limited amount of RAM, those programs ran very slow.
At that time, it was not unreasonable for you to start a program and then have lunch and hope it was finished after lunch. Not all computers can execute firmware from RAM. The ARM processors such as the STM32H743 do have that capability. Because the RAM space of the STM32H743 is so large, we have lots of space for program overlays.
The next issue is speed. We know the M17 protocol works at 168 MIPS on the STM32F405. The STM32H743 executes at a speed nearly three times faster and sometimes over three times faster because of its extended instruction set. Therefore, I believe that chip will do all the protocols with speed to spare.
The only roadblock is software. What makes this project feasible is the fact that almost all the firmware we need has already been done on the MMDVM. The MMDVM is open source so we should be able to complete this project in a reasonable amount of time.
Some of you might be thinking that there must be at least one other way of doing that. There are many other choices that might work and, on the surface, might be better. I will give some of those choices and explain why they were not chosen.
For those of you who are familiar with the ARM architecture, might know you can run code memory directly from external serial flash memory. To do this you will need at least two flash memory chips. The problem with this is the speed of execution runs considerably slower and might be too slow for the application. We did not want to try it and find out months later that it did not work satisfactorily.
For those of you who kept up with the CS7000 project many years ago, know that we had the perfect hardware solution. It used a dual processor architecture from Texas Instrument. One processor was a super-fast floating-point DSP chip and the other processor was a very fast ARM chip. The radio has lots of RAM and Code memory on external chips. There were only two issues. The first issue was cost. It cost us about twice what the CS7000 M17 PLUS will cost to manufacturer. The second and most important reason was the dual processor architecture was too difficult to work with. Even with a little help from the radio manufacturer, it was beyond our capabilities. With a lot of help we might be able to finish it but at that time they were not willing to give us the help needed.
There was another practical consideration. To get the manufacturer to help us with this project, we wanted to minimize his effort. The design of this radio is almost identical to the radio he is currently selling.
| 
Bob, N1KPR
