Messages

1

µTasker general / Re: Application using FAT Emulation

« on: May 12, 2017, 04:15:25 PM »

Thanks for the update Mark,

I've been away from the forums for a few days, setting up a dev ide, and toolchain for the FRDM-K66F.  Also had to setup the debugger etc.  I'm at a point where I think I've got that all ironed out now, and I'm starting to focus on the code that needs to be written.

I'm currently in the process of wading through the demo code, and programmers reference, to educate myself on the thing.  I will have to grab a new copy of uTasker at some point, and give it a go.  :-)

Chris

2

µTasker general / Re: Application using FAT Emulation

« on: May 04, 2017, 03:18:57 PM »

Mark,

Yes, your fixes worked, and I was able to get a file uploaded to the simulated SDCard using FTP.  Sorry it took so long to get back to you, been busy this week, and haven't had much time to devote to this project. 

I'm probably going to be putting the uTasker side of this down for a bit, as my FRDM-K66F came in yesterday, and I'm exploring the dev toolchain for it, and debugging options, to get a stable platform to play with.  I'll let ya know if I need further assistance.

Thanks again for all of your help,

Chris

3

µTasker general / Re: Application using FAT Emulation

« on: May 02, 2017, 03:38:42 AM »

Mark, Here's a list of the ones that wouldn't compile for me:

TWR_K60N512
EMCRAFT_K61F150M
FRDM_K64F
TWR_K70F120M

they throw the following error messages into the output window:

Code: [Select]

Warning 1 warning C4138: '*/' found outside of comment c:\teensy\utaskerv1.4.11-kinetis-opensource\utasker\utfat\mass_storage.c 2129 1 uTaskerKinetis
Error 2 error C2059: syntax error : '/' c:\teensy\utaskerv1.4.11-kinetis-opensource\utasker\utfat\mass_storage.c 2129 1 uTaskerKinetis
Warning 3 warning C4723: potential divide by 0 c:\teensy\utaskerv1.4.11-kinetis-opensource\stack\dhcp.c 985 1 uTaskerKinetis

hope this helps,

Chris

4

µTasker general / Re: Application using FAT Emulation

« on: May 02, 2017, 03:21:07 AM »

Mark,

I'll try to go through them all again, and see if I can get you a list of the ones that aren't compiling.  :-)

If there is a crash after enabling Ethernet it is probably due to
    if ((PALR & 0x01000000) != 0) {                                      // {29}
        _EXCEPTION("Check that the own MAC address doesn't set the multicast bit!!");
    }
in the Ethernet initialisation.

That is exactly where it was throwing the error.  So, I'll delete the ini file, and see how that works for me.  :-)

Thanks for the help,

Chris

5

µTasker general / Re: Application using FAT Emulation

« on: May 01, 2017, 05:18:58 PM »

Mark,

I attempted to build the code for a different device (one that supports Ethernet), in fact, I tried all the devices I could see that supported Ethernet, and I was unable to get them to work. 

I ran into one of 2 problems, the first problem I encountered with about half of the devices, was that the code wouldn't build.  Some code down in the ethernet files wouldn't compile. 

The 2nd problem I encountered was with the other half of the devices, and in that use case, it would build fine, but when I ran it, it would throw an access violation, when the simulator first started. 

Unfortunately, I was busy this weekend, and didn't get a chance to go after either of the two problems.

It may be a moot point now, as my development board should be here sometime tomorrow, or wednesday, and I will be able to debug on the chip at that point.

Chris

6

utFAT / Re: Mountable version of SD_CARD.bin

« on: May 01, 2017, 05:08:46 PM »

Mark,

If it is possible to read and write sectors of the SD card it would be possible to perform utFAT directly on the card when the simulator runs.

Yes, I believe it is possible to read and write the sectors of the card directly using IoCtl. 

If via USB either a memory stick could be used, or an SD card in a USB reader. Otherwise maybe directly to the SD card in its reader (?)

When I was writing and testing my code, I was using a USB SD card reader, connected to a debian linux virtual machine, running on my Windows 7 desktop box.  I'm not sure how you would go about connecting directly to an SD Card reader, because I've never worked with them.  But, USB card readers seem to work fine.

At first glance I can't say that I understood much about what routines would be used though....or about how to get started on it.

Possibly the starting point is here (?)
https://msdn.microsoft.com/en-us/library/ff566970(v=vs.85).aspx

On Linux (where I was writing my code), the calls go through the generic SCSI driver, and to the device.  I'm not sure what layers are involved on Windows, but that link you posted definitely seems like the right place to start. 

