Working with SD cards and others

Hi,

I have seen on youtube people making mp3 player and digital photo frames with the info being stored on an SD card. Would it be possible to make programs for a robot, way for it to react to different sensors and have them stored on an SD card so that they can be easily changed?

Has anyone ever heard of something like that before?

You could, but there's not much point - instead of reprogramming an SD card, just reprogram the micro.

Micro controller reprogrammers are specialty devices compared to an SD card Nigel, it's difficult to buy computers or even printers nowdays that don't have SD card slots build into them. If you had a sufficiently well written program on the micro controller you could use plain english language in a text file on the SD card to control the robot, making it reprogrammable by the end user without a lot of fuss. A bootloader with code to read from the SD card would even allow you to do active updates of the micro controller in system with no special hardware onsite without a programmer. And the storage space on even the cheapest SD cards are an order of magnitude more than what's available on even the largest of micro controllers. Reading and writing to an SD card is comparatibly slow next to local access to the onboard micro controller resources, but for something like a robot this shouldn't be a problem, in such narrow instances where it is a problem code chunks can be read from the SD Card and exectued on the micro as most of them have the ability to real time reprogram their own flash program memory. Micro SD cards are also so incredibly small they take up less space than the micro controller itself would.

You've got to have a programmer to program the PIC in the first place, so it's no problem to program a bootloader in, and then just re-program it via a simple serial lead. Reading data or tokens fron an SD card is a very backward step, basically (pun intended) recreating the old slow BASIC STAMP.

How much program data could you actually need anyway?, I can see the point in using an SD card for storing data (from sensors perhaps?), but not for controlling the robot.

Nigel, pretend a robot was designed to use a field programmer which the customer doesn't have.. They have a machine down and it's costing them 5 grand an hour for the downtime. Do you want to be the one that has to tell someone they have to wait for someone from the nearest branch office to fly over with a programmer to fix their issue or do you want to tell them you'll e-mail them the repair file in 30 seconds and all they have to do is drop it into the bot for reprogramming on a memory chip that can be bought at convenience stores for less than 20 dollars.

It's almost trivial to interface an SD card to a micro controller, it takes up minuscule space and is nearly a universal standard nowdays.

In the case of a robot program execution speed is irrelevant, it should have all it's code for machine motion programmed on board, and then you just needs tokens to read from to execute the specific variables for that specific desired motion. This has nothing to do with a basic stamp where any program you wrote had to go through a byte code interpreter. As a programmer you have an interface for hardware less in system programming and the customer gets unlimited re-usable access to their own machines. Win win. Additional cost is a few I/O lines and the SD card carrier.

Systems like this are built into almost all CNC machines in existance, although the bulk majority of them still use floppy discs for reprogramming.

Sceadwian said:

Nigel, pretend a robot was designed to use a field programmer which the customer doesn't have.. They have a machine down and it's costing them 5 grand an hour for the downtime. Do you want to be the one that has to tell someone they have to wait for someone from the nearest branch office to fly over with a programmer to fix their issue or do you want to tell them you'll e-mail them the repair file in 30 seconds and all they have to do is drop it into the bot for reprogramming on a memory chip that can be bought at convenience stores for less than 20 dollars.

Click to expand...

So why have we suddenly jumped from a hobbiest robot to a multi-thousand dollar machine?.

I'm not denying SD based bootloader programming might be useful in some circumstances, but there's little use for it in a hobbiest robot.

It's almost trivial to interface an SD card to a micro controller, it takes up minuscule space and is nearly a universal standard nowdays.

In the case of a robot program execution speed is irrelevant, it should have all it's code for machine motion programmed on board, and then you just needs tokens to read from to execute the specific variables for that specific desired motion. This has nothing to do with a basic stamp where any program you wrote had to go through a byte code interpreter.

Click to expand...

If you're reading instructions from an SD card (rather than bootloading) it's almost identical to a STAMP - which has the program in ROM, and reads tokens from EEPROM.

As a programmer you have an interface for hardware less in system programming and the customer gets unlimited re-usable access to their own machines. Win win. Additional cost is a few I/O lines and the SD card carrier.

Click to expand...

As would a simple RS232 bootloader from a computer - at much less cost of system resources.

Systems like this are built into almost all CNC machines in existance, although the bulk majority of them still use floppy discs for reprogramming.

Click to expand...

There have been numerous such examples over the years (decades!) - but still have little relevence to a small hobbiest robot - where any advantage is miniscule, and probably less than the disadvantages.

Because Nigel it's good general engineering practice to plan for what if scenarios, and the added features/functionality are so low cost and easy to implement it's almost a no-brainer. It's easier to add during development then it is after the fact.

The difference between a stamp and a robot is you have direct access to the code that those tokens execute, so you get the best of both worlds. Flexible onboard code and unlimited offchip storage.
For a robot that was designed to execute extremely complex patterns or perhaps for something like a motion control system it would be essential.

