I'm trying to integrate FATFS file system on Micron NAND SPI FLASH. I'm using the SPI peripheral of the STM32L486RG as interface.
I have developped a low level driver through which I'm able to read, write and erase data from different locations in the NAND memory.
I have then integrated my Low-level driver APIs under diskio.c file in order they could be used by fatfs APIs.
I have successfully formatted the memory through f_mkfs (I'm getting FR_OK with both f_mkfs and f_open APIs and when debugging the fs object is containing the FAT signature).
However, when I try to write buffer into the file that I have created using f_oprn , I get "FR_INT_ERR" .
I have debugged my code step by step and I found that my get_fat function returns (1) as result which means that an internal error has occurred .
Any idea what could be the issue ?
I guess you need to erase the memory's sector you mean to write in - even though you write per pages and not per entire sector - and that's why using FatFs becomes tricky in NAND Flash.
Since your purpose is to bound the logical drive to the entire physical drive, you need to use the option ( FM_SDF | FM_ANY ) for the parameter opt into the f_mkfs function to format the memory.
Related
We are working on project where we need to do some image processing on FPGA. For that purpose we are using ZedBoard with linaro (Ubuntu Version) running on it.
What we have already done is we have stored the image in binary form pixel by pixel in DDR using python script on Processing System of Zedboard.
Now our task is to read the content of DDR memory, process it and send back the processed output to DDR Memory again. We are using vivado xilinx tool for FPGA part. We tried to use AXI-DMA with AXI-Interconnect to read and write data from DDR.
My question is, Do We need to use SDK and some sort of C coding to read and write DDR Memory on Programmable Logic side? As we want to make our module start reading the data from DDR with a control signal and then start actual processing of Image data. Once we read specific block of data, process it and store the result back to DDR memory on the fly. We are not sure which IP Block do we need in our block design for vivado. Also do we need Block Ram Memory at the end before sending the date to DDR.
Can anyone who already done this sort of project or have any knowledge ? Any help from your side will be appreciated !
Thanks
The zynq FPGA provide an AMBA AXI interconnect for that purpose.
This is the interconnect on the right.
I am using two motes. one has unicast sender program on it and one has uni-cast receiver program on it. Instead of connecting receiving mote with PC, I want to use batteries for mote power source and I want to save outputs of both motes on its mote memory. How can I save output(printf command outputs) of each mote in mote memory and retrieve later on after completion of experiments. Is there any method(built-in functions, commands or code snippet) available for this
P.S. I am using zolertia z1 motes
The straightforward way is to use the xmem interface. The function prototypes are declared in file xmem.h:
https://github.com/contiki-os/contiki/blob/master/core/dev/xmem.h
For Z1 there's a platform-specific implementation of xmem in platform's directory.
If you have never worked with flash memory before, note that the "rewrite" operation is typically not supported by the hardware. You need to erase a whole sector of the flash before you can write anything in that sector. Therefore, the typical usage pattern for dumping sensor data or logs is "write only at the end, never modify". When the current sector is full, erase the next one and write there, and so until the whole flash is full.
Contiki also the Coffee filesystem, which a higher level interface if you need one.
I'm in an assembly language course focusing on x86 Pentium processors, and am working on a Linux system. I understand that programs get loaded into memory and that you can perform operations directly within the registers but I'm not sure you can avoid creating a data segment altogether.
A yes or no, followed by a brief explanation as to why would be great.
It is not required. A data segment is simply a block of memory allocated for data and thus can be written to and read from. Code segments are read only. If you try to write to a code segment the hardware will generate an interrupt. However, assembly codes can be fed any address in memory, and if protected mode is disabled, then the hardware won't generate an interrupt.
As an example, the boot sector loads into a very restricted space on launch, and it is quite common (because space is so restricted) to place variables among the code bytes. Once I even wrote a boot sector that adjusted its own byte-code to accommodate differences in booting from different disks. So this is a case of code using code addresses as variables.
However, while you definitely can avoid creating a data segment, 99.99% of the time you do separate out a data segment.
You may also want to read up on protected mode to understand this better.
I know the definition
A character device driver is one that transfers data directly to and
from a user process.
But can some one explain this in a more intutive way? First of all there should be a device. What is the device in the above definition?
If you say it can be a file, then can we say file reading and putting the data on the console an example of character driver?
What exactly is a character driver ?
Device driver is Integration of two pieces of code. First piece of code is how the driver services are made available to the application.(user space)
Second piece of code is the hardware access part. Instructions to carry out physical operation on target hardware.
Based on first piece of code we have three models. Character model, Block model, Network model. we can say character driver, block driver, Network driver.
First piece of code is totally kernel specific. what Interface kernel provides to access the hardware. Implementing first piece of code on Linux,windows on other os may be different. we should know what inteface it offers to provide services to application .
In linux From user perspective everyhardware is a file. Why means at boot time all the hardware devices present are detected and added to device tree. Based on hardware corresponding device node gets created automatically in /dev directory. As mentioned above if it is char device---> character device node. Block device---> block device node gets created.
To write character driver. we create a device node in /dev directory , assigning a major no and application usually performing read/write operations on device file.
We implement driver operations and assign driver operations to file structure (fops) pointer.
Device file request received by VFS. VFS turns device file operations into your corresponding driver operations.
APP--->dev file----> fops--->driver---->device.
dev file ---> interface between application and driver.
driver interacts ----> device
You can refer http://lwn.net/images/pdf/LDD3/ch03.pdf.
According to my knowledge,
The device can be your own private structure or system object.
The driver is said to be a char driver because the data read and write is in byte range
If you are writing your char driver you can use char buffer or kfifo to read and write into the device.
you can create your device file in procfs,
and can read/write as u wish and this is accomplished though your char driver
I hope that my answer helps you
Think of device driver as abstraction of various hardware that the kernel has to deal with. The device driver knows the details of hardware it is communicating with. So the kernel reads and writes data as it would do with any other filesystem file.
If you can make some reading on Device Drivers, you will find out that the system calls of fopen, read, write, fclose are all mapped to driver specific function calls.
There is 2 types of drivers: block driver and char driver. The difference is that first one handles with blocks of data and second one receives/transmits data byte by byte.
Ok, for example you have a device and you want to talk to it, how to do it?
You have a driver, simply a number of functions, that will be called by the kernel at the right time. Driver itself can't do anything (neither send data, nor receive data), you need to say your driver what it should do. As you should know so far, you can't discretely communicate with a kernel from user space. There are some tricks that you can use. What you are talking about named as device file. Your driver generates a file for your device and when you write something to this file from user space, driver is notified that it is some information to handle, it takes this information and provide this data to write function, that will transmit data to your device(in this case byte by bite).
Hopefully, this what you wanted to know.
I'm using a rabbit microcontroller. It uses the Dyanimc C language.
How can I read from a file in my PC and manipulate it or print it to the screen?
C or C++ methods are not working here.
If you read the Rabbit manual then you can see that the file system function calls from within the Dynamic-C language refer to files that are stored on local flash devices that are connected to the processor chip.
FAT version 1.02 supports SPI-based serial flash devices. FAT versions 2.01 and 2.05 also support SPIbased
serial flash devices and require Dynamic C 9.01 or later. FAT version 2.05 introduces support for
NAND flash devices. FAT version 2.10 extends μC/OS-II compatibility to make the FAT API reentrant
from multiple tasks. FAT version 2.13 adds support for SD cards and requires Dynamic C 10.21 or later. In
all versions of the FAT, a battery-backed write-back cache reduces wear on the flash device and a roundrobin
cluster assignment helps spread the wear over its surface.
There is no way that the Rabbit can read or access a file on your pc directly. You must first provide a transfer mechanism to pass the file over from the pc to the flash storage device that you have designed into your hardware platform and use the file write function calls to store this data into the Rabbit file system. This would normally be by transferring the data over a serial link using some protocol of your choice or invention.
Next you seem to want to display some data on the screen. I assume that by this you mean the pc screen (although you could have a local screen connected to the Rabbit) Again the Rabbit has no direct method of accessing the screen. You will have to write a pc application that takes data messages from the Rabbit, possibly over the serial interface (other interfaces may be available), and interpret these as instructions to display some text or formatting on the pc screen.