???? help ???

tried again using: USBMSD_SD::USBMSD_SD(PinName mosi, PinName miso, PinName sclk, PinName cs, const char* name) : FATFileSystem(name), _spi(mosi, miso, sclk), _cs(cs)

and defining the class with multiple inheritance.

class USBMSD_SD : public USBMSD , public FATFileSystem { public:

It compiles, but crashes when trying to access the SDcard if I am attempting a write via FATFilesystem. If I try just the sd.disk_initialize() it won't crash but come up with the "No Disk, or could not.... Didn't get a response from the disk... Set 512-byte block timed out.

That seems to me like the correct place to start. Sadly I don't have an SDCard holder, so hard to help with this. I assume this is without a USB cable connected for the MSD part? And if you try it via MSD and not FATFilesystem?

I have both hello worlds working individually yes. trying to combine. I think I am almost there.... been studying the usb composite device example for HID and SD together.

got it!

Hey, could you share what you did?

Thanks in advance!

Until he publishes that, this might help you: http://mbed.org/users/Sissors/code/USBFileSystem/

thanks Eric!

I have now something working see: http://mbed.org/users/karelv/code/SD_USB_FS_HelloWorld/ do I need to call 'connect' from USBMSD in my constructor or not?

Now I created a loop of 1min: 5 sec ==> disconnect 55 sec ==> connect

So I have 55 sec to use my pc to peak the data. When I didn't use connect at all, the SD does not appear as a drive. And when used in the constructor it appears only correct when I comment the write operations in the mbed-main-program.

You can call connect in the constructor, then it immediatly will do the USB drive part. Connect makes it appear as drive, disconnect removes it again. It should also work when you use it in the constructor, but because of some data traffic right after connecting it, it might block your write attempt. In general with the library you should make it so that if a NULL pointer is received when a file is opened it doesn't generate an error, but just waits a bit and tries again.

You will need to keep the disconnect/connect around that function call, or you can set the library to do it automatically for you. But otherwise the data you see on your PC will never gets updated since your PC caches everything. (Actually I think when I release a next version I set that as the default mode). The function you need is:

sd.usbMode(1);

Maybe the helloworld programs of the library can also give you a starting point. For sure when it works correctly I would like to link your program as an example program.

So I used now the usbmode 1, and removed the surrounding disconnect/connect. And added again the connect in the constructor.

This works.

Although, it is not very convenient, since my win7 pc always disconnect/connect the drive and at disconnect it also closes the explorer which show the content of that drive. It does the same with the editor that has the file opened.

Do you have any suggestion for that?

Nop :D.

You are correct that that is what happens, got the same on windows 8. The problem is that windows (and probably every other OS) is quite heavy on caching of USB drives. So it reads the data ones, and after that it only writes and assumes its commands have been performed. For example if you have a drive with a bunch of files, and I enable write protection on the library, you can still happily delete the file and windows will tell you it is gone. You can make new files and windows will tell you they are created. Despite nothing actually being done. So the only way to force a refresh is disconnecting/reconnecting. Well not entirely true, I found out if you are writing custom programs you can disable this caching behavior after alot of digging. But in principle it is always on, and you have to reconnect the device. An alternative file browser might have other behavior, but dunno.

So the TL;DR: It is OS behavior that the program can't do anything about. Initially I intended to just use write protection to block the computer from writing, which is why it is still the default, but it doesn't actually work like you want it to work for 99% of the use cases. So reconnecting it is.

okay... I will your statement on the homepage of the lib. Unless you disallow me of course.

No problem of course. You okay with it if I link it as example program for using the lib with SD card?

Sure go ahead

En veel plezier ermee!