Skip to content
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

Using these controllers as gimbal-style drivers? #112

Open
jwatte-imvu opened this issue Apr 21, 2016 · 1 comment
Open

Using these controllers as gimbal-style drivers? #112

jwatte-imvu opened this issue Apr 21, 2016 · 1 comment

Comments

@jwatte-imvu
Copy link

jwatte-imvu commented Apr 21, 2016

The software as-is supports rotating forwards and, optionally, backwards.
However, I'd like to use some of these controllers (Afro 20A) with 22/24 pole motors in specific-position mode, like a gimbal motor or stepper motor.
In some ways, this may be simpler than driving at high speeds; it may even be possible to drive it "open loop" (without commutation sense.)

Instead, the PWM that drivers the motors needs to be adjusted to support "micro-stepping" of the position of the motors.

But, to do this, I need to know which pins connect to which FETs on the board.
Is there a good source of a schematic for these boards? Or do I have to reverse engineer the definitions for ports/pins in the appropriate INC file?
(Also, is the current Afro Opto 20A set of boards the "afro_nfet.inc" or some other file? How do I tell?)

Also, has anyone translated this software to C? Assembly is cool and all, but I think I'd be more productive in C.

Also, apologies for using my work GitHub login to ask the question ;-)

@sim-
Copy link
Owner

sim- commented Jan 13, 2017

afro_nfet.inc is probably the easiest to use for a schematic. The stickers are supposed to say what firmware they have, and the .inc is what is used to describe the .hex. There is some old stuff (2013) from olliw that implements gimbal output on bs_nfet-compatible ESCs, for example, so I know it can be done.

As for C, I have done it on STM32F3, for example, but for the AVR architecture, the C output is a big step backwards from hand-written assembly in this case. There is finally support for 24-bit types and such, but the ABI specifications and how they play with r0/r1 (versus mul) and the hacks I play with ijmp and Z are very difficult to implement should it be ported to C. These directly translate to maximum RPM and minimum power (or the jump between almost full and full power), as software is doing direct PWM output.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants