BASIC for Teensy 3.0/3.1

[ARMbasic]

We have been working on porting ARMbasic to the Teensy FreeScale ARMs. This is a compiler, not an interpreter, so speeds are comparable to C.

It is passing our initial tests, and we'll be putting together an installer package in the next few days. When that is ready, I'll post a link.

For now if you want to look at the BASIC dialect we use

http://www.coridium.us/ARMhelp/index...ge=DocToc.html

Our version works for Windows, and generates .hex files that can be loaded with the teensy.exe loader.

It could be done with command lines in linux/MAC, but those are not our areas of expertise, but would help anyone interested in going that way. The BASICtools utility is written in Tcl, and some time in the past we actually had it working on ubuntu, but haven't tried to keep it up to date.

[stevech]

great. Looking forward to a beta version to try on the Teensy 3.1.

[ARMbasic]

Go niners (though it is looking bad)

I have a beta version of BASIC for Teensy 3.0/3.1 ready at

www.coridium.us/files/setupBASICbeta.exe

To use this make sure you have installed version 1.18 of the Teensyduino installed, which gets you the right drivers and Teensy.exe

Run BASICtools like normal

Teensy devices will show up as serial ports ComX, first character capitalized

If the Teensy device is not showing up as a USBserial device, you can force it to load that program by selecting >Options >Control >Teensy 3.0 or 3.1. Then if you refresh the >Options >Serial ports >Refresh, it should be visible

Then you can either type in programs or load them from disk.

On Teensy; the program is loaded, but not automatically executed after the load. To run the program either type RUN or hit the RUN button. Programs do start following a power up, so the Teensy will remember your BASIC program and will start it up following powerup.

We rely heavily on the serial interface to debug programs in BASIC, and the Teensy will disable that interface during the reboot process and certain programs can hang up that interface. But we think we have a relatively stable relationship with loading programs.

I have this working on a Win8.1 and one Win7 system. But on one of my Win7 systems, Teensy.exe is not started by BASICtools, you will get an error asking whether the Teensy loader is running. If this is your case, exit BASICtools, start Teensy.exe, then restart BASICtools. I'm investigating a work around, seems to be some interaction of Tcl and Teensy.

... oh well, good luck Seahawks

[stevech]

A bit of a crib sheet, s.v.p.
Windows 7, 64 bit.
Installation went OK. I let it use the defaults for all, including where to put the examples.
In BasicTools:

It did not launch teensy.exe - which for me is located in C:\Arduino\hardware\tools ... which is the default location for Windows.
So, I launched teensy.exe manually.

options->control ... do we override the default selection of "Normal", with Teensy 3.1 (e.g.) ?
options->Serial Port ... Displayed list of ports are the usual ports, none of which are Teensy at this point. No teensy choices because there's no download yet initiated. How's this supposed to work? No serial port until will exist until BasicTools tells Teensy.ext to use the relevant .hex file, right?

I guessed at several choices in the menuas. None worked.

I was going to use, from the examples, blinkey.bas but that code had no ifdef for the Teensy3.1 CPU.
So I edited a hello.bas file.
When I told BasicTools to "load" that file, looks like it compiled then tried to automatically download it to the board, via Teensy.exe which I launched manually.
the output was

Analyzing C:/Users/steve/Desktop/BasicToolsHello.bas
Programming Flash 0031...

Error:

Teensy Loader is unable to read your compiled sketch (r) This error should never happen. Please report this to paul@pjrc.com, hopefully with enough information to reproduce the problem so it can be understood and fixed!child process exited abnormally
Teensy Loader is unable to read your compiled sketch (r) This error should never happen. Please report this to paul@pjrc.com, hopefully with enough information to reproduce the problem so it can be understood and fixed!child process exited abnormally
while executing
"exec "$teensyDir/teensy_reboot""
(procedure "downloadTeensy" line 29)
invoked from within
"downloadTeensy 1"
(procedure "download21XX" line 8)
invoked from within
"download21XX"
(procedure "processFile" line 19)
invoked from within
"$command $file2send"
(procedure "chooseBASFile" line 28)
invoked from within
"chooseBASFile [pwd] "processFile" "Load File""
(menu invoke)

here was a pop-up window named "Choose Teensy Type", containing the boldface type: "Teensy is Downloading".
By the way, I couldn't find the .hex for my hello.bas which I put on my desktop. Maybe that's why Teensy.txt couldn't run?

