esp32-td-first-steps

[jlpoltrack]

Tested on BetaFPV SuperD, single RF path only. Untested on ESP8266

[olliw42]

btw, maybe consider to adjust your editor to not use tabs, only spaces, 4 spaces for a tab :) a number of formatting changes :) just nitpick for sure

[jlpoltrack]

btw, could you adjust your editor to not use tabs, only spaces, 4 spaces for a tab :)

Do you have some specifics? VS Code uses spaces only, quick check of Rxclock in Notepad++:

[olliw42]

ah, didn't knew VSCode only uses spacces was just noting that your formatting often comes out a bit off, so thought it looks good in your editor but not here ... which would be a typical tab vs spaces thing

[jlpoltrack]

It looks like there should be 4 spaces (I see sometimes I have 2...)

[olliw42]

tested on RP4TD, and it indeed seems to work very nicely !! GOOD JOB !! huge step forward

[olliw42]

locking at the PR now carefully, I get a feeling that it was not based of the latest main or not in sync, and hence has lots of little things which are off I think we should agree that any PR which is intended for merge, should always be based of latest master (at the time of the PR). Otherwise it somehow should be marked, e.g. as WIP, or NOT_TO_MERGE, or whatever. IMHO.

should we add some labels, to help us with that? labels which would come to my mind at this point in time could be ESP, WIP, do not merge.

[olliw42]

this works !!!!

• replacing SPI.beginTransaction(SPISettings(SPI_FREQUENCY, SPI_MSBFIRST, SPI_MODE0)); by spiSimpleTransaction(SPI.bus());
• replacing SPI.endTransaction(); by spiEndTransaction(SPI.bus());
• replacing SPI.transferBytes(dataout, datain, len); by spiTransferBytesNL(SPI.bus(), dataout, datain, len);, and dito in the spi_red() and spi_write() functions
• in the init function setting freg, msb order, mode, also for the ESP32

can't do timing, would be interesting to see if this speeds up spi for esp32

[olliw42]

as regards the changes in the sx1280 driver:

I don't know why, but I don't seem to need these changesat all, the "original" just works fine for me !! It seems that the full config of the pins which you did in the hal seems to do it :)

also Save works, Bind works too ... FLRC seems to not work well though, constant receiver connected, disconnected, connected, ... also, Save works a bit less smooth with the Lua, I guess maybe the timing with startup is a bit different, but not a functional issue I got also a situation where it suddenly would be only at LQ 4, and I had to repower

we may have to optimize things a bit, FLRC we eant to work

but really a huge step forward

[olliw42]

that's the esp-spi.h as it looks for me now esp-spi.zip

[jlpoltrack]

that's the esp-spi.h as it looks for me now esp-spi.zip

Do you want to PR this to the branch in my Fork? Seems a little cleaner (and I think would address some other items that you called out)

[olliw42]

that's the esp-spi.h as it looks for me now esp-spi.zip

Do you want to PR this to the branch in my Fork? Seems a little cleaner (and I think would address some other items that you called out)

ah, now, pl you decide just wanted to show :)

[jlpoltrack]

I don't know why, but I don't seem to need these changesat all, the "original" just works fine for me !! It seems that the full config of the pins which you did in the hal seems to do it :)

I tried going back to the unmodified SX driver and it didn't work for me on my BetaFPV SuperD. SuperD has shared TCXO between the two SX chipsets and your RP4 has 2x TCXO (one for each) - maybe related...

[olliw42]

I don't know why, but I don't seem to need these changesat all, the "original" just works fine for me !! It seems that the full config of the pins which you did in the hal seems to do it :)

I tried going back to the unmodified SX driver and it didn't work for me on my BetaFPV SuperD. SuperD has shared TCXO between the two SX chipsets and your RP4 has 2x TCXO (one for each) - maybe related...

I hate the hardware variation of the elrs hardware ....

I think this will give some headaches for putting up a nice hal & api ...

[olliw42]

the work in progress label, you've created it or it was available already as default?

[jlpoltrack]

the work in progress label, you've created it or it was available already as default?

I created

[olliw42]

so I'll add a do not merge

[olliw42]

I guess we do not want really many of them though LOL

[olliw42]

can you rebase this branch to main? I may have gotten this wrong ... :)

[jlpoltrack]

can you rebase this branch to main? I may have gotten this wrong ... :)

Have updated to latest hal.h and device_conf.h

[olliw42]

I'm running out of complains LOL .... you and @tmcadam need to decide now :)

really great stuff !

[olliw42]

@jlpoltrack re-fetched this branch for testing, and do get now this warning

(I believe I didn't got it before ... but I may be wrong also ... so figured I just tell

[olliw42]

tested it on RP4TD ... seems to still basically work, but some "issues" Save via lua doesn't work so well, not as smooth, and it actually seems that receiver doesn't always grab e.g. a mode change, when I do the mode change via OLED and Store, it is smoother also FLRC same behavior as described in the above

however, since it's for the dev branch, it's by a country mile the best we currently have, and should be no blocker to merge :)

[jlpoltrack]

Save via lua doesn't work so well, not as smooth, and it actually seems that receiver doesn't always grab e.g. a mode change, when I do the mode change via OLED and Store, it is smoother

Out of curiosity - what Tx are you using? Is it possible that FLRC + OLED is not a great combination? To rule out any environment issues, could you try this FW: ESP32-TD.zip

[jlpoltrack]

@jlpoltrack re-fetched this branch for testing, and do get now this warning

I did update the espressif library to 6.6 (was using 6.5) so maybe it came with that.

[olliw42]

Out of curiosity - what Tx are you using? Is it possible that FLRC + OLED is not a great combination?

one of my tx modules I use since very long I had that worry too, that somehow in the latest versions something got just bad in the tx code, so tested it extensively with a stm32 receiver module ... and it just works great ... whatever I do, no issues ...

[olliw42]

@jlpoltrack trying to flash the ESP32-TD.zip firmware using the esp webtool from the docs, but don't get along well ... don't know how to do the "Upload the .bin file for your receiver and click program." I do get this page so, clicked select on thw first item, flashed, but receiver is not working at all ... should I need to test out all, or what shoudl I do?

[tmcadam]

I'm running out of complains LOL .... you and @tmcadam need to decide now :)

really great stuff !

Amazing work, a lot of issues overcome in this one, happy to add my tick to this one!!

[olliw42]

GREAT !!!