Porting to the Retevis RT50 (aka TYT MD-680D)

Discussions related to the firmware code development
EA5JAQ
Posts: 86
Joined: Thu Jul 16, 2020 6:08 am

Re: Porting to the Retevis RT50 (aka TYT MD-680D)

Post by EA5JAQ » Thu Feb 23, 2023 10:24 pm

So a couple days ago I received the logic analyser and today I've had a chance to try it. Turns out my delays were way too long. I've made improvements but still couldn't make it work, I still need to adjust and test more things.

I found out several curious things. First of all, I've had to use much longer for() delays when sending the first burst of data (the initialisations in HR-C6000.c) than for the rest of the SPI0 data transfers. When I use the same delays, the data at the start gets sent way too quickly and the C6000 doesn't receive it properly. Maybe that's why, before using the logic analyser, I could only get the C6000 to do something by using long delays, because otherwise all the initialisation data is not sent properly. But still I don't know why that happens, maybe because at the very start the processor is not as loaded and executes the instructions quicker, so I need more iterations in the for() delays.

At the moment I've just worked with the clock signal, to adjust the timing (and it still needs more work). But the data transferred after the initialisations seems to be different when using bit-bang (maybe because I haven't adjusted it properly). I have to investigate more, and check the other signals (one by one, because I need the full 24 MHz).

Thank you for the idea, at least with this cheap logic analyser I can see what's going on.

VK3KYY
Posts: 7481
Joined: Sat Nov 16, 2019 3:25 am
Location: Melbourne, Australia

Re: Porting to the Retevis RT50 (aka TYT MD-680D)

Post by VK3KYY » Thu Feb 23, 2023 10:34 pm

OK

As you know the opengd77 firmware does not send the data at different rates, so I don't know why your firmware only works if you intially send slowly

Are you allowing the C6000 long enough to power up etc

EA5JAQ
Posts: 86
Joined: Thu Jul 16, 2020 6:08 am

Re: Porting to the Retevis RT50 (aka TYT MD-680D)

Post by EA5JAQ » Thu Feb 23, 2023 11:47 pm

Basically, I just used the unmodified released code, changed the C6000 SPI U port declarations (as GPIO pins instead of SPI0) and modified spi.c so SPI0 uses a bit-bang system and SPI1 stays unmodified (in the RT50, SPI1 is connected to the same pins as the DM-1801, but SPI0 is connected to random GPIO pins). I'm trying to send the data always at the same rate, like in the unmodified release. The thing is, the initialisation data needs more iterations in the for() delays to keep the same rate.

For example, when the C6000 is already initialised, I'm just using "__asm volatile( "nop" );" as a delay between clock set and clock clear. That keeps the same rate that native SPI0 does. Between bytes, I'm using "for(volatile int x=0;x<14;x++);" to keep the same rate as native SPI0. I've compared it to the opengd77 lastest release binary with the logic analyser, my bit-bang modifications give the same clock signal that the opengd77 binary gives.

But, while the clock signal in normal operation is similar both in the unmodified opengd77 and my bit-bang modified code, mine is much faster in the initialisations. And it's weird because I'm using exactly the same function and code to transfer (read/write) both in normal operation and in the initialisations. Best solution I could find is adding an "if" clause in the function, so longer delays are used only in the initialisations. The result of this, when I check it with the logic analyser, is that the rate is the same both in the initialisations and in normal operation.

Sorry if I'm not explaining it properly, it's a bit too technical (and weird) to explain. And also I still need to do some more testing, I haven't had much time these last days. I'll keep trying next week. Once I get this working, I just need to add this bit-bang system to my RT50 project, solder the flash and EEPROM (when I receive them) and I'll have a first version to start testing... I hope.

EA5JAQ
Posts: 86
Joined: Thu Jul 16, 2020 6:08 am

Re: Porting to the Retevis RT50 (aka TYT MD-680D)

Post by EA5JAQ » Thu Feb 23, 2023 11:47 pm

