Diskussions- und Newsboard des DARC-Ortsverbandes I40
allgemeine Kategorie => mcHF Projekt Deutsch / English (here you can discuss everything related to mcHF) => Message started by: yo2ldk on 13. September 2017, 15:19:39

Title: stm32f4 vs stm32f7 compatibility
Post by: yo2ldk on 13. September 2017, 15:19:39

Some time ago, reading here and on some pdf's as the two CPU is pin to pin compatible, I think it to change the CPU on mcHF with STM32F767VIT6.
today, a friend on facebook group asking for CPU upgrade, so that impulse coming again and I was already to buy one
To be sure anyway, I look it at pinouts, but seems that is not compatible... to bad.
it is someone who really have F7 series on mcHF ?


Title: Re:stm32f4 vs stm32f7 compatibility
Post by: yo2ldk on 13. September 2017, 15:20:24

pinouts pdf to compare

Title: Re:stm32f4 vs stm32f7 compatibility
Post by: DF8OE on 13. September 2017, 20:10:48

On mcHF STM32F429VIT6 or STM32F439VIT6 are "bleeding edge" - no possibility to get a faster / somewhat else "better" MCU. But OVI40 is designed for use of STM32F7 - and uses 144LQFP package for much more possible connections to outer world 8)

vy 73
Andreas

Title: Re:stm32f4 vs stm32f7 compatibility
Post by: dl8mby on 13. September 2017, 20:18:15

Dear OM YO2LDK,

if you would like the effort, you could design your own LQFP100 pcb adapter.

Top side with the STM32F7XX pin layout and bottom side
with the STM32F4XX pin layout that has to fit the UI pcb
pads.
Will be a bit tricky to solder the adapter bottom side
and the adapter board have to be near of the same
dimension as the LQFP100 case.
This is a challenge but will give you a bost in performance
for the old mchf design.

Andreas will perhaps argue that it's better to wait for the
new I40 pcb design so it's up to you what you prefere to do.

Markus
DL8MBY


Title: Re:stm32f4 vs stm32f7 compatibility
Post by: DF8OE on 13. September 2017, 20:24:02

Additional:
UHSDR firmware does only accept buttons, I2C, I2S and other GPIOs on mcHF using exclusively STM32F4. If you compile firmware for F7 you will get pin design for OVI40 with much more buttons, two I2S, two audio codecs and so on. No firmware available for mcHF layout using STM32F7. We will not support this because the amount of OMs who wants this solution will be ~0 - I think...

Of course it is possible - but I will not do that work.

vy 73
Andreas

Title: Re:stm32f4 vs stm32f7 compatibility
Post by: dl8mby on 13. September 2017, 20:49:04

Dear Andreas,
dear Danilo,

just for better understanding.
I was convinced that a stm32f4x binary
could be executed on a stm32f7x controller
so that the same programm will run faster
due to the clock speed increas (216MHz).

Am I wrong?

Markus



Title: Re:stm32f4 vs stm32f7 compatibility
Post by: DF8OE on 13. September 2017, 21:00:09

Yes - completely. Binaries for F4 and F7 are incompatible.

vy 73
Andreas

Title: Re:stm32f4 vs stm32f7 compatibility
Post by: DB4PLE on 14. September 2017, 06:46:07

Hi,

the STM32F7 can execute every (non-floating point related) instruction of the STM32F4 and it will yield the same result since both are based on the M4F architecture.
But ut has a "completely" different floating point unit (double precision), different memory architecture, differenct cache architecture, most peripheral cores have been changed (SPI, I2S, SAI, I2C, ... ), it has more instructions not found on the STM32F4.
Hey, wait, the GPIOs handling is identical...

The compatibility the manufacturer claims is based on the fact that the pinout is identical and most (if not all) peripherals are using the same pins. Tool chain is similar, if you are using the STM provided HAL software, your applications using the same peripherals are fairly easy to port, for instance although the I2C in the STM32F7 is implemented differently, we did not have to change single line of UHSDR application code between both processor types. However, I2S/SPI changed so much that we could use the I2S peripheral anymore in the F7 since no longer full duplex capable (which we need) and had to switch to use the SAI peripherals...