I looked up one of the calls that I implemented (a ReadCapacity call), there, and it appears to be doing the exact same thing I was on Linux.  I believe, on windows, the DeviceIOControl function is the key to it.  On Linux, the function is called IoCtl, but they both take similar parameter lists, and I think they do the same thing.  Here's a link to the MSDN docs on the windows version:  https://msdn.microsoft.com/en-us/library/windows/desktop/aa363216(v=vs.85).aspx

The IoCtl function can be used to interact directly with the driver layer of a device, and it allows you to pass device specific commands to the device, and get back the results.  For mass storage type devices, I believe the underlying commands are just the SCSI commands that the device supports (at least this seemed to prove true on Linux, because that was what I used when writing my code).

I can post my code for you, if it would help ya.  It's written in Free Pascal, but it only wraps 2 of the function calls right now, one to read the device's capacity (i.e. total sectors, and sector size), and one to read a raw sector from the device.

it basically boils down to something like the following:

Code: [Select]

   // Open a file handle to the device
   fd := fpOpen('/dev/sdb1', O_RDOnly);  // here, /dev/sdb1 is the device Linux mapped to my SD Card reader

   // Send IoCtl codes to the device to perform the functions you want
   // this is actually a bit more involved when you add in appropriate error handling etc.
   fpIoCtl(fd, ...);  // The parameters here vary based on what command you want to send.  The first parameter is a
   fpIoCtl(fd, ...);  // a single byte code that represents the command, and the other parameters are for passing data
                           // in and out of the command.

   // Close the device when done
   fpClose(fd);


Here's a link to one of the documents I found, documenting the SCSI commands that can be sent via the IoCtl function:

http://www.seagate.com/staticfiles/support/disc/manuals/scsi/100293068a.pdf

Sorry it took so long to respond, My birthday was Saturday, and my family had all kinds of activities planned for me, so I wasn't able to get online much.  :-)

Hope this helps,

Chris

7

µTasker general / Re: Application using FAT Emulation

« on: April 27, 2017, 10:15:16 PM »

Oh, and I've been meaning to tell you, but I kept forgetting, I might be able to do some high speed USB testing for you at some point in the future.  I have an EE friend who is going to use a Teensy 3.6 for a project he is working on, and he and I are going to build a debug/test board for the teensy 3.6, and we are going to wire up a usb connector to the high speed interface, so once I have that in hand, I can probably run whatever tests you want me to.  :-)  I'll let ya know when I've got my hands on it.   

Ok, scratch that, we just finished figuring out how much it would cost us to build a development/debug rig for the teensy, and it's like $90 for each of us, so we decided to just buy the dev board you recommended (FRDM-K66F).  Got one ordered and on the way.  That board should still allow me to do some testing for you though, right? 

8

utFAT / Re: Mountable version of SD_CARD.bin

« on: April 27, 2017, 07:27:37 PM »

Mark,

Have you looked into the IOCtl interface in Windows? 

When I was researching low level access to my usb drive on the Raspberry Pi (Linux), I ended up using to the IOCtl api to send SCSI commands directly to the device, which allows me to read/write sectors.   

I know Windows also supports the IOCtl api, so theoretically, you should be able to do the same thing to gain access to SD Card via USB on windows, and either copy the raw sectors to an image file, and mount that via your code, or talk directly to an SD Card mounted via usb.

Chris

9

µTasker general / Re: Application using FAT Emulation

« on: April 27, 2017, 07:11:17 PM »

Mark,

I eventually stumbled on a forum post that led me down the UART path, using com0com, and I was able to connect to the simulator, and use the menu to format the sd card.  Sorry for not posting sooner, to save you the time invested in that last post.  :-)

Now that I have that set up, I am trying to get a file onto the simulated SD card, so that I can use it in my debugging tests, but I am not seeing any way to transfer the file to the simulated SD card via the menu.  Is this something that is supported?  I initially was thinking of using telnet for the menu, and ftp to get the file uploaded to it, but I understand why that isn't possible.  if I can't copy the file up using the menu, is there some other way to transfer the file to the simulated SD card?  If not, I might look into modifying your simulator to add a function to copy it up.

Oh, and I've been meaning to tell you, but I kept forgetting, I might be able to do some high speed USB testing for you at some point in the future.  I have an EE friend who is going to use a Teensy 3.6 for a project he is working on, and he and I are going to build a debug/test board for the teensy 3.6, and we are going to wire up a usb connector to the high speed interface, so once I have that in hand, I can probably run whatever tests you want me to.  :-)  I'll let ya know when I've got my hands on it.   

Thanks,

Chris

10

µTasker general / Re: Application using FAT Emulation

