Title: Mod-fw of UHSDR 2.11.91m1
Post by: satoryboy on 28. October 2020, 03:27:55
I'm posting a new version of my mod-firmware 2.11.91m1. At the request of RA1OKO added:
- Option to allow 10 W transmission in the CB civilian band, relevant for the Russian Federation - Debug / Exper. Settings -> CB 10W TX Enable.
- Option of temporary (within the session) memorizing filter settings for each mode of each range - Debug / Exper. Settings -> Remember BWs on bands. It would be possible to store the settings not only temporarily, if we find free space in the non-volatile memory for a 16-bit 10x20 array. I did not find.
Firmware:
https://yadi.sk/d/NfLcX_Bh6BrqLA (https://yadi.sk/d/NfLcX_Bh6BrqLA)
Sources:
https://yadi.sk/d/TYi-ErT3x5xTxw (https://yadi.sk/d/TYi-ErT3x5xTxw) |
Title: Re:Mod-fw of UHSDR 2.11.91m1
Post by: pa3met on 28. October 2020, 10:49:31
is it possible for you to push it in git?
|
Title: Re:Mod-fw of UHSDR 2.11.91m1
Post by: satoryboy on 28. October 2020, 12:14:55
| Sure. I used to do that, my callsign is even in Hall of Fame. The problem is reaching agreement with UHSDR. They consider many of my developments useless and even harmful. |
Title: Re:Mod-fw of UHSDR 2.11.91m1
Post by: DF8OE on 28. October 2020, 15:27:18
Hi,
not all of the improvements would be accepted. So it would e nice if the changes would be broken up into single pull requests - and - very importtant!!! - they mut be tested with the use of both display types (320x200, 480x320) AND mcHF / ovi40. Actual code breaks function of ovi40.
vy 73
Andreas |
Title: Re:Mod-fw of UHSDR 2.11.91m1
Post by: DF8OE on 28. October 2020, 17:37:00
Exactly these are the issues that must be solved before any pull request will be accepted. Test procedures for F4, F7 and H7 are mandatory.
vy 73
Andreas |
Title: Re:Mod-fw of UHSDR 2.11.91m1
Post by: satoryboy on 28. October 2020, 17:37:04
| I agree that the code should be tested on all firmware versions. Until the end of the year or the end of January, I will have the opportunity to test on an F7 processor and a 480x320 display. Still, I would like to see a list of improvements that the UHSDR group considers interesting and useful, if not difficult. If there will be no material problems, I will also solder the OVI40 H7 for the tests. Now I have some financial problems, sorry. |
Title: Re:Mod-fw of UHSDR 2.11.91m1
Post by: DF8OE on 28. October 2020, 18:04:41
We will wait until testing for H7 is possible. H7 is the processor which is used on most OVI40 and compatible devices.
I do not know if F4 binary fits into "small mcu" - that would be preferred, too. If not there must be created a config possibility to build "small build" by automatically disabling some parts.
PRs will be reviewed by the team and must follow the contribution guide (https://github.com/df8oe/UHSDR/blob/active-devel/CONTRIBUTING.md). We have worked hard to make the code easier to understand, have broken it up to functions and made it much easier maintainable. It is mandatory that we do not step back.
vy 73
Andreas |
Title: Re:Mod-fw of UHSDR 2.11.91m1
Post by: SP9BSL on 28. October 2020, 21:03:32
I checked all the F7 and H7 series STMs
UHSDR 2.11.91m1 program.
STM32F767_ZIT6 is OK
STM32H743_ZIT6 is OK !!!!!
STM32H743_ZIT6U is wrong the program does not start
One TRX STM32H743_ZIT6U has a white screen, the led is black.
the other TRX STM32H743_ZIT6U has a black screen, the led is black.
I guess the STM32H743_ZIT6U chips are different from the STM32H743_ZIT6.
It's probably not a problem that "STM32H743_ZIT6U" is 480MHz and STM32H743_ZIT6 is 400MHz.
The STM32H743_ZIT6U chip is faster and costs less money (Farnell, Mouser) Why?
|
|
Because it is obsolete...
Farnell has old revision and wants to sell them. Both are marked as 400MHz. Starting from the revision 6 these cores have 480MHz, if the core has "V" marking on the case, then it is capable of run at 480MHz. Please read the manual about the changes they made. Also, there is no such marking as "U" in ordering info looking to description in datasheet. |
Title: Re:Mod-fw of UHSDR 2.11.91m1
Post by: SP9BSL on 28. October 2020, 22:28:09
As previously said: obsolete. Your chip is almost two years old... Must be an intermediate version or "something". As said, look to the current pdf from ST: https://www.st.com/resource/en/datasheet/stm32h743zi.pdf (https://www.st.com/resource/en/datasheet/stm32h743zi.pdf), page 352.
Directly from ST factory: |
Title: Re:Mod-fw of UHSDR 2.11.91m1
Post by: satoryboy on 29. October 2020, 04:57:29
DF8OE
Firmware for "small MCU" are also compiled, with FreeDV cut out. Here is the complete 2.11.91m1 firmware for "small MCU":
https://yadi.sk/d/vr9qvCUEm_-nbw (https://yadi.sk/d/vr9qvCUEm_-nbw)
SP3OSJ
I temporarily stopped compiling monochrome firmware versions. I am a not so-so programmer, all my attempts to introduce monochrome styles into one firmware have failed, but I do not lose hope. Here is sepia for F7. Wouldn't it be too much impudence on my part to ask for a photo of Sparrow with this firmware at a B/W waterfall?
https://yadi.sk/d/MOUt1b-XjRwZiQ (https://yadi.sk/d/MOUt1b-XjRwZiQ) |
Title: Re:Mod-fw of UHSDR 2.11.91m1
Post by: DF8OE on 29. October 2020, 06:08:53
As "U" - version works fine with official build (as Thomas DL8EBD already stated) there must be something broken in modified firmware. STM has a poor communication about the processor revisions. It seems the "U" is not outdated but an OEM revision which is now available for the public (for whatever reason). It is the 480MHz version, but UHSDR only sets it to 400MHz at the time.
vy 73
Andreas |
Title: Re:Mod-fw of UHSDR 2.11.91m1
Post by: SP9BSL on 29. October 2020, 11:13:46
I called the ST and have the answer for "U" marking - there is no silicon change, the "U" marking means that the chip price contains fee for licensing some linked libraries for example MicroEJ (Java). So why it doesn't work is a question to author.
Also found some explanation in nucleo boards: |
Title: Re:Mod-fw of UHSDR 2.11.91m1
Post by: satoryboy on 29. October 2020, 14:47:48
| I have not made all modifications to my code that did not concern the executable code. But this is fixable. Need hardware for testing. And thanks for the photo! |
Title: Re:Mod-fw of UHSDR 2.11.91m1
Post by: satoryboy on 01. November 2020, 12:42:26
| I read somewhere about the possibility of CPU clocking from "DDC Module 2". In this case, the processor is not forced to start until stable generation is established. Is this not the case on the left? |
Title: Re:Mod-fw of UHSDR 2.11.91m1
Post by: DF8OE on 01. November 2020, 13:25:45
If you use official builds on both:
Do they show same behaviour now? --> problem is in firmware.
Quite easy to determine.
vy 73
Andreas |
Diskussions- und Newsboard des DARC-Ortsverbandes I40 | Powered by YaBB SE
© 2001-2003, YaBB SE Dev Team. All Rights Reserved.
|