Go Down

Topic: Flashing via SD card (Read 3490 times) previous topic - next topic

D3C3PT1C0N

Nice project!
I really like this part "The user picks one, then the "proccessor" chip gets flashed and takes control of the system."

mowcius

#16
Jun 04, 2010, 06:57 pm Last Edit: Jun 04, 2010, 06:58 pm by mowcius Reason: 1
Well regarding games for an arduino, I would have thought it would be much better to just have a seperate code routine for each game and a menu. If you can upload from one arduino to another it will be very slow, espeicially if the code is so big you could not fit a few of them on the ATmega chip.

If you are short of space then just go for the 644 or something. Double the space (and double the RAM etc - better for games)

Mowcius

D3C3PT1C0N

#17
Jun 04, 2010, 09:36 pm Last Edit: Jun 04, 2010, 09:47 pm by Fredx Reason: 1
In SD-Card there are many game-files (preverified/compiled). User chooses one code-file and uploads it to Arduino. Every time user wants to change to another game, he must reset and reupload from SD. I think theres no need of another Arduino... just figure out, how to upload from SD-card. To erase old uploaded script, just use reset button on Arduino board.

For graphical games, we may use some small LCD-s // or led-s + buttons (reaction time games)... led tic-tac-toe etc.

Also I was thinking, if it is possible to upload code from SD card, then how to upload libraries? Lets say there are games for LCD.... but every time when reset is being made, the old library is erased... then when uploading new game for LCD we must also upload the library.

BTW: Sorry for my messy elngish  8-)

Adrastos

#18
Jun 04, 2010, 10:07 pm Last Edit: Jun 04, 2010, 10:09 pm by Adrastos Reason: 1
I see what you're thinking, Mowcius, but I was going more with what D3C3PT1C0N said..

Use one chip to load up an SD card, and look for .hex files, showing those .hex files to the user (via a 128x64 graphic lcd). When they pick the one they want, it loads the .hex from the SD card and uses that data to flash the "processor" chip.

The idea behind this was that to get a new game on the thing, I wouldn't have to plug it in and reprogram it from a computer, I could just have / build multiple .hex files on an SD card and use those (and add, swap, edit, etc, at will).

As to the speed, I don't see how it can be any slower than how the Arduino currently uploads files (through UART) - those only get uploaded at 57600 baud (and only in 64 byte chunks too!)

I have considered using a 644, but a) I don't currently have any laying around, whereas I have several 328's lying around, and b) I thought it would be cool to just create standard Arduino programs, with their native libraries and everything that doesn't need to get ported to the 644.

This morning I played around with writing my own bootloader, but it didn't pan out so well (couldn't make it properly work / couldn't verify the bootloader was running, but I'll put more time into it when I actually have the time..).

What might be easier for me to do, however, is to just have code on the Arduino that "emulates" the STK500v1 protocol that avrdude / uisp use to upload.

I just found the "upload.verbose" preference, so that will make my reverse engineering of the upload process much easier.


Also, D3C3PT1C0N: I don't understand what you mean by libraries? Currently all Arduino "libraries" are compiled straight into the .hex as regular code. Are you thinking along the lines of shared object files (ala .dll's, etc)? If you are, then I don't think that's possible / feasible with embedded chips like these.

D3C3PT1C0N

#19
Jun 04, 2010, 10:21 pm Last Edit: Jun 04, 2010, 10:22 pm by Fredx Reason: 1
i was thinking about those that are at the beginning of a script
(like #include <Servo.h> )
When both files are in SDcard (script + Servo.h) then how to tell Arduino, that when you select a file to upload, then it must also upload that Servo.h

--------------

but compiling into "HEX" - it means that "script + Servo.h" are both inside it?

Adrastos

Yea, when you click the upload button in the Arduino environment, the following things happen (more or less):

  • All the files in your sketch get merged into one (the multiple "tabs" in the environment)
  • That file then gets compiled into machine-readable instructions (.hex file) (All the included libraries also get compiled, and get merged into the single .hex file)
  • Arduino environment resets the ATMega chip on your board
  • Bootloader runs first, recognizes that you want to upload new code
  • Arduino environment starts sending out the machine-readable instructions (the single .hex file), and the bootloader receives them, flashing the chip along the way


To do what I want, I would simply do the first couple steps on my computer (compile the sketch into a .hex file), then I would place it onto an SD card and let the "programmer" do it's work.

mowcius

Yeah I see what you mean. Then you can add extra games to it without any need to re-program the chip with a computer.

Maybe you want to simply run games off an SD card rather than physically loading them onto the arduino.

The SD card read is a little slow but I would have thought that it's be fast enough for simple graphic LCD games :)

Mowcius

Adrastos

As, write an interpreter on the Arduino, and write the games in my own interpreted language?

I've thought of that too, and that was definitely one of the ways I was thinking of going. The biggest issue I can see with this is that the 328 only has 2 KB of ram, so storing any sorts of graphics might be a pain (not to mention the ram that the fat libraries take up...)

Though I think it could definitely be possible, especially if I "compiled" the games down (to save on unnecessary string buffer memory).

I'll give it more thought, but I still think using one chip to flash another should be easier...

I hope to get somewhere around 10-20 fps, so I'd assume reading from an SD card would be ok (they *do* use an SPI interface, after all...)

mowcius

yeah the SD card libraries can take up quite a bit of room.

I do think that you would be better off with a 644 or mega maybe as they have more in the way of RAM.

It's an interesting one, anyway I look forward to seeing what you get sorted and how you go about it.

Mowcius

D3C3PT1C0N

#24
Jun 05, 2010, 04:14 pm Last Edit: Jun 05, 2010, 04:23 pm by Fredx Reason: 1
i found nice graphical lcd 128x64 used with arduino: http://www.youtube.com/watch?v=hid0eEHqmvs

although i think at first im trying to get a cheap non-graphical lcd for just showing temp etc.


# 16x2
# module 80x36mm
# LCD 64x13.5mm
# 5V
# Blue backlight
# White numbers

Adrastos

Note that the interfaces for graphical and non-graphical lcds are very different (and even different types of graphical LCDs are different).

Using the character LCDs is really easy, I'd suggest looking at Adafruit's tutorial here: http://www.ladyada.net/learn/lcd/charlcd.html.

For this project I will using her new serial graphic LCD: http://www.adafruit.com/index.php?main_page=product_info&cPath=37&products_id=250&zenid=0e0f628671c1c67faa6579949c10af37

Also, the game in your video is definitely one I was thinking of making..

D3C3PT1C0N

#26
Jun 05, 2010, 09:01 pm Last Edit: Jun 05, 2010, 09:01 pm by Fredx Reason: 1
thank you for the links, i also found a page http://jonnyblanch.webs.com/arduino.htm, where everything is made very simple. Standard 16x2 LCDs are the easiest.

Go Up