I see potentiometers are supported but I’m not sure what I can do with them in ProffieOS.
I’m working on a new saber and I have a knob I want to use, I considered an encoder but the knob is limited and also has numbers in it so, infinite turns would simply not work right in this case, and since there’s no way to know the encoder position after a power cycle, unless absolute encoders are supported?
In any case, I think a potentiometer is the more ideal approach for my case.
Can I change blade colors?
Can I change the brightness?
Can I cycle through the styles
Can I go to unstable and back to stable and anything in between while turning the pot?
Any of these while the saber is ignited of course.
Can more than one of those actions be assigned at the same time?
One bonus question not related to potentiometers:
Can blade ID be implemented just for crystals and change style according to the crystal that has been inserted?
I’ve seen this but I’m not sure it was on a proffie saber.
That looks like it might work if I shorten the shaft a little bit.
On the RFID implementation, I checked the thread where you talked about it and suggested a board and antenna, I would have to find tags small enough for the way I want to make the crystals.
But assuming I go this route, I see the reader connects to the RX and TX pads.
Is it safe to assume I can enable a second set of RX and TX, I thing we have up to three, right?
I’m planning on using a Bluetooth module and I want to make sure that’s ok.
Also, another question I have: Where are you on color screens?
I know you were considering implementing them and if so I’d like to add one to my project assuming the screen is small enough to embed it in the chassis, like one of these:
It’s ok if it’s not ready yet as I’m just in the design phase, I even would not mind installing it and waiting for it to be ready down the road, assuming it will be implemented, that is.
If you have a V3 board, there are three serial ports available, so we should be able to make that work. We may need minor code changes, but I can help with that if needed.
I have most of the code written, but it doesn’t work properly yet.
Also, there is probably a fair amount of work in making it show the right thing at the right time.
(Not to mention actually making animations for it, which will be interesting…)
Finally, color displays tends to take up a fair number of pins on the board. Not sure if BT, RFID and color display is going to be possible at the same time…
Well let’s see…
The SPI display currently requires the following pins:
… and we may also need a pin for RESET
This is likely to improved…
MISO isn’t really required, because the display doesn’t return any data. However, I currently don’t have an API for setting up SPI without MISO.
CS might not be needed, it should be possible to just ground the pin instead.
So, none of these pins are RX/TX, so that means we have one serial port unused at least.
The other two serial ports are Data2/Data3 and Free2/Free3. We need Data3 to be MOSI, so we can’t use the first one. Free2/Free3 can probably be used though. It would be kind of nice to have a PWM-capable pad for the Light pin, but I don’t know if I’m ever really going to use that. A regular on/off pin is probably enough.
It’s also possible to use SPI2 instead of SPI1, which would mean that Button3 becomes MOSI, and then Data2/Data3.
Come to think of it, RFID only requires an RX pin (no TX pin) so we could still use Free3 as the LIGHT control pin.
So, it looks like it’s possible to have all three features after all!
The challenge now would be to be able to fit all the hardware inside the chassis
Any of those LCDs I linked before I now they fit, assuming I modify those ugly boards they come with it simply make my own, which it my be the best route.
Bluetooth I love to have it, it’s cool when I use it, but who am I kidding? I rarely make use of it because of the short range, specially inside a metal hilt.
RFID I’ve never used before, but seeing the antenna gave me an idea for a cool crystal chamber design, assuming I can use place it the way I have in mind.
Other than those features I only use two buttons, two LED pads for the blade, one for the accent lights/crystal chamber and one for vibration motors.
Vibration motors are one of my favorite features actually, after using them I feel weird igniting a saber without them because it feels numb and disconnected, like when you drive a sports car and have all the little road details coming through the steering wheel, and then you go back to driving a normal every day car
Oh, this flash gun I’m working with has a camera detection system embedded in the bracket that uses one wire for positive going to an isolated stainless steel pin/button and the body of the flash as negative, I was thinking about driving a normal led with that, so I could slide in and out boards with different LED colors without having to deal with connecting and disconnecting wires, so I guess that’s another LED pad.
Also forgot to mention the dual pot we mentioned before, that one is quite important, as it’s a feature of the flashgun I want to retain, and make it functional, otherwise there would be no reason to be there.
So, each display will need a support class.
In most cases, the adafruit library will have all the information needed to generate that support class, but it will mean that I need to add support for each individual display to make them work.
Both of these looks like the could work, but I don’t know which would be better.
The dfrobot one seems like it might be a better size for sabers though.