Back
[07:24:47] <GeneralStupid> Hmm
[07:24:55] <GeneralStupid> i have a S25FL116 flash chip...
[07:25:07] <GeneralStupid> I dont know from which company it its-.-
[07:44:01] <Jartza> probably spansion
[07:44:15] <Jartza> they have lot of SxxxF series flashes
[07:44:35] <Jartza> except spansion is now part of cypress
[07:44:40] <GeneralStupid> ok -.- i just need to know how to write and read data from it or to it---
[07:44:47] <GeneralStupid> Shouldnt be that hard...
[07:45:19] <GeneralStupid> Jartza: then everything is fine. i found two datasheets, one from cypress and one from spansion
[07:45:38] <Jartza> use the cypress one, it's newer probably :)
[07:47:45] <GeneralStupid> until now i just used i2c.
[07:48:43] <GeneralStupid> is there an Ack or something i will see on the line? MOSI?
[07:48:47] <GeneralStupid> Or MISO :D
[07:55:27] <Jartza> it's SPI?
[07:55:31] <Jartza> (didn't check the datasheet)
[07:55:32] <GeneralStupid> yes...
[07:56:07] <GeneralStupid> it looks a bit complicated to me... Why cant i just address one sector and push my data into it?!
[07:56:24] <Jartza> hmm?
[07:56:29] <Jartza> what's complicated in SPI?
[07:56:40] <Jartza> you just push data out and read data in simultaneously :)
[07:57:09] <GeneralStupid> i mean the flash chips SPI Interface looks complicated to me
[07:57:14] <GeneralStupid> way to much instructions
[07:57:15] <Jartza> usually those flashes have sequential mode
[07:57:20] <GeneralStupid> i just need two! read and write
[07:57:34] <Jartza> the flash chips are not made for just you ;)
[07:57:58] <GeneralStupid> next time i will design the pcb. With very easy to handle chips :D
[07:58:02] <Jartza> I bet it wouldn't be commercially viable to make flash chip with only read & write
[07:58:37] <Jartza> nowadays most flash chips support quad-spi, which is nice
[07:59:39] <GeneralStupid> i read that the blackfin is capable of booting over SPI
[07:59:59] <GeneralStupid> thats why i have this nice flash chip. The i²c flash was programmed in minutes :D
[08:10:55] <Jartza> many chips are capable of booting over spi
[08:23:27] <GeneralStupid> Hmm
[08:23:36] <GeneralStupid> write works, but it did not read any data -.-
[11:33:17] <bss36504> GeneralStupid: Wait, write works but you can't read? How do you know write works then??
[11:36:27] <bss36504> What are you having trouble with? Can you read a chip ID from it with a 0x9F command?
[11:37:17] <bss36504> you should get three bytes back. In order to do so, simply send a 9Fh then three dummy bytes, usually 00h is fine, though anything can work. Once that is good to go, you know you have communication in both directions
[11:37:51] <bss36504> As long as CS is low, you can take as much time as you need between sending bytes.
[11:38:21] <bss36504> I find SPI to be vastly simpler than I2C, in addition to being more reliable (IMO) and much faster (objectively)
[11:38:55] <LeoNerd> Conceptually neater
[11:39:14] <LeoNerd> Though harder to route boards for - twice as many traces. Moreso with lots of slave devices having an SS each
[11:39:39] <LeoNerd> I tend to run a mixture these days. I move "UI" components onto I²C expanders (buttons, front panel LEDs, etc...) to free up GPIO lines for fast internal hardware
[11:39:42] <bss36504> Also, flash must be erased before a "sector" can be written to. I put sector in quotes, because I dont feel like figuring out what they call their smallest erasable unit. It might be called a block for all i know. The point is, there will be a certain byte amount that is the smallest erasable block
[11:40:03] <bss36504> LeoNerd: Yes, I agree
[11:40:20] <LeoNerd> Also a thing I like about buttons on I²C expanders is that the interrupt->task schedule->read I²C expander latency is usually sufficiently slow that it acts as a nice button debouceing mechanism :)
[11:40:21] <bss36504> If you have a buttload of sensors all using SPI, it's not quite as nice to route as I2C.
[11:40:38] <bss36504> That is quite handy
[11:41:08] <LeoNerd> Another thing about I²C is that even at 400kHz it's usually too slow for clock skew to matter on interconnection wires
[11:41:25] <LeoNerd> Whereas try talking SPI at 10MHz down lines that differ in impedence/capacitance/trace length and soon you'll find problems
[11:42:02] <bss36504> Oh for sure. High speed SPI can be tricky, but if you need that much speed it's probably for good reason and worth your time to do a rigorous layout
[11:44:07] <bss36504> Oh, GeneralStupid, one more thing. When writing a large burst of data, like an entire page, it's technically possible to clock it into the chip faster than the chip can actually write it. So, it's good to be in the habit of checking the status register after every write, unless youre just doing single byte writes at relatively slow intervals.
[11:44:42] <bss36504> What I mean is, the chip buffers the whole page of data while it writes it, but you cant really do anything with it while it's busy
[11:45:00] <bss36504> Same with chip erase, which might take many hundreds of milliseconds
[11:47:02] <bss36504> Looks like a 64kbyte sector erase erases at 131 kbytes/second. So a full 32Mbit chip should take around 31 seconds.
[11:49:23] <LeoNerd> Those charge pumps take time
[11:57:07] <GeneralStupid> bss36504: my logic analyzer shows me that it writes the correct bytes to the chip
[11:59:11] <bss36504> GeneralStupid well that's great I guess, but that only proves that you know how to operate the SPI on your microcontroller, not that the memory is actually working properly.
[11:59:19] <bss36504> Try a chip ID next with 9F
[12:00:03] <bss36504> They are relatively simple things, but subtle mistakes can cause problems.
[12:00:52] <GeneralStupid> bss36504: actually i can read things like the status register
[12:01:04] <GeneralStupid> 9F is the chip id?
[12:01:10] <bss36504> Oh good, well then you're practically done
[12:01:13] <GeneralStupid> i thought this is AB
[12:01:17] <bss36504> 9F requests the ID, the ID is three bytes long
[12:02:06] <bss36504> Sorry, you're right AB is the mfgr ID, 9F is the JEDEC ID
[12:02:12] <GeneralStupid> hmmm 9F, i will try that tomorrow... It's a bit strange..
[12:03:16] <GeneralStupid> i tried 06h , then 02h 00h 00h 00h 42h
[12:03:27] <GeneralStupid> then i tried 03h 00h 00h 00h and read
[13:51:27] <twnqx> GeneralStupid:
https://bpaste.net/show/119d69f287ca
[13:51:31] <twnqx> maybe that helps
[13:54:09] <twnqx> especially the chip id stuff
[13:54:51] <bss36504> ewww whats that #undef doing in there ;)
[13:55:05] <twnqx> blame C and no namespaces
[14:10:09] <GeneralStupid> twnqx: Thanks!
[14:10:25] <carabia> could really just rename flashcmds
[14:10:46] <twnqx> it's the "SE" flash command, not all of them
[14:11:01] <carabia> well yeah,
[14:11:41] <twnqx> actually
[14:11:45] <carabia> don't know why it's insisted to redef it
[14:11:47] <twnqx> i am not even sure if i need avr/io.h ....
[14:12:08] <twnqx> "it"? you mean why i insisted?
[14:12:20] <carabia> oh, you, yes
[14:12:57] <carabia> well i guess clarity but prefix it?
[14:13:23] <carabia> all of them*
[14:19:02] <twnqx> bah
[14:19:11] <twnqx> it's only used inside thatone single .c file
[14:19:30] <twnqx> else it would be in a .h file, and prefixed
[14:20:59] <carabia> that's pretty nice though, how many chips does that cover?
[14:37:34] <twnqx> in theory all of single bank ones that work with standard SPI
[14:37:47] <twnqx> (not forced double/quad)
[14:38:02] <twnqx> as jedec standardized the commands
[14:38:50] <twnqx> IDing them is the trickier part since some chips predate the jedec standard, hence the multiple IDs
[14:39:00] <twnqx> and i think it's a year or so sicne i searched for new ones
[14:40:20] <twnqx> code also won't work with differenc page size than 256 bytes, i think. never used a chip that needed it
[14:40:37] <twnqx> that's part of some data logging code, caches into RAM until a page is full, then flushes it to flash
[14:41:52] <twnqx> it also assumes that the chip erases to 0xff, and some other things
[14:42:12] <twnqx> and i only tested it 5 or so types :P
[16:14:45] <LeoNerd> General question: I seem to recall some people around here have a little "microkernel" scheduler system they use for writing AVR code. I have one too...
[16:15:20] <LeoNerd> I'm pondering what to do about timers and delays. Currently my code I have an array of "alarms", delays after which to schedule a task again. But I'm wondering if I should merge that into my task structure
[16:16:38] <LeoNerd> The downside would be that I'd pay RAM cost for tasks that don't need delays, but on the upside I'd waste less RAM on the task IDs in the alarm structures. Overall I think it's about neutral either way
[17:19:24] <GeneralStupid> twnqx: really helpful, thank you!
[17:32:48] <LeoNerd> I²C bus. A few chips on it. One (a PCF8574) is not 400kHz-capable. After I've sent an addressing byte that doesn't address the chip, I wonder if that chip will get upset by 400kHz data on the bus
[17:33:16] <LeoNerd> I'm also trying to talk to an OLED so I want that as fast as possible
[17:36:40] <LeoNerd> I reckon it's worth a try anyway