@profezzorn I don’t see the Proffieboardv3.9.pro nor the Proffieboardv3.9.kicad_pcb file in that ZIP.
Because of reasons, it’s not called that.
The files are called teensysaberv2.*
There is a teensysaberv2.kicad_pro in there, and a teenssaberv2.kicad_pcb, but they contain PBv3.9 designs.
For anyone on MacOS updating Kicad from version 5 to 7 so that these new 3.9 board files can be opened, you might need to delete ~/Library/Preferences/Kicad, else you just get a non-responsive PCBNew app.
That is all.
V3 breakout board page is done:
https://fredrik.hubbe.net/lightsaber/v6/test_rig_breakout.html
(Still working on cleanup up related pages though.)
1 Like
Ok, the test rig page is done:
The image on this page is still a V2 test rig, but the links and sub-pages are all done:
1 Like
I was confused for two things:
- In the V2.2 files there was also a teensysaberv2 files, which where not the ones used to open it.
- I was using version 5.0 of KiCAD which throws a general error with the file, and you have to open the
Detailsbutton to see that the problem was that the file was done with a newer version.
So: Update KiCAD to 7.0 and open teensysaberv2.pro.
The button1 (13,14) pin numbers in the diagram don’t match the ones in the table (11,12):
http://fredrik.hubbe.net/lightsaber/v6/
Thanks for pointing it out.
The diagram was wrong, fixed now.
1 Like
@profezzorn How does the new pad layout affect these defines?
#define ORIENTATION ORIENTATION_SDA_TOWARDS_BLADE
#define ORIENTATION ORIENTATION_SERIAL_TOWARDS_BLADE
1 Like
Well, moving the pads doesn’t change the orientation, so if the pads move, the names are just wrong. Any ideas for better names?
how about LED1_TOWARDS_BLADE AND LED6_TOWARDS_BLADE ?
Not going to work for the Proffieboard M2 if that ever gets made…
OK.
data1 and spk ?
Maybe UP_IF_USB_ON_LEFT and DOWN_IF_USB_ON_LEFT ?
Not sure if that’s clear enough though, the idea was that if you have the board the way it’s usually pictured with USB on the left, then the blade is either up or down…
Would it be crazy thinking to require referring to documentation?
Many other things pretty much require some documentation, maybe we make a POD page picturing the orientations and just name them O1, O2, O3 etc…?
Similar to how Shtok NPXL PCBs document V1-V4.
As much as text only might be ideal, a picture does paint a thousand words.
Not crazy, but I also don’t see a conflict.
We don’t have to have cryptic names just because we have documentation.
This would be the same as USB_POINTING_DOWN and USB_POINTING_UP which might be clearer?
The issue with both versions might be assuming USB is always recognized as being on the top of the board and therefore facing the observer.
If viewing the bottom of the board, USB is technically still on the left or right or pointing up or down, hence why this is tough to word.
How about USB_FRONT_AND_DOWN, USB_FRONT_AND_UP?
or USB_FRONT_BLADE_LEFT, USB_FRONT_BLADE_RIGHT?
1 Like
So this assumes the blade is pointing to the right?
It feels a bit redundant to mention that the USB is on the top to me though.
(Pictures and documentation, right?)
Maybe USB_CW_FROM_BLADE / USB_CCW_FROM_BLADE ?
This could still be reversed if the bottom of the board is facing the observer.
USB_FRONT_AND_DOWN, USB_FRONT_AND_UP would be ambiguous because I imagined it blade to the left. That won’t work, but these provide 2 axis of info so should be “foolproof?”
ORIENTATION_USB_FRONT_BLADE_LEFT
ORIENTATION_USB_FRONT_BLADE_RIGHT
USB_FRONT seems like it could be interpreted 8 different ways.
(USB on top, but pointing towards 0, 3, 6 or 9 o-clock, or usb pointing towards the observer, but with the board rotated in four different ways…)