New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
serial 1wire passthrough for ESCs with the BlHeli bootloader #1159
Conversation
This is awesome! It could also be added in configurator as well |
That's cool! I agree that an MSP implementation and Configurator support would be nice. This would allow the Configurator to automatically disconnect which would save people a step, and provide instructions at the same time. Is there a reason that ESC_COUNT is 6 and not 8? |
Blhs will support the whole handling mid of august... |
This is awesome. Will this work with ESCs that have the SimonK bootloader? |
No. Unfortunately not. |
@borisbstyle & @4712, Blhs is awesome, but windows only and not open source (right?) A cross-platform open source implementation in the cleanflight configurator would be ideal. I've playing with the configurator and will hopefully get the chance to add an "ESCs" tab shortly. @thenickdude, is there an advantage to an MSP implementation vs. putting a nice GUI on top of the CLI command? Also, my boards only appear to have 6 outputs and it is configured per target. Maybe I missed this, but it seems like we only have a ps. fixed the STM32F3DISCOVERY target |
@nathantsoi I was just saying this is a huge step in the right direction :D. |
@nathantsoi I'm not sure if this is the right spot to post a bug... I've been trying to get this to work because I love the idea, but I've run into a bug (or maybe this is a hardware limitation). I'm using the afromini connected via FTDI to the computer. When I type 1wire 1 in the CLI the serial port immediately fails. It works on the naze I have though. Any ideas? |
I really look forward to using this but I also can't make it work. I follow this sequence:
Then I get the dialog to connect power to read the ESC; if I do connect power, nothing happens. I think the problem is in BLHeli because the baud rate between the Com Port and the Connect button is 19,200. I cannot connect over USB to the board at 19200 in Configurator. Somehow it must be possible to get BLHeli to talk over USB at 115200? But it is greyed out. I think it will work then.... :-) But I don't know how to change the BLHeli baud rate for a USB/Com connection. |
@nathantsoi MSP has error checking and will confirm the success of or retry any failed commands sent to it. The CLI could change appearance in future since it's designed to be used by humans, so it's not good to rely on parsing any of its output. |
@Elmeerkat, did you add the necessary config for the afromini as described here: https://github.com/nathantsoi/cleanflight/blob/serial1wire/docs/1wire.md#implementing-and-configuring-targets ? Also, do you see the "Switching to BlHeli mode on motor port x" message before it fails? @ctzsnooze, what board are you targeting? 1wire 1 immediately disables the cli, and switches to "passthrough" mode so you wont get the opportunity to enter any more commands until you unplug the serial port (or send the the board 0x00 at 110 baud... implementation on the configurator side is coming for this). The baud rates are a little confusing since the CF configurator speaks at 115200 and the BlHeli bootloader is fixed at 19200. This is actually ok though because as soon as the 1wire command is entered, "passthrough mode" sends all traffic from the UART/USB converter to the esc specified. The flight control board is now is baud-agnostic it is basically just "wiring" passing through the serial traffic, so we disconnect the configurator and connect with BlHeli Suite at 19200 to talk to the esc. Here's a short guide for the CC3D: https://www.youtube.com/watch?v=fmUPL1lRcss I'll post a video for the naze shortly, if that would be helpful. Also note, I had the same problem in development, with my debugging harness attached. The leads through my logic analyzer were quite long and my guess is that the extra resistance was causing slow enough rise times that BlHeli couldn't connect. It may be the case that your setup has a similar problem. It might help to fully power your board from the start (ie. plug in the battery). Final note, I've been testing with the latest BlHeli firmware, v14. Are you perhaps running an older firmware? On what ESC? I can test out the latest v13.x and see what happens. @thenickdude, excellent point. I'll look at the MSP interface. |
@nathansoi: "baud-agnostic" does not hit the point. It is the driver for the usb-uart device that sets the baud rate to real 19200 when open the port with BLHeliSuite and again to 115200 if you reopen it with the configurator. |
Good point @4712, I've updated my comment, I hope it's a bit more clear now... |
It's strange that it's not working for me. I have now tried a lot of times with no success. I am on a Mac and initially was using CleanFlight in the Mac environment and BLHeli on VMwareFusion. Now I put both in VMWare fusion still the same issue. I'll make a movie. |
@nathantsoi I just compiled for Naze. I was under the impression that the afromini uses the same firmware as the Naze. And no, I did not see the switching mode. It just immediately disconnected from configurator and said serial port failure every time I tried |
I get identical findings with AfroMini and standard Naze32, FTDI for the AfroMini and USB/Silabs for Naze32. |
It works with Flip32 w/ Xrotor10A (Silabs) perfectly - very easy and fairly slick actually |
I'm having the same issue as ctzsnooze with MAC and VMWARE. |
You might try powering you copter with a battery @ksal0? Ps. I have been testing mac + vmware and when it works, it works fine with this setup :) |
I am now building a PC for this and many other programming issues that arise when trying to work on electronics using a Mac with VMware or other windows host.. It's not the host actually but the way the Mac/OSX handles the USB ports.. It got weird from 10.7 onwards (google it) I've had occasional success but I've never been able to solve it completely.. It just becomes too painful to mess with every time you plug in to something and so I think the only sensible way to do PC based software uploads with a Mac is DONT! Just buy any old crapper PC and gain the extra years to your life is my suggestion :D
|
So far I've had no particular issues at all with serial devices under VMWare. I'll try the resistor later. Definitely 3.3V as the source?? I'm using sn20a's with all soldered wires, not so easy to add the resistor. |
It doesn't seem to work for me as well (naze32, afro12a esc's). When I try to connect BLHeli 14 to the esc, the esc seems to go into a boot loop. As I hear the three initialisation beeps (due to a 3s lipo) over and over again in rapid succesion and the BLHS never connects. |
Are you using blheli bootloader om afro escs?
|
Much excite! |
@borisbstyle That will be the problem. I assumed that flashing BLHeli changed the bootloader as well, but I understand now that I've been flashing BLHeli using the SimonK bootloader (since that was installed on the afro's by default). |
Duuuuuhhhhh!!! OK that's my problem too, I have the original SimonK boot loader... !!!! Get back to you later. That detail needs to be in big print... :-) |
@joshuabardwell, do you have an arduino sitting around? You could make an Arduino BLHeli Bootloader interface to test with: |
I've no problem flashing that way. I'm just trying to help development by reporting that it's not working for me. And it'd be nice to be able to flash my ESCs without taking the top plate off my copter to get at the motor leads. |
I don't use either of those because I'm always working over the signal wire if I can possibly help it. I use number 2. I think this may cause some ambiguity, since the 4w-if interface can handle both bootloaders, but I used to use the 1-wire interface with BLHeli selected, before 4w-if was invented. So I'm really 99% sure these have BLHeli bootloader on them. But not 100%, I guess. |
I actually was using the single wire interface as well, but via Interface 1: http://nathan.vertile.com/blog/2015/06/17/updating-blheli-via-1-wire/ (the guide says to make a 4w programmer, but before those existed, i was using a blheli bootloader interface via 1wire), if you want to test it out at some point or maybe try it on a different (less assembled) quad? |
Check: |
I tried 1wire 1 with USB/Com interface last night and no dice. |
Really BLHeli bootloader not SimonK? |
I think either some old bootloader or simonk.
|
I don't know how I could have flashed previously via 1wire if I was selecting the wrong bootloader type. Could that even work?
Can you give more detail about where to find the log? |
Ok guys, I think you can go ahead and ignore this one. I flashed the Uno with the Arduino BLHeli Bootloader programmer and selected interface 1, and got the exact same results. Although I am darn sure that I have flashed these using 1wire and BLHeli bootloader, the most likely explanation at this time is that my ESCs have SimonK bootloader. Regardless, I get the exact same results with the serial passthrough as I do via an Uno-based programmer, so your code is not at fault. Thanks much for the effort. |
BTW, if the log of the 4w-if reads, "cmd_InterfaceSetMode OK AtmelSK" does that mean I have SK bootloader? |
@joshuabardwell: BTW the version of the BLHeli Bootloader is found here: |
Well, how about that. I'm really amazed an ESC ordered factory pre-flashed with BLHeli would have SK bootloader. And I have no idea how 1wire ever worked before. But there you go... |
It's a lot more common than you think. Are they DYS bl20a's by any chance? Anyway, back on topic!! :P My email is being filled with support requests rather than pull requests 💃 |
I think 1-wire is known to work with either boatloader (part of its appeal). http://blog.oscarliang.net/esc-1-wire-bootloader-signal-cable-blheli-simonk/ |
I didn't realize that. I thought that 4w-if was the first to be bootloader-agnostic. Odd that there is a separate menu option for the different bootloaders, though, if it doesn't matter. @add1ct3dd They are F-12A ESCs from RTFQ. I just don't get it ... if the vendor is flashing them anyway, why not flash with the "right" bootloader?!?! Grr. |
The cleanflight solution, we are talking about here, does not support SimonK bootloader. |
Yup, detailed in first post. |
I know that. What I didn't know was that the old 1-wire solution (using Arduino Uno programmer) was bootloader agnostic. Because I had previously flashed using 1-wire (BLHeli), I believed that meant that I had BLHeli bootloader. |
Hey all! You could just have asked, and I could write a host-side serial bridge to the Turnigy USB linker style encoding, but it turns out sambas already did it: sambas@c4af093 You can also see a "bit dump" ;) of a linker-to-UART thing I did to test on stm32f4discovery here: http://0x.ca/sim/tmp/stm32f4-wavegen.zip As you can see, not that complicated if it's just doing serial pass-through and the host is actually doing the rest. The reason I went with this implementation originally is that it's not possible to arm and smack you in the face no matter what you send to the serial port, even with "oneshot125" enabled. I figured this was more important than maintaining compatibility with the serial linkers, but serial to a UART is probably going to be less code. Also, stk500v2 because the avrdude author recommended it rather than inventing something new (also a bit more code). It's nopped out a bunch, too, and has a page duplicated for self-updating, but I might be able to squeeze in 256 bytes if that would be helpful. Let me know if this would help -- I can also work with sambas. Note that wherever this boot loader is, it can also keep up with down to 5µs quarter-bit timing (115200bps) if the flight board side can also keep up. |
@sim- unfortunately I cannot compile the samba code for my NAZE without further changes. EDIT: 256 bytes would be more a dream ... ;) |
Well, that sounds broken, and obviously shouldn't be merged like that. The diff should affect only the soft serial encoding part, and should be tiny. But do you mean CLI integration within the FC console? If so, sure, that would mean merging stk500v2 communication there, too, as opposed to just pass-through to some other application. Again, I explained the reason above: with a standard UART connected to ESC input, it's possible for any other application to accidentally open the port and send commands that may look like valid PWM pulses. I haven't seen this happen yet, and it probably doesn't matter if implemented by the FC (where the host would have to enable pass-through mode first or otherwise be limited to what is on the FC), so it probably doesn't matter there. Probably we/you should ship a temporary boot loader in application space so it can load a new boot loader (switch to AVRootloader or otherwise) without having to break out another interface first for whatever ESCs happen to be present. I guess it can't change the boot loader size fuses, though. :( |
The CLI integration is - in my opinion - obsolete. It insures, that the user can switch the pass through manually. Well - for testing purposes it might be useful. Yes the fuses are a special theme, but writing this, better don't ask about the factory fuse settings :( |
Hmm, so, if my ESC code is present, the default setting is just to check for not 0xffff and not 0x0000 at BOOT_START, which defaults to THIRDBOOTSTART. I guess this actively defeats your boot loader, since there would be 0xffff there, since it doesn't start until later. But if it just jumped to it anyway, it would nop-sled to your boot loader, and work. Hmm. Maybe if I add code to check each of the boot loader starts and jump to the first non-empty one, that would help this situation. Likewise, maybe you could add an .org in (the middle of) your code to trampoline from THIRDBOOTSTART to FourthBootStart, even if your code is too large to fit otherwise. This would be kind of ugly, though. The alternative would be to just never use the boot loader fuses and do it all from the application. I originally avoided this so it could recover from an incomplete flash, but I found another way to do this as well: the program starts by jumping to the end which jumps to the real start. This way, if the flash is incomplete, it nop-sleds back into the boot loader. Not fool-proof, but better than half of a program that can't do anything. Anyway, I will check the code and maybe propose a better patch or something. |
Actually BLHeli checks for the first 3 bytes to detect any of both bootloaders (see https://github.com/bitdump/BLHeli/blob/master/Atmel/BLHeli.asm#L5399). And it is also working for Atmega168. |
The multi-ESC passthrough does not work with newest betaflight_SPRACINGF3.hex, only first ESC is read, however it works with newest betaflight_NAZE.hex just fine. I recall it working with previous hex, but not sure which one, could the problem be the new blhelisuite 14.1.0.3? |
…chain Fix/included toolchain
…chain Fix/included toolchain
Initial support for F4BY target
This pull has been superseded. Please see the new pull request for usage details: #1246
Old:
IO - Program BL Heli flashed ESCs via configurator #216
Allow configuration of ESCs with the BlHeli bootloader via the 1wire (passthrough) interface.
This will NOT work with ESCs that have a bootloader other than BlHeli. E.g. ESCs with the simonk bootloader will not work.
Usage
The user experience is currently not ideal, as you'll need to start the CF configurator, go to the CLI, enter
1wire <esc index>
e.g.1wire 1
to program the first esc. Disconnect, open the BlHeli configurator, pick the USB passthrough tool, click connect, click read, then update the settings. Power off the board and repeat. Still, it sure beats disassembling your quad to re-configure your ESCs.Note, you'll need a UART/USB adapter on the CC3D.
Full directions are here: https://github.com/nathantsoi/cleanflight/blob/serial1wire/docs/1wire.md#1-wire-passthrough-esc-programming
Note, both updating settings and flashing (updating) BlHeli via this interface is tested and working.
Status
I've tested the following binaries (for the boards I own). If folks could request support for/test other boards, that would be great. Send a schematic if you have one so I can map the GPIO pins, my email is my commits or on my github profile page.
Binaries
NAZE: https://www.dropbox.com/s/1a88bf2jrt68ohe/cleanflight_NAZE-serial1wire-d91cb08c5e495bd892941d7af59443c3.hex?dl=1
CC3D bin (display disabled): https://www.dropbox.com/s/vx4ji4fsuw4e9yl/cleanflight_CC3D-serial1wire-8d3473a99aade980ef0380ff34d24edc.bin?dl=1
TODO
It sounds like @4712 plans to implement integration w/in the BlHeli suite, so all the ESCs could be configured w/in BlHeli suite w/o switching back and forth between the CF configurator. It will also be possible to switch ESCs without rebooting the flight controller.
Ps. to any developers out there, I'd love a code review on this. @samguns?