Forum Rule: Always post complete source code & details to reproduce any issue!
Page 3 of 4 FirstFirst 1 2 3 4 LastLast
Results 51 to 75 of 91

Thread: BASIC for Teensy 3.0/3.1

  1. #51
    Senior Member
    Join Date
    Jun 2013
    Location
    So. Calif
    Posts
    2,828
    Is the ARMbasic ship still underway?

  2. #52
    Member ARMbasic's Avatar
    Join Date
    Dec 2013
    Location
    Lake Tahoe, CA
    Posts
    60
    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

  3. #53
    Senior Member
    Join Date
    Jun 2013
    Location
    So. Calif
    Posts
    2,828
    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.

  4. #54
    Member ARMbasic's Avatar
    Join Date
    Dec 2013
    Location
    Lake Tahoe, CA
    Posts
    60
    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??

  5. #55
    Senior Member
    Join Date
    Jun 2013
    Location
    So. Calif
    Posts
    2,828
    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 by stevech; 02-05-2014 at 02:43 AM.

  6. #56
    Member ARMbasic's Avatar
    Join Date
    Dec 2013
    Location
    Lake Tahoe, CA
    Posts
    60
    Quote Originally Posted by stevech View Post
    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.

  7. #57
    Member ARMbasic's Avatar
    Join Date
    Dec 2013
    Location
    Lake Tahoe, CA
    Posts
    60
    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...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.

  8. #58
    Senior Member
    Join Date
    Jun 2013
    Location
    So. Calif
    Posts
    2,828
    Great!
    Are user defined ISRs (e.g., pin change interrupts) implemented?

  9. #59
    Senior Member
    Join Date
    Jun 2013
    Location
    So. Calif
    Posts
    2,828
    How Mr. ARMbasic can get rich!

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

    Name:  Capture.JPG
Views: 274
Size:  15.7 KB

  10. #60
    Member ARMbasic's Avatar
    Join Date
    Dec 2013
    Location
    Lake Tahoe, CA
    Posts
    60
    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.

  11. #61
    Senior Member
    Join Date
    Jun 2013
    Location
    So. Calif
    Posts
    2,828
    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?

  12. #62
    Member ARMbasic's Avatar
    Join Date
    Dec 2013
    Location
    Lake Tahoe, CA
    Posts
    60
    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

  13. #63
    Senior Member
    Join Date
    Jun 2013
    Location
    So. Calif
    Posts
    2,828
    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 by stevech; 02-27-2014 at 01:41 AM.

  14. #64
    Member ARMbasic's Avatar
    Join Date
    Dec 2013
    Location
    Lake Tahoe, CA
    Posts
    60
    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

  15. #65
    Senior Member
    Join Date
    Jun 2013
    Location
    So. Calif
    Posts
    2,828
    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 by stevech; 02-27-2014 at 04:07 PM.

  16. #66
    Senior Member
    Join Date
    Jun 2013
    Location
    So. Calif
    Posts
    2,828
    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 by stevech; 02-27-2014 at 04:28 PM.

  17. #67
    Member ARMbasic's Avatar
    Join Date
    Dec 2013
    Location
    Lake Tahoe, CA
    Posts
    60
    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

  18. #68
    Member ARMbasic's Avatar
    Join Date
    Dec 2013
    Location
    Lake Tahoe, CA
    Posts
    60
    These UARTs are a bit different than what we have been using and we weren't handling the receive idle interrupt correctly which affected the WAIT and TIMER routines.

    That is now fixed, and the beta download has been updated (now version 8.30c), same bat channel same bat time

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

  19. #69
    Senior Member
    Join Date
    Jun 2013
    Location
    So. Calif
    Posts
    2,828
    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 by stevech; 03-01-2014 at 01:25 AM.

  20. #70
    Member ARMbasic's Avatar
    Join Date
    Dec 2013
    Location
    Lake Tahoe, CA
    Posts
    60
    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 by ARMbasic; 03-01-2014 at 12:15 PM.

  21. #71
    Senior Member
    Join Date
    Jun 2013
    Location
    So. Calif
    Posts
    2,828
    Very good.
    Is the fractional baud rate hardware divisor implemented?

  22. #72
    Member ARMbasic's Avatar
    Join Date
    Dec 2013
    Location
    Lake Tahoe, CA
    Posts
    60
    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.

  23. #73
    Senior Member
    Join Date
    Jun 2013
    Location
    So. Calif
    Posts
    2,828
    Just need to keep error down for 115200

  24. #74
    Senior Member
    Join Date
    Jun 2013
    Location
    So. Calif
    Posts
    2,828
    Quote Originally Posted by ARMbasic View Post
    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?

  25. #75
    Member ARMbasic's Avatar
    Join Date
    Dec 2013
    Location
    Lake Tahoe, CA
    Posts
    60
    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.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •