BASIC for Teensy 3.0/3.1

Status
Not open for further replies.
However, I think allocating that much for buffers takes away too much memory that the user might need for variable space. This would be a case where a special UART routines can be written in BASIC.
True, for AVRs. Teensy 3.1's 64KB makes it far less of an issue. Challenge is that a framed data device like the XBee in API mode (commonly used), sends to the host CPU about 130 bytes in one API frame, back to back bytes. Same thing with some other UART apps. So aggressive polling is needed to avoid data overrun. An event callback is of course more conventional/elegant.

EDIT: The buffers for the 3 UARTs could be obtained at run time from the heap or some such, rather than being static / compile-time. Perhaps with a new function like UARTbegin(uart, baud, TXbufSize, RXbufSize). And the inverse to free buffers when the UART is disable.d
-----------
 
Last edited:
ARMbasic compile-only in IDE

With ARMbasic I really do miss a compile-only option.
Just compile to see if I've fixed coding syntax errors and I don't want to download to the chip yet. Most all IDEs have that "build don't run" option.
 
I thought you didn't like it when it was compile-only and you had to hit run. Can't please everybody :)

Actually you can do compile only by running in DEMO mode, which compiles the code on the PC, and builds a table for PC emulation. The download is quite quick on the Teensy and we only delay 2 seconds after load to allow time for Windows to reestablish the USB serial connection (which seems to take forever).

Writing a custom interrupt routine in BASIC for the UARTs is not all that complex, or alternatively a background timer based interrupt could be handling bigger RX buffers. As the 3.0 is going away, we might just grab the extra memory for RX buffers.
 
