Support Teensy 3.0, 3.5, 3.6 #9
Comments
|
If anyone has access to a 3.0, 3.5, or 3.6, please get in touch with me. I would be happy to work on this once I have a way to test if it works. |
|
✋🏻 I have a couple of Teensy 3.0s on hand. |
|
@ratkins Awesome! I think these are the steps that are necessary to support the teensy 3.0:
The process for 3.5/3.6 will be similar, however I'm pretty sure we will need to regen the Feel free to tackle any of the above, I wont have time to work on this until at least this weekend. I'm happy to provide support if you have any questions! |
|
I have a 3.5 so I would love to help testing it |
|
I've got 3.6. Would like to help testing it. |
|
Have you started working on this @jamesmunns? If not and the process is the same for the 3.5 as the 3.0, I wouldn't mind giving this a shot |
|
@TheZoq2 Please feel free to work on it, I've been a bit sick and tied up in catching up on work, so I haven't been able to make any progress. I'm happy to support if you have any questions. |
|
Ok, I did some work on this. I got it to compile for the 3.5 and managed to upload and run the example project. However, it stops working after the first alive blink. If I uncomment the I assume this might have something to do with
The only thing I had to do to make it work was change the Here is my demo repo with the changes https://github.com/TheZoq2/teensy3-rs-demo @jamesmunns Do you think regenerating the bindings will fix the serial issue, if so, how would I do that? Edit: Slight update, I looked into this again and realised that mk66... is the teensy 3.6 CPU while Edit2: I looked in the board.txt file for the teensy install and found this line: I tried adding those flags to the But if I add the mfloat-abi parameter, alive() function is never run and if I add the mfpu=... part, it gives me the following error |
|
This is most likely a problem with that the new teensies have FPUs. See stack question, I believe it is related (don't have a 3.x yet). It is probably because the linker and compiler are using different flags. Also, you haven't pushed anything extra to your repo, could you push your changes? |
|
Yep, im suspecting the FPU is the issue aswell since the problem only happens when I add the floating point related flags. I pushed the latest changes to my repo |
|
@TheZoq2 Yes, I agree, if you would like to use the hard float abi, you will likely need to rebuild the C(++) code with matching flags. This exists in https://github.com/jamesmunns/teensy3-rs/blob/master/teensy3-sys/teensy3-core/Makefile#L60 You will need to get the |
|
@TheZoq2 The more I look at this, I do think you will need to regen the bindings, since the 3.1/3.2 and 3.5 and 3.6 use different CPUs, and the rust bindings are currently specific to the 3.1/3.2. To regenerate them, you will need to use Servo's fork of bindgen, and run the tool against the contents here: https://github.com/jamesmunns/teensy3-rs/tree/master/teensy3-sys/teensy3-core, which comes from here: https://github.com/PaulStoffregen/cores/tree/master/teensy3 (not sure which version). The command that was used to generate the current bindings is: PATH="/home/simon/projects/servo/ports/geckolib/binding_tools/rust-bindgen/target/debug:$$PATH" bindgen --no-type-renaming --match teensy3 bindings.h -o src/bindings.rs -- -I/usr/lib/clang/3.8.1/include -x c++ -std=gnu++11 -target thumbv7em-none-eabi -DF_CPU=48000000 -DUSB_SERIAL -DLAYOUT_US_ENGLISH -DUSING_MAKEFILE -D__MK20DX256__ -DARDUINO=10600 -DTEENSYDUINO=121Some of the parameters above will likely need to be tweaked to match the 3.5/3.6 hardware parameters (such as CPU frequency, etc) If you can get it building manually, I can help you with integrating it cleanly so that we can support 3.5 etc side-by-side. |
|
Also, im guessing the processor is crashing at "hello" because it is probably using the serial peripheral incorrectly (probably still configured like a 3.1/3.2, which probably has different settings/memory locations from the 3.5) |
|
Im having a bit of trouble running bindgen. I compiled the latest version from git but if I run the same command you did, it says --match is an unknown option. Also, What directory should I be in when running bindgen? I assume somewhere in teensy3-rs |
|
I did some more looking into this and got it working somewhat by checking out an older version of bindgen. Looks like --match has been removed rust-lang/rust-bindgen#50 I tried running it in both the teensy3 and teensy3-sys folder but now I get |
|
@TheZoq2 Hey sorry, I don't think that command will work exactly, it was run a while ago, on someone elses computer. It was meant to be a starting reference for you. Bindgen is probably vomiting because you don't have a What you are doing is generating a file (bindings.rs) to replace this one: https://github.com/jamesmunns/teensy3-rs/blob/master/teensy3-sys/bindings.rs |
|
Ah makes sense, I got it to run with the latest version but it's not working propperly. It now gives me the following output: Followed by thousands of lines of this I was able to fix the "file not found with things by editing WProgram.h and changing the angle brackets to However, I can't get rid of the warnings or the errors about redeclaring functions. I also have no idea how to avoid the massive amount of errors from bindgen. Im running this command In teensy3-sys where I have copied the current version of the teensy3 folder from the core repo. Do you have any suggestions for things I can try to get this working? |
|
Try this, I think you're close! You need to tell clang where to find the files. |
|
That got me a bit closer but I have not got it working yet. Clang gives me an error about redefining the random function as The only remaining problem is that bindgen gives me thousands of lines of what I posted before. Edit: Looks like I got a |
|
@TheZoq2 FWIW (I'm the bindgen maintainer), those lines are not worrisome, though are handy for debugging. Specially: "invalid type" with an empty type name is expected. Edit: Oh, and yeah, bindgen still tries its best to generate correct output even when it spits errors :) |
|
@emilio Alright, makes sense. At the end of the output, it prints some other errors aswell, are these harmless too? @jamesmunns I think i'm pretty close to getting it working now, Bindgen seems to generate a valid This is my current bindgen command I noticed some cargo.toml files in the teensy-rs repo. Running Im not sure why im not getting that error when building in the other places. Also, if I add the Somewhat unrelated, I tried to do some floating point calculations with the flag combination that works but it tells me that f32 is undefined, I assume the float stuff is part of rusts stdlib which is not available. |
|
I finally got some time to work on this again but no luck so far. I upgraded bindgen to the latest version and most of the repeated errrors are gone, however I get some errors that I havn't seen before. Could any of these cause issues? @emilio I also got the compiler to link with the The last flag I think might be causing issues is the Some quick googling tells me that this is because the "standard library" im linking against hasn't been compiled with float-abi set to hard and the error message suggests the same thing. Perhaps I need to change the target? @jamesmunns Any ideas? |
|
Hey @TheZoq2, I haven't forgotten about you. I don't know what the problem is, and I haven't had time to troubleshoot from my side. If I get a chance, I'll let you know. Sorry for not being more helpful :( |
|
#18 does build-time bindgen. It has some compiler flags hard-coded in "-mthumb",
"-mcpu=cortex-m4",
"-D__MK20DX256__",
"-DF_CPU=48000000",With that, I think the next step is to have Cargo features in both the teensy3 and teensy3-sys crates, one for each type/version of supported Teensy hardware. The build script would check that one and only one is enabled, check that it is consistent with |
|
@TheZoq2 @ratkins @pointlessone are you all/any of you still interested? @SimonSapin has done some seriously awesome groundwork to make the binding process more dynamic, and we might be able to make progress again, but I don't have access to hardware (other than the Teensy 3.2) to test. I will hopefully be able to merge #18, which will allow for compile-time switches, then I can help get the build options adapted correctly for the 3.0, 3.5, and 3.6. |
|
@jamesmunns Unfortunately I'm busy with other things at the moment but I'm willing to sponsor the boards to you. Ping me on email if you're interested. |
|
I'm still interested in this and I'll gladly help test things. |
|
@pointlessone, no worries, I understand how schedules are. I'll ping you when I have something I think should work, and if you have a bit of time to test it, that would be great, and if not, or if additional debugging is required, I can reach out to you to get boards, or set something up. Thanks for the offer! Hopefully if TheZoq2 is around, we can work through some of the pains with the 3.5 board before we have to test the 3.6. |
|
Definitely interested, may be limited on time but will see if I can get to it this week. |
|
I forgot to mention that I did that and it doesn't seem to reveal any more info. Here is with backtrace=1 And full: |
|
This doesn't tell as much as one would hope, but I think L162 in the buildscript is the problem. |
|
@Emilgardis I'm not sure why this is breaking, he pulled v0.2.0 of that crate and built previously. Actually I think I know whats up, @TheZoq2, could you please checkout the submodules for cd teensy3-rs
git submodule init
git submodule update --recursiveSorry, I forgot that step in my previous instructions. |
|
After you get the submodules, you can try building again |
|
Also I will change the |
|
Sorry to spam, but @TheZoq2, please try my steps without making @Emilgardis' changes (or at least try them one at a time). |
|
Yep, checking out the submodules fixed the issue. The program compiled fine and got further than last time. The led seems to blink several times which means it goes through the loop more than once. However, if I try to open the serial monitor it stops running. I think that may be an issue with my PC though as it seems like serial doesn't work with the example sketches either. I will try on my laptop and see what happens |
|
@TheZoq2 Hooray! Progress! If you are still stuck, I should be available tomorrow most of the day. Just send me an email (its on my github profile) or @ me here, and we can find a way to chat (IRC, etc). If it runs the loop too many times without serial being connected, I think it will crash (the output buffer is probably full and failing an |
|
Looks like my theory was correct, it runs well on my laptop and prints the serial message. Looks like it's working fine. Also, the issue only happened as soon as I opened the serial monitor, without it on it ran fine, atleast for 10-20 seconds :D |
|
@TheZoq2 Sounds good! Feel free to play around with it a bit, and let me know if you can manage to break it somehow. @ratkins I'll try and get the Teensy 3.0s up and working tomorrow, hopefully I should have something for you to try in the next 24 hours or so :) Right now none of the boards have Hard Float enabled, but I'll get soft-float-only working for this stage/ticket, and tackle the hard float problem separately. This shouldn't be a problem since neither the Rust code nor the C code have it enabled (it will just impact performance). |
|
Yep, i'll have a go at trying to break it tomorrow, finally being able to use rust on a microcontroller will be nice :) |
|
My understanding is that only 3.5 and 3.6 have floating-point hardware. Cortex-M4F vs Cortex-M4 on https://www.pjrc.com/teensy/techspecs.html |
|
@SimonSapin I'll look at that in #21. I think you're right, not sure what had me confused at the time. |
|
Hey @TheZoq2, could you please get on #rust-embedded on irc.mozilla.org? |
|
I think I have 3.0, 3.5 w/hard float, and 3.6 w/hard float ready to test. @ratkins and @TheZoq2 could you please check? # skip if you already got it
git clone https://github.com/jamesmunns/teensy3-rs-demo.git
cd teensy3-rs-demo
# if you already have the branch, don't forget to pull
git checkout teensy_3_5_test
# Edit Cargo.toml with your board. Set the [features] section correctly
# teensy_3_0 => ratkins
# teensy_3_5 => TheZoq2
nano Cargo.toml
# Build for ratkins:
xargo build --release --target thumbv7em-none-eabi
# Build for TheZoq2 - note this changed
xargo build --release --target thumbv7em-none-eabihf
# Pick the right one:
arm-none-eabi-objcopy -O ihex -R .eeprom target/thumbv7em-none-eabi/release/teensy3-rs-demo target/hex
arm-none-eabi-objcopy -O ihex -R .eeprom target/thumbv7em-none-eabihf/release/teensy3-rs-demo target/hex
# Flash, first for ratkins, then TheZoq2
teensy_loader_cli -w -s --mcu=mk20dx128 target/hex
teensy_loader_cli -w -s --mcu=mk64fx512 target/hex |
|
Failing at the compile step: Full output: How do I know if I have "A somewhat current arm-none-eabi-gcc toolchain", and how do I get one on macOS Sierra? (I thought I must have had this installed from the last go-round, but I have no |
|
@ratkins I think you can check if you have the toolchain installed by trying to run |
|
|
@jamesmunns I tested the hardfloat stuff but it doesn't seem to work. This is the error I got when running This is my Edit: We seem to be in different timezones, I'll be in the irc channel now though |
|
@jamesmunns I tried the same thing on my desktop where I have not made any modifications to the code. This time I got the following error Edit: Changing between feature teensy_3_5 and 3_2 don't seem to affect the output at all Edit2: I realized that I ran a system update on my desktop which meant I was using clang4. Switching to clang35 gives me the same error as on my laptop |
|
@TheZoq2 / @Emilgardis thanks for that. I did have it installed via Homebrew and it's now at 5.4.1 and I'm getting a different error: So that seems to be the same error as @TheZoq2? I'm running |
|
Hey @ratkins and @TheZoq2, thanks for testing! I will have to try and lock down the specific dependencies, and also probably try to test in a more reliable environment than "works on my machine". I also am a little worried about how much value users actually get from generating the bindings and build time (if they use At least one problem was caused by me adding this line: https://github.com/jamesmunns/teensy3-rs/blob/add-feature-flags/teensy3-sys/build.rs#L23 - I will revert this change. It looks like this will at least partially fix @TheZoq2 's issues. |
|
@TheZoq2 I pushed the changes, you can try again if you like. You may need to run @ratkins you are welcome to try again now, but it looks like different versions of llvm, or even Mac's version vs Linux's version of llvm is likely going to cause some problems. I am using clang v3.9, from the PPA provided by Clang, on debian, in a docker image. |
|
Looks like your fixed worked @jamesmunns. |
|
Still similar errors for me: From that I'm not even sure if it's trying to cross-compile? |
|
@jamesmunns Would it help the process if you had a 3.5/3.6 board ? I will gladly buy one for that cause if you would like it. I'm a little new in the low level embedded stuff, but I'd like to contribute, and I'll see how far I can get on a 3.5 the next couple of days. |
|
Teensy 4.0 is out now. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Some combination of rust-lang/rfcs#1645 (comment) and perhaps a rebuild of teensy3-sys for the new targets, selected during
build.rsbased on feature flags.The text was updated successfully, but these errors were encountered: