 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : Serial Flash chips for newbies
| Author | Message | ||||
lew247 Guru  Joined: 23/12/2015 Location: United KingdomPosts: 1702 |
Can Anyone help with the following please? I know nothing about serial flash at the moment! I'm planning on using the Winbond 25064fVSIG serial flash (64MB flash) that's on the back of my TFT display and I'm using an E100 ver 1B board so it should work perfectly I've read the DATASHEET for the serial flash chip, but for someone like me who knows nothing about them it might as well be written in swahili or any other language I don't know. Can anyone explain to me in simple English that someone who knows nothing about serial flash chips how to do the following I'm "Assuming" by reading Matherp's posts about serial flash memory that it's arranged in "Pages"??? 1 know how many "pages" I have available 2 how many "pages" does loading an 800x480 24-bit image use? 3 Can I still use data logging on the chip while using the chip to store the picture? 4 I've had a look at the data logging page noted in Peter's post HERE , but this post doesn't say if you can still use data logging while using it for storing/reading the picture? 5 how do "pages" actually work? how do you know how much you've used or how many "pages" you've used? If I wanted to store, read and update some data how would I go about it? an example I want to store things such as rainfall daily then each day move it into another location add it up so I can then read and display, weekly, monthly and yearly rainfall Air pressure so I can compare it to the pressure at 6am and see if the pressure is falling or raising and compare it over a week? and other things like that Sorry for so many questions, but I'm trying to get my head round this and the only way I can learn is "by doing" and seeing how it works once its explained to me. |
||||
| Warpspeed Guru Joined: 09/08/2007 Location: AustraliaPosts: 4406 |
In plain English, first you need to understand that an image on a screen consists of in this case, 800 x 480 pixels, and each pixel is made up of separate red, green, and blue components each of which requires eight bits to specify the brightness. These eight brightness bits (for each colour) need to be stored at one video memory address. Each pixel then requires three video ram addresses. For data logging only simple raw data is usually stored in ram, and software then has to be written to convert that data into whatever type of image you wish to display it as. Could be a simple graph, or histogram, or something vastly more complicated. Raw data first has to be converted into an image that is then used to modify all the individual 1.15 Meg of pixels in the video ram, which may be a fairly slow business. The amount of video ram storage for one complete displayed image is 800 x 480 x 3 or 1.152 Meg of address space, each individual address containing eight bits of brightness data. Its usual to store more than one complete image in different areas of video ram and switch between different images. The idea is that one complete and unchanging final image is displayed on the screen, while another alternate image is slowly formed and built up by software, progressively bit by bit. For data logging only simple raw data is usually stored, and software then has to be written to convert that data into whatever type of image you wish to display it as. Could be a simple graph, or histogram, digital readout, or something vastly more complicated. Raw data first has to be converted into an image that is then used to modify all the individual 1.15 Meg of pixels and brightness data into the video ram, which may be a fairly slow business. When the construction of the second image is complete, that is displayed as a whole new complete image, and the first original image can then be modified, erased, overwritten or whatever by software into some new form. When that process is completed, it is displayed as a finished next image. So there are two things going on here simultaneously. Two or more images are shown alternately on the screen, and while one is being displayed the other is being modified (hidden from view) so you don't see all the garbage that is going on while some or all of the 1.152 Meg of ram is being progressively overwritten bit by bit by the main program. For data logging only raw data is usually stored, and software then has to be written to convert that data into whatever type of image you wish to display it as. Could be a simple graph, or histogram, or something vastly more complicated. Raw data first has to be converted into an image that is then used to modify all the individual 1.15 Meg of pixels in the video ram, which may be a fairly slow business. When that task is completed, the final result of the fully modified video ram is displayed as a finished work. For scrolling, animation, or moving displays, there will be at least two stored images. One is being modified while the other is being displayed, and what you see is an alternate switching back and forth between the two stored completed images. The serial video ram is split up into blocks and pages for convenience, but those have nothing directly to do with the size of the final displayed image, or how many images are stored. Because three ram locations are required for each pixel, you will probably find that the the stored image will not be a neat fit into the block and page boundaries defined for the video ram. That is not a problem, just an inconvenience. Cheers, Tony. |
||||
| lew247 Guru Joined: 23/12/2015 Location: United KingdomPosts: 1702 |
Thanks Warpspeed but I actually understand about the image and how it's comprised it's the flash ram I don't understand |
||||
| Warpspeed Guru Joined: 09/08/2007 Location: AustraliaPosts: 4406 |
The data sheet explains everything. What you feed into it serially always begins with an instruction. What follows immediately after could be another instruction or data block of varying length. Cheers, Tony. |
||||
Grogster Admin Group  Joined: 31/12/2012 Location: New ZealandPosts: 9749 |
Hi Lew.  #1 - The datasheet tells you how many pages you have in total, and how many bytes there are per page. There is NO way to tell how many you have used, and how many are left, unless YOU keep track of that in your program. That is not difficult to do with small RAM chips, but gets much harder with the likes of the one you are talking about, as there are 32,000 or so pages!!!!  #2 - Pass.... #3 - Absolutely. You just need to know where the picture data is being stored, and use addresses outside of that range. #4 - You will be able to, BUT you won't be able to load/save pictures at the same time as logging stuff, as the chip can only do one thing at a time. Generally, that should not prove to be a problem if you use a simple flag to tell the system if it is using the chip for something somewhere else. #5 - Pages exist so that the memory can 'Page-write' to the memory. This involves writing a preset number of bytes to pre-defined areas of the memory. It makes memory management easier. If you have a memory with 64-byte pages, you can write up to 64-bytes in ONE I2C/SPI instruction if you want, instead of writing 64 separate I2C/SPI instructions - one for each byte. Just don't cross the page boundary as part of a write.  As far as keeping track of what is available as blank pages, used pages, or partly used pages, the memory does not track that in any way shape or form, so YOU have to keep track of that yourself in your code - if that is a requirement. Most of the time, that ISN'T a requirement, rather just a simple memory-map so you know where certain things will be stored before you read or write anything to the chip It is left totally up to the user to manage the pages in the memory, and to avoid writing across a page boundary in a single write operation, which is a no-no, and will overwrite the start of the page you are writing, and NOT continue on to the next page.EEPROM's are fun, aren't they! Smoke makes things work. When the smoke gets out, it stops! |
||||
panky Guru Joined: 02/10/2012 Location: AustraliaPosts: 1116 |
Hi Lew, To add to Grogsters info above, your Flash Memory chip from the data sheet is structured like this, starting at the lowest level 64M bits as 8M Bytes divided up into Pages, Sectors and Blocks with 256 Bytes per "Page" then there are 32 Pages (or 4K Bytes) to a "Sector" and 16 Sectors (or 512 Pages or 64K Bytes) to a "Block" ending up with 128 Blocks (or 64K Pages or 2048 Sectors or 8M Bytes) for the whole device. Different devices may use different page, sector and block sizes but the numbers above are for the device you asked about. You can read (with the approprite command) any byte location in the entire device from 000000H to 7FFFFFH but for writing, there are restrictions about writing over a page boundary and you have to manage this yourself (I think the functions posted by Geoff, Peter M and Grogster explain this better and look after this for you but this is deeper than my knowledge). Also, it is my understanding that you "write" 0's so to ensure the correct bits are written into a byte, all bits in a byte need to be 1's (or erased as erase effectively writes 1's) before data is written. You can only erase by page, by sector or by block as needed. As to your questions about how many "Pages" are used, you have to track and manage this yourself as mentioned by Grogster above. There are many complicated methods of reading to speed up performance and again, you need to study the datasheet however my own feeling is that most of these performance enhancing read commands are excess to standard logging and retrieval requirements. Hope this helps. panky. ... almost all of the Maximites, the MicromMites, the MM Extremes, the ArmMites, the PicoMite and loving it! |
||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
