Микроконтролери и електроника
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, да се празни от главната програма.
Вторият начин е по-професионален :) щото не държи 400 байта винаги заети, а и организационните конфликти са по-малко.
Обаче (2) изисква непрекъснато заделяне и освобождаване на памет и не зная какво ще стане след фрагментирането на паметта.
И не съм уверен, че в (2) ще успея да се оправя с указателите :), поне не без ваша помощ.

Така, че очаквам преложения, идеи и коментари :). Вероятно има много подобни примери и описания на подобни неща, но не ги намирам.

Автор:  miro_atc [ Сря Мар 30, 2011 1:40 pm ]
Заглавие: 

Зависи от файловата ти система...
Обикновено такива като fatfs си имат кеширане поне на ниво сектор (512 байта). Демек може много начесто да пишеш по малко байтове, а то ще ги кешира в РАМ докато не се напълни сектора и чак тогава ще почне трансфер към картата. В случая най-добрата стратегия е при първа възможност да викаш write_file() ако ще и за 1 байт.
Но ако ползваш файлова система без никакъв кеш ще трябва да внимаваш на колко големи парчета пишеш, т.е. ще е добре повече да буферираш отвън.

Зависи също и от мениджера на паметта. По-масовите имат стратегия при заделяне, т.е. не ти връщат първия свободен блок, ами преравят за най-подходящия. При подобна стратегия вероятността някога фрагментирането да ти прави проблеми клони към нула...

В случая обаче аз не виждам нужда от динамична памет. Един кръгов буфер си е ОК.

Автор:  NikB [ Сря Мар 30, 2011 2:30 pm ]
Заглавие: 

miro_atc написа:
Зависи от файловата ти система...
Ползвам това: http://www.roland-riegel.de/sd-reader/index.html
Има едно "#define USE_DYNAMIC_MEMORY 0", но и да е включено, не виждам да се ползва при запис на файлове (ползва се при заемане на дялове и директории).
(за мен все още стила на C не е много обозрим, тоя драйвер има пет H файла и няколко C файла - има много да ровя :))
miro_atc написа:
В случая обаче аз не виждам нужда от динамична памет. Един кръгов буфер си е ОК.
ОК, вероятно за сега ще го направя така. По нататък ще му мисля.

Автор:  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 ]
Заглавие: 

по принцип си прав - има проблеми.... и няма пълно щастие :D

Но конкретно преходът от мега към атмелски куртекс би трябвало да е по-лек щото периферията е много близка да не казвам една и съща... А и специално Атмел имат доста прилично АПИ за хардуера, константи, макроси и т.н.

Страница 1 от 1 Часовете са според зоната UTC + 2 часа [ DST ]
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
http://www.phpbb.com/