Bigquad modification for more uarts

[theseankelly]

Hey bitcraze -- I'm modifying my bigquad deck a little bit to get two more UART ports. I need UART for GPS, an OSD, and a spektrum RX. I plan to repurpose the SCL and SDA lines for one UART, but the second is a little harder. RX2/RX2 will work, but are currently driving the signal to M1 and M4. So I need to find two other IOs with TIM support to drive M1 and M4, and put them on 5v pull ups. I'm thinking IO1 (NC on the bigquad deck) and MOSI (cppm input on the bigquad deck) will work well.

Two questions:
1) do I need to depopulate the pullups on tx2/RX2 to use these lines as UART? I think I shouldn't have to.
2) do you have layout/board files for the bigquad deck available to the community? If this works out I may want to build a modified version of the PCB for this

Thanks!
Sean

[tobias]

I thought a bit about this problem when I sketched the BQ-deck. I think what you plan to do will work but keep in mind that the I2C is used by the EEPROM. However I think you can first read out the configuration from EEPROM then switch to UART. So Spectrum RX would be suitable there as you won't tamper with the clock line. Moving the timers should be pretty simple and has been done before.

1) do I need to depopulate the pullups on tx2/RX2 to use these lines as UART? I think I shouldn't have to.

The UART will work just fine, just consume a bit more current.

2) do you have layout/board files for the bigquad deck available to the community? If this works out I may want to build a modified version of the PCB for this

Currently we only send it on request but drop us an email and we will send it to you .

[theseankelly]

Oh darn! I missed that the E_SDA/E_SCL I2C bus was hooked up to the EEPROM. I guess I assumed it was another internal I2C bus. I guess you're right that it should still work..but I'd rather not have to contend for access to the EEPROM. I might wanna add support for configuring stuff like PIDs via the OSD and saving to the EEPROM in the field down the road, for example.

Have you ever looked at software UARTs on the STM32? That would make this a bit easier. If I'm running a spektrum rx, then CPPM in is useless, and I could maybe do without a buzzer. Wouldn't want to run something mission-critical on that, but GPS would be fine.

Also, maybe I could hook up to the N_IO_1 and N_IO_2 lines and plumb GPS over syslink.

Also thought about configuring an Arduino as an I2C slave and having it bridge the UART link.



...or I could just find and buy an I2C GPS module...

[theseankelly]

Also, what are those pin connectors you've used for the ESC connectors? They're .1 right angles but the female connectors lie flat against the PCB instead of up in the air a bit.

[tobias]

If you use the E_SDA as Spektrum RX UART I think it could work. Might be a bit complicated to handle in FW though but they don't have to be used at the same time so maybe not such a bad solution.

I thought about using the nRF51 as Spektrum RX but unfortunately it only has 1 UART which is used for syslink... Would have made sense to use it as RX otherwise. Is the Spektrum RX inverted signal. There is one which is but can't recall which.

My initial plan was to have a general receiver port but as there was no obvious choice to occupy a UART-RX it just became a CPPM. Software UART is an alternative but it is a bit complicated and I never got the time to try it out. That I think would be the sweetest solution and you don't have to do so many HW changes.

[theseankelly]

Alright, been doing some more thinking on this and here's where I've landed.

To recap, I need a minimum of 2 UARTs to run OSD + Spektrum Rx. A third UART for GPS is a nice-to-have but not strictly required for FPV flying. I'd also like to preserve as many bigquad features as possible and minimize any necessary rework to the expansion deck so it's easy for others to repeat what I've done if they like.

First UART is there by default: the GPS pins, routed to RX1/TX1 on the cflie.

I can get a second UART pretty easily, as discussed above: The signal lines for motors M1 and M4 can be repurposed as USART2. For motor signal replacements, I'll take IO_1 (NC on the bigquad deck) and MOSI (used as CPPM in on the bigquaddeck). I'll need to add VCOM pull-ups on these lines.

Third UART is more complicated. There's a few ideas:
1) As discussed above: steal the I2C bus, which can be repurposed as USART1. Downside: it breaks EEPROM access. As Tobias points out, it might be easy to solve this by using these pins for the Spektrum receiver: It typically only needs Rx so we don't need to worry about accidentally clocking the EEPROM when sending Tx traffic. However I worry about the receiver messing with the data lines when the EEPROM is in use, since there's not really a way to tell the receiver to stop sending information. Even if I could solve that, I don't like this because most OSDs allow for configuring various flight parameters using the RC sticks: That would be a cool feature to add to the CF, which would require simultaneous receiver and EEPROM access.

2) I could implement a soft UART on the STM32 using PWM/timers. Ought to be plenty of bandwidth to do this on the F4 chip. The problem is, which pins to use? There's really only three pins left, all of which require more extensive board rework and/or removal of features from the bigquad deck: buzzer signal (IO_4), vbat sense and current sense (Both require some shorting and depopulating on the board). Would be sad to lose any of these features. Could recover the buzzer feature using one of the brushed motor output connectors on the main CF, though.

3) The two Nordic IO pins -- N_IO_1 and N_IO_2. It's sad to see two pins go completely unused, isn't it? Unfortunately the NRF only has 1 hardware UART and it's already used for syslink. I haven't run the numbers, but I'd be surprised if I can't bitbang a software UART in the NRF51 on these two pins (especially since the chip won't really be doing a whole lot in this config...), and then forward it over to the STM on syslink. Would work well for GPS, since its less critical and the baud rate can usually be configured for something lower like 9600 on GPS modules.

I'm going to go with #3!

[theseankelly]

Oh and I had some EE questions about re-routing the motor pins:

1) I've got a couple 1.2k resistors lying around from a previous project. Will it cause problems if I use those for M1 and M4 but M2 and M3 are left with 1k resistors on their pullups?

2) It'd be cool to keep CPPM working if a UART receiver isn't used: Does adding a pull-up to the CPPM in signal break CPPM? Do CPPM receivers drive signals high or low?

Thanks
Sean

[tobias]

I'm happy to answer:

1) 1.2k will work just fine

2) CPPM is push-pull driven so you don't need any pull-up, just a timer input to measure pulses.

Edit: Forgot your big post.
I think #3 sounds like a good option as GPS might not be used so much and there are I2C GPS receivers a two as you pointed out. Also the nRF can easily reroute the signals between pins so you could listen on the GPS and send it over syslink directly afterward.

[theseankelly]

Thanks! Didn't know it was so easy to switch pins on the nRF -- I'll add that to my list of things to try.