I thought you didn't like it when it was compile-only and you had to hit run. Can't please everybody :)
Ha! No, in all IDEs/languages, (most?) and I want a quick compile to check errors. Later, compile/link/download. You'll see those options in Arduino's IDE, Visual Studio, IAR, Keil, Eclipse, et al. Just one mouse click; no menu to navigate (ARMbasic's menu to reload is kind of a PITA).
Actually you can do compile only by running in DEMO mode, which compiles the code on the PC, and builds a table for PC emulation. The download is quite quick on the Teensy and we only delay 2 seconds after load to allow time for Windows to reestablish the USB serial connection (which seems to take forever).
I'll try it, but having to do too much to reconfigure for a download isn't fun. I "worry" about doing needless downloads - flash endurance issue.
Writing a custom interrupt routine in BASIC for the UARTs is not all that complex, or alternatively a background timer based interrupt could be handling bigger RX buffers. As the 3.0 is going away, we might just grab the extra memory for RX buffers.
Indeed, we needn't be so thrifty of RAM! Ideally, UARTs don't get static RAM buffers (compile time), since most often, not all 3 are in simultaneous use.

There is a recurring bug as I experiment with ARMbasic. Can't be reproduced with regularity. But it's quite frequent. Edit/compile/test, repeat, repeat. Then suddenly, COM20 no longer available. Teensy is running last-downloaded code properly per the LED blinking. Program is using UART 3 though I believe that's irrelevant. The only cure is to exit ARMbasic, push button on Teensy to force a download, restart ARMbasic. I have a feeling it's a timing situation, where when I choose RELOAD at the wrong time, with concurrent print statements' output happening on the USB COM20, the problem occurs. Compile/test download every 3 minutes or so, it happens several times an hour.

Documentation question:
Strings with C-like escapes like \r are not supported within string literals/constants, right? If I code
s = "hello\r"
the \r remains literal.
s = "hello" & CHR(13)
gets the intended.

Same apply to the formatter string for PRINTF and SPRINTF?
PRINTF("Value is: %d\r", 123)
is of course what we all use of habit, from C.

Docs aren't clear on this.

Nit: The menu shortcut CTRL-R doesn't work here on Win 7.
 
Last edited:
I'll try it, but having to do too much to reconfigure for a download isn't fun. I "worry" about doing needless downloads - flash endurance issue.

It's just changing the Option->Serial port to DEMO, and you can even run some programs there as long as you don't expect emulation of ARM peripherals. The IDE attempts to keep things as simple as possible, so as few menu items as possible. Lots of icons for functions is definately out, as using up space and not adding much functionality. One difference is if you use the "implied" #define MK20DX256, which BASICtools inserts into the source for pre-processing, you will have to add to your source, with
Code:
#ifndef MK20DX256
#define MK20DX256 
#endif

As for flash endurance, 30 reprograms a day gets you to 10000/year, don't know if Freescale specs 10K or 100K like others, but that is a lot of trials. And $20 for a new one, come-on. Anyone serious about it should have a couple on hand anyway -- Paul can send me a kickback for the plug :)

While there is an ANSI BASIC, no one really pays much attention to it. VB is really the standard and it doesn't support escape sequences in strings. While it could be added, we try to follow VB practices.
 
To address the Arduino/Teensyduino world, I think ARMbasic's IDE needs a "check" icon and a "download" icon like the Arduino IDE and others.
ARMbasic's "Reload" menu startles the user: several compiles with errors, then suddenly, no error and it downloads, ready-or-not... where some attached I/O thing isn't yet ready.
 
Control-R... contrary to bug described above,
CTRL-R to reload DOES work: only if the mouse/cursor focus is within the "dumb terminal" ENTER text box on the IDE in order to trigger the IDE's menu item marked RELOAD with shortcut CTRL-R.
That is, must click on the dumb terminal's ENTER box then press CTRL-R to use the menu shortcut CTRL-R.
 
The production version of ARMbasic for Teensy 3.0/3.1 is now available.

www.coridium.us/teensy

There is also a new product announcement for this in the May issue of Nuts and Volts Magazine. This is just the beginning, we will offer library upgrades as they become available.
 
teensy_gateway.exe

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.

Sorry I am jumping in here late,
why not use the teensy_gateway.exe app instead of forcing the teensy to use USBSerial?
The gateway app provides a network telnet session (forget the port off the top of my head, but it is not 22) you can connect to the does not disappear when the teensy reboots.
It may not respond, but does not error or drop connection, from the teensy side of things, you just use Serial.print as before..
and you set the teensy to RawHID device type, which does not require and sort of preexisting code to get the app loaded into the teensy..

btw, this applies to the teensy 3.1, not sure of the rest.


Just a though.
g-
 
We'll have to look into that, we chose serial as it drops into our tool sets. Thanks for the pointer
 
Not loading/running program on re-boot. With Teensy 3.1 I can load a sketch with the Arduino IDE, it is programmed into the Teensy and runs. If I disconnect power then re-connect power it re-boots the sketch and runs. If I load the Blinky.bas sketch under BASICtools the Teensy runs the program fine. If I disconnect the USB cable then re-connect the USB cable, or use an external power source the Teensy does not re-boot/doesn't run the program.
Yes, I down loaded BASICtools, yes I purchased, downloaded and copied the Teensy 3.1 personality file into /Program Files (x86)/Coridium/Freescale directory. Everything seems to work fine including Print "Hello World" etc. BUT nothing in ARMbasic appears to remain programmed.
I am running ARMbasic(9.31a) BASICtools(5.28)
If I attempt to load the example BLINKY.hex ARMbasic sketch with the Teensy loader the following is the Verbose info. Note the line where it says it can not find the .elf file. What do I need to change?

09:19:52: File "BLINKY.hex". 19590 bytes, 7% used
09:20:00: Device came online, code_size = 262144
09:20:00: Board is: Teensy 3.1 (MK20DX256), version 1.03
09:20:00: File "BLINKY.hex". 19590 bytes, 7% used
09:20:00: File "BLINKY.hex". 19590 bytes, 7% used
09:20:00: Error: can't open file 'C:\Users\Terry\AppData\Local\Temp\Coridium\BLINKY.elf' (error 2: the system cannot find the file specified.)
09:20:00: Code size from .elf file = 0
09:20:00: begin operation
09:20:00: flash, block=0, bs=1024, auto=1
09:20:00: flash, block=1, bs=1024, auto=1
09:20:00: flash, block=2, bs=1024, auto=1
09:20:00: flash, block=3, bs=1024, auto=1
09:20:00: HID/win32: waiting for device
09:20:00: flash, block=4, bs=1024, auto=1
09:20:01: flash, block=5, bs=1024, auto=1
09:20:01: flash, block=6, bs=1024, auto=1
09:20:01: flash, block=7, bs=1024, auto=1
09:20:01: flash, block=8, bs=1024, auto=1
09:20:01: flash, block=9, bs=1024, auto=1
09:20:01: flash, block=10, bs=1024, auto=1
09:20:01: flash, block=11, bs=1024, auto=1
09:20:01: flash, block=12, bs=1024, auto=1
09:20:01: flash, block=13, bs=1024, auto=1
09:20:01: flash, block=14, bs=1024, auto=1
09:20:01: flash, block=15, bs=1024, auto=1
09:20:01: flash, block=16, bs=1024, auto=1
09:20:01: flash, block=17, bs=1024, auto=1
09:20:01: flash, block=18, bs=1024, auto=1
09:20:01: flash, block=19, bs=1024, auto=1
09:20:01: flash, block=24, bs=1024, auto=1
09:20:01: sending reboot
09:20:01: begin wait_until_offline
09:20:01: offline, waited 2
09:20:01: end operation
09:20:01: redraw timer set, image 14 to show for 1200 ms
09:20:01: HID/win32: vid:045E pid:0745 ver:0656
09:20:01: HID/win32: vid:045E pid:0745 ver:0656
09:20:01: HID/win32: vid:045E pid:0745 ver:0656
09:20:01: HID/win32: vid:045E pid:0745 ver:0656
09:20:01: HID/win32: vid:045E pid:0745 ver:0656
09:20:02: redraw, image 9
09:20:26: Verbose Info event
 
The Arm BASIC compiler produces just a .hex files which is downloaded, not the .elf format one, so while it shows as an error there In the verbose mode it is not really one.

As for restarting from power up, last I looked it was working fine, and we use BLINKY for that. But I will verify that is working when I get back tomorrow (on the road today). The code is set to restart on a power on event, but not from reset pin pulled (which is what the second CPU does to get the attention of the MK20DX.
 
Thank you for the quick feedback.
I loaded blink_fast_Teensy31.hex which also has blink_fast_Teensy31.elf in the same folder. Everything worked fine including removing power then re-connecting power which created a re-boot and program run.
After receiving your reply I reloaded Blink.bas successfully, however, once I disconnect power the program is lost and will not re-boot into the program.
 
Last edited:
Turns out the php code in that sends out the digital goods was almost correct (ie a bug) and that has been corrected. We have fixed that and can send you out a new file. We will send out new files to all people that downloaded it, but we are waiting to integrate some features we added for the LPC4330.

If you(aSled) want a preliminary one to try I can send that, though I can't figure out who you are from your handle (drop me a private email)
 
Thank you for the reply, glad it will be fixed.

Turns out the php code in that sends out the digital goods was almost correct (ie a bug) and that has been corrected. We have fixed that and can send you out a new file. We will send out new files to all people that downloaded it, but we are waiting to integrate some features we added for the LPC4330.

If you(aSled) want a preliminary one to try I can send that, though I can't figure out who you are from your handle (drop me a private email)

I can wait for the update with the bug fix, but please send it out when it is ready. I re-wrote my ARMbasic program in C+ so I could get the equipment up and running. Programming and running the Teensy 3.1 went smoothly, I installed the controller today, and it worked flawlessly.
I am more interested in writing code in ARMbasic than C.

Terry
 
We have fixed the digital goods download so that it properly configures the Teensy 3.0/3.1 BASIC programs so that they restart on a power on event. In addition we added the latest SDcard file system functions and the QuickSort routine. To take advantage of these the latest compiler has to be used which is at

http://www.coridium.us/files/BTupdate.zip

In addition we have fixed some installation issues for systems where Teensyduino was not installed.

We will be sending out updated firmware to those who have downloaded it, if we missed you let us know if it doesn't get there by tomorrow.

thank you for your patience.
 
Status
Not open for further replies.
Back
Top