Haha 
A PIC is too slow to take advantage of the bandwidth already provided by MMC/SD cards, so it doesn’t really make sense to consider alternative solutions.
Isn’t it much more difficult to interface a CF card to a microcontroller?
Best Regards, Thorsten.
Isn’t it much more difficult to interface a CF card to a microcontroller?
In theory probably not, because it can also be addressed linearly, and there is even some PIC assembler code around on the net. But I was not able to get it to run when I tried that seriously last year (could have been my fault, naturally ;)). My advice would be to forget CF.
I won’t have the time to continue the evaluation in the next two weeks, but you can be sure that SD cards will be supported in future
GREAT, GREAT, GREAT! ;D
Yikes!
Best regards, ilmenator
TK: Perhaps it would be better, to have a tool for the PC to write to the midibox format, than to have the midibox support FAT…?
To give you some numbers: reading a 512 byte sector takes ca. 3 mS, writing a 512 byte sector ca. 4 mS
For comparison to an IIC EEPROM: 512 byte read ca. 11 mS, 512 byte write ca. 100 mS
Flash memory consumption of the driver: ca. 600 bytes
TK: Perhaps it would be better, to have a tool for the PC to write to the midibox format, than to have the midibox support FAT…?
of course, it would be better - but who is skillfull enough to implement such a tool? It could be difficult to get raw data access via a common SD card reader.
However, writing/reading sectors of the card via SysEx would work as usual, we are speaking about a more comfortable, and especially faster solution (if you want to read/write data from any computer w/ a cheapo SD card reader). I think, that it wouldn’t be so difficult to search in the root directory for a single file which holds the complete data (e.g. “SIDBANKS.DAT”), and to go through the FAT to find out the corresponding clusters/sectors. So long the used clusters are cached in a buffer, it wouldn’t decrease the access speed. It’s something which cannot be realized in one day, but maybe in two until it will work
Best Regards, Thorsten.
I did some work using CF a while back. The I/O is parallel, a CF card effectively looks like an IDE drive. This is very good for fast cameras where transferring data to the card is the bottleneck. In the world of microcontrollers as used in the MIDIbox, a serial peripheral interface is better: it only uses a few pins, and the interface is going to be fast enough anyway.
CF are good for booting micro PC’s from, and for very fast large block data. They can virtually be interchanged with small hard discs, (in fact, some of the bigger camera cards were small hard discs). They are physically large, and have a complex socket which needs a minimum of 20-something connections. CF pairs very well with the older PCMCIA/PC-Card slots, being virtually a straight through interface that needs no real drivers, (the new ExpressCard has trashed that, of course)
SD are the other common standard, (along with smaller MicroSD and XD). They are small, serial and come in sizes well big enough for our purposes. They seem to be a lot cheaper too. As camera cards get bigger, we can recycle the smaller ones for MIDIbox.
As TK says, the FAT files interface is going to be a challenge, and if it’s going to be a challenge for TK, then I’m not even going to take a look at it! Perhaps one approach might be to go modular: add another micro to the SD card interface, and make the card subsystem look like a big stack of banksticks. Select banks by simple title or number, (no long file names, thank goodness), and only ‘see’ certain file types. Don’t allow file operations beyond load/save/delete from the MIDIbox. MIDIbox generated file names might have to be of the generated form FILENN.XXX. Set up a simple list of XXX extensions for MIDIbox. “.SV3”, “.SQ3”, “.SID” or whatever, and refuse operations on others, (apart from perhaps ‘delete’, with a good ‘are you sure’ system). Date/Time would have to be set as defaults, unless someone wants to interface an I2C real time clock, (not that hard, thinking about it - I’ve got a feeling there might be a handle waiting in MIOS for just that too, knowing TK). Do your file renaming and ‘housekeeping’ on the PC.
With regard to sockets, I wouldn’t think of buying in yet: the sockets are easy. The board they go on is going to be the hard part. It has to hold the socket, (more easily available in surface mount), and some flexible way of panel mounting it. An activity light is nearly essential, (to avoid pulling the card during a write), and there might well be some I/O parts. A panel bezel with a simple screw mount would be good as well - plenty of design things to be digging in to, and group buy of sockets, PCB’s and bezels would be even more useful.
Just a few thoughts. In my case it was work for a FORTH based data logger running on the late lamented TDS series of cards, we had to use CF - SD hadn’t come out at that time, and I shudder to remember just what a 512K card cost back then. We did have an RTC, the main effort was doing a low power mode to get maximum battery life. I think the final version would run 2/3 months in the field.
TK: you never cease to surprise us!
Best wishes
Hello,
my 2cents: can a PIC emulate an I2C eeprom? If so, it could be visible to the Core as a common (huge) BankStick and no modification to MIOS would be required. On the other hand, the emulator can implement all the SD/FAT stuff, or even gather data from anything else than an SD.
I had the idea to use a PIC18F4550 to bridge the SD card to USB and IIC, but I skipped it because of the reduced flexibility, and the slow IIC transfer speed.
I also think, that getting such a system stable and foolproven would cost me even more effort.
Best Regards, Thorsten.
I’d been thinking more SPI than I2C, and using a second processor to off load the file system from the main processor, though the filing I/O and display etc wouldn’t mean that much of an off-load.
I still like the idea of a local processor to do the filing system ‘primitives’, given the cost of the hardware, but I’m not competent enough in PIC design to analyse the hardware/software trade off.
My thinking was coloured by my work with CF. IDE already does quite a lot of the filing primitive worK, SCSI does a bit more. It might be possible to have a similar thing for SD.
A point I’d forgotten: where are the life extending algorithms for the SD?, (the software that prevents spurious erase and write cycles, to optimise the cards working life) are they in the card, or do they need to be implemented outside?
Card would still be a very good idea though.
Best wishes
Mike
A point I’d forgotten: where are the life extending algorithms for the SD?, (the software that prevents spurious erase and write cycles, to optimise the cards working life) are they in the card, or do they need to be implemented outside?
They are in the card itself.
Best regards, ilmenator
In distance to IIC, SPI doesn’t allow to stretch a data transfer request, accordingly the SPI slave has to handle the request immediately during a block transfer to avoid data loss. An handshaking to sync the master with the slave can only take place at the beginning of a block transfer. Since SD is interfaced via SPI as well, the resulting overall bandwidth will be (much) lower than the speed which could be achieved on a direct connection. And it would probably be lower than using the more reliable IIC protocol.
Only elegant solution I see for a multi-processor setup: searching for a ready-made open source solution which is running on a faster microcontroller. The microcontroller should be faster than the PIC to avoid performance loss. Once such a project has been found, let’s compare the costs
Best Regards, Thorsten.
http://www.dosonchip.com/ Interesting?
I2C/SMBus (not enabled in current firmware)
(see here)
Which probably means that they did not even start with implementing this…? Nice find, though!
Best regards, ilmenator
Well, they’ve got a new firmware in progress at the moment, which increases speed, and introduces some new features, I suspect that IIC may be one of them… But it still works with SPI in the meantime.
While they’re focussing on the new firmware, they aren’t shipping to distributors, but sparkfun had these for $12, and I read a fairly recent forum post saying something about a $5 price (probably in large quantities)… They also have a note there saying that they will take inquiries about stock in the meantime. I suspect that a community like ours could arrange a decent size bulk buy of these, and maybe we could provide some useful assistance to them with testing the IIC interface? Could be a win-win situation…
Yes, I saw that Sparkfun had the chips for US 13$ (and the complete module for US 45$ - a little steep for my taste).
A community bulk buy might actually be a good idea. Assuming that the bankstick memory was replaced in all applications with this module (or the SD would be available as an alternative to the bankstick memory), this could actually create the necessary demand. Let’s see how the USB MIDI interface thingy develops and what experiences can be gained from that. The documentation looks as if the necessary hardware was rather easy to implement, and the ridiculous prices for (proper) card connectors should come down considerably for larger quantities.
Best regards, ilmenator
I dunno, I got the best connector around for $5… They aren’t that bad. I even offered freebies to everyone I saw at the time I was ordering, and noone wanted one!
Speaking of which… $5-13 for the chip… $5 for the socket… so, that sparkfunPCB is worth like 30 bucks. ouch! Good if you want it ready to go, but in our case, I’m sure we could make it as a small kit for a lot cheaper.
It’s an interesting idea as to whether they could be used as a generic replacement for banksticks. Given that these are file-based, and BS are address-based, I don’t know how it’ll work. The datasheets will say a lot 
I dunno, I got the best connector around for $5…
Now, that sounds more reasonable than what even Reichelt have in their shop - usually they have rather good prices, so I might got confused.
And yes, the PCB should be cheaper than what Sparkfun has to offer. As for file-based vs. address-based: a simple conversion/naming scheme might already do the trick.
Best regards, ilmenator
Now, that sounds more reasonable than what even Reichelt have in their shop - usually they have rather good prices, so I might got confused.
ouch… but perhaps we could misuse one of those cheap USB-SD-card-readers which you can buy everywhere.
http://australia.rs-online.com/web/search/searchBrowseAction.html?method=getProduct&R=5025010
That’s the Hirose DMB1 series, it’s a springloaded push-in/push-out with a detector switch and all that, AUD$4.81 (about USD$5). This seems to be the standard ‘nice’ connector This is the DMB1-B* where the card goes into the slot pin-side-up, There is one that costs ~10c more, where the card is not upside-down, the DMB1-A*. Or, you can go with a slightly less-nice older model like this one for about $3
http://www.dosonchip.com/ Interesting?
You’re freakin me out stryd, I was just looking at that site yesterday in relation to a completely different project (IDE support on 68k Macs)
A very geeky SD socket replacement by Rob Wentworth: http://uanr.com/sdfloppy/
See, this is why I never throw out connectors, ever.
That kind of connector is ok if you never ever want to change the SD card, e.g. if it goes inside the box as a fixed memory extension. It is not so nice anymore (and probably rather error-prone) if you want to exchange the SD card on a regular basis. Though at the moment, I cannot think of any application scenario that would make replacing an SD card necessary - except for backups maybe, but then a file system is a must. dosonchip again…
Best regards, ilmenator