Oops, ok, but that is not the case here, the ADC_Average is not called as soon as I want to record data, just in case it would influence the writing to the sd card. But it did not help. The datarate is not constant, it hangs up to 100 ms, quite long...
You have kept the Beep. That would be OK if you were sure that you had only 1 problem that is not related to Beep, but at this point you are not sure that you don't have 2 connected interrupt conflicts of which is just 1 related to Beep. You have also kept TIMER2COMPA interrupt and didn't move code to OnSysTick, so you still risk them to fight each other. You didn't strip enough code. For example, you have SPI card and SPI ADC. Although at first look they are not in conflict, why don't you listen and kill SPI ADC completely in your code for testing purpose, kill GetGSensorADC() and let ADC_AVERAGE function return just some dummy number like 3,14? Can't you see that you are trying to debug too many things at once? Trying to build a house using all bricks at once is not good. How do you know that you can write 16 bytes always in 5ms? Did you try thousand writes in a row and all were successful and showing equal start/stop on oscilloscope or logic analyzer? Did you (for debugging purpose) set/reset some spare AVR pins on each logic function start and stop (card write start/stop, ADC start/stop, systick stop in OnSysTick...), and monitor them with some logic analyzer and trace for irregularities in sequence order or periods? If your LA shows 3000 times always the same sequence of debug pins and in next 100 times you see quite different sequence order, wouldn't that show you where is the problem, and you could make conclusions from recorded sequence analysis? Your code still writes to card inside of interrupt (I don't see 2 buffers in code), you didn't report prime numbers test results... You could test everything with writing just 1 instead of 16 bytes, you could use soft SPI instead of hardware one, you could try to preinitialize file to certain length and then just write to it instead of appending to it, you could kill all SPI usage and write to serial instead of card (at 115200 single char could be written without problems even with 1ms periods), and you could forgive me for not wanting to participate in this topic any more...
I did all that, I have several testprograms, one program which just writes 1 byte to the sd without everything else, one time on the timer interrupt, one time in the systick interrupt and also one just in a systimer loop.
Also the prewritten file was done before, no better result. I also tried to leave the beep out, no result. Buffers did not help too. I cannot post all testprograms here, that would not make it clearer. Instead I posted one program to show what is going on. That program should normally work, but it does not. Software SPI was not tried, but that would go too far.
"Did you try thousand writes in a row and all were successful and showing equal start/stop on oscilloscope or logic analyzer? "
Yes, I wrote 1 MB of data (16 bytes packets) in a row, in the complete program with beep, TWI Multilcd, serport etc. No problem. As soon as I trie to write packets in the interrupt, systick interrupt or systimer loop, it starts geting irregular.
This problem took far too much time, I soldered a dataflash into the system, I now write to the flash and then copy the data out to the sd, that works just fine. It is a pitty, that it did not work directly, but thats life.
Thank you all for trying to solve the problem, I guess it has something to do with the internal writing buffers of the sdcard, when writing fast it works, when writing slow it seems that the card does some work in between the write cylces, blocking the interface. Who knows..
Note due to EU Cookie Law This page uses cookies to handle logins and unread markers. If you use this forum you allow that this page is storing cookies on your computer. To remove Cookies from this site just click on "Delete cookies of this forum" on the bottom of the page. You can find more infos in our Cookie Policy.
