Something has to be used to convert C/C++ code into machine instructions. This is what the PC is used for - for the editor, the compilation and linking of the code and then for the uploading.
Even if one AVR could easily compile the source code you have to take into consideration that usually source code is lot larger than compiled code. But writing a compiler and squeezing it into the AVR and using it is hard task. So to keep the source on the SD card is OK but as far as I know the compiler usually has to process the code for a single lib/program as a whole, that means to load it somewhere. And one more consideration - you have to provide all the dependencies on that SD card.
So in theory this would might be possible, if data for the program was stored on the memory card?
Would the arduino be powerful enough to convert the code and send it to the memory card.
The other question was that if it could be done then could it be coded via the serial pins on the board or does the data have to go through the USB port?
Could it be possible if I had a memory card (possibly CF extreme IIII - for data speed) for RAM/temporary storage and then loading main files off of the memory card?
You could use serial RAM or FRAM for swap space & extra storage. Then extract much of GCC-AVR and compile it (with itself) into a library and put it on an SD card, and figure out a way to load code dynamically from an SD card into flash ROM (this is Harvard architecture (separate program memory and data memory), so it's hard to run programs dynamically like a PC). Then run the code, a piece at a time (since it probably won't all fit into flash rom), on a piece of data at a time (since it won't all fit into RAM), then finally write it out to the other Arduino.
I think it's not really feasable for standard Arduino C++, but you might be able to write a BASIC interpreter which loads its programs to another Arduino (just implementing simple commands like digitalWrite, Delay, etc. - you'd need to dynamically create the machine code for these calls, piece them together, and write them into a "template" sketch binary for the other Arduino) You could probably use the existing Arudino's flash rom (which contains the libraries, etc.) as the template, then just hack in the appropriate address translations for the setup and loop routines as you're writing it to the second Arduino. You'll need to study fairly deeply the AVR architecture, the bootloader upload format, and basic compiler theory.
I have a small amount of knowledge on this type of thing but not enough to get all of that... :-?
If there is anyone who has any more knowledge and would like to provide some help, no matter how little, then I would be very interested...
I think i'll be spending the next few months reading up on the more complicated stuff and trying to get a grasp of it... Now I realise why nobody has done it before
You could use serial RAM or FRAM for swap space & extra storage. Then extract much of GCC-AVR and compile it (with itself) into a library and put it on an SD card, and figure out a way to load code dynamically from an SD card into flash ROM (this is Harvard architecture (separate program memory and data memory), so it's hard to run programs dynamically like a PC). Then run the code, a piece at a time (since it probably won't all fit into flash rom), on a piece of data at a time (since it won't all fit into RAM), then finally write it out to the other Arduino.
I think it's not really feasable for standard Arduino C++, but you might be able to write a BASIC interpreter which loads its programs to another Arduino (just implementing simple commands like digitalWrite, Delay, etc. - you'd need to dynamically create the machine code for these calls, piece them together, and write them into a "template" sketch binary for the other Arduino) You could probably use the existing Arudino's flash rom (which contains the libraries, etc.) as the template, then just hack in the appropriate address translations for the setup and loop routines as you're writing it to the second Arduino. You'll need to study fairly deeply the AVR architecture, the bootloader upload format, and basic compiler theory.
Not impossible, but "real hard".
Good luck!
-Paul
You seem to have a decent knowledge of this kind of thing...
Any basic help you can give to start off this project would be great!!
Any forum posts that will help me with parts of the project would also be great if people know any...
I don't want to rain on your parade too much but I think it highly unlikely you'll get gcc running on an Arduino or Arduino-like board. If you want a highly portable development environment I'd look at getting a teeny sized netbook or tablet PC. I seem to remember some people managed to get a Nokia 770 tablet to act as a USB host rather than client and talk to an Arduino - that might be a way forward.
Let's face it - if to program an Arduino you have to remember to carry around an Arduino Mega (say) with a LiOn battery pack duct taped to it then you may as well remember to carry around a handheld MID (mobile internet device).
I like your enthusiasm though, and you should go with that.
You could make a sketch that incorporates the BASIC interpreter and allows you enter the program on a keyboard and display like that link you mentioned.
And you could add a layer on top of this that can send and receive interpreted BASIC opcodes. That way you could write the program on one system, and connect the other one and upload the BASIC program to it.
That's almost like what you were first suggesting, except in BASIC rather than C++ / Wiring.
If you wanted to take it to the next level, you could have the sketch actually "reproduce" itself on to a second unprogrammed Arduino, in addition to uploading a BASIC program to it.
Another way you might take that idea is to be able to network a bunch of Arduino's together (using some sort of serial bus) which could listen for a BASIC program coming from the first system.
Ok, i'm looking at the BASIC stuff and hopefully i'll have an idea about that soon... Bitlash is looking promising...
I have the PS2 libraries and soon I will have had a good play with them to get them how I want them... I am thinking of buying one of the basic character displays form sparkfun, do you think that 4 lines will be enough?
Do you think that I should purchase the microSD shield for the arduino? I presume that for any larger coding it will be essential to have more storage...
I will have 2 and a half months or so to work on this project soon so although I have limited knowledge now, hopefully I will have a bit an a bit
Bitlash was my attempt at doing something that seems very similar to what you describe. The interpreter lives on-board, the code lives in eeprom, and you program it over the usb serial link. The language is not BASIC, but close enough if you squint. (Careful observers will note Pythonic influences in the syntax, and a hint of Forth in the macro system.)
You can get a surprising amount done with Bitlash macros with just the built-in eeprom for storage, especially now that the '328 parts are coming to market. I'd suggest you max out an eeprom in a project before worrying about offboard storage.
I'm slightly confused by the concept of bitlash... So the main reason why it would be good to use is to make coding simpler and to decrease code size when calling on the same things (such as saving/writing text - many letters but repeated characters). Am I correct or barking up the wrong side of the tree?
Well, Mowcius, the way I see it from the side of the tree I usually bark up, it's less about saving typing and more about saving time (edit/compile/upload cycles).
Suppose you are bringing up a new hardware interface. How do you test it the first time? You could write a 2000 line sketch including the driver and your whole application, and then spend a lot of time figuring out, for each bug, whether it's a problem with your hardware or with your software.
Or you could start by uploading Bitlash and using the command line and maybe a couple macros to poke at your hardware and make sure it works and the pin assignments agree with your schematic. Then when you load your sketch and it breaks you know it's not the hardware. So, debugging the hardware with known good software is one use.
Once you're comfortable debugging hardware with Bitlash, you might find that there is a class of small applications that can be entirely implemented in Bitlash macros. This is a second use.
A third category of use is to integrate Bitlash with your C application as a programmability layer to allow your users to control and customize the behavior of your device from the command line without using a compiler. Think Cisco's IOS, minus the routing stuff, but with application-specific language elements suited for your application added in place. Embedding your application in Bitlash gives you quite a large command line tool set to start with.
I hope that helps give a perspective on how I expect people might use Bitlash.
Ok, I get your point now. I don't understand yet how to use it but I think that that's because I have not had time for a good read of the info on the site, once I have a had a better look then I'm sure I will understand how to do all of that (maybe). You also said that you can stick a lot in the EEPROM but surely as I suggested, for any sketch that is almost always more than 1kb, I will need an external RAM/EEPROM module.
As you can probably tell, I am a bit of a newbie at C++ coding and similar. If I am asking really stupid questions then by all means laugh but I will hopefully gain the knowledge to finish this project in the next few weeks.#
I think a small example to clarify the different memory strategies used by Arduino C and Bitlash (itself an Arduino C program, yes?) may help you on your journey.
Consider the tiny application which is "toggle the led on pin 13 every 100ms". If one were to write the obvious little Arduino C sketch:
it would indeed compile to considerable space, in my case 984 bytes of flash (and no eeprom).
The same "toggle pin 13" application implemented in Bitlash macros takes 43 bytes of eeprom, out of the 512 bytes on your '168; you already paid about 14k of flash to have Bitlash there in the first place. Bitlash runs in flash, and interprets your program from eeprom. Here is a listing and an eeprom map for one way to do the blinky app:
When the Arduino starts up, Bitlash runs the macro named 'startup' if one is present. In this case, the startup macro causes the 'toggle13' macro to be run in the background every 100 milliseconds. The toggle13 macro, in turn, flips the D13 pin taking advantage of the direct pin addressing feature (d13 is the name of a pin variable).
So this is the usual "interpreter tradeoff": you pay a fixed cost up front to have an interpreted environment, and what you get in return is that you can change behavior on the device without edit/compile/upload, and incremental changes are very light and small. And you pay a price in speed: interpreted code is (usually) at a speed disadvantage to compiled code.
I hope that sheds a little light on how the different strategies for using memory play out in what you can accomplish using each approach.
I don't want to rain on your parade too much but I think it highly unlikely you'll get gcc running on an Arduino or Arduino-like board. If you want a highly portable development environment I'd look at getting a teeny sized netbook or tablet PC. I seem to remember some people managed to get a Nokia 770 tablet to act as a USB host rather than client and talk to an Arduino - that might be a way forward.
Let's face it - if to program an Arduino you have to remember to carry around an Arduino Mega (say) with a LiOn battery pack duct taped to it then you may as well remember to carry around a handheld MID (mobile internet device).
Andrew
Yes, I could carry round a MID or smartphone (or possibly just a phone) but that's not the point.
Everything that people have done using an arduino could probably have been done with something else so why use the arduino in the first place?
It may be bigger to start with but if I get it all working then I am going to use an XBOX360 controller and chatpad for text and then I will make my own board integrating the arduino, microSD module and extra EEPROM etc to make it much smaller.
I feel that this could be useful in robotics for a robot to tell another what to do or for a company using arduinos on a network etc and then any idiot could update it by just plugging this unit into each one.