« on: April 27, 2017, 03:57:43 AM »

Mark,

Ok, I have spent the time since my last post, researching on the Pi, about getting low level access to the usb hard drive, and it is quite doable.  In fact, I've already written a set of helper functions that will allow me to serve up the capacity of the drive (i.e. Sector count and Sector size), and will also allow me to read raw blocks from the drive, so they can be returned to the Teensy.

Now that that is done, I was planning on moving over to the Teensy side, and continuing work on my code there to plug into your USB MSD layer. 

In the process, I figured I would start by writing my functions to emulate the low level calls the pi is going to make, by reading a disk image file stored on the SD Card, and returning blocks from it to your MSD code, to ensure that my functions are hooked into your code correctly, before moving on to write my interface to the Pi. 

I wanted to do this in the simulator, so that it would be easier to develop, and I'm having a couple issues with it.  I have read through a few tutorials, and see references to connecting to the simulator via telnet to access the menu, and be able to format the simulated sd card, but it doesn't appear that the simulator is publishing anything on the ip I set up.  I looked at my config.h file, and noticed that ETH_INTERFACE define isn't being defined for the teensy 3.6.  I tried defining this my self, but when I do, the project won't build, I get some errors in kinetis_enet.h, about PHY_ADDRESS being an undeclared identifier.

Given that background, I've got a couple questions for ya.  :-)

Is it not possible to connect to the simulator via telnet while using the teensy 3.6? 

If it is possible, what all do I need to configure to make it work? 

If it isn't possible, how else can I connect to the simulator to get access to the menu interface?

Thanks for any help you can give me,

Chris

11

µTasker general / Re: Application using FAT Emulation

« on: April 25, 2017, 01:06:10 AM »

Mark,

If you can get low level access to the SD card via the Pi you will "effectively" be connected directly to the SD card. This means that you can use USB-MSD directly - but rather than reading an SD card connected via SPI you read the same SD card via a Pi interface. This would remove any need for emulation - making the code much easier and removing the need to build up any tables of the SD card content in order for the emulation to be able to operate.

In fact I think that you need a method to read low level data from the files anyway since any emulation would still need to be able to request the SD card content to be able to return any file content. Since you must have this you can just as easily use it to also read the FAT content - no emulation complications at all.....

Therefore I think that what you actually need is a Teensy > Pi - SD card bridge which allows you to read a block of data from an SD card sector at the SD card connected to the Pi. This is called instead of a local SD card sector read (vai SPI) and you are already done.

Great minds think alike lol.

This is basically where I landed as well.  I am planning on taking the calls coming into the uTasker MSD handling code (so basically raw sector read requests), and proxying those over to the Pi to be executed against the USB hard drive, in some code that I write.  I was leaning towards a custom byte-wide GPIO interface to communicate between the Teensy and the Pi. 

I've spent most of today, analyzing your code, and identifying where to plug in my calls to the Pi, and I believe I have a good handle on it.  So far, I've started out by emulating what you did with FAT_EMULATION, by providing a new define, and some new functions for reading sectors and partial sectors from the pi.  Oh, and I also copied your Prepare function, and made my own, as I think this is going to be needed when all is said and done.  I've also set it up, so that it basically registers itself as an emulated drive in your drive info structs, similar to what you did for the fat emulation.  Off hand, is there anything you can think of that I'm missing?

I also have to research whether Linux will let me access a mounted USB drive in that fashion (i.e. read raw blocks from it), and if it will, I should be all set I think.  :-)

Oh, and one more thing, do you have any suggestions as to how I could emulate the host calling in to read the MSD while in the simulator?  It would make this a lot easier to develop if I could do that.  Maybe I could somehow grab the calls being sent from Windows when it reads a MSD and then set up a script to send that binary data to the simulator or something?

Thanks again for all your help on this,

Chris

12

µTasker general / Re: Application using FAT Emulation

« on: April 24, 2017, 07:37:31 PM »

The emulated FAT is flat in structure - its main idea is to allow files that are not really files (eg. dynamically generated or formatted data) to be presented to the USB-MSD host so that it can read it as if it were a file.

In order to do this each virtual file requires a bit of information so that its details can be returned and its content generated when requested. At some point there will not be enough memory to do this for a large number of files.

Yeah, the more I study the code, the more I was coming to this conclusion myself.  It's great for the purpose you intended it for, but I'm thinking it may not be the right fit for my use.  Which is fine, it just means I'll have to write a bit more code.  :-)

In your case, when you have an SD card attached, I don't see exactly why you need to emulate its content when it can be so large. Why doesn't the USB-MSD directly access it?

