Mass storage emulation raspberry pi

If you use the Raspberry Pi Zero, it can emulate storage to another computer as if it were a USB stick. Is this what you are after?

Clem

Yes I believe so. Does it need additional boards? Or is it natively able to do this? After it receives a file I would like the pi to then print it.  So it would need to be booted into the OS while it is acting as a USB drive is that possible as well?

The CPU on the raspberry pi family has the ability to work as an "USB Device". The hardware on B, B+ and Pi3 however makes this impossible unless you probe signals internal to the board. The A, A+ and Zero however bring out the right signals on the USB connector.

There are however two problems with this approach. First there is the problem that this would use the ONLY usb peripheral on the chip. How are you going to connect to the printer? Through USB? No. Through Ethernet? Just need to add an USB-Ethernet adapter... Ah...shucks!

Secondly, there is no (open source) software that I know of that makes the pi behave as an USB device.

There now is open source software  (http://pi.gbaman.info/?p=699 )  that allows the pi to behave as an USB-device. As a mass-storage device everybody thinks that you would simple export the whole SD card. I don' think this is a good idea: both OSes (the one on the pi and the one on the "third party device") would cache disk-blocks of the storage. This would create big problems. So the best would be to have an image on the SD card that is exported as the USB-storage device. Then on the pi you would make some software to "peek" into the image and extract the report for printing.

Possibly you might be able to use an ESP8266 board to get connectivity on the pi with the USB port already taken?

My thought was to use the hardware UART on the pins as a USB if needed with a converter to 5V from 3.3V on Raspberry Pi pins. There are many to be found. As to programming, a CRON task could wake up and look in the appropriate directory and perform the operations needed to print the text.

Clem

I don't think that will work. The "third party device" expects to find an USB DRIVE, not an USB serial port.

Yes, in theory that solution would be possible. However the term "third party device" usually implies: "so we can't change its hardware or software".

For clarity, the previous post is to set up a USB for printing text. The OTG is used as a storage device.

C

Would I still be able to program the pi? the printer can use a ttl pin I was looking at this one:

https://www.adafruit.com/products/597?gclid=Cj0KEQjw5Ie8BRCJ9fHlr_bH24cBEiQAkoDQcWk-G6TSWUQmB1ZmDQsSc9VzhxNlfUwzMBKZW4Io…

Here is what you can do:

1. Buy Raspberry Pi Zero. Microcenter is good place if you are near one, Otherwise find one online.

2. Install software like https://gist.github.com/gbaman/50b6cca61dd1c3f88f41

3. Create a cron task to run python to read file(text based) and print to the thermal printer. It could run every few minutes. It would need to know the name(s) of the files being created. If it works, cleanup the files by deleting them.

Clem

Here is what you can do:

1. Buy Raspberry Pi Zero. Microcenter is good place if you are near one, Otherwise find one online.

2. Install software like https://gist.github.com/gbaman/50b6cca61dd1c3f88f41

3. Create a cron task to run python to read file(text based) and print to the thermal printer. It could run every few minutes. It would need to know the name(s) of the files being created. If it works, cleanup the files by deleting them.

Clem

Tutorial at https://learn.adafruit.com/turning-your-raspberry-pi-zero-into-a-usb-gadget/other-modules

Clem

Yes! That printer would work. It has a serial interface, and with a bit of configuration, you can disable the getty and console output there.

You can mount the backing store as a loop device, but I would recommend mounting it read-only, thus preventing the plan of removing or renaming (I always prefer renaming: should the print job fail for some reason you can re-do the job by manually pushing the file back into the input queue).

Yes, having printed the files it is a good idea to mark them in the filesystem as having been handled. However... The pi will present a file on its SD card as the whole disk to the "third  party device". That third party device is thinking it has total control of the bytes on that device. Changing them "behind his back" is going to lead to trouble.

Also even the read-only plan is a bit tricky: Writing a new text file involves writing the data onto the device but also writing records indicating "there IS a file".

It is entirely valid for the "third party device" to first write the allocation table and directory: "block xxyyzz now contains data for a file called name.txt" and only later write the block xxyyzz with the data for the file. If your cronjob would run between those two moments, you would get garbage... The device could also do things the other way around, but that is not guaranteed: Usually there is a buffer cache, and the changes are written to the buffer cache. Later the system will see those changed blocks and write them to the backing store, in this case the pi and the file on the SD card. That will happen "randomly": you cannot count on this happening in a certain order.

These are very good points I'll have to monitor the file name creating and the write operation time.

I will probably just run a cron job every second or so.  When it sees a file name wait 4 seconds for the write to complete then start printing. (actual timing to be determined.)

I should be able to just do a purge of all the files at the end of the day when no one is using the equipment anymore the text files take up very little space so i can hold on to a day's worth I'm sure.  Then maybe I can reboot the device and delete the files on startup.

Linux normally caches stuff for disks up to 30 seconds before starting to write to the device. I think this is shorter for external/removable devices. If your third party device works the same way, that 4 seconds may indeed be enough.

This weekend I started logging my electricity meter data into a database. It's running on a pi-zero. Extrapolating from a days worth of data, 10Gb of my SD card can hold 20 years of ALL the data that the meter produces!

So.. In your case, I wouldn't be in  a hurry to remove the files. Just note somewhere which ones have already been handled.