this is all likely my confusion, lacking a crib sheet.

I moved the .bas file to the myDocuments folder (which I don't use), Coridium folder. The did a load. Immediate error about unable to communicate, COM error.

The Teensyduino rc18 I'm using does work for Arduino 1.0.5's IDE and for Visual Studio with the Arduino plugin.

[stevech]

For how BasicTools should handle the Teensy loader, the following, taken from Paul's comments in the Codebender thread here, has the gist which is probably old news:

Teensy uses its own HID-based protocol for programming. It's quite different from all the other Arduino compatible boards, which implement serial devices for programming. There are 2 ways you might incorporate Teensy's upload protocol. There's an open source command line loader, which might be the easiest way. You could also try using the proprietary GUI-based loader, which has some command line control programs. That's what the Teensyduino installer puts into hardware/tools. Just launch the GUI, then you can open a file with teensy_post_compile, and set the loader to "auto" mode (where it will automatically program the next Teensy that reboots). The teensy_reboot program will find a Teensy (if it's running code previously made with Teensyduino) and ask it to reboot to programming mode.

[ARMbasic]

You should have control set to Teensy 3.0 or 3.1 depending on the board you have

Yes we have not gone through any of the example code to make them compatible with the Teensy. That is going to be a huge job, and we;re looking for community support in that effort. We'll probably do blinky.bas as that is pretty simple. However ALL the peripherals are incompatible with the corresponding NXP types, so like I say it is a big task, and we will do some of them.

As for command line loaders, those are not currently up to date for either Win8.1 or Teensy3.1, so that is why we are using the GUI version for now.

The BASIC hex file is %temp%/coridium/teensyBASIC.hex

If you have to start the Teensy loader manually, use the one we install in Program Files (x86)/Coridium/freescale directory, it is version 1.18-rc1 which is the latest AFAIK

I ran into "Teensy Loader is unable to read your compiled sketch ", but only when we inserted an extra blank line into the file. That blank line should not be there now.

I was running on a 64 bit version of Win7, during much of the development, and later on Win8.1. I only ran into the issue when I put it onto a "virgin" system which happens to be my wifes. So it was only discovered at the last minute, and some quick work arounds did not work. For some reason launching teensy_post_compile from Tcl fails to execute, it seems to just hang and not produce any error. And other than yours and my wife's I had not seen it before.

The BASICtools environment is going to be a moving target, and the crib sheet is really going to be here.

Thanks for the feedback.

You should be able to force the Teensy to load BASIC firmware by manually loading /Program Files (x86)/Coridium/freescale/teensyBASIC31.hex When doing this, I often had to push the reload button more than once. But I could tell when it worked by getting the Win8.1 tones for a USB device being installed. And walla, it did show up in the serial port list. On my Win7 system, I often got the welcome message, but on the Win8 I did not. I'm sure this is timing dependent on USBserial device configuration driver. Just as a heartbeat, I added a routine in the firmware startup that flashes the LED 3 times quickly.

A simple blinky is --

for i=1 to 20
io(13) = i and 1
wait(500)
next i

[stevech]

Win 7 64 bit.

OK. The above should help.
I launched Teensy.exe from your Freescale folder as discussed above.
But in BasicTools, when I choose Teensy 3.1 in the controls menu, it immediately starts trying to download something (I've not yet loaded and source).
I cancel out of those two error pop-ups.
Then I create a file with your suggested code

for i=1 to 20
io(13) = i and 1
wait(500)
next i

Teensy.exe from your Freescale folder is still running.
when I tell BasicTools to load, I see

Teensy Loader is unable to read your compiled sketch (r) This error should never happen....

same as discussed in prior posts of this thread.

To manually upload...
I don't see a .hex as discussed above. I opened a command window, did cd %temp% and dir *.hex.
The resultant dir is C:\Users\steve\AppData\Local\Temp

[ARMbasic]

Cheat sheet updates--

What we have tested is the compiler test cases, which check it's operation, pre-processor all arithmetic, string and floating point operations.
The timer is calibrated to 48 MHz clock, and the IOs are re-mapped to the Teensy assignments. (Just as an aside we use to do it this way for the NXP parts, to remap to the board layout, but later gave up trying to support that as it was too confusing for people trying to use the vendor assignments).

Futures-
We tried to run at 72 MHz, but the stock routines don't setup USB correctly when running at that speed, so we'll wait until someone here posts that code.
We have some examples of timer and IO interrupts and will post that code soon.
For one of our custom designs we needed a QuickSort and will make sure that runs on Teensy
Also for one of our custom designs, we implemented a simple interface to an SDcard file IO, using the builtin SPI hardware. We have this working on NXP parts, and will port it to Teensy SPI
Apparently the only mechanism at present to write to Flash is to use the Mini54 to control the EZport, and when we get some sample code we'll add that feature to BASIC (I wonder if it is truly impossible for an MK20DX to write to its own Flash.
Our BASIC compiler uses different intel hex format flags to handle >64K than Paul is using. We just have to find out what those are, and we'll then be able to do code >64K. Though that is pretty low priority, as there are only a couple customers who have got programs that have grown that large. One case uses a lot of complex menus that are displayed on a multi-line LCD, but that is really an exception.
An oversight on this version only allocates 16K of variable space, the 3.1 should have 64K, and that will get into a future revision.

At this point I think the firmware itself is pretty stable, we just need to get more feedback on bringing up the BASICtools IDE and Teensy loader environment.

[ARMbasic]

When you choose >Option >Control >Teensy 3.0/3.1 It should launch the Teensy loader, as it is trying to load some boiler plate code that enables the USBserial port. This is one of those chicken and egg issues, you need to get the USBserial running for the BASIC to talk to it. And I often had to push the activate button until the USBserial port was started (most of the time I have the Teensy loader configured for Auto, not sure how to do that from the command line)

The hex file is down one more directory

%temp%/coridium/teensyBASIC.hex

What version of Teensy loader are you using? And may email me the above file if it still complains about it.

[ARMbasic]

Found a cure for the Win7 teensy startup, updating the setup files now, also pruned the examples to include only those for Teensy so far. All the libraries are included for now as those may help with ports to Teensy

I guess it would have failed on my other Win7 machine, just once teensy.exe is loaded, it never quits. And that is the issue with Tcl, it needs to start this way--

exec teensy &

[ARMbasic]

I launched Teensy.exe from your Freescale folder as discussed above.
But in BasicTools, when I choose Teensy 3.1 in the controls menu, it immediately starts trying to download something (I've not yet loaded and source).
I cancel out of those two error pop-ups

One of those should be an info window (will correct that later), the other is not an error window, but should be the select the Teensy type.

I'm still playing with the interaction of BASICtools and teensy downloader, BT was written with the idea the serial port was always available.

[ARMbasic]

OK, version 5.20 should be good to go. It handles cases where the Teensy did not have USBserial code loaded, or cases where the USBserial code has crashed. So if no Teensy USBserial ports are listed (any one with the first letter capitalized); to enable a Teensy device select >Options >Control >Teensy3x

Code at the same place

www.coridium.us/files/setupBASICbeta.exe

[stevech]

some progress! But the fat lady is mute.
With this newest version (as above)...

From earlier in this thread, did you say that TeensyBASIC must push down some code when it first starts up? Is that called teensyBASIC.hex?
I see that this file was created in the temp dir.
I don't think it is getting loaded successfully.

When BasicTools is run from the Windows 7 start menu, it does now launch a Teensy.exe.
I defined the desired editor (setting lost due to the update).

When I use the menu: Options->teensy3.1, I think that Coridium Basic tries to push teensyBASIC.hex to the board.
A popup says

Teensy Loader is unable to read your compiled sketch (r) This error should never happen. Please report this to paul@pjrc.com, hopefully with enough information to reproduce the problem so it can be understood and fixed!child process exited abnormally
Teensy Loader is unable to read your compiled sketch (r) This error should never happen. Please report this to paul@pjrc.com, hopefully with enough information to reproduce the problem so it can be understood and fixed!child process exited abnormally
while executing
"exec "$teensyDir/teensy_reboot""
(procedure "resetTeensy" line 14)
invoked from within
"resetTeensy"
(menu invoke)

This is before I do a load or reload.
Until this works right, perhaps the rest, below, is moot.

I then did a load of my little LED blinker: test.bas.
pop-up said Teensy is loading.
teensy.exe window said downloading, OK. But it was loading teensyBASIC.hex. That's not my code: test.hex.

In the temp dir I see test.bpp but no test.hex.

[ARMbasic]

Lets get on the same page-

What version of BASICtools? Mine shows 5.20 - the compiler is not changing for now 9.28e
What version of Teensy.exe? Mine shows 1.18-rc1
What version of Teensy? I have been using a 3.1

I went back to a Teensy 3.0, and do see issues there, and am tracking that down

I have not seen the

Teensy Loader is unable to read your compiled sketch (r) This error should never happen. Please report this to paul@pjrc.com, hopefully with enough information to reproduce the problem so it can be understood and fixed!child process exited abnormally

messsage for quite some time.

teensyBASIC30.hex and teensyBASIC31.hex are what in NXP versions we have been calling BASIC firmware, they contain all the called subroutines, PRINT, string handling, floating point and the like

The BASIC compiler reads the those files, your source is then compiled to a hex file that is appended to that file, placed in the temp directory and downloaded using Teensy.exe and currently named teensyBASIC.hex I'll look into changing the name to your original, maybe making a copy into your original directory. Though I don't like using the original directory because people put things in places that sometimes can not be modified by Tcl programs.

[ARMbasic]

Wow, this USBserial port opening and closing is causing a real nightmare to keep in sync with the Teensy, once in sync though it is working.

How to get in sync (until we figure out how to do it programmatically). And for now use Teensy3.1

run Teensy.exe (1.18)
load /program files (x86)/coridium/freescale/teensy31.hex
activate by pushing button

You should see the LED flash 3 times quickly
A USBserial port should now be available (look in device manager, or teraterm)

Quit Teensy.exe

Start BASICtools
It should see a ComX port which is the Teensy
Certain commands in BASICtools are sent to the board among them the debug commands so type --
@0
It should show

00000000: 20008000 000001C1 00000991 000009B1 000009D9 000009F9 00000A19 00000000

At that point you are in sync, and you can load and run BASIC programs

[PaulStoffregen]

Quit Teensy.exe

You should not need to quit the Teensy Loader, but of course you can it you want.

After the Teensy Loader writes the .hex file and reboots the board, it does not attempt to access it again as it reboot to your program. It should be safe to just leave it running.

[stevech]

OK. I get what you are doing now.
So I used Teensy.exe to manually push down teensy31.hex.
That seems to open a serial port (Com16) per device manager. That's the usual port # for this board on my PC.
Then I use BasicTools.. it shows Com16.
Your suggestion to use an @0 command... I couldn't find how to enter that command. So I pressed on.
I did 'load test.bas' which is a little test snippet to blink the LED differently than do the utilities so I can ensure that the ARM didn't crash to some other led blinking in the downloader/trap handler:

for i=1 to 20
io(13) = 0
wait(100)
io(13) = 1
wait(500)
next i

when load is done, I see a pop-up Teensy Is Downloading; then there are LED flashes (3?). then nothing.
Last thing from BASICtools was "Programming Flash 0031...".

So now, maybe the issue is just that the code, above, is missing a Basic statement to set pin 13 as a digital output? I'll seek out the syntax for doing that.

If I can get this code to run, then we can discuss the options for a more automated/foolproof scheme to push code. Such as pre-pending teensy31.hex (minus the end record) to the user's application hex. Then call teensy.exe to just push both at once.
It really needs to let me invoke the compiler for error checks before trying to push a .hex to the board. I usually do compile for errors many times before wanting to push a .hex.

[stevech]

I added as a guess, the first line of code, output()...

output(13)
for i=1 to 20
io(13) = 0
wait(100)
io(13) = 1
wait(500)
next i

to the little code snippet LED linker.

I did reload and got 3 LED blinks (from teensy31.hex code?)

So maybe the issue now is merely that the test code, above, is wrong? Not sure how BasicTools' output() and io() are doing pin/port numbering for the K20 ARM.

[ARMbasic]

Let me first preface by this, I really appreciate your help Steve, as it is hard for me to get far enough away from the interface to view it from a new user perspective.

Anyway

Your suggestion to use an @0 command... I couldn't find how to enter that command.

Is entered in the Enter: box at the bottom of the window (typing anywhere else in this window does nothing)



If you see the 00000000: 20002000 ... then the Teensy is responding (if you don't see then it is not)

Your program is fine. IO when on the left hand side of an expression turns that pin to an output and assigns the value. If on the right hand side of an expression it becomes an input and returns 0 for low 0xffffffff (-1) for high. We are mapping pins to the assignments Paul has given them on his diagram.

When a program is loaded into memory it does not start your portion of the code. The algorithm is, on reset the code looks at the reset cause status register. If the reset was a power on event, then the user code IS started. If the reset event was the reset pin pulled (which is done during teensy load), then the program stops before execution of the user BASIC code. This allows you to be in sync with the terminal emulation side of BASICtools, also do debug commands like @ -- dump or ! write to memory. Actually much of this is in the user manual, just we haven't done specific stuff for Teensy (as it is still a moving target).

From the command prompt you can now run your program by typing run or ^ or hitting the RUN button

[stevech]

I'm fumbling a lot; don't yet get "it" .. probably because I'm accustomed to the concept of compile then command a download and there's no subsequent 'run' command. Lots of "Com16 no longer available pop-ups).

The @0 command yielded a different number than shown above
00000000: 20008000 000001C1 00000991 000009B1 000009D9 000009F9 00000A19 00000000

So the LED has yet to blink by my code.
Still working to get-it, on the proper procedures.

[stevech]

When I choose options->Teensy3.1, a pop-up says Hit Activate button. But simultaneously, Teensy.exe's window shows it's downloading then rebooting, I think, teensy31.hex. Without me hitting/pressing the button. This is confusing. After this, the menu has reverted to Normal, rather than Teensy3.1. I think that pop-up windows just displays and closes itself after a few seconds, no matter if I push the button or not. Teensy.exe is in the AUTO mode.

[ARMbasic]

Sounds like you are almost there, you can either type a short program line by line into the Enter box (it will be red in the next version) or using a test editor as you have been.

The differences in the numbers, are I used a Teensy3.0 as it was the first one I grabbed (though the "release" version still doesn't have the right code yet). I was going to post the .hex file here, but that is not one of the allowable attachments in the forum.

We could just produce a .hex file and after the load run it. But the reason we don't is that without a serial wire debug or JTAG your visibility into the code is pretty poor. You could do it all by wiggling pins, but that gets old. So to actually see the results of the PRINT commands, we need to be in sync with the USBserial device. That's why we stall the code right before the launch of your BASIC program.

The stock USB code on the Teensy side loses anything sent before the Windows side has opened the serial device.

We will change the .hex file to reflect your source file, maybe copy it into your original directory. But right now the program will only start on a power on reset. I'm not sure in the Teensy way whether there is a good alternative between being able to debug and load-and-run the program.

[ARMbasic]

We are still struggling with the synchronization between windows and teensy, and between running the first time and running subsequent times.

There may be a better way for Windows to know what is going on, on the teensy side. We have not dug into the teensy.exe and really don't want to at this point.

One thing we have been burned by is the the USBserial device can show up in the registry (which is where we look) and it actually being available. This has been a surprise, and it is the way the "Teensy is downloading" popup is removed. We are looking at the registry and when USBSER00x shows up we remove that popup, or we also remove it after 5 seconds. However we have seen that 5 seconds may not be enough time. We added the popup in the first place to keep people from pushing buttons or typing before it was really ready.

[PaulStoffregen]

From Arduino, you can use "Serial" in a boolean context to test if the USB has been enumerated and the terminal emulator on the PC has asserted the DTR signal. For example:

  while (!Serial) ; // wait for the Arduino Serial Monitor to be opened

On Linux and Macintosh, DTR is always asserted when the device is oped and deassered when it's closed. While open, the program can control DTR.

On Windows, this behavior is generally the default, but the WIN32 API also provides a way to gain control of DTR before opening the device. So on Windows, this mechanism is not a 100% reliable way to detect when a program opens the port. There may not be any completely reliable way to do so with Windows. But this approach usually works pretty well anyway, and of course if you are providing the software that opens the serial port, you can in control of whether it asserts DTR normally or not.

Regarding waiting on the PC side, I'm afraid Windows is a minefield of inconsistent timing. I wish there were better answers. Mac and Linux always seem to detect USB devices and create the device files quickly. Sadly, Windows has strange delays. Several times I've tried to investigate why it does such things, but I've never made much progress.

[stevech]

I've found that (for USB), (!Serial) rarely or never evaluates to True, on the Teensy 3's.

For now, with Teensy 3 and C/C++, I just put in a 5 second delay before sending debug info out the USB/serial port, and assume that I will open a terminal window in that time.