So even if you can make a working adapter, it would required "wiring" changes which go beyond the simple pin relocation. And I think it would be simply too much effort. It would be better to redesign the whole UI part, which in fact the OVI40 is the result which much more capable audio architecture (2 independent codecs for audio and iq processing make life so much easier!)


BTW, there is a migration document from STM explaining the "small" differences between STM32F4 and STM32F7. Essentially the "fully compatible" is more marketing than anything else. High degree yes in many areas, but full compatibility is something different from my point of view.

73
Danilo

Title: Re:stm32f4 vs stm32f7 compatibility
Post by: dl8mby on 14. September 2017, 06:56:04

Dear Andreas,

according to ST, see link below,

http://www.st.com/en/microcontrollers/stm32f7-series.html?querycriteria=productId=SS1858

Compatibility

Cortex-M7 is backwards compatible with the Cortex-M4 instruction set
STM32F7 series is pin-to-pin compatible with the STM32F4 series*

So in this case I would expect a binary compatibility and that the registers
of a STM32F4 MC are a subset of the STM32F7 MC.
HW features are extendet in the case of F7 but should also include HW
of the F4 family.

Still asking if I am wrong?

Sorry for my tenacity.

Markus



Title: Re:stm32f4 vs stm32f7 compatibility
Post by: DB4PLE on 14. September 2017, 07:18:22

Hello Markus,

see my lengthy explaination above. What you think compatiblity should mean and how STM defines it clearly differ.

73
Danilo

Title: Re:stm32f4 vs stm32f7 compatibility
Post by: dl8mby on 14. September 2017, 07:19:05

Thanks Danilo for clarification.

But the issue is different. The question is if you could run a
mchf old FW compiled for F4 on the same ui board equiped
with a pcb adapter that now mount a F7 mc on the same board.

So if the F7 binary is build using the STM provided HAL software
for the F4 and compiler/linker is configured for F7 the MC should
be able to run the code created by the compiler.

Best way to check this is to creat a smal pcb and mount a F7
onto the old UI board. Costs should be less then 50€ without
taking the time into account to create the pcb.

vy73
Markus.

PS.: By the way I had already mentioned in an old thread,
that from my point of view it will by more forward looking
to mount the MC as well as the both WM8713 chips onto
separate smal pcbs that could be plug onto the new UI
board. The new System will then be more flexible and the
om's that had troubles to solder the smal pitch ic's could
sent the smal pcb via cheap mail to others to help them to
solder them. The minor price increas should be accepted
for better handling.




Title: Re:stm32f4 vs stm32f7 compatibility
Post by: DB4PLE on 14. September 2017, 07:36:31

Hello Markus,

the answer is absolutely no. Since the peripherals are different (different registers etc) it simply will not work. The instructions will be executed but do not produce the same behavoir, so in the end it does not work. If you don't believe me, read

http://www.st.com/content/ccc/resource/technical/document/application_note/73/76/21/47/ef/d0/4c/16/DM00164538.pdf/files/DM00164538.pdf/jcr:content/translations/en.DM00164538.pdf

page 18 for instance, see which peripherals are different: USB FS, USB HS, I2C, I2S is not full duplex.

If Chris would have used SAI, no I2C, no USB: maybe. Yes, the RTC is backward compatible, hurray. Lots of other peripherals are but not some of the main ones we use.

BTW, the performance of an F4 binary on a F7 is probably not much better than on a F4 until you enable the caches which are F7 specific commands. And you'll need proper cache handling in some places to ensure data consistency.

To be fair, porting from STM32F4 to F7 was fairly painless, most changes are related to the cache handling and the use of different peripherals for audio codec communication and some other architectural changes between mcHF and OVI40.

73
Danilo



Title: Re:stm32f4 vs stm32f7 compatibility
Post by: dl8mby on 14. September 2017, 08:32:36

Danilo,

again thanks for clarification.
On the other side I could not understand why ST promote the
pincompatibility and make the effort to be (more or less) pin
compatible when no binary compatibility is given.

So old (automotiv/industrial) projects have to chenge pcb layaout
and in addition firmware, so if someone has to do both there is no
reason for pincompatibility and someone will have to designe
a totaly new device - looks for my very strange.

I will ask some ST people on the comming spc ipc drives in
Nürenberg end of November for the thoughts behind the so
called pin compatibility.

Again Thanks.

Markus






