A suggestion for a future BASIC Stamp
brucee
Posts: 239
in BASIC Stamp
I put together a proof of concept version of an ARM based BASIC Stamp. It used a modified version of the Propeller IDE, and includes both C and BASIC compilers. A few of these went to Parallax for evaluation, and there are a number left over. Ken granted me permission to give those away here. This will help flesh out the concept and be a beta test.
So what is it? --
So this is a proof of concept, which means a bit rough around the edges, but generally is ready for use. The Qt tools can be downloaded from eisenhard.net/files/Cbasic.zip An installer was not built, just download that zip and install at the root, ie. C:/Cbasic
These tools are for Windows, but others could be built for other systems.
Drop me a line through the forum here if you would like to get a board to play with.
So what is it? --
LPC11U37 ARM controller 50 Mhz ARM CPU
Stamp form factor an pin compatible
Qt based IDE -- should be portable to Linux, Mac Unix, and Android
BASIC compiler
GCC compiler (C++ support possible)
128K Flash
10K SRAM
4K EEPROM
USB serial builtin
8 10bit A/D
upto 40 IOs (17 used on Stamp with 2 additional for serial
Stamp form factor an pin compatible
Qt based IDE -- should be portable to Linux, Mac Unix, and Android
BASIC compiler
GCC compiler (C++ support possible)
128K Flash
10K SRAM
4K EEPROM
USB serial builtin
8 10bit A/D
upto 40 IOs (17 used on Stamp with 2 additional for serial
So this is a proof of concept, which means a bit rough around the edges, but generally is ready for use. The Qt tools can be downloaded from eisenhard.net/files/Cbasic.zip An installer was not built, just download that zip and install at the root, ie. C:/Cbasic
These tools are for Windows, but others could be built for other systems.
Drop me a line through the forum here if you would like to get a board to play with.
Comments
The concept and general approach sounds great
The only detail I would change is to select a 5V capable ARM, (not just 5V tolerant) so this can be backward compatible into 5V systems.
There are an expanding number of 5V ARMs to choose from.
For this sort of use, I'd lean more toward better speed and performance, than "save the last 10c".
ie 10b ADC and 10k RAM is at the rather low-spec end.
One example is Nuvoton M452, adds 12b DAC, 12b DAC, 2.5~5.5V Vcc and 1.8-5.5V io, with ROM loader and is a Cortex M4.
M452 is new, but eval boards I think are avail and sub US$20 - links from here
http://www.nuvoton.com/hq/support/tool-and-software/development-tool-hardware/development-kit/?__locale=en
Nuvoton publish the PCB files, so you can morph to any form factor.
Board uses M453VG6AE, family superset device with
256kF
32kR
80io
4 timer
4+1 Uart
1 ISO7816
3 SPI
2 i2c
1 Can
2 LIN
2 i2s
USB: OTG
PWM: 12
Comp: 2
DAC: 12b x 1
ADC: 12b x 16-ch
Cap: 16
RTC
Bootloader
LQFP 100
and also see http://coocox.org/index.html
Addit: I see Avnet show good stocks of 64pin
Avnet M453RE6AE - 10000 stock 250 $2.46
Seems similar price, or lower, than the LPC11U6x, which would replace the older LPC11U3x
What that means is
FREQOUT is not a builtin word, but is written as a library that can be included. The BASIC takes advantage of C Pre-Processor, to handle libraries.
One route to go would be to do a PBASIC -> BASIC preprocessor to port old code. This could be done with some sed like scripts.
Jus so we are on the same page here is a picture, and it does maintain the Stamp pinout, but debug is through the USB serial port
This compiler is written in C for MinGW, and has already been compiled to Mac and Linux. With a Qt GUI front end could run on multiple platforms.
What code size is this on eg an ARM core ?
Looking ahead to P2, collecting numbers...
I can see a place for a BASIC interpreter more than a compiler.
On a part with moderate RAM, there should be ample code room to include a BASIC interpreter that at least matches the old Stamp.
Maybe even with a Slow_Down switch to (optionally) broadly match the Stamp speed ?
A 'full blown compiler' on a MCU is always going to be compromised, and the resource is better placed into a better debug for example.
Can't a BASIC interpreter do that ?
A compiler is less interactive, because you have to do the compile step before you can run, and that also infers something of a mini file system to manage the compiled output.
A BASIC interpreter that does something like a JIT Tokenize could give better run-time speeds, but that's not quite a full compiler.
Something like Turbo Pascal would be nice, where you can Source Step, and Compile is very fast, but I think that is pushing mid-range ARMs too much.
I did see this news item :
http://www10.edacafe.com/nbc/articles/1/1397590/Toshiba-Expands-Line-up-ApP-Lite-Processor-Family-Wearable-Applications
Looks to be a 8mm BGA, with 2.2MB of RAM
(but that's not going to be 5V operating)
How much RAM does it need, and besides the Source Code, and output Binary, what other working resource does it need ?
Does that 40k include any Debug support, or is it compile-and-hope ?
and the Arduino market place is suffering from 3v versions that cannot tolerate 5V shields.
Smarter to avoid that minefield entirely, and there is no need to be 3V constrained these days - see the above Cortex M4 chip that can do 5V operation.
5V also gives you 5V ADC, 5V DAC and direct gate drive to Logic level Power FETS
You can always replace the code in any flash device, but that means clobbering what was there.
If you want to co-exist with someones close-source firmware, that's going to be trickier.
I took the comment above
http://forums.parallax.com/discussion/comment/1361389/#Comment_1361389
to mean that had been done.
That lock likely includes the interrupt vector areas, which limits what you can add into any spare space.
As jmg noted, 5V compatibility is crucial if you want to replace Stamps with this. Without 5V compatibility, you might as well use a Propeller. An interpreter for PBasic would not be hard to do if Parallax would make the BS2 interpretive code format available to an interested developer. Still, such a device wouldn't be hardware compatible.
You really want to have the initial Basic implementation look as close to identical to the existing Stamp Editor as possible so existing programs can be compiled "as is" or at least with no more parameterization than already exists among the various Stamp models. There's an awful lot of existing code and educational materials that would have to be changed otherwise.
Most ARM vendors IOs are 5V tolerant which means they will not clamp an output at 3.3V. Most TTL really runs with a 2.6V threshold so those are not an issue. Some power MOSFETs do require higher than 3.3V, but that can be accomplished with a pullup, something the P1 can not do.
The existing code base is an issue, but I think can be addressed with a PBASIC translation, you could keep it always running in that mode, but then you would give up parameterized functions and subroutines, floating point, and other things.
Hehe, one could even emulate the PIC using the ARM
but more practical would be to remove the serial memory, and use RAM / Emulated EEPROM - DataFlash to host the code, with the code re-written for ARM.
There would be place for 3+ modes
* Emulate existing code, including Timing
* Run existing code faster & with more Data
+ maybe extended data types
* Run PC compiled code, more options, more vars
and faster again.
Using the Spin2Cpp, this could also host Spin sources...
However it is difficult to find.
Brucee I welcome your efforts.