I would challenge the assertion that RS232 is easier to implement than an SD interface. You still need an off chip charge pump something like a Max232. If the MCU system is 3.3v based you require only a few passive protection components for SD interfacing even that's not actually required, for 5 volts systems you might need a single transistor, but should be able to implement slower SD access with all passive components. And keep in mind the SD interface is actually SPI compatible so a simple header would allow it to be a general purpose SPI interface as well. The cost of the SD carrier would be comparable to a Max232 with fewer passives (if any) required. And the carrier isn't even required, although the pin pitch doesn't match exactly for standard SD cards it's close enough to allow standard 2.54mm (.1 inch) headers to contact all of the power and control lines.

Sceadwian said:

Because Nigel it's good general engineering practice to plan for what if scenarios, and the added features/functionality are so low cost and easy to implement it's almost a no-brainer. It's easier to add during development then it is after the fact.

Click to expand...

Yet no one does - so perhaps not a 'no brainer'. Although to be fair, it's not totally unknown, there are SD card bootloaders out there - but only in tiny numbers, and for particular purposes.

The difference between a stamp and a robot is you have direct access to the code that those tokens execute, so you get the best of both worlds. Flexible onboard code and unlimited offchip storage.
For a robot that was designed to execute extremely complex patterns or perhaps for something like a motion control system it would be essential.

Click to expand...

So, if it's far superior to all other methods? - how many times have you utilised it?

I would challenge the assertion that RS232 is easier to implement than an SD interface. You still need an off chip charge pump something like a Max232.

Click to expand...

Nope, you need ONE RESISTOR - and 'coincidentally' that's pretty well all the BASIC STAMP uses.

Common sense is not common, which is why it needs to be beat into people =)

One resistor? To meet RS232C standards? Nope sorry Rs232C standard noise floor is -3 and +3 volts for even recognizing that there is a logic level on the line. If an Rs232 port a Basic stamp is connected to picks up 0 volts as a low voltage it is only because of it's specific construction and NOT becaues the basicstamp is Rs232c compliant.

TRUE voltage level compliance with an SD card is much simpler as no negative voltage is required by the standard.

Sceadwian said:

One resistor? To meet RS232C standards?

Click to expand...

I never suggested meeting RS232 standards, merely suggested a 100% working error free solution that requires nothing but a single resistor.

Why would you want to actually meet an antique standard for driving teletypes when it's not required?.

Wow you guys are clearly at the top of your respective games, hopefully in ten or twenty years I'll know around half of what you guys do

I like the idea of making it so that a simple text file could be created that allowed the user to use simple commands in ordinary English to program the robot, I might try and do that although I think it may be some time before I'm capable of doing it

Thanks for the help.

ozirock said:

Wow you guys are clearly at the top of your respective games, hopefully in ten or twenty years I'll know around half of what you guys do

Click to expand...

You'll find as many different opinions as replies!

I like the idea of making it so that a simple text file could be created that allowed the user to use simple commands in ordinary English to program the robot, I might try and do that although I think it may be some time before I'm capable of doing it

Click to expand...

Essentially to do that you need to design your own language, and write an interpreter to run it - not a simple task, but it does allow you to write a language with specific exact capabilities.

Ha yes I've no doubt but it'd probably be almost impossible for me but sure no harm in trying, I might learn something. Hopefully it wont just learn never try the impossible again

I think the easiest way would be to use a large memory model micro controller (PIC 18F8722 has 128k of program memory, etc.) and execute one of several behaviors after reading a set of switches or jumpers, or any other method of distinguishing what the user wants....

I'm first going to try make a micro chip that makes six inputs from sensors, sends four outputs to the motors and has one switch to select mode, I'm pretty sure that it'll work easily enough from some of the simple tutorials I've been doing, I can't wait until my exams are over so I can get some time to experiment

Because Nigel, technically all PC's are supposed to require those voltage levels to be actually called RS232, the fact that a single resistor to protect the PIC and 0-5 volts from the PIC can trigger a PCs RS232 port is an accident of construction only and is technically a violation of the standard.

If you want to use the SD card the way I think you've imagined it, were you can just copy a file to the card using your PC and then plug it into the target board, then you need to implement a file system library on your microcontroller, which isn't trivial.

If you're using C code it is, there are libraries for it available on most C compilers. If not it could be adapted by porting code from another C compiler, porting code is a lot easier than writing things from scratch.

Sceadwian said:

If you're using C code it is, there are libraries for it available on most C compilers. If not it could be adapted by porting code from another C compiler, porting code is a lot easier than writing things from scratch.

Click to expand...

You have really been arguing technicalities a lot here now. I've done it for a few different microcontrollers, and no, given the OP's level of expertise, it is not trivial even using prebuilt libraries. It's not hard, but it's not trivial and generally they take a decent amount of resources which could have been used just to implement Nigels idea in the first place.

If I tell you I was going to try do it with assembly code would you call me an idiot, honestly?