BTW I'm not doing this on the RT50, I'm doing it in the DM1801 using the lastest release and only changing the native SPI0 communication to a bit-bang system. My goal now is getting a version of the firmware for the DM-1801 that works exactly the same as the release, but with SPI0 using bit-bang (and then I'll just add this tested bit-bang system to the RT50, which uses random gpio pins instead of the dedicated SPI0 ones).

VK3KYY
Posts: 7481
Joined: Sat Nov 16, 2019 3:25 am
Location: Melbourne, Australia

Re: Porting to the Retevis RT50 (aka TYT MD-680D)

Post by VK3KYY » Thu Feb 23, 2023 11:52 pm

EA5JAQ wrote:
Thu Feb 23, 2023 11:47 pm
BTW I'm not doing this on the RT50, I'm doing it in the DM1801 using the lastest release and only changing the native SPI0 communication to a bit-bang system. My goal now is getting a version of the firmware for the DM-1801 that works exactly the same as the release, but with SPI0 using bit-bang (and then I'll just add this tested bit-bang system to the RT50, which uses random gpio pins instead of the dedicated SPI0 ones).
Ah. OK

Good idea, test it on the DM1801 first

But there must be some difference in timing, and not the speed which is causing the problem

EA5JAQ
Posts: 86
Joined: Thu Jul 16, 2020 6:08 am

Re: Porting to the Retevis RT50 (aka TYT MD-680D)

Post by EA5JAQ » Fri Feb 24, 2023 10:57 am

VK3KYY wrote:
Thu Feb 23, 2023 11:52 pm
But there must be some difference in timing, and not the speed which is causing the problem
Yeah, maybe at the start the code is executed quicker and that's why the for loops have to be longer there... I don't know.

BTW, I just contacted TYT and this radio is still in production (or they are gonna start producing them again soon or something like that), but all the new units use the C7000... It's a shame. I'm gonna try to find a couple units from the older MK22 and C6000 stock before they start selling the new model, but that'll be difficult, as the one I own is from late 2021.

VK3KYY
Posts: 7481
Joined: Sat Nov 16, 2019 3:25 am
Location: Melbourne, Australia

Re: Porting to the Retevis RT50 (aka TYT MD-680D)

Post by VK3KYY » Fri Feb 24, 2023 8:28 pm

EA5JAQ wrote:
Fri Feb 24, 2023 10:57 am
BTW, I just contacted TYT and this radio is still in production (or they are gonna start producing them again soon or something like that), but all the new units use the C7000... It's a shame. I'm gonna try to find a couple units from the older MK22 and C6000 stock before they start selling the new model, but that'll be difficult, as the one I own is from late 2021.

Unfortunately all new radios are likely to use the C7000. This makes sense from a commerical point of view, becuase its cheaper than a separate CPU and C6000 and also there are no supply problems or potential import restictions on IC's made inside China

However, AFIK, there is no data sheet for the C7000 and no SDK and no build toolchain / compiler, that is publically available.

I don't see any point in buying these radios, they are not cheap, and they don't have a screen or keyboard.

RT3S / UV380 is still available at the moment and hopefully will now continue to be available now that TYT is using a Chinese made STM32F4 chip instead of the genuine chip.
Probably the Chinese chip is considerably cheaper than the genuine chip, and TYT will make more money selling these radios and it will continue to be profitable enough to continue manufacturing them.

EA5JAQ
Posts: 86
Joined: Thu Jul 16, 2020 6:08 am

Re: Porting to the Retevis RT50 (aka TYT MD-680D)

Post by EA5JAQ » Fri Feb 24, 2023 10:17 pm

VK3KYY wrote:
Fri Feb 24, 2023 8:28 pm
I don't see any point in buying these radios, they are not cheap, and they don't have a screen or keyboard.

RT3S / UV380 is still available at the moment and hopefully will now continue to be available now that TYT is using a Chinese made STM32F4 chip instead of the genuine chip.
Probably the Chinese chip is considerably cheaper than the genuine chip, and TYT will make more money selling these radios and it will continue to be profitable enough to continue manufacturing them.
Yeah, I own an MD-UV390 and it’s far better. For me, this RT50 is interesting but only because I have to make it work, figure out how to make a (very limited) user interface with its hidden screen, etc.

But from the viewpoint of a regular user, I wouldn’t even consider it as an option, they are very limited compared to the RT3S, etc. And it’s great that the future of the project it’s ensured now that the fake CPUs are supported.

VK3KYY
Posts: 7481
Joined: Sat Nov 16, 2019 3:25 am
Location: Melbourne, Australia

Re: Porting to the Retevis RT50 (aka TYT MD-680D)

Post by VK3KYY » Fri Feb 24, 2023 10:29 pm

EA5JAQ wrote:
Fri Feb 24, 2023 10:17 pm
VK3KYY wrote:
Fri Feb 24, 2023 8:28 pm
I don't see any point in buying these radios, they are not cheap, and they don't have a screen or keyboard.

RT3S / UV380 is still available at the moment and hopefully will now continue to be available now that TYT is using a Chinese made STM32F4 chip instead of the genuine chip.
Probably the Chinese chip is considerably cheaper than the genuine chip, and TYT will make more money selling these radios and it will continue to be profitable enough to continue manufacturing them.
Yeah, I own an MD-UV390 and it’s far better. For me, this RT50 is interesting but only because I have to make it work, figure out how to make a (very limited) user interface with its hidden screen, etc.

But from the viewpoint of a regular user, I wouldn’t even consider it as an option, they are very limited compared to the RT3S, etc. And it’s great that the future of the project it’s ensured now that the fake CPUs are supported.
Probably using code from the GD77S build target would be more suitable for this radio.

Hopefully TYT will continue to manufacture the UV380/390 and MD9600 for a while.

There are other possible radios that could be supported e.g. Baofeg DM1702, because it appears to be very similar to the UV380, except it does not have the rorary control for channel selection and also does not have Left / Right arrows.
However because the radio does not have the buttons or rotary control, and also becasue Baofeng may have stopped production already, it is probably a waste of time to attempt top port to that radio.
The changes to the UI would be a problem, without those buttons etc

TYT MD2017 is also a rado with similar hardware, but it is more expensive than the UV380 and people do not like the tiny joystick that is used instead of the arrows.

Unfortunately none of the owners of these radios appears seems to be developers with the skill and experience and knowledge to port to these radios.

And as you know, porting to a new radio is not easy and takes a very long time.

It took around 1 year to port to the UV380, i.e probably 500+ hours work.

Post Reply