| Микроконтролери и електроника http://mcu-bg.com/mcu_site/ |
|
| AVRGCC(Mega128)Как да организирам оптимална опашка от масиви http://mcu-bg.com/mcu_site/viewtopic.php?f=3&t=8751 |
Страница 1 от 1 |
| Автор: | NikB [ Сря Мар 30, 2011 12:46 pm ] |
| Заглавие: | AVRGCC(Mega128)Как да организирам оптимална опашка от масиви |
AVR GCC (ATMega128) Как да организирам оптимална опашка от масиви? Правя измервания на нещо, примерно, 100 пъти в секунда получавам по 4 байта. Целите измервания са по разни прекъсвания (таймери и АЦП). Резултати трябва да ги записвам на SD карта, което е сравнително бавно и го правя в главна програма. Сещам се за два начина (благодарности за други предложения): 1. един кръгов буфер, например с 100х4 байта, пълнещ се при измерване, а всеки път, когато главната програма се натутка - записва новополучената част от буфера на SD. 2. опашка, която да се пълни по прекъсване и, след запис на SD, да се празни от главната програма. Вторият начин е по-професионален Обаче (2) изисква непрекъснато заделяне и освобождаване на памет и не зная какво ще стане след фрагментирането на паметта. И не съм уверен, че в (2) ще успея да се оправя с указателите Така, че очаквам преложения, идеи и коментари |
|
| Автор: | miro_atc [ Сря Мар 30, 2011 1:40 pm ] |
| Заглавие: | |
Зависи от файловата ти система... Обикновено такива като fatfs си имат кеширане поне на ниво сектор (512 байта). Демек може много начесто да пишеш по малко байтове, а то ще ги кешира в РАМ докато не се напълни сектора и чак тогава ще почне трансфер към картата. В случая най-добрата стратегия е при първа възможност да викаш write_file() ако ще и за 1 байт. Но ако ползваш файлова система без никакъв кеш ще трябва да внимаваш на колко големи парчета пишеш, т.е. ще е добре повече да буферираш отвън. Зависи също и от мениджера на паметта. По-масовите имат стратегия при заделяне, т.е. не ти връщат първия свободен блок, ами преравят за най-подходящия. При подобна стратегия вероятността някога фрагментирането да ти прави проблеми клони към нула... В случая обаче аз не виждам нужда от динамична памет. Един кръгов буфер си е ОК. |
|
| Автор: | NikB [ Сря Мар 30, 2011 2:30 pm ] | ||||||||||||||||||
| Заглавие: | |||||||||||||||||||
Има едно "#define USE_DYNAMIC_MEMORY 0", но и да е включено, не виждам да се ползва при запис на файлове (ползва се при заемане на дялове и директории). (за мен все още стила на C не е много обозрим, тоя драйвер има пет H файла и няколко C файла - има много да ровя
|
|||||||||||||||||||
| Автор: | miro_atc [ Сря Мар 30, 2011 3:00 pm ] |
| Заглавие: | |
Не знам... това жувотно има само 4К нали? Ще имаш ядове с паметта... само дето не мога да разбера що се мъчите. Като гледам цените на Атмел между куртексите и мегите няма голяма разлика... |
|
| Автор: | michev [ Сря Мар 30, 2011 4:30 pm ] | |||||||||
| Заглавие: | ||||||||||
Само дето куРтексите са значително по сложни. Къде къде по лесна е работата с мега.. на 2 кратки реда съм установил даден извод като изход и съответно стойност. Това на куртекса (м3) не можах да постигна (само на 2 реда). Да не говорим , че всеки производител слагал негова си библиотека. Имената на регистрите - и те различни от производител до производите (за периферията). В примерите за куртекс рядко някой се сеща да напише аджеба, защо в даден регистър записва например 0х0055AC00, еместо да го напише разбираемо като (1<<REG_BLA) | (1<<REG_BLABLA2) и т.н. После викай ти - учи куртекс.. Ей, и без да се засягате |
||||||||||
| Автор: | miro_atc [ Сря Мар 30, 2011 4:46 pm ] |
| Заглавие: | |
по принцип си прав - има проблеми.... и няма пълно щастие Но конкретно преходът от мега към атмелски куртекс би трябвало да е по-лек щото периферията е много близка да не казвам една и съща... А и специално Атмел имат доста прилично АПИ за хардуера, константи, макроси и т.н. |
|
| Страница 1 от 1 | Часовете са според зоната UTC + 2 часа [ DST ] |
| Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group http://www.phpbb.com/ |
|