Android Spin Tool
embed68k
Posts: 19
I have done some due diligence on researching this topic, but have found very little in the way of a solution. Am I wrong in assumming a android app for programming the propeller chips is not a far-fetched concept that is doable? Most of the forums I have read deal with interfacing a usb-serial link,wi-fi,bluetooth,ethernet to an already programmed propeller. What I want is a Android app to directly plug into my Acer Iconia Tab a200 running ICS 4.0.3 and be able to program a propeller chip attached to the usb port and also have it receive serial data in some kind of terminal. I just started learning java after finding out that I don't need to pay some company $400 for a license to use mono4droid. I just stumbled upon AIDE in the android marketplace that allows you to write and compile java android code directly on the device. I have successfully written a sample app to display some things on the screen. Before I get too carried away, I want to ask if anybody is working on a BST/Spin editor for android?
It appears that this free app has *all* the build in android packages such as android.hardware.usb.*. So after my knowledge of android programming increases I could probably manage to get a IDE up and running with code completion and color highlighting of keywords and code block sections(var,con,pub). What I am not sure of is I don't think the propellent library will be any good. This is where I want somebody to correct me if I'm wrong. Now, if i went the eclipse/mono4droid route I would be coding in C# and would have no problem using the propellant libraries. But as it is I am mainly sticking to coding directly on the tablet. Are there any white papers on how the compiler/interpreter creates the binary images. Basically I'm assuming I would have to duplicate the propellant libraries, but I'm unsure if this is neccessary at this stage.
The whole point of this is,not only the ability of in-the-field programming, that I am using a tablet as my only computing device and programming the propeller is something I like to mess around with and this is not available to me without my computer. Besides I am moving out of state and shipped my computer ahead. Even a intel atom d525 with a 22" LCD monitor apparently cost $20 month to run. My electric bill was barely $50, and i'm sure I can run my tablet on solar power if I wanted to.
To sum up, my questions are as follows:
1. Why isn't there a android app(no interest, android usb is too laggy,etc)?
2. Is anybody working on one that will be available any time soon?
3. Can the propellent library be ported?
4. Is there a way to convert the text spin/assembly file directly to binary on a propeller chip itself? I imagine being able to send a file to a programmer board from an android device via bluetooth or wifi and have the programmer board convert it and write it to an socketed eprom. Then you could just remove the eprom and insert it in your project board.
Any comments would be helpful. Also I am trying to make this work on un-rooted devices.
It appears that this free app has *all* the build in android packages such as android.hardware.usb.*. So after my knowledge of android programming increases I could probably manage to get a IDE up and running with code completion and color highlighting of keywords and code block sections(var,con,pub). What I am not sure of is I don't think the propellent library will be any good. This is where I want somebody to correct me if I'm wrong. Now, if i went the eclipse/mono4droid route I would be coding in C# and would have no problem using the propellant libraries. But as it is I am mainly sticking to coding directly on the tablet. Are there any white papers on how the compiler/interpreter creates the binary images. Basically I'm assuming I would have to duplicate the propellant libraries, but I'm unsure if this is neccessary at this stage.
The whole point of this is,not only the ability of in-the-field programming, that I am using a tablet as my only computing device and programming the propeller is something I like to mess around with and this is not available to me without my computer. Besides I am moving out of state and shipped my computer ahead. Even a intel atom d525 with a 22" LCD monitor apparently cost $20 month to run. My electric bill was barely $50, and i'm sure I can run my tablet on solar power if I wanted to.
To sum up, my questions are as follows:
1. Why isn't there a android app(no interest, android usb is too laggy,etc)?
2. Is anybody working on one that will be available any time soon?
3. Can the propellent library be ported?
4. Is there a way to convert the text spin/assembly file directly to binary on a propeller chip itself? I imagine being able to send a file to a programmer board from an android device via bluetooth or wifi and have the programmer board convert it and write it to an socketed eprom. Then you could just remove the eprom and insert it in your project board.
Any comments would be helpful. Also I am trying to make this work on un-rooted devices.
Comments
https://play.google.com/store/apps/details?id=com.aide.ui&hl=en
The idea I had was to use IOIO board to program basic stamps, but it should work with a prop or anything else.
http://www.sparkfun.com/products/10748
Now that AIDE is out there I'd bet things will change really fast.
-dan
BTW, welcome to the forums
It is possible to run native code compiled from C/C++ under Android with a Java wrapper. So one could start with the new open source Spin compiler in C++ from Parallax.
Thinks....actually I have run one of my C++ Qt apps under Android using Neccistas (spelling?) so perhaps PZST could be convinced to run there as well. How much it may need modidying for an Androd tablet environment is a mystery.
I want this for my playbook as well as a serial / usb interface and terminal emulator i.e. Vt 100/200 etc. Don't have time to do it myself even though all the development tools are there. Well except for a way to use a serial/usb device through the usb port on the thing.......
Frank
Then there must be many fools in the world!
Traditionally pretty much all compilers were written in non-garbage collected languages as most languages were non-garbage collected. Often the aim is to write your compiler in the language that you are compiling. So for example the Free Pascal compiler is written in Pascal, the GCC compilers are written in C, the GNAT Ada compiler is written in Ada and so on. Often that is not achieved, so for example Google's V8 Javascript engine is written in C++. It works very well.
Then there is the "bootstrapping" problem. How to start from having no compiler at all. Or perhaps there is not yet a compiler written in the new language you have just designed. The first compiler ever must have been written in some assembler language. For sure not garbage collected.
Technically garbage collecting is not going to save you from writing a compiler that hangs, crashes out or otherwise fails. Consider that you wrote a compiler in C that malloc'ed lots of little data structures as it went along but never freed them when they went out of use. No problem it would compile your source, write the output and then all that memory is freed when it exits. The only issue would be if it consumed all available memory at some point, say when compiling a large program on a small machine. I bet that was not the problem with jikes.
Finally, the Spin compiler in the Parallax Propeller Tool is written in x86 assembler !
My conclusion is that if you really want a Spin compiler that runs under Android the best bet is to start from the new open source Spin compiler form Parallax which is written in C++ and wrap it up in the Android native code interface. Probably not a trivial task. If you want an IDE to go with that it could be a rather large piece of work.
I would not want to use any of this until I can plug a keyboard and mouse into my Android tablet and have a full Linux environment available. For this reason I think a better bet is Prop development on an ARM board like the Beagle board, ISEE IGEP board or Raspberry Pi when it becomes available.
Most early compilers were multipass because GC wasn't available, and a lot of lessons have been learnt along the way about how to do software better - one of the most important reasons people write a compiler in the language itself is because they designed the language and want to use it in earnest to see where the design is lacking or awkward - you gain a lot of experience doing it. But really the way to write a compiler is with a compiler writing toolsuite like the gcc framework - and there are many others mainly in academia which allow you to quickly throw together a compiler and/or interpreter for a new language - and without GC such toolsuites are less capable. Surely a non-sequitur? Most garbage collectors have crucial parts written in assembler to access the relevant hardware (page table bits, fault handlers) and there's no big issue with adding GC to a system written in assembler, especially for a conservative GC where the mutator is pretty un-restrained in its behaviour. I mean the Lisp Machine was coded in microcode and it had one of the first proper GC systems. It will save you from crashing, but not hanging. It will save you having to think about data structure lifetimes and malloc/freeing issues (which is where most of the bugs in jikes will be, trust me on this) The problem with the never-freeing solution (this is just very inefficient garbage-collection!) is that it doesn't scale to large amounts of Java source since you need to recycle the compilation results for each class but hang on to its compact signature (for 10,000's of files). Basically with a GC you spend more time writing the compiler and less time writing a (buggy!) memory-reclaimation subsystem. OMG, that is truly sick. Oooh, that reminds me my Pi ought to arrive within the next week
Interesting stuff. I have to admit that my compiler writing skills are limited to having implemented my version of Jack Crenshaw's TINY/KISS language
(http://compilers.iecc.com/crenshaw/) which generates Propeller LMM code. I wrote my little compiler in C.
I suspect early compilers were multi pass because the memory spaces available were so small at the time so it was only possible to do the job in stages.
CG does not save buggy programs from crashing, many a time I've seen Java, Python, Javascript, PHP etc code bomb out with an exception. I guess calling it
an exception masks the fact that it was a crash. At least such exceptions generally dump some usfull stack trace etc.
Don't get me wrong, I would never suggest "never freeing" as a good programming style, except for the dirtiest of little quick hacks.
In my gut it feels like cheating to write a compiler in a language of a higher level than the compiler target.
Yep it is:) Our Chip Gracey is clever enough not to need a compiler.
I'm very envious. All the updates I get from RS and Farnell still put my pi
weeks away.
Correct. I'm working on an Propeller-based IBM 1130 emulator. The typical 1130 had 16k or 32k of core memory, but could have as little as 8k.
To support this, the FORTRAN compiler has 20+ passes. It can actually compile a program that's too large to run on the same machine (due to the runtime libraries using more memory that the compiler).
wow, having started out my Prop explorations with Intel 8080 and then Zilog Z80 emulations an IBM emu is fascinating. Mind you I have promised my self never to attempt any kind of emulator again.
Do yo have an OS and compilers etc that will run on your emulator?
As I said before, you will have to wrestle the BST source away from BradC or get him to do an Android port. All of which seems unlikely just now.
Looks like our best bet is the new open source Spin compiler.
But what to do for an IDE? Perhaps Jazzed will support Spin in SIDE.
We could develop on Android if there was a Spin byte code interpreter that could handle the Sphinx environment... ie handle stdin, stdout, and access to files. The Sphinx binaries would then run on Android, thus running mpark's Sphinx compiler... no need to write a compiler!
I must admit, the idea of running a Sphinx VM on Dalvik is a bit twisted...
Heater, yes, thanks to the wonderful folks from http://ibm1130.org.
I'm using a disk image (1MB, yes, that's 1 megabyte) that has the monitor, FORTRAN compiler, RPG compiler, assembler, and utilities.
I've been able to compile and run a short FORTRAN program... quite a bit of time was spent figuring out that the writers of the compiler used some "not recommended" programming techniques. Thankfully, I have the full (assembler) sources to the monitor and compiler. Code that's 35+ years old!
Walter
Not at all. Writing an x86 emulator in JavaScript which boots Linux in your browser is twisted, but here it is:
http://www.readwriteweb.com/hack/2011/05/run-linux-on-javascript.php
So a Spin interpreter in Java for Android is quite a reasonable idea.
@wmosscrop,
That is fantastic. You are in for a great ride. I totally amazed myself when I first got a CP/M prompt
out of the Propeller.
You are right. That is truly twisted.
Anuways back on topic i belive there may be a way to program the propeller from a non rooted android phone, all though rooted would be better. there are multiple ways to get linix running on an android phone. for those of you with root look into debian chroot images and install one on an ext2 card on yoir phone. for non root theres a market program called linux installer which will make a a file that contains a debian chroot.
once you have linux installed u can do all kinds of stuff including install x win and run a vnc server. anyways my idea is to get bst installed on linux and preferably use the the bst command line in conjunction with droid edit. so the compiler problem is solved u can run any linux compiler bst gcc whatever.
hardware is the issue with this. my phone wont do usb host kernel hacks or not. so bluetooth is the best cheapest solution. thats what im tryin to figure oit right now is how to get bst/spin tool to work over bluetooth. ive been told in my bluetooth thread that reset is the problem but my bluetooth has rts/cts lines on it. im not sure how u send data over bluetooth and not a com though. once i get the bst/spin side of things figured out that should bridge the gap, and the linux installer is ez peazy so you dont have to be a cli buff to get debian on ur phone unless u want it in its own partion with swap space and other goodies.
I have compiled Spin on ARM, an IGEP v2 board from ISEE. I used mpark's HomeSpun compiler. Problem there is you need to have the mono runtime installed to run it which may be an issue for Android.
I think the best approach at this time is to start with the new opensource Spin compiler from Parallax which is written in C/C++. I should be relatively easy to get that compiled with the Android NDK.
Getting the Prop loaded from Android withe out a host mode USB port to drive a serial adapter may be tricky. I don't recall anyone managing it via bluetooth.
having mono libs is no issue. im trying to say it is easy to run a full linux distro with x and whatever u please on a phone via chroot command. for example i have debian with ssh emacs lxde set up and a vnc server. speed is the issue but i can bearably run x on a 600 mhz virgin prepaid. once u run the chroot start up script u have a full linux system going in your terminal totally seperate from android. press home ur back to ur phone open the terminal ur in debian. its basically the same as virtualization on a pc. its also quick theres just no frame buffer or graphics only term. in order to get to x u either vnc in from ur pc or a vnc client on ur phone set to 127.0.0.1.
this may sound hacky but is very usefull. i use it to write cli utilities with gcc and gas somewhat. you can run cron or whatever youd like that is compiled for arm right along side android. if you compile cli programs anyone with a terminal emulator and root can run them. this allows me to learn arm asm by coding straight on my phone via lxde and vnc from my pc.
so with a an arm based compiler the only missing link is going to be the serial connection to the prop. for portable programming i think building a prop sheild to a ras pi is going to be a better combo than a phone but i just cant seem to get a pi. but if someone can come up with a com link from android phone to prop everything is in place and i wont mind staying at my girlfriends a little more often as long as i bring my bt keyboard .
if you guys would like when i get some time i can demonstrate the arm spin compiler running on my phone. as long as its cli based it should be a very reasonable option along with droid edit which is what im typing this in best android code/txt editor out.
So, ignoring the Android part, what you are saying is that you have an ARM machine running a fairly complete Debian installation including gcc and other tools. That means you can just check out the Open source Spin/PASM compiler in C/C++ from Google code and compile it on your machine. Bingo you have a Spin/PASM tool chain. All that needs sorting is the Prop download link.
See here http://forums.parallax.com/showthread.php?137452-Open-source-Spin-PASM-compiler-in-C-C
@jazzed,
Almost a year ago I tried building one of our graphical Qt apps for Android using Necessitas. It sort of mostly works, no touch input working, but it took forever to start up. Seemed to take ages to get the Qt libs loaded.
See here: http://sourceforge.net/p/necessitas/home/necessitas/
Things have moved on with lighthouse ant Qt Quick so I may have another go one day, to many things to do...
Oh yeah, forgot. About the same time I also tried out Qt Quick on Android under Necessitas. Managed to get some gauges dancing their dials and slider input. Touch worked fine.
if your not a linux/android buff there is a very easy option. go to the market and search for linux installer. use its few click interface to get a 1 gig block file made on your sd card. then hit install linux. thats that now all you have to do is sudo apt get install gcc and then download the compiler above and build it. now u have spin running on your phone.
so this is a call to anyone who thinks they can find a way to program the prop via bluetooth. i plan on looking into this but im not the sharpest guy for this kind of thing yet. im thinking building a seperate circuit to pull reset via an unused bluetooth com line is the answer.. my bluetooth has a ton more uarts and a spi interface though. i think with 2 5 dollar ones this may work.
heater does the compiler also support pasm?