In my case, the SD card isn't really attached to the Teensy.  I've just been testing with a SD card in the Teensy, to get the USB MSD side of things ironed out, and working. 

The actual media content is stored on a USB hard drive, that is connected to my Raspberry Pi, it needs to be this way, to satisfy other requirements of my project (i.e. I am serving the same media content up via Plex media server, to my kids and their devices, directly from the Raspberry Pi). 

So, what I am aiming to do with the Teensy, is build a sort of media bridge, that can be connected to my car stereo on one end (via USB mass storage device, as that is the only input I have for the stereo, and I want to retain my stereo controls over the media, i.e. steering wheel controls to advance to the next song etc), and then on the other end, I was intending to use GPIO from the Teensy to the Raspberry Pi, to access the same media content that is already available over there, from the USB hard drive. 

At this point, I'm leaning towards modifying your code, and hooking into the calls between the USB MSD layer, and the FAT layer, and conveying those across the GPIO, to the Pi, where I can write a separate FAT emulation layer, to republish the hard drive's contents.  Or, if it's possible, maybe I can get low-level access to the drive, and just proxy the MSD requests back and forth.  I've got to do some more research on the Pi side of things, and see what Linux will let me do with the attached drive.  Either way, I'm pretty sure I'm going to do the FAT emulation on the Pi, because it has 1 GB of ram, and I have a bit more breathing room over there.  :-)

As usual, thanks for the great info,

Chris

13

µTasker general / Re: Application using FAT Emulation

« on: April 23, 2017, 05:13:36 AM »

ok, I reread the emulated FAT example, and came across the section stating that you can remove the ROOT_DIR_SECTORS define, to stop the code from creating one of the in memory arrays (root_files I think). 

When I try this though, it appears that not all of the code that should be wrapped with that define, is, because I get a couple errors.  Specifically, the following line:

Code: [Select]

        unsigned long ulFAT_cluster = (ROOT_DIR_SECTORS + 2);

found at line 7339 of mass_storage.c, and this line:

Code: [Select]

                                    ulFAT_cluster -= (ROOT_DIR_SECTORS + 2);

found at line 7381 of the same file.

both of these lines are in the function fnGenerateFAT.

not sure what they should be replaced with, if the define is turned off.

I also tried setting it to 0, which I didn't think was correct (the example says to remove it, not make it zero).  That leads to other errors though.

Chris

14

µTasker general / Re: Application using FAT Emulation

« on: April 23, 2017, 01:41:16 AM »

Mark,

Ok, I just finished debugging a bit more, and I think I've learned a few things, and I want to validate them with you.

1.  It appears that your emulated FAT is setup to publish a single directory, with MAXIMUM_DATA_FILES as the count of files in the directory.  Am I right that there is no support for sub directories?

This isn't a major deal if it doesn't support subdirectories, but it would be nice to represent the file structure as it is on the usb disk.  If I can't publish the real file structure, I can build some kind of file map to map from a filename in the MSD directory to an actual path on the Pi I guess.

2.  It also appears that for every file being represented in the emulated directory, your code in mass_storage.c is keeping a struct of size 28 bytes, in the dataFileList array, and another struct in the root_files array, of size 32 bytes.

I'm worried about these arrays growing too large, and consuming all of the teensy's memory.  I'm currently at about 6600 files across my entire disk, and that puts the memory requirements for the first array at 184,000 bytes, and the second array at 211,200 bytes.   

The Teensy 3.6 only has 256,000 bytes of RAM, obviously, these 2 arrays alone would blow memory.

It appears that these arrays are being used to calculate the sector/cluster information to return thru the MSD interface.  I'm thinking I may need to store this information on the local SD card instead of in RAM, for the amount of files I'm dealing with.  What do you think?

Am I on the right track here?  Or am I thinking about this wrong?  I have not actually located your memory allocation for these arrays, are they actually in ram?  Or are they in flash, like you were saying before?  If they're in flash, it might actually be better for me, as the Teensy 3.6 has 1 MB of flash.

It's been quite a few years since I've worked in C/C++, so I'm still getting used to the different memory allocations and such. (I've been working in Delphi Object Pascal for the past 20 years lol)

Thanks,

Chris

15

µTasker general / Re: Application using FAT Emulation

« on: April 23, 2017, 12:12:57 AM »

I'm also looking into what it might take to support the NTFS file system

So, it appears that my stereo can't handle NTFS drives either.  So, it's either go with FAT32, or exFAT.  It can handle both of those.  So I'm gonna table this for now, and maybe later, I'll look at implementing exFAT within your framework.  Back to trying to define the file system dynamically.  :-)