Mintoris Forum

Author Topic: USB support?  (Read 16572 times)

cr0sh

  • Jr. Member
  • **
  • Posts: 5
USB support?
« on: Jan 08, 2012, 10:22 PM »
Just to pile things on for you Chuck…

;)

…any possibility of getting USB support (even as a virtual serial port would be worthwhile); I'm not thinking as a HID device or anything (that would be nice), but more as a means to communicate with other hardware (including the PC) via serial or native USB (think using Mintoris Basic to communicate directly to an Arduino or other microcontroller via a virtual serial port). Right now, at least in theory (it's something I want to play with), you should be able to do this with bluetooth; however, bluetooth requires extra hardware for things like the Arduino (and that hardware, depending on what you use, may or may not be inexpensive), as well as extra programming. Going direct over USB could eliminate this extra cost (and if you could also implement where the Android phone is the USB host, then you could also somewhat easily hook up an FTDI cable or similar). You could develop applications such as reading one or more analog ports on the microcontroller, and plotting the data on the phone using Mintoris (as a simple example) - or sending it to the network (via the potential future commands discussed elsewhere on another thread).

Chuck

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1899
Re: USB support?
« Reply #1 on: Jan 10, 2012, 10:08 PM »
Hey cr0sh, where do you get your Arduino controllers from?  I have a set of tank treads that needs a brain.  Also, do you have a usb cable that could connect your Android device to an Arduino?  I will need those things if I am going to get usb communications working.

-Chuck

Chuck

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1899
Re: USB support?
« Reply #2 on: Oct 06, 2012, 01:49 AM »
Today I got a USB to RS232 converter cable. My tablet has a full size USB port so I am going to experiment with serial I/O. This is one of those problems where you need at least Android 3.1 while trying to support 2.1 and up.

So I downloaded a free app that is supposed to work on any serial port. Every time I try to connect it says I don't have read/write permission on the serial port. I remember reading that you needed root access to get read/write permission. That might halt this project, at least till Android catches up on USB serial I/O.


memi205

  • Full Member
  • ***
  • Posts: 26
Re: USB support?
« Reply #3 on: Jan 08, 2014, 05:36 PM »
Hi Chuck ‼

I think I have the same need as cr0sh…

I have an Android PC stick (rooted) and I need to connect a USB to serial cable (like Prolific or FTDI chip).

And I don't want to go Bluetooth for my project.

Did you experiment more on that ?   If yes, is it possible to add some commands in Mintoris ?

I saw this : http://www.prolific.com.tw/US/ShowProduct.aspx?p_id=230&pcid=41 

By the way… Mintoris is great ‼

Memi205

« Last Edit: Jan 08, 2014, 05:46 PM by memi205 »

Chuck

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1899
Re: USB support?
« Reply #4 on: Jan 08, 2014, 11:59 PM »
The thing is I'm kind of stuck with Basic. I need to up the target Android version from 7 to the latest version in order to implement USB. The trouble is that I implemented the HttpDownload command incorrectly. In order to fix the problem I need to change the syntax of the HttpDownload command meaning that any older program that uses the HttpDownload will need to be slightly modified. That will cause problems for some users and I have been really trying to avoid that.

USB support itself does not appear to be that difficult.

memi205

  • Full Member
  • ***
  • Posts: 26
Re: USB support?
« Reply #5 on: Jan 09, 2014, 12:49 AM »
Ok, I will wait because usb support is essential for my project.

Thank's a lot ‼

Memi205

Chuck

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1899
Re: USB support?
« Reply #6 on: Jan 09, 2014, 01:11 AM »
I'll take a look at it tomorrow. I did promise to extend Basic at the beginning of the year.

memi205

  • Full Member
  • ***
  • Posts: 26
Re: USB support?
« Reply #7 on: Mar 11, 2014, 03:08 AM »
Hi Chuck ‼

Do you have any news for USB support ?

memi205

Chuck

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1899
Re: USB support?
« Reply #8 on: Mar 11, 2014, 07:47 PM »
I'm still struggling to get Basic to compile to Android 4.4. The fact is I programmed myself into a corner when I added the network communications commands and I can't find a way out. I followed example code when adding the HTTP commands which never mentioned that Google would later insist that all network communication be done on a background thread. In order to fix that I need to change all the network functions to commands since I can't pause the expression parser to wait on a background thread.

If this were any other kind of app I could make the changes and no one would know. But with Basic, if I make the changes, everyone who uses network commands will have to revise their programs.

It would be a pleasure if I could just sit down and start coding the USB extension.

This is very frustrating for me. It's kind of like a major writers block.

harold

  • Sr. Member
  • ****
  • Posts: 807
  • My Favorite Material Posession
    • MyElectronicArt
Re: USB support?
« Reply #9 on: Mar 11, 2014, 10:20 PM »
Hello Chuck, could you come out with a new basic to sell, then people could decide which one they wanted to use, Harold.

Chuck

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1899
Re: USB support?
« Reply #10 on: Mar 12, 2014, 02:54 AM »
I could but then old users would have to repurchase it.

harold

  • Sr. Member
  • ****
  • Posts: 807
  • My Favorite Material Posession
    • MyElectronicArt
Re: USB support?
« Reply #11 on: Mar 12, 2014, 06:22 AM »
Hello Chuck, small price to pay, let me be your first customer, Harold.

