FlameTube DevTools and OS
FlameTube
Posts: 35
in Propeller 1
FlameTube DevTools and OS development
Comments
Hm... Interesting thing. Looks like my first prototype, it's also single-sided and not interactive.
But I have better idea! I have a few pre-serial prototypes with some display defects. Displayed images have artifacts, but the devices are absolutely usable for the development. I could provide them to those, who will help me to create FlameTube DevTools and OS.
According my idea, DevTools should have FlameTube software simulator (we have to simulate the display and sensors). When the DevTools is ready, anyone could write code for FlameTube without FlameTube.
We have a few days to build the development plan and the team.
Those developers, who would like to receive FlameTube RIGHT NOW, send me your candidatures and explain, what you can do for the project.
FlameTube displays the same data on both sides, and on the backside it's mirrored.
This is because I don't use hardware display drivers. The display driver is 100% software, written on PASM (256 brightness levels for each pair of LEDs, by PWM). All the display circuit do is current ampification to drive LEDs. Sorry, the Prop1 does not have enough pins to drive two sides separately.
Kind regards, Alexey
Make it 4 groups, each group charliplexed by 8 Prop pins
Sure it will use all 32 Prop Pins, but as 8*7*4= 224 max individual segments,
but you have 192 LED's, you probably could still get i2c to coexist.
Why not? It displays text well (with vertical scrolling). On the reverse side it looks funny, but absolutely readable (because of vertical scrolling). It's not a problem at all.
I suppose. It certainly means you can't display something different on each side though. Makes the device a lot less general.
it sounds to me like @FlameTube doesn't need anything remotely close to an entire "OS". What you do need is:
Tachyon and PropForth have both been mentioned. Great ideas for those familiar with Forth. I will be stunned if you gain much traction with developers if you go this route. "Makers" and "hackers" worldwide are used to Python, JavaScript, and an easy-to-use version of (library for) C++ called Arduino. I would think that, if you can't accomplish what you want in a common language like one of the above listed three, you would be better served by redesigning your system with a more powerful chip that can do everything you need.
So what to use for a common language? Your options come down to C++ (choose C++ over C, since this allows you to target the Arduino community), Basic... and I think that's it? Spin is certainly out-of-the-question since you want it compatible with future FlameTubes and you likely don't want to limit yourself to the Propeller family.
Basic would be a nice and easy choice. There isn't as much activity on PropBasic (aka: limited library support), but I suspect that could change in the "near" future (1+ years) now that Propeller IDE has baked in support.
C++ is my favorite, but I am quite biased on that point. See my signature.
The other two points don't sound too complicated... should be fun!
Another option is a cloud compiler & online GUI for developers and end-users.
Developer functions:
- creation of libraries and apps online
- online FlameTube simulation
- sharing of libraries (to other developers) and apps (to users) online with an option to hide or show source code
- placing of their apps in FlameTube app store (for money or for free)
User functions:
- FlameTube registration (by entering S/N of his device, so, the system will know the model of the FlameTube, encoded in the S/N)
- Purchasing of Apps, available for his FlameTube model
- Installation of purchased apps directly from the web UI
The compilation should happen in realtime, for user's model of FlameTube, using the latest versions of libraries.
What can you say?
Whether you use a web-based IDE, command-line only tools, or a powerful desktop-based IDE, you still need to define what you need the software to do. That's all my post was trying to get at.
That being said, a web-based IDE has my vote! mbed has done a great job. Taking inspiration from them, I created a proof-of-concept for the Propeller, with source files being sent to a centralized server, compiled with PropGCC, and then the binary file uploaded back to the user. Not as simple as running a JavaScript Spin compiler in the browser, but it gets the job done. Unfortunately I just goofed this morning and deleted the Tomcat server :P but you can find the source here and here.
http://forums.parallax.com/discussion/155208/open-propeller-project-5-blocklyprop/p1
https://github.com/parallaxinc/BlocklyProp
http://blockly.parallax.com/blockly/
End-users could click something together. Developers could build the blocks.
As long as it does not use somebodies specific servers in the cloud. At that point you are tied to a service that will disappear at a moments notice. See Google Next and so on.
Espruino gets it right.
Putting a Spin or other compiler in the browser would do it too.