The current implementation of adc app has quite a few shortcomings. Most notably the lack of info on different drive modes and inability to see/configure what pins have what functions.
I have started laying out a new path here:
https://github.com/Teslafly/bldc/tree/adc-app-upgrades
The idea is that you will have a pool of io pins you can use. You select a adc mode, then get a list of functions with a drop down of available pins for you to use for each function. Then you can select and reassign digital / analog pins to whatever functions you want and aren't limited by predefined values.
This also would allow you to tag pins by what their silkscreen labels are, and use the swd pins for additional digital io instead of clobbering the UART.
When a pin is selected for one function, (or UART is clobbering those pins) the pin will become greyed out and unselectable for another function
Good start. I agree that the ADC app needs some work.
For the digital pins, I think that there should be a simple mapping between pin and function that also can be overlapped, to avoid adding the extra logic to the configuration structure in VESC Tool; it might also be desirable to overlap the pins in some cases, and the logic also has to take that into account. The pin mapping should be independent of whether the UART app is active; the user probably realizes the pins are used for UART when connecting things. Pin options could be e.g. Unused high, Unused low, Servo floating, Servo PU, Servo PD, RX floating, RX PU, RX PD etc. If ADC and UART have overlapping pins, the UART will dominate as it is initialized after.
Another thing I have been thinking about is enabling pull-ups and pull-downs on the ADC pins themselves. The STM32 does not allow enabling pull resistors on analog pins, which makes this difficult. To kind of solve this in software it might help to quickly alternate the pin mode between analog and digital input, and have the chosen pull resistor active when the pin is in digital input more. If the pin is floating there might be enough stray capacitance in the pin and traces to keep the voltage at the desired default level when sampling. A hardware solution I have been considering is always having pull down resistors on the analog pins, but that does not help the hardware that is already out there.
Hi,
do you think it is possible to add the functionality to read out a incremental encoder with two of these digital pins to set up speed and a third pin to start the motor ? then i can stop working on my custom user app ;)
Georg
CTSchorsch,
While this may make it easy to add new input types, that is outside the scope of the ADC app and you should continue working on your custom app. That is probably the best for your use case.
Another problem you will have would be that depending on what hardware you have, the only incremental encoder reading timer would be the one used on the hall port. Depending on the speed using an interrupt wouldn't work so well.
If you want a discussion about implementation tips on such an app, please create a new forum thread.
On another note, I am getting back to this. Mostly on the fw side, but am starting to dig into the Vesc tool code as well.
I should have a better flashed out proposal on functionality incorporating Vedder's feedback in a day or so.
Well, I just tried enabling the pupdr register anyways to enable the pullup/pulldown, and it seems the 407 physically gates the pullup/downs in hardware when the analog mode for that pin is enabled.
Why they did this, I don't know. other st microcontrollers are just fine with this (the f1 series I believe).
toggling between input pulldown and analog mode when sampling is the only possible method to add disconnection safety to hardware without hw pulldowns.
Hello, I'm looking for new pals that enjoy playing online games. In our spare time, we can make friends and play diggy. It will help us release stress after school