Okay, so I have scoured TheRebelArmory and this forum, and cannot find the info I’m looking for. I know it is out there…and probably obvious, but it is 12:30 AM and I don’t have enough brain cells left firing.
I have two questions:
-
Where (and how) do I define the function of the data pins? Is it in the config file, prop file, or the OS itself? This is probably a dumb question, but it wasn’t obvious from the wiki.
-
How do I define the output of the pin to be a PWM audio signal. Is there a PWM audio signal already in the board and it is a simple as porting to a data pin? Or, does the digital signal going to the amp need to be normalized to PWM manually?
As a bit of background, I am trying to feed the PWM signal into a haptic chip (TI DRV2603) to drive a small vibration motor to match the audio output of the board.
I’ve done a bit of basic arduino coding, but it is taking me a while to understand the structure of everything in terms of the OS and what does what.
Thanks!
In most cases, pins are of unspecified use until you start using them, which in proffieOS usually means setting up a blade for that pin. It could also mean setting up a serial port, an IR receiver, serial port or something else. The setup code for each of those things contains the required calls to configure the pin to do what you want.
For setting up a PWM pin, you could in theory use analogWrite() to set it up. The problem is that you need an available timer to run generate the PWM waveform, and a Proffieboard V2 is usually using all of it’s timers to generate PWM and WS2811 signals.
However, if you’re using neopixels, the FET signals are just on/off, and do not require a timer to run, so it might be possible to use one of those timers with a little bit of fiddling.
The second problem is to get the actual audio to be fed out over PWM. There is currently no code for that. (Although, I wonder if maybe it’s possible to make the Audio block on the CPU generate the PWM signal…)
Now, I have to ask the obvious question though: Why not hook up the haptic chip to SPKR+? It’s a 400kHz PWM signal already, and the haptic chip seems to accept 5v input if VDD is 5 volts.
Thank you for your reply!
Okay, no neopixels, just blue/blue/amber tri-cree.
The haptic chip is wired to use the battery ground and positive, which means a 5V signal would be outside the range…however you could use a simple voltage divider to drop it down to 2V or something, so that’s not really a problem. What is a problem is that the maximum frequency for the signal going to the chip is 250kHz, so the audio signal would be above that at 400kHz. I guess you could in theory use a D-Latch set up as a T-flip-flop to divide the signal, but now we’re talking some serious external wiring.
I am wondering if you could piggy-back off another timer, since the input frequency is not critical? (10-250kHz)
Thanks!
If you don’t have any neopixels, things gets a little easier, because we can use the TIM2, which is normally dedicated to generating WS2811 data.
However, that still leaves some semi-tricky code writing, because we have to trigger a DMA transfer every time we feed data into the SAI to also feed data into the correct TIM2 PWM register.
Although, if the haptics is fine with only getting updates ~1000 times per second, then we could just call analogWrite() from the audio interrupt, which runs every 44 samples by default. Since the audio interrupt calculates the volume already, we could use that as the input to the PWM.
Interesting topic since this is done in my field but with different components.
I’m down to read how it works out.
Let’s see if @NoSloppy has covered any of this since it’s audio oriented.
FWIW here’s a link I have from when I researched for an old KR hilt.
I’d like to try and find a solution that works with or without neopixels. Your last idea sounds intriguing…but the chip needs at least 10kHz on the input.
Luckily, PWM frequency and “update frequency” are not the same thing.
We can set the PWM frequency to 20kHz and then call analogWrite() 1000 times per second to update the PWM rate. That will create a sort of low-pass filter for the haptics, as it won’t be able to produce frequencies over 500Hz. Not sure if that is a good thing or a bad thing for haptics though.
The solution has to look slightly different for the neopixel and non-neopixel case.
IF we don’t have neopixels, TIM2 is not used. TIM2 can drive data1, data2, data3, RX orTX.
IF we DO have neopixels, TIM2 is not available, however, if the neopixels are powered from LED2 or LED2+LED3, then TIM16 is not being used. TIM16 cannot drive data1/2/3, but it can drive the button1/button2 pads, so we could hook up our haptics there instead.
Now, if you’re also planning to send IR, then TIM16 will be busy with sending IR codes. In that case we could use LED1+LED5 to power the neopixels, because that frees up TIM15. However, the only other pin available that TIM15 can drive is TX, so then the serial port would be unusable.
I am starting to think pulling the PWM from SPKR+ is looking better and better…especially when looking at ease of implementation. I am going to try a simple voltage divider and see if the haptic chip will take the 400kHz…
If it doesn’t, I have a bunch of TC7WH74FU,LJ(CT flip flops laying around for my saber shield board, as well as some breakouts for the SSOP-8 package. It would be pretty easy to implement as a divider on the signal. That would give us 200kHz at half the duty cycle. I’m not sure how halving the duty cycle will affect the output of the haptics. If it works well, I will re-design the saber shield to include a divider on the input for the PWM. That way, it will always be as simple as tapping into the SPKR+ signal, and won’t tie up any of the board outputs. Or, I can probably find a different haptic chip with a wider input range, and skip the divider altogether.
I am really trying to get this to work, because I have implemented it in three CFX sabers so far, and having haptics is amazing to feel. You do have to play with the motion settings to prevent false swings, but it is not nearly as much of an issue as it used to be before smoothswing.
1 Like
The divider seems like a pain in the butt to be honest. If the chip doesn’t accept 400kHz input, it’s probably better to just look for another chip, or try the software solution.
1 Like