BASIC for Teensy 3.0/3.1

Status
Not open for further replies.
It is still moving along, we have not updated for a while, as we believe what is out there is working, let us know if you don't think so.

Current limitations-
UART1 and UART2 may not totally work in the beta version, but we have them working in house
We have SDcard access working in house
 
would like a listing or some such on what I/O peripherals are working in this beta, and which are TBD.
Such as SPI, I2C, UARTs (work in progress), timers, etc.

Thanks.
 
Our model is to NOT build peripherals into the BASIC, except for ones that we traditionally use. The UARTs are somewhat an exception. We use a UART for the debug port, that is where PRINT statements send output and get input on DEBUGIN. Now Teensy has the USBserial port performing this function, but we have all the infrastructure to support UARTs anyway so we will support UART1 and UART2 as builtin BASIC keywords BAUD, RXD and TXD.

The BASIC TIMER now uses the Systick register built into all ARM Cortex parts.

SPI in this case we will use for file access to an SDcard, and for that reason if you do File IO those are builtin BASIC calls. If you don't use File access you can use the SPI hardware by writing directly to registers which ARMbasic gives you access to with pointers done C-style (*addr = x) rather than PEEK, POKE which I always cringed at.

The other TIMERs and I2C are not used by the BASIC firmware. So access to those is through libraries that we use #include files (adapted from C). Those libraries we will do as we need them or get to them, but they are more like what you get from a compiler vendor, something that is an add on. Now before we all get flamed here, there are only a couple of us and lots of lots of users, so we are looking for aid from the community on producing libraries. Did a couple guys write all the Arduino code??
 
The Teensyduino libraries for all the peripherals on the K20 chip - were, I believe, all done by Paul with a bit of contributed code. Like Arduino's libraries, the goal is to have library code (akin to a #include). And then some, e.g., better/faster SPI to exploit the FIFOs in the K20 chip, better ethernet interface to the WizNet 5xxx chips, etc. The inventory is very impressive. I believe the work is done to get the basics all supported, then improve drivers for the popular apps, like the serial data driven LED arrays (thousand of LEDs), and DMA for the A/D and D/A for fancy sound things, and the ethernet chip.

EDIT: -- added
A large portion of the libraries are ARM hardware equivalents to those done for Teensy2 which is an AVR chip as are Arduinos per se. Thus, a lot of application code for Arduino and most all Teensy 2 code runs with few changes on the Teensy 3, due mostly to the work done in the libraries. SPI is an example... where Paul has extra code for the Teensy 3 to emulate the AVR SPI for the sake of code portability.

Could ARMbasic just wrap the Teensyduino libraries -as a hardware abstraction layer - rather than coding all new I/O run time?
 
Last edited:
Could ARMbasic just wrap the Teensyduino libraries -as a hardware abstraction layer - rather than coding all new I/O run time?

Not my first choice as that requires firmware and compiler changes, and becomes difficult to support across many different parts. Then add to it optimizing an interface for some feature or in conjunction with DMA for instance, and you are trying to be all things to all people, always an impossibility. But with BASIC you have full access to all hardware and interrupts, so anything you can do in C, you can do in BASIC. Often translating is not a big task unless the C code is heavily object oriented.
 
We've updated the files today. This version has UART support and also can read and write files on an SD card connected to the SPI port; check the help files for how to use it and hook it up.

We've been spending time on documentation (including a getting started section)

http://www.coridium.us/ARMhelp/index.htm#page=bTEENSYgo.html

The software is still at

http://www.coridium.us/files/setupBASICbeta.exe

This most likely will be the last beta release, as we go on to getting the web pages ready.
 
How Mr. ARMbasic can get rich!

Costco's website browser tab - as below - trademark infringement?

Capture.JPG
 
Like any interrupt not being used by the BASIC firmware, the pin change interrupts can be used by a BASIC program. It is not a builtin function, but done by writing to the hardware registers, and setting the interrupt vector (all allowed in BASIC). We have done examples of this on the NXP parts, and eventually we'll do it unless someone here beats us to it.

As for Costco, more likely we'd get a nasty lawyer letter from them, but we've been using it for nearly 10 years now, so we don't have to worry.
 
in the beta run time, what syntax is used to configure/use the third UART? Its TX is on pin 8, RX on pin 7 of Teensy.
' default pin mapping
BAUD(8) = 115200 ' ???
TXD(8) = uint8_t x
int n = RXD(7)


Or is there support in beta for buffered/interrupt driven UART 0, 1, 2?
 
Like our NXP ports, the index is based on the UART number not the pin.

