Closed brianc118 closed 9 years ago
@brainchen98 , may I ask which versions of STino, Arduino IDE, TeensyDuino, SublimeText you are using? today I'm gonna spend some time installing TeensyDuino and testing on a Teensy 3.1 to see if this works. had such an issue in the past and can't remember if I found a workaround or not
thanks.u
from http://www.pjrc.com/teensy/td_download.html: Teensyduino 1.20 supports only Arduino version 1.0.5 and 1.0.6. Arduino 1.5.x BETA versions are not yet supported.
Arduino 1.0.5 Teensyduino 1.19 New-STino (for the new features) ST3 Everything works when I compile using the Arduino IDE.
I've been using the STino/ST3/Arduino 1.0.5/Teensyduino 1.19 setup for a long time. The issue on arose when I installed the new-STino. Everything worked before when I was using the old STino 1.2 (the one you install via package control).
This is certainly an issue with new-STino only.
thanks.
thanks for the detailed config, @brainchen98 looking forward to giving it a shot and see if I can help :)
Hi @brainchen98, Stino is not Arduino IDE and it does not depend on Arduino IDE. So, what works well in Arduino IDE maybe not work well in Stino. They are not same softwares. The Teensy's provider provides an add-on for Arduino IDE, and the different version add-ons support different version Arduino IDE. I guess the add-ons revised certain version Arduino IDE's source code and replaces some Java libraries for Arduino IDE, but I do not know what it did. There is no documents on Teensy's website. That is I will add support for Teensy boards, but I need your help. For writing this plugin, I bought a mega2560 and a Leonardo, but I can not buy all kinds of boards. So, I can not test by myself, I will improve the board support when you give me feedbacks. Thanks a lot.
hey @Robot-Will and @brainchen98
I've been trying to compile for Teensy 3.1 and got the error.
the wrong compiler gets called in by STino. it seems it defaults to avrg++
, so most of the options won't make sense to the compiler.
I tracked down in the source code for STino that here is where it happens pyarduino/arduino_compiler.py #269
if not 'compiler.path' in self.params:
compiler_path = '{runtime.ide.path}/hardware/tools/avr/bin/'
self.params['compiler.path'] = compiler_path
it may be that pyarduino/arduino_info.py
fails to extract all the parameters from boards.txt
in the Teensy folder.
I'm not big on Python, sorry :)
Hi @ubidefeo ,
Do I have the same issue as you? I don't think avrg++
(though I thought it would be avrgcc
) is the problem.
@Robot-Will , could you please help here?
I've tracked it down to here. pyarduino/arduino_compiler.py #195
target_arch = \
self.arduino_info.get_target_board_info().get_target_arch()
I added this to the next line after it to print out "target_arch"
self.message_queue.put('target_arch = {0}\n', target_arch)
And when building, I find that
[Stino - Start building "Blink"...]
target_arch = avr
Creating C:\Users\Brian\Documents\Arduino_build\Blink\Blink.ino.cpp.o...
unknown MCU 'cortex-m4' specified
Known MCU names:
...
target_arch = avr!
self.arduino_info
is declared/defined earlier on in pyarduino/arduino_compiler.py #37
self.arduino_info = arduino_info.get_arduino_info()
arduino_info
is an object from the class ArduinoInfo
found in pyarduino/arduino_info.py
I kept tracing everything and finally end up at pyarduino/arduino_target_board.py #77-81
def get_target_arch(self):
target_board_id = self.target_board.get_id()
ids = target_board_id.split('.')
target_arch = ids[-2]
return target_arch
Now, when I was printing out self.target_board
on the console, I found that
self.target_board = ide.teensy.avr.teensy31
?!
It's correct as being listed as a Teensy 3.1, but why is it an avr?
target_arch = ids[-2]
is the second element of ids
from the end, meaning that ids[-2] = avr
.
I also noticed this in the main menu before. If you go to Arduino -> Board
on the interface, you'll find that the Teensy boards are listed as "TEENSY AVR Boards." I had thought this was just a bug, but perhaps it isn't?
Help please @Robot-Will? Surely you know you're code better than me. I too am not familiar with python. I've only written about 150 lines of it before.
Hi, @brainchen98 and @ubidefeo, I added Teensy support. You can try it. Thanks.
Thanks @Robot-Will .
Blink now compiles. However, the teensy loader application (teensy.exe) isn't started. Instead, when uploading, STino throws the error: [Stino - Exit with error code 1.]
after staying on [Stino - Start uploading...]
for a few seconds.
Also, the compiler doesn't generates a .hex file. Instead, the closest thing I can find to the .hex file is is Blink.bin
which is around 100kB larger than what is specified by the compiler:
Sketch uses 5,512 bytes (2.1%) of program storage space. Maximum is 262,144 bytes.
By the way, you don't really need to have a Teensy to test the plugin. All you need it Teensyduino.
thanks again for your continuous help @Robot-Will and @ubidefeo .
thanks @Robot-Will for fixing the compilation issue.
@brainchen98 I am not involved in the development of STino. I try to help with issues I am comfortable with :) at some point I'm gonna have to learn proper Python, and this project seems ideal as a playground.
anyway...
TeensyLoader should be already running before you upload, but even so I had no luck uploading a compiled sketch. as @brainchen98 reports, no .hex
is generated.
there's something odd happening through the whole pipeline, and I believe we can find it just by reading both Arduino IDE and SublimeText console output.
I'm running Arduino IDE in full verbose mode (compilation/upload).
what I found out:
success
anyway without uploading. this means that Teensy Loader works fine.hex
is generated. looking at the log I found out that the option for -O
(output) is set to binary
while it should be ihex
.Arduino
/Applications/Hardware/Arduino_106/Arduino.app/Contents/Resources/Java/hardware/tools/arm-none-eabi/bin/arm-none-eabi-objcopy -O ihex -R .eeprom /var/folders/l1/z4525b5j61g04d0147sqt9n80000gn/T/build5347094290838081088.tmp/ST3_test.cpp.elf /var/folders/l1/z4525b5j61g04d0147sqt9n80000gn/T/build5347094290838081088.tmp/ST3_test.cpp.hex
SublimeText
"/Applications/Hardware/Arduino_106/Arduino.app/Contents/Resources/Java/hardware/tools/arm-none-eabi/bin/arm-none-eabi-objcopy" -O binary "/data/Dropbox/AppsDocuments/ArduinoBuild/ST3_test/ST3_test.elf" "/data/Dropbox/AppsDocuments/ArduinoBuild/ST3_test/ST3_test.bin"
@Robot-Will , I'll keep running a few tests and see if how it pans out. there must be something else we're overlooking. Teensy boards are becoming extremely popular among more advanced users, and I think being able to support them is important.
thanks for following up. speak later (y)
Looking at the build folders, it seems like everything is there except the hex file.
Eventually, Arduino will fully support command line building (parsing arguments to the executable); however this probably won't happen for a while yet. The beta 1.5.x is testing this and the last time I tried it wasn't spectacular. Paul at PJRC has specified that he won't support Arduino 1.5.x until it's no longer beta, which will be after a long time (probably like a year).
Support for Teensy boards is really helpful, as there is quite a large community behind it.
I'm quite sure that the .bin file is not the .hex file. I've renamed it to .hex and manually uploaded it to the Teensy. It doesn't blink.
@brainchen98 not the same file format :)
not sure which HEX
format the linker outputs, but if you're interested in formats you can find some nice info here.
http://en.wikipedia.org/wiki/Intel_HEX
i don't blame Paul for holding back on officially supporting 1.5.x in Teensyduino (probably my favourite little hardware dev platform) until it's 'final'. Arduino 1.5.x, if not already, is well on its way to becoming the textbook example of how not to manage a software project: lack of goals, feature creep, chopping & changing spec, design-by-committee... not to mention Arduino being pulled in several 'target market' directions that will be difficult, if not impossible, to reconcile. It's probably one of the reasons things like COSA (https://github.com/mikaelpatel/Cosa) have sprung up, to take Arduino's multiple-platform support framwork, but take off most of the training wheels. This is also the reason I'm so interested in STino :)
@techydude Paul is an incredible engineer. Arduino is a difficult machine to run, nowadays. I love what they're doing, and they're friends :) I think they're doing some incredible work. there's so much behind the scene that it's easy to judge the outcome without knowing. I still believe the AVR Arduino is one of the best beginner boards out there, and learning how that chip works can lead the way for more platforms.
in the past I've looked into other libraries more optimised for pro users and chip nerds. MakeHackVoid (currently InfernoEmbedded) released MHVLib a while ago. it's now called Flame Runtime. https://infernoembedded.com/products/flame-runtime
@ubidefeo thanks. @techydude , My experience with the Arduino gui has been ... well let's just say bad enough for me to change to something else within an hour. I've gone into much research into compiling with makefiles but I use Windows and it isn't that easy to get it working. I first went to Visual Micro which worked wonderfully, except was a bit slow, especially with the serial monitor. Eventually, every time I opened VS it gave me messages to continuing trying the debugger, and so I gave up. Then I stumbled across STino and Sublime and I've never regretted since. The new-Stino now has pretty much the same functionality as Visual Micro, except that it lakes the debugging feature (which I find to be quite useless). It's amazing when I compile for non-Teensy boards.
agreed
Hi @ubidefeo @techydude @brainchen98, another fix. Thanks all your supports.
@Robot-Will tested, but something's still off.
{compiler.objcopy.eep.extra_flags}
appears in the command, and triggers an error for arm-none-eabi-objcopy
's first launch (-j
option).
the second step (-R
option) will not run as it stops there.
we may be closer than we thing :)
Hi @ubidefeo, sorry that I forgot to update the file platform_teensy3.txt. Thanks.
@Robot-Will It Works!
I guess the next step will be testing how the RFDuino behaves :D
@brainchen98 , can we consider this issue resolved and close it? please run a test with the newest release and confirm :)
Thanks @Robot-Will . It works wonderfully.
Hi @ubidefeo, I added RFduino support.
@Robot-Will you're a wizard! it's a good thing I got so many boards around, I love supporting this project :)
compilation works, upload fails with this
Traceback (most recent call last):
File "./threading.py", line 901, in _bootstrap_inner
File "./threading.py", line 858, in run
File "/Users/ubi/Library/Application Support/Sublime Text 3/Packages/Stino-new-stino/stino/pyarduino/arduino_uploader.py", line 38, in <lambda>
target=lambda: self.start_upload(using_programmer))
File "/Users/ubi/Library/Application Support/Sublime Text 3/Packages/Stino-new-stino/stino/pyarduino/arduino_uploader.py", line 49, in start_upload
self.exec_cmds()
File "/Users/ubi/Library/Application Support/Sublime Text 3/Packages/Stino-new-stino/stino/pyarduino/arduino_uploader.py", line 125, in exec_cmds
working_dir, self.cmds, self.message_queue, show_upload_output)
File "/Users/ubi/Library/Application Support/Sublime Text 3/Packages/Stino-new-stino/stino/pyarduino/arduino_compiler.py", line 464, in exec_cmds
message_queue.put(cmd + '\n')
TypeError: unsupported operand type(s) for +: 'NoneType' and 'str'
Hi @ubidefeo, thanks. A new fix.
@Robot-Will :)
[Stino - Done building "ColorWheel" in 2.4s.]
[Stino - Start uploading...]
"/Applications/Hardware/Arduino_1.6_rc1_zero_r04/Arduino.app/Contents/Resources/Java/hardware/arduino/RFduino/RFDLoader" -q "/dev/cu.usbserial-DN008OS4" "/data/Dropbox/AppsDocuments/ArduinoBuild/ColorWheel/ColorWheel.hex"
##############
SUCCESS !
##############
[Stino - Done uploading.]
Hi,
I'm experiencing this issue again with new Stino. I've tried building/compiling for all the Teensy boards. The Teensy 3.0 and 3.1 get the following error:
Whilst the Teensy 2.0 and Teensy ++ 2.0 simply get's the Serial error:
Note that I have a slightly modified version of Blink (but it did compile and does compile on Arduino):
Thanks.