I've just read that SD cards all have some DRM code that will prevent reads or writes of "protected content".
As my code will sometimes use SD cards for storage, what is the practical consequence of the DRM? What steps (if any) do I need to take to avoid writing out files that might not be read back?
It is not so simple. DRM functions use separate storage from non-protected area. There are special SD commands for DRM and in addition, there is "secret" part of SD Card spec. Buy membership for $1000 at sdcard.org and get the info :) In short - DRM features can be used mostly by special hardware (microcontroller connected to SD slot), not simple PC software.
Related
I am looking to implement some kind of transmission protocol in C, to use on a custom hardware. I have the ability to send and receive through RF, but I need to rely in some protocol that validates the package integrity sent/received, so I though it would be a good idea to implement some kind of UDP library.
Of course, if there is any way that I can modify the existing implementations for UDP or TCP so it works over my RF device it would be of great help. The only thing that I think it needs to be changed is the way that a single bit is sent, if I could change that on the UDP library (sys/socket.h) it would save me a lot of time.
UDP does not exist in standard C99 or C11.
It is generally part of some Internet Protocol layer. These are very complex software (as soon as you want some performance).
I would suggest to use some existing operating system kernel (e.g. Linux) and to write a network driver (e.g. for the Linux kernel) for your device. Life is too short to write a competitive UDP like layer (that could take you dozens of years).
addenda
Apparently, the mention of UDP in the question is confusing. Per your comments (which should go inside the question) you just want some serial protocol on a small 8 bits PIC 18F4550 microcontroller (32Kbytes ROM + 2Kbytes RAM). Without knowing additional constraints, I would suggest a tiny "textual" like protocol (e.g. in ASCII lines, no more than 128 bytes per line, \n terminated ....) and I would put some simple hex checksum inside it. In the 1980s Hayes modems had such things.
What you should then do is define and document the protocol first (e.g. as BNF syntax of the message lines), then implement it (probably with buffering and finite state automaton techniques). You might invent some message format like e.g. DOFOO?123,456%BE53 followed by a newline, meaning do the command DOFOO with arguments 123 then 456 and hex checksum BE53
So according to 2 books I have on device drivers(for Linux), notable the O'REILLY version("Linux Device Drivers(3rd edition") there are 3 types of device drivers:
Character drivers that read/write on byte of data at a time.
Block drivers which read and write blocks of data(file storage devices).
Network drivers that send and receive frames(for ethernet and wifi these are 48 bit chunks of data).
So where do video and sound drivers fit in? I ask because AFAIK your screen has a bus that sends frames from the motherboard to the monitor and the image on your screen is a memory map(a square array) that is refreshed at a certain number of frames/sec. The sound driver also sends 16-bit(2 byte) frames to the DAC at a sampling rate of 44.1 KHz. Are these character drivers? I would think they would be in a similar category as network drivers as network interfaces, screens, speakers, microphones, and webcams are all devices that read and write frames(an array of bytes).
A more accurate way of describing these types of devices would be to say that:
Character devices deal with streams of data. You can write data to them and read data from them, but you can't skip around. Reading data from them may block if nothing is available. Common character devices include terminals, serial ports, and special devices like /dev/null and /dev/random. This need not be one byte at a time, though: many devices return data as larger frames. (For instance, Linux input devices under /dev/input return data in 32-byte frames, each one representing one event.)
Block devices deal with a fixed block of data. You can read and write data to any location in them you want, as well as mapping them to memory using mmap(). They are often used to represent storage devices (like disks), but can also be used to represent other, more unusual things.
Network devices are a special case. They are more or less exclusively used for devices that actually interface with a network (e.g, Ethernet NICs, wireless network hardware, cell modems, etc). They don't show up in /dev at all.
Both character and block devices can implement special operations that don't fit into the normal framework using ioctl() (e.g, changing the baud rate of a serial port, ejecting a CD, etc), so, to some degree, the decision of which one to use can be somewhat arbitrary. Nevertheless, for the types of devices you're describing:
Audio devices are typically represented as character devices.
The older OSS Linux sound system represented a sound device as /dev/dsp: reading data from it would read PCM data representing microphone input, and writing PCM data to it would play that through the sound card. The more modern ALSA sound system uses a more complex set of devices and formats, but the concept is the same.
Video devices are an unusual situation.
Some simple "framebuffer" video drivers are implemented as a block device such as /dev/fb0. This device represents the image on screen — a 1024x768 screen using 32-bit color would be represented by a 3 MB buffer, for instance — and writing to it changes that image. It's most commonly used by mapping it into memory.
Most modern video devices aren't that simple, though. Many of them are implemented partially as a kernel driver and partially as a X11 device driver which may directly map and write to the video hardware. They may sometimes include an extra character or block device (e.g, some Nvidia graphics cards use a character device /dev/nvidia), but the details of what data is read from or written to this device are largely proprietary.
They are character drivers.
gfx http://www.x.org/wiki/Development/Documentation/HowVideoCardsWork/
audio http://www.alsa-project.org/~tiwai/writing-an-alsa-driver/
My requirement is to store data in kernel..Data are incoming packets from networks..which may be different in size and have to store for example 250ms duration..and there should be 5 such candidate for which kernel level memory management is required..since packets are coming very fast..my approach is to allocate a large memory say 2mb memory for each such candidate..bez kmalloc and kfree have timing overhead..any help regarding that?
sk_buffs are a generic answer that is network related or as Mike points out a kernel memory cache is even more generic answer to your question. However, I believe you may have put a solution before the question.
The bottle neck with LTE/HSDPA/GSM is the driver and how you get data from the device to the CPU. This depends on how hardware is connected. Are you using SPI, UART, SDHC, USB, PCI?
Also, at least with HSDPA, you need a ppp connection. Isn't LTE the same? Ethernet is not the model to use in this case. Typically you need to emulate a high speed tty. Also, n_gsm supplies a network interface; I am not entirely familiar with this interface, but I suspect that this is to support LTE. This is not well documented. Also, there is the Option USB serial driver, if this is the hardware you are using. An example patch using n_gsm to handle LTE; I believe this patch was reworked into the current n_gsm network support.
You need to tell us more about your hardware.
As already noted within the comments:
struct sk_buff, and it is created for that exact specific purpose
see for example http://www.linuxfoundation.org/collaborate/workgroups/networking/skbuff
So we're trying to store bytes (from an A/D converter) of data into a SanDisk 1Gb microSD card from a LPC1769 microcontroller board using the on-board SPI protocol. I know how all that stuff works, but I have no idea how to start working with the microSD card--I've seen various references to CMD0 and what not, but I don't know where to find this library or how to properly incorporate it into the C compiler for the board.
All I need is to figure out how to start the connection properly and then how to read and write data into the card at designated blocks.
void write(int data, int block)
int read(int block) << if there is a way to do this simply with a library of pre-defined microSD functions, that would be AWESOME
FatFS is a simple FAT filesystem that has been ported to many microcontrollers (perhaps it's already available for yours) that also provides the low level writing to the SD card (and you can use that as a reference for your working.. It lets you write actual files to the SD card that you can then put on a computer and read/write. This ends up working very nicely.
http://bikealive.nl/fatfs.html
There is also a nice App Note from TI that has some basic API to do this:
http://www.ti.com/general/docs/lit/getliterature.tsp?literatureNumber=slaa281b&fileType=pdf
Although it's for the MSP430, it can clearly show you what kind of register accesses you need to write the bytes yourself and you can implement the equivalent thing.
Finally, Olimex have boards with similar microcontrollers and SD cards, and you can see what they do:
https://www.olimex.com/Products/ARM/NXP/LPC1766-STK/
I found more information specifically for your microcontroller (though the suggestions above work well as well):
Two app notes from NXP on doing what you're asking for:
AN10916 - "FAT library EFSL and FatFs port on NXP LPC1700"
AN11070 - "Accessing SDC/MMC card using SPI/SSP on LPC1700".
With this you should be all set.
I have been playing with creating sounds using mathematical wave functions in C. The next step in my project is getting user input from a MIDI keyboard controller in order to modulate the waves to different pitches.
My first notion was that this would be relatively simple and that Linux, being Linux, would allow me to read the raw data stream from my device like I would any other file.
However, research overwhelmingly advises that I write a device driver for the MIDI controller. The general idea is that even though the device file may be present, the kernel will not know what system calls to execute when my application calls functions like read() and write().
Despite these warnings, I did an experiment. I plugged in the MIDI controller and cat'ed the "/dev/midi1" device file. A steady stream of null characters appeared, and when I pressed a key on the MIDI controller several bytes appeared corresponding to the expected Message Chunks that a MIDI device should output. MIDI Protocol Info
So my questions are:
Why does the cat'ed stream behave this way?
Does this mean that there is a plug and play device driver already installed on my system?
Should I still go ahead and write a device driver, or can I get away with reading it like a file?
Thank you in advanced for sharing your wisdom in these areas.
Why does the cat'ed stream behave this way?
Because that is presumably the raw MIDI data that is being received by the controller. The null bytes are probably some sort of sync tick.
Does this mean that there is a plug and play device driver already installed on my system?
Yes.
However, research overwhelmingly advises that I write a device driver for the MIDI controller. The general idea is that even though the device file may be present, the kernel will not know what system calls to execute when my application calls functions like read() and write().
<...>
Should I still go ahead and write a device driver, or can I get away with reading it like a file?
I'm not sure what you're reading or how you're coming to this conclusion, but it's wrong. :) You've already got a perfectly good driver installed for your MIDI controller -- go ahead and use it!
Are you sure you are reading NUL bytes? And not 0xf8 bytes? Because 0xf8 is the MIDI time tick status and is usually sent periodically to keep the instruments in sync. Try reading the device using od:
od -vtx1 /dev/midi1
If you're seeing a bunch of 0xf8, it's okay. If you don't need the tempo information sent by your MIDI controller, either disable it on your controller or ignore those 0xf8 status bytes.
Also, for MIDI, keep in mind that the current MIDI status is usually sent once (to save on bytes) and then the payload bytes follow for as long as needed. For example, the pitch bend status is byte 0xeK (where K is the channel number, i.e. 0 to 15) and its payload is 7 bits of the least significant byte followed by 7 bits of the most significant bytes. Thus, maybe you got a weird controller and you're seeing only repeated payloads of some status, but any controller that's not stupid won't repeat what it doesn't need to.
Now for the driver: have a look at dmesg when you plug in your MIDI controller. Now if your OSS /dev/midi1 appears when you plug in your device (udev is doing this job), and dmesg doesn't shoot any error, you don't need anything else. The MIDI protocol is yet-another-serial-protocol that has a fixed baudrate and transmits/receives bytes. There's nothing complicated about that... just read from or write to the device and you're done.
The only issue is that queuing at some place could result in bad audio latency (if you're using the MIDI commands to control live audio, which I believe is what you're doing). It seems like those devices are mostly made for system exclusive messages, that is, for example, downloading some patch/preset for a synthesizer online and uploading it to the device using MIDI. Latency doesn't really matter in this situation.
Also have a look at the ALSA way of playing with MIDI on Linux.
If you are not developing a new MIDI controller hardware, you shouldn't worry about writing a driver for it. It's the user's concern installing their hardware, and the vendor's obligation to supply the drivers.
Under Linux, you just read the file. Now to interpret and make useful things with the data.