So RXD(0), TXD(0) are for the USB serial UART (you can make calls to BAUD(0) but that is ignorred)

BAUD(1), RXD(1), TXD(1) are for UART1
BAUD(2) ... for UART2
BAUD(3) ... for UART3
 
Thanks for prompt reply...
I have UART 3 in loopback: Teensy pins 7,8 jumpered for a loopback.

With this code
Code:
__MAP__

BAUD(3) = 9600
WAIT(2500)
FOR j = 1 to 3
	TXD(3) = 43 ' + in ASCII
	WAIT(100)
	print "Here1 RXD:", RXD(3)
NEXT j
WAIT(100)
print "sent +++"

WHILE 1
	print "Here2 RXD:", RXD(3)
	WAIT(100)
LOOP

the printout is
Here1 RXD: -1
Here1 RXD: -1
Here1 RXD: -1
sent +++
Here2 RXD: -1
Here2 RXD: -1
Here2 RXD: -1
Here2 RXD: -1
Here2 RXD: -1
Here2 RXD: -1
Here2 RXD: -1
Here2 RXD: -1
Here2 RXD: -1

Then it hangs. The loop with "Here2" ran for about 1 second before hanging. Odd.
No "+" chars were received via the loopback.

If I disconnect the loopback: same result.

Clue: If I comment out the TXD(3) = 43,
then the "Here2" loop does not hang.



(This is the beginning of BASIC code to talk to an XBee on UART3 - that does work OK via C code.)
 
Last edited:
What version of BASIC? It is reported in the startup message.

Is this a Teensy 3.0 or 3.1? I know we tested it on the 3.1
 
Thanks for the response. I know this is beta.

ARMbasic 9.28e BASICtools 5.26 (these, per the help/about menu display)
and startup msg is: ARMbasic Kernel[8.30b] with Floating Point

Teensy 3.0 (I haven't, but could test on 3.1's that I have).
 
Last edited:
Ran on Teensy 3.1... same result as 3.0.

ARMbasic Kernel 8.30b is probably not the correct version but that is what the link in this thread points to.
 
Last edited:
8.30b is the latest one, our simple loopback works, but we verified yours fails. There is some issue either with WAIT or the combination of WAIT and UART use, we are still tracking it down. Our WAIT uses SYSTICK, which is common to all Cortex parts, and we haven't combed through the USB serial code to make sure there are no conflicts.

This test worked for us --

Code:
dim j as integer

print "UART3 Test"
BAUD(3) = 9600


FOR j = 1 to 3
    TXD(3) = 43 ' + in ASCII
NEXT j

print "sent +++"

WHILE 1
    do ' read out any characters from UART3
        j = RXD(3)
        if(j <> -1) then print "Here2 RXD:"; j
    until j = -1
LOOP
 
Thanks, II'll give it a try.
Appreciated.

Just confirming... there is no buffered interrupt driven I/O on the three serial ports now?
 
Last edited:
No, actually all 3 UARTs have 64 byte interrupt driven buffers on both TXD and RXD, and the first 2 UARTs use the internal FIFOs.
 
Last edited:
The fractional hardware divisor is not used. But the same as our NXP versions, you can call BAUD(x) which configures the UART, sets interrupts and initializes the buffers. After that you can write directly to the UART registers to change the baud rate using the fractional divisor, or change the handshake parameters.

Or if you need something really custom, you can write an interrupt routine in BASIC and have complete control. In the final release, we may increase the buffer sizes.
 
The fractional hardware divisor is not used. But the same as our NXP versions, you can call BAUD(x) which configures the UART, sets interrupts and initializes the buffers. After that you can write directly to the UART registers to change the baud rate using the fractional divisor, or change the handshake parameters.

Or if you need something really custom, you can write an interrupt routine in BASIC and have complete control. In the final release, we may increase the buffer sizes.
Yes, perhaps tx buffer 128 rx 256 to accommodate frame burst devices like the XBee in API mode at 115200 baud.

Is there a way to avoid a blocking call to TXD(n) ? Such as having TXD return -1 if buffer is full or a call to get free byte count or some such?
 
In version 8.30 of the firmware we added TXFREE(uart), and I checked it on the Teensy. Also made me write a page for the help file that will be published later.

While we write mostly C ourselves, as part of a custom design we wrote the bulk of a controller code in BASIC for a customer, and it used 5 UARTs, and we found we needed the TXFREE ourselves. I've always said that for the best tools the author has to be using them themself.

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.
 
Status
Not open for further replies.
Back
Top