Title: Re:stm32f4 vs stm32f7 compatibility
Post by: dl8mby on 14. September 2017, 08:42:41

Sorry Danilo,

one final question ;-)

The FW inside the github for the old mchf and the new OV I40 UHSDR
compiles for both of the MC's F4 and F7 according to the switches inside
the Makefile - right?

Means this that the FW code include a huge amount of #defines to brunch
during compil time through the hw specific code?
And I do not speak about the #defines inside the HAL but about the community
code developed by you and others.

Markus


Title: Re:stm32f4 vs stm32f7 compatibility
Post by: DF8OE on 14. September 2017, 08:42:45

Markus,

you are thinking and living in a world which wants to keep things - to give things more lifetime.

That is NOT how our system works. You shall buy new, lifetime should be as short as possible - you will be pushed to be a CONSUMER.

It is a very good idea to make it impossible to run same binaries on different controllers even if they are "pin compatible". So manufacturer can push people to better consumption.

Be careful: there is strong difference between that what people (politicians, manufacturers) tell and how they act. And, honestly, sometimes compatibility to "old" things can block development. Regard 640KB issue on old processors which was drawn to Pentiums and do make much trouble - block the future...

Technically it will be much effort to adapt STM32F7 to mcHF. In my eyes it is abvsolutely senseless.

OVI40 will be available in all possible stages: as bare PCBs, as kits, as preassembled (SMD), completely assembled, and completely assembled and adjusted. And there will be available two different housings. That is the problem what was wrong with mcHF. Chris never wanted to distribute his idea in this way. He does not want to do it by himself and he does forbid others to do it. I would not lost one second to put energy in mcHF hardware.

EDIT:
Regarding your question:
Yes. You have to set switches to build a mcHF version and a OVI40 Version. At this stage there are only two swtches (MiniTRX is fully mcHF compatible) - maybe number will increase in future.

vy 73
Andreas

Title: Re:stm32f4 vs stm32f7 compatibility
Post by: DB4PLE on 14. September 2017, 09:41:30

Hello Markus,
Quote from: dl8mby on 14. September 2017, 08:42:41
Sorry Danilo,

one final question ;-)

The FW inside the github for the old mchf and the new OV I40 UHSDR
compiles for both of the MC's F4 and F7 according to the switches inside
the Makefile - right?

It is a bit differently organized, but there are some switches in the Makefile. Have a look.
Quote:
Means this that the FW code include a huge amount of #defines to brunch
during compil time through the hw specific code?
And I do not speak about the #defines inside the HAL but about the community
code developed by you and others.

Markus

By using the HAL we get away with a fairly well controlled amount of these switches, but yes there is a share of these
in the code in the places where the architectures of the TRXs differ, not so many really related to the F4 vs. F7. Not too many, since we try to keep this properly organized.
So even if both TRX variants would use the same microprocessor, these differences would exist.
The processor related differences are handled below basesw/{mchf,ovi40} to 95% or something like that.

73
Danilo

Title: Re:stm32f4 vs stm32f7 compatibility
Post by: dl8mby on 14. September 2017, 10:06:28

Dear Andreas,

I had noticed that there are switches inside the Makefile to distinguish
between the F4 or F7 hw. My question focusing on the effort to be done
to write code for both scenarios F4 (old staff) and F7 (the new one).

Is the C code divided in different paths separated by #defines or how
huge is the effort to maintain both architectures.


vy73
Markus



Title: Re:stm32f4 vs stm32f7 compatibility
Post by: dl8mby on 14. September 2017, 10:10:00

Sorry, Danilo had already answered my question.

Thanks a lot.

Markus



Title: Re:stm32f4 vs stm32f7 compatibility
Post by: yo2ldk on 14. September 2017, 11:33:04

OK, now is clear - thank you all for clarification ! :)
I wait for OVI40 , as I see, that will be much over mchf
as performance and development.
BTW is some schematics file /info available or need to wait until is ready?
Have you consider to use a little bit large screen, and maybe for a better audio coder/decoder, at least at 192kHz?
just some idea if is applicable to OVI40.

Title: Re:stm32f4 vs stm32f7 compatibility
Post by: DB4PLE on 14. September 2017, 11:36:36

Hi,
1. yes: 3.2" vs. 2.8" to keep the formfactor the same and also to keep the power consumption low)
2. No. However due to the separation of audio and iq codec (we have 2) we may go up to 96khz (this is max for WM9831) at some point.




