Good.
Put a deliberate error in the file and hit verify. (A stray ( for instance.)
Does it fail?
If not, it’s not reading the file you think it is.
Ok, I think I figured out the problem. The ProffieOS.ino file I’ve been using was loaded from my backup of the SD card. So as you pointed out, it wasn’t reading the file I thought it was. It wasn’t even reading the directory I thought it was. So I closed out of the IDE, navigated directly to the SD card and found the ino file, and re-opened it. Compiling it now, it’s throwing errors, but that at least means it’s SEEING the code now.
It caught some capitalization errors that I’ve gone ahead and fixed, then I was down to a single error:
In file included from D:\extra\ProffieOS\ProffieOS.ino:605:
D:\extra\ProffieOS\config\s3config_v3.h: In member function 'virtual void PinballController::Loop()':
D:\extra\ProffieOS\config\s3config_v3.h:67:25: error: expected primary-expression before '.' token
67 | float angle = Fusor.pov_angle();
| ^
exit status 1
Compilation error: expected primary-expression before '.' token
I changed Fusor.pov_angle(); to Fusor().pov_angle(); and that got rid of the error. But now when I hit upload, I get this error:
The current directory is invalid.
Failed uploading: uploading error: exit status 255
And then it disconnects my board, and I have to disconnect it and reconnect it.
Good catch again on the fact that I most likely wasn’t reading from the right location.
That will create a new Fusor every time, which is not what you want.
It should be fusor.pov_angle(). (Not capitalized)
Is everything on the SD card?
Try copying ProffieOS and stuff the desktop, or documents. (And run Arduino there.)
For a successful ProffieOS Arduino upload to your Proffieboard, your ProffieOS folder MUST be on your hard drive (not on your SD-card). Also your ProffieOS folder should be named “ProffieOS” and not for example “ProffieOS_7.15”, or else Arduino will create a ProffieOS subfolder in your ProffieOS_7.15 and move your ProffieOS.ino file in that subfolder which will “break” the relative folder structure inside ProffieOS.
Progress!
Since I was already somehow pushing updates using the prior ino file, I just did what I was doing before and found whatever config file was in that backup folder (I made another backup).
Changed Fusor to fusor, uploaded, serial monitor is now flooding with println statements from the code chunk. Mainly, LeftPin keeps churning out a 7, and RightPin keeps churning out an 8. Pivoting the core doesn’t change these values. Based on the pinout, it looks like it’s just outputting the values they correspond to on the pinout.
That is what this code does:
If you want see if left pin is high or low, you need to do:
STDOUT.println(digitalRead(leftPin)));
But maybe something like this would be better:
STDOUT << "Left=" << (angle < -M_PI / ) << " Right=" << (angle > M_PI / 8) << "\n";
Perfect, now it’s churning out changing values.
Based on the orientation of the core inside of the hilt, it currently detects any forward tilts as my “right”, and any backward tilts as my “left”. This can of course be manually corrected by rotating the saber clockwise in-hand by 90 degrees, but I’m anticipating the button on the front of my saber to play a role as well, which is now facing to the user’s left. It may have been a red herring for me to provide an arbitrary left/right direction without considering the final position of the board within the hilt, so that’s entirely on me.
With the relative position of the board in mind, left/right tilts by the user should actually be forward/back tilts from the board’s perspective. For the time being, I modified fuse.h to have an additional function called pov_angle2(), and I made it return atan2f(down_.z, down_.x); and that’s getting me the results I was hoping for. However, the serial outputs appear to be delayed by about 1-2 seconds.
Here’s the modified fuse.h block:
// 0 = up, +/-PI = down, PI/2 = left, -PI/2 = right
float pov_angle() {
return atan2f(down_.y, down_.x);
}
//CUSTOM
// 0 = up, +/-PI = down, PI/2 = left, -PI/2 = right
float pov_angle2() {
return atan2f(down_.z, down_.x);
}
//END CUSTOM
And here’s the modified pinball code chunk:
//start of custom code
class PinballController : public Looper {
public:
const char* name() override { return "PinballController"; }
static const int LeftPin = blade5Pin;
static const int RightPin = blade6Pin;
void Setup() override {
pinMode(LeftPin, OUTPUT);
pinMode(RightPin, OUTPUT);
}
void Loop() override {
// float angle = fusor.pov_angle();
// digitalWrite(LeftPin, angle < -M_PI / 8);
// digitalWrite(RightPin, angle > M_PI / 8);
// STDOUT << "Left=" << (angle < -M_PI / 8) << " Right=" << (angle > M_PI / 8) << " Angle =" << angle << "\n";
float angle = fusor.pov_angle2();
digitalWrite(RightPin, angle < -M_PI / 8);
digitalWrite(LeftPin, angle > M_PI / 8);
STDOUT << "Left=" << (angle > M_PI / 8) << " Right=" << (angle < -M_PI / 8) << " Angle =" << angle << "\n";
}
};
PinballController pinball_controller;
//end of custom code
I had to reverse which pin lights up to the proper angle calculation, and I appended the angle value into the serial output as well.
As I’ve kept it plugged in and writing out this reply, the delay gets worse. To prevent anything from crashing or getting too hot, I’ve gone ahead and unplugged it.
Don’t know if this applies to you but, there are defines for board orientation:
#define ORIENTATION_ROTATION 0,20,0 // X,Y,Z //For Curved hilts, or where the board is not parallel with the blade.
//This will rotate the orientation of the board 20 degrees around the Y axis.
#define ORIENTATION ORIENTATION_FETS_TOWARDS_BLADE //Default is USB connector points away from blade
#define ORIENTATION ORIENTATION_USB_TOWARDS_BLADE
#define ORIENTATION ORIENTATION_USB_CCW_FROM_BLADE
#define ORIENTATION ORIENTATION_USB_CW_FROM_BLADE
#define ORIENTATION ORIENTATION_TOP_TOWARDS_BLADE
#define ORIENTATION ORIENTATION_BOTTOM_TOWARDS_BLADE
Loop() runs a lot. Thousands of times per second, and something isn’t keeping up with all the printouts.
I suggest doing something like this:
static uint32_t last_printout;
uint32_t now = millis();
if (now - last_prinout > 100) {
last_printout = now;
STDOUT << "Left=" << (angle > M_PI / 8) << " Right=" << (angle < -M_PI / 8) << " Angle =" << angle << "\n";
}
As for pov_angle2(), we could add that if you want to submit a PR for it.
However, a more general apprach is to use ORIENTATION_ROTATION.
It may also be possible to use the ORIENTATION define, but it doesn’t normally care about rotations around the blade axis and doesn’t have values for those sort of rotations.
adding in the ORIENTATION_ROTATION did the trick:
#define ORIENTATION_ROTATION -90,0,0
Now it acts the same as pov_angle2() and was much cleaner to incorporate. I don’t think a PR would be necessary since the command above does the job. And that if statement really helped de-spam the monitor and is back to real-time.
Well from what I can tell, I think the proffie is doing everything I need it to do now. Flip a high output when tilted left or right. Now my next mission is going to be figuring out how to send these radio signals through what’s essentially a faraday cage. It already has a bluetooth module installed, and apparently S3 leverages the blade to act as a sort of antenna to propagate the signal. I can either find a way to make my xbee use the same connections, or I might have to make the bluetooth module act as my impromptu radio module, and link it with the receiving xbee and do some data communication. My hope is to make option 1 work.
Unless there are any additional comments or suggestions lingering (such as for this next effort), I think this milestone has been reached. Thank you both for helping me out big time with this effort, I greatly appreciate how helpful and inviting this community is to beginners. Hopefully I’ll have something post-worthy in the near future to share with y’all 
3 Likes