iOS to Propeller programming proof-of-concept
dgately
Posts: 1,630
There are several discussion threads in response to Ken's original post asking for possible iPad-to-Propeller solutions for programming and controlling robots and other Propeller-based devices. There are some great projects being developed based on that thread...
This thread is more a direct response to the original post and discusses a native iPad/iPhone app solution.
I'm developing an iOS app (iPhone and iPad compatible) that runs a version of openspin. At this point, my project is just a proof of concept for editing, compiling and loading of .spin-based projects.
The current status is that the app can:
Current work "in-progress":
Future work:
I'm looking for help in the loader aspect of this project. Since the HM-10 device that I am using does NOT currently support a binary transport mode, I'm developing a simple text-based solution for this. See further posts for progress on that front. Suggestions and comments are welcome.
Looking for other discussions on cross-platform propeller development? see these threads:
http://forums.parallax.com/showthread.php/153214-Open-Propeller-Project-1-iPad-to-ActivityBot
http://forums.parallax.com/showthread.php/152711-A-Propeller-WebTool-Framework-for-Compiled-Languages
dgately
This thread is more a direct response to the original post and discusses a native iPad/iPhone app solution.
I'm developing an iOS app (iPhone and iPad compatible) that runs a version of openspin. At this point, my project is just a proof of concept for editing, compiling and loading of .spin-based projects.
The current status is that the app can:
- create new .spin files and edit them
- upload previously created .spin files as well as .spin libraries (from eMail, websites, other apps, etc.)
- compile .spin sources and included libraries
- display compiled results data (binary or eeprom type, file size, etc...)
- send all file types (.spin, .eeprom, .binary) to other apps (such as eMail) for transport to other devices
- communicates via Bluetooth LE to a modified Bluetooth Xbee (upgraded with a Bluetooth LE HM-10 module), attached to an Activity Board
- compiled projects have been tested, though loading took place from a MacBook Pro
Current work "in-progress":
- working on transport of compiled binary to RAM
- working on transport of compiled eeprom to EEPROM
Future work:
- provide other transport support (XBee WiFi type devices)
- provide a terminal for display of running program output/input
- port application to Bluetooth LE enabled Android devices
I'm looking for help in the loader aspect of this project. Since the HM-10 device that I am using does NOT currently support a binary transport mode, I'm developing a simple text-based solution for this. See further posts for progress on that front. Suggestions and comments are welcome.
Looking for other discussions on cross-platform propeller development? see these threads:
http://forums.parallax.com/showthread.php/153214-Open-Propeller-Project-1-iPad-to-ActivityBot
http://forums.parallax.com/showthread.php/152711-A-Propeller-WebTool-Framework-for-Compiled-Languages
dgately
Comments
What kind of project is this?
What approach you plan for the loader?
Here's one example (Soft Loading an Application Image into the Propeller P8X32A via XBee Transceivers): http://www.parallaxsemiconductor.com/an007 Discussion thread at: http://forums.parallax.com/showthread.php/127780-Upload-Prop-programs-via-XBee?highlight=XBee
How much space does the Bluetooth code take? Can it run entirely in a COG so you can have the loader fill all of hub memory with the user program?
Also, how will you provide a console link back to the iPad after the user's program starts? Can you share your approach with Bluetooth?
Where I bought the Bluetooth LE module: http://www.ebay.com/itm/wireless-MBT...item3f2efbc862
More answers in the next post...
dgately
tdlivings commented: Instead of sending binary data send text like in the olden days using Motorola S Records or something similar. This way you are just using the serial connection you already have to send the text. On the Prop side the loader becomes a parser in front of the present Prop loader that can parse the SRec data back to binary.
This would also require OpenSpin and PropGCC to output SRec's files to be sent wireless.
Just a suggestion to think about http://en.wikipedia.org/wiki/SREC_(file_format)
dgately
In the early days of micros 6800 etc S-Records were the way to save the assembler output and to load
the output into RAM or the EEPROM burner.
Intel had their Intel HEX format. Same concept
Still used but we now have elf files to describe the compiler image to be loaded.
Sending text is the way to go as trying to send raw binary. if you try and send binary 0x10 it looks like a line feed so send "10" two ASCII chars
http://www.x-ways.net/winhex/kb/ff/Motorola-S2.txt
Tom
Thank's for the info.
If the GCC linker can output S Records would there be an option that could be entered into SimpleIDE
to dump the S Records out.
My brainstorming is thinking if we can send over the air by some means the S-Records for program and the
receiver can then read them and wiggle pins 30 and 31 just like the PropTool or SimpleIDE the Prop development
board i.e. Activity Board does not even know it is not a direct serial connection.
Tom
Yes the Activity board with an XBEE is the receiver.
I was not revering to physical hardware serial connection when I said wiggle the pins bu
instead can we create or already have software to take the S-Record description of a program
and send it into the serial port on 30,31 to load it just as if it came from the PropTool or SimpleIDE
Tom
Am I completely misunderstanding what you're trying to do?
No way to miss understand as I was thinking out loud but do not have a complete concept
yet. Just thinking of various pieces.
After reading your last post it hit me that what I was really visioning was a separate box
which received S-Records over the air and had a serial port on the
output that connected to the serial port on the Prop development board and downloaded the program
to the board the same as the PropTool. The Activity Board would not know it was not actually connected
to a PC USB serial port but instead to this separate box acting as a PC USB serial port.
Maybe it can even receive an email from Tech Basic containing the S-Records and download the code.
As I said thinking of the various pieces
Thank's for the info on your thoughts
Tom
First, an app I've named "spinTab" (as in: Spin Tablet), an iPhone/iPad app that uses the openspin compiler to compile & edit Spin code. It's in an XCode project that at this time is based on a Bluetooth LE communications link. I'm using an HM-10 module, that has been soldered to a Bluetooth XBee adapter (details below). Current status: App can compile spin code, transfer compiled data to the ActivityBot. Not sure if Bluetooth LE provides an efficient means for transfer of compiled code (small packet size of 20 bytes, total)...
Second, a robot controller, similar to the techBASIC controller demonstrated in the other forum thread. This is a native iOS app, that communicates view Bluetooth LE (commands are small packages < 20 bytes). The UI provides for speed, direction, rotation of an ActivityBot as well as switches/buttons for I/O control. Right now, I'm working on parsing commands from the serial stream. I've ported Jonny Mac's spin-based Human Friendly Control Protocol (jm_hfcp.spin) to C and am getting that to handle the commands.
Bluetooth LE:
Links:
HM-10 Datasheet/manual: http://www.jnhuamao.cn/bluetooth40_en.zip
Issues:
That's my update for now...
dgately
There one in XBee footprint, the BLEBee from Seeedstudio, currently out of stock but word is it will be back "soon".
Here is developer Micheal Kroll's github, and forum. Don't know if he is still looking for beta testers!
Where do you buy the HM-10 modules?
That's a good question! I bought 2 HM-10 modules off of eBay (around $16.00 U.S.) from seller: http://www.ebay.com/usr/nuannuan0411
Now, I only see this very oddly-priced item: http://www.ebay.com/itm/wireless-MBTV4-bluetooth-4-0-module-Low-Energy-BLE-module-Serial-port-module-ios-/271371192418?pt=LH_DefaultDomain_0&hash=item3f2efbc862. Either it's a mistake or the pricing is for 10 of these modules... Hmm!
Here are two websites where the modules can be purchased ($6.50 U.S.):
http://www.fasttech.com/products/0/10004051/1292002-ti-cc2540-bluetooth-4-0-ble-2540-transparent
dgately
Yes, those have been out-of-stock for a while... Of course, firmware will be different so AT commands will most likely be different, as well. I picked the jnhuamao modules because of the Let's Make Robots article which explained how to use them and jnhuamao seems to be actively developing firmware and has produced several (4) updates since I've purchased. The updates were in support of iBeacon advertisement, which iOS uses to find the modules. I'll take a look at the other modules and the software at github. Thanks Tracey!
dgately
The Robot Control iPhone/iPad app can now send a few primitive commands to the ActivityBot. P26 & P27 LEDs can be turned on & off. The speed UI control now sends data that makes the ActivityBot move forward, though it's still a bit sketchy as to its actual movement (goes forward, turns right, goes a bit more forward, makes a u-turn; all this when the command was just forward movement). It appears that the commands are reaching the bot far faster than it is able to consume them.
My question is, "How often should I allow the sending of commands that move the bot (as opposed to commands that turn LEDs non & off)?" What's a typical time between events for RC controllers (for RS planes & copters) as they send them via radio? As the user slides the control up & down, to increase forward speed, reduce speed or even reverse the bot, how often should I send speed values to the bot?
I've been working from the idea of sending raw data as fast as I can send it from the iPad, then timing the execution of movement type events on the prop side. Of course, I would probably need to throw out some commands as they fill up a queue, in order to keep the bot in sync with more recent commands. I would not throw out important commands like stopping the bot, reversing its movement, etc... Though, this tact will be problematic if the bot is to do anything precisely, right?
Any ideas are quite welcome!
dgately
So:
Turn Right at speed X
Still Here
Still Here
Forward at speed X
Still Here
Still Here
Still Here
Still Here
Stop
Still Here
Still Here
That would seem to make it possible not to need to process commands nearly as fast and if you can short-circuit the rest of the command parse for "Still Here" then you can react quickly and stop if the controller stops communicating for a couple of check periods. You would stay responsive to commands that make the bot change it's motion, and not need to discard commands or stream them constantly.
One thought... while we won't for now get a compiler into the app store, we could still team up on the app if it were in GitHub and those of us who are iOS developers could download it, build it and run it on our own iPads/iPhones.
Is this something you'd consider? (posting it to GitHub and letting some of us contribute to it and letting all of us benefit from its existing?) If you've already posted to GitHub or here, forgive my enthusiasm, I'm just catching up on posts! (But let me know where ;-)
I'd be a great tester and contributor, for example ;-) I would also consider working on a propeller download BLE service spec as well as a Bi-directional propeller debug service. which we could implement in our BLE hardware making the app work for all who built in these services.... Just some thoughts.... ;-)
-Stephen, KZ0Q
Stephen,
Yes, I'm good with all of this. I'm a little out of time for the next week as I've got a webpage to build for another project. Let me look at the sources and see what I can do about posting to github. One thing I need to update is in bringing-in the latest openspin source to compile inside the app project. I'll update this thread when I've had time for that.
Thanks,
dgately (Dennis)
Dennis, I'll be watching for news... Thanks!
Stephen- KZ0Q