Title: Re:stm32f4 vs stm32f7 compatibility
Post by: DF8OE on 14. September 2017, 11:42:28

You can find schematics (preliminary) here:
https://www.amateurfunk-sulingen.de/forum/attachments/mchf_ui_i40_15.pdf (https://www.amateurfunk-sulingen.de/forum/attachments/mchf_ui_i40_15.pdf)
...and 3D model here:
https://www.amateurfunk-sulingen.de/forum/attachments/UHSDR_ui_OVI40_17.pdf (https://www.amateurfunk-sulingen.de/forum/attachments/UHSDR_ui_OVI40_17.pdf)

...and photo of first prototype here:
https://www.amateurfunk-sulingen.de/forum/attachments/I40_ui.png (https://www.amateurfunk-sulingen.de/forum/attachments/I40_ui.png)

vy 73
Andreas

Title: Re:stm32f4 vs stm32f7 compatibility
Post by: yo2ldk on 14. September 2017, 14:35:49

TY Andreas,

for the schematic; the 3D model i found it earlier.
Under LCD in right is a place for one more push button,
this can be used as memory switch mode, then the others
from left can become M1 to M5 (for CW, RTTY messages fro ex.)
or, maybe you have another good solution.
STM32F7 have so many I/O, so PCB can be a little high or longer,
but I see you keep it the mchf standard; even if OVI40 will be 85%
another transceiver. ;)

73 de alex

Title: Re:stm32f4 vs stm32f7 compatibility
Post by: DF8OE on 14. September 2017, 15:04:20

Hi Alex,

yes: we want to be compatible with the 30p header used on mcHF. But we have additional headeres on our UI board - and the three buttons under the encoders do have different functions than the integrated buttons in encoders. We do have one more button betwee power and BANDM. PCB is alredy in betatest state - so no more changings can be done now. But our project will consist of more than two PCBs. Please stay tuned 8)

vy 73
Andreas

Title: Re:stm32f4 vs stm32f7 compatibility
Post by: KevinA on 04. October 2017, 03:15:31

Quote from: DB4PLE on 14. September 2017, 11:36:36
Hi,
1. yes: 3.2" vs. 2.8" to keep the formfactor the same and also to keep the power consumption low)
2. No. However due to the separation of audio and iq codec (we have 2) we may go up to 96khz (this is max for WM9831) at some point.


Has anyone done the math on sample size/sample rate/ MCU clock?
48Khz sample rate with 16 bit and 180Mhz clock F4xx (current)
96Khz sample rate with 32 bit and 216Mhz clock F7xx
192Khz sample rate with 32 bit and 400Mhz clock H7xx

What is gained with higher sample rates? What is gained with larger sample sizes?
If the MCU did nothing but DSP on the I/Q what could the maximum size and rate be?
Thanks
Kevin K2AAE




Title: Re:stm32f4 vs stm32f7 compatibility
Post by: DF8OE on 04. October 2017, 06:32:34

Hi Kevin,

using higher sample rates increases the range in spectrum / scope. Yaou can look at a wider span. We will do that oa OVI40 - it is probably not possible on mcHF because we are on the edge of RAM and audio interrupt, where important maths are done, would explode.

Using higher resolution (bits) does only produce CPU load and increases RAm consumption. You do win in theory 3dB - in practise nothing.

vy 73
Andreas

Title: Re:stm32f4 vs stm32f7 compatibility
Post by: KevinA on 04. October 2017, 17:41:38

Another 'quick' question: What DSP processing is needed for the I/Q codec?

Title: Re:stm32f4 vs stm32f7 compatibility
Post by: DF8OE on 04. October 2017, 18:24:05

It is possible to start "a quick question" about this - but impossible to give a "quick answer". Math is complicated and complete answer would fill pages. You find some informaitons in GutHub WIKI about DSP and if that does not satisfy you the only quick possiblility is to look at the code...

But we will do a complete restructuring of DSP routines to WDSP the next months so I think it does not make much sense to dig into the actual DSP code...

vy 73
Andreas


Diskussions- und Newsboard des DARC-Ortsverbandes I40 | Powered by YaBB SE
© 2001-2003, YaBB SE Dev Team. All Rights Reserved.