jclemens

  • Sr. Member
  • ****
  • Posts: 146
Re: USB support?
« Reply #12 on: Mar 12, 2014, 10:11 AM »
Chuck, remind me again why you can't put the expression parser into  a wait state.  Was it something about losing your context? Do you use the physical stack to support recursive expression parsing?  What is your context besides your stack pointer and your position in the token stream?

mjcoon

  • Sr. Member
  • ****
  • Posts: 116
Re: USB support?
« Reply #13 on: Mar 12, 2014, 12:34 PM »
…  What is your context besides your stack pointer and your position in the token stream?

Well, I would guess a need to keep names of variables and either the values or a link to Android objects. And no doubt links to Android objects that have to be created to support interface actions. So rather a lot of context, I suspect…

Mike.

Chuck

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1899
Re: USB support?
« Reply #14 on: Mar 12, 2014, 08:28 PM »
Quote
remind me again why you can't put the expression parser into  a wait state.

Well, the expression parser is a set of recursive routines that call one another as the parser works it way through an expression. This is all done on the main thread.  Pausing execution is accomplished by releasing the thread, which means you have to return out of that recursive maze and let the calling method end.

Some might say that all of the work should be done on a background thread, but Basic's main task is to manipulate the UI and that can only be done on the main thread (also called the UI thread). In any case it is far too late to change this now without a total re-write and I feel the results would be less effective than what we have now.

A few solutions have occurred to me over the year+ that I've been thinking about this.

1) Let the recursive parser work it's way thru an expression until it hits a function that has to pause execution. Then set some sort of flag that makes the interpreter execute the same expression a second time when the function value is available and somehow make the paused function know that it does not need to pause, but return the prior value. Very messy and what happens if there is more than one function in an expression that pauses execution.

2) Move the recursive expression parser to the compiler and modify it so that instead of executing the expression it reorders the terms so that the Interpreter can perform each operation in a linear manner. If the expression parser is just moving from one term to the next no recursion is necessary so execution can be paused at any point by just storing a placeholder. But this will not work because users are now allowed to write their own recursive functions which are used inside expressions so the expressions become recursive anyway. This method also scares me since the expression parser is at the core of Basic and all sorts of errors could creep in if I tried to change it.

3) Bite the bullet, make the offending functions into commands that can pause execution. Problem solved.

jclemens

  • Sr. Member
  • ****
  • Posts: 146
Re: USB support?
« Reply #15 on: Mar 13, 2014, 03:18 PM »
OK. So bite the bullet:

1. Implement commands corresponding to network functions
2. Leave the network functions for 1 release as empty shells that merely output informative error messages (i.e. not just "syntax error")
3. Provide a program that goes through selectable program directories with user provided mask (e.g. *.bas, *.inc), and for each
    network function reference, output the line and the line number to a file, and if conversion is easy, do a conversion, i.e.

    lvalue = networkfunction(p1, p2,…pn) => networkcommand p1,p2,…pn,lvalue

Include in this new release some piece of functionality that many have been clamoring for.
« Last Edit: Mar 13, 2014, 03:25 PM by jclemens »

Chuck

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1899
Re: USB support?
« Reply #16 on: Mar 13, 2014, 05:44 PM »
Quote
OK. So bite the bullet

Yes, that's the only reasonable choice. I was planning on adding a popup message box to the compile stage which would explain the problem and offer to continue or get more info. If they select more, then a page from the reference will be displayed.

The real problem is if someone has used network commands and created a stand alone apk. If I changed the Basic runtime, those apps will cease to function.

Right now I am re-writing the file download function in the web browser. Fortunately that network problem does not involve Basic commands and can be changed transparently.

There are also dozens of Android API which Basic uses that have been depreciated. All of those have to be dealt with. Fortunately most of those can be fixed under the hood.

Also having some personal problems which are distracting me from this project, but springtime usually motivates me.

-Chuck

p.s. jc, I still have those additional Big Decimal routines you sent me (ArcTan and such). I will be adding them at some point.
« Last Edit: Mar 13, 2014, 05:57 PM by Chuck »

Chuck

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1899
Re: USB support?
« Reply #17 on: Mar 17, 2014, 07:53 PM »
Ok, I've got the reference browser downloading on a background thread. I like the way the new download routine is working and will use the same method with the HttpDownload command. While I was working on the browser download I added support for downloading and installing apk files. So you will now be able to directly download and install apk files from the forum. For the next couple weeks I will only have a few hours a day to work on Basic, but I am encouraged by the results so far. I have the Android 2.1 emulator running right next to the Android 4.2.2 emulator, testing on both. I will be calling this next release 6.0 and USB support is my main objective. I also intend to include as many outstanding future requests as possible. I think it will take me another week just to iron out the differences between API 7 and API 19.

-Chuck

jclemens

  • Sr. Member
  • ****
  • Posts: 146
Re: USB support?
« Reply #18 on: Mar 19, 2014, 06:42 AM »
I hope you keep in mind my SHELL call wish.  It has the potential to obviate various other development requests.

Chuck

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1899
Re: USB support?
« Reply #19 on: Mar 19, 2014, 05:56 PM »
I hope you keep in mind my SHELL call wish.  It has the potential to obviate various other development requests.

I was just thinking about that. Right now I'm juggling threads trying to get TCP to work. Just hoping I'll be able to preserve current functionality.