Окей, значи ето я старата тема:
http://www.mcu-bg.com/mcu_site/viewtopic.php?t=6384

Сега искам да усложня постановката като добавя повече датчици. И изобщо, като цяло, ако се намери читаво решение, ще си го ползвам и за други работи. Да, най-смислено е да сменя контролера, изобщо да разкарам контролера и да сложа логика и т.н., обаче не ми се занимава - твърде много работа, учене и грижи за това начинание със съмнителна полза. Иска ми се с минимум промени да сложа повече датчици, примерно 4-5.

Този мултиплексор, доколкото мога да преценя, изисква полиране, което ми се иска да избегна.

Слагай контролер с повече АЦП входове и си карай с RC-филтри. ШИМ-а е аналогов сигнал, така че аналоговото преобразуване в случая е най-подходящо.

@Рек, с тия сензори нямаш никакви грижи... Според мен всеки нормален 16+ бит микроконтролер ще ти свърши работа за колкото канала искаш. Даже не е задължително да имаш прекъсване на PIO-тота.

Аз ти препоръчвам АРМ щото там нямаш софтуерни ограничения. При тези честоти спокойно може да мериш 50-100 такива датчика на фонов режим и в същото време да управяляваш дисплейче, клавиатурка и някаква серийна/USB комуникация. Ако честотите бяха по-височки щеше да имаш изисквания към хардуера, но в случая нямаш и затова по-добре да мислиш за подходящ софтуер а не хардуер...




Не работя с дискове, а флаш памети... и в тия 6 байта я държа естествено, защото подобна информация е овърхед
На теория може да се мине без овърхед ако не броим дължината на файла като излишна информация. Аз имам ограничение от 32К за размер на файла, т..е. 2 байта за дължина са достатъчни. Така всеки сектор от горните адреси надолу пиша дължините, а от долния край нагоре последователно се пишат самите файлове.
Така няма да има овърхед, но ще е прекалено бавно при търсене и затова аз освен дължината пиша още 2 байта CRC на името на директорията и CRC на името на файла. Общо 6 байта или по-точно 3 15-битови числа. С трите оставащи бита се валидират съответно - записа на 6-те байта, записа на файла и последния е флаг дали файлът е изтрит.
Операциите изискват обхождане, което изглежда плащещо но става тъй като не се четат чак толкова много данните. По принцип от един флаш гледам да правя повечко дискове, така че дискът да е от един или няколко сектора. Така търсенето се свежда само до секторите на диска. Примерно ако диска е с 1000 файла за да намеря даден файл в най-лошия случай изчитам 1000х6 = 6КВ.
Нещо съвсем излязахме от темата... ако ще правиш нещо подобно отвори друга тема щото дяволът е в подробностите. Това с овърхеда е най-малкия проблем.

Рек, с най-малко промени ще стане ако добавиш аналогови входове и
караш по утъпкания вече път с интегрирането. Явно MCU-то ти ги няма, щом
търсиш други решения; но да добавиш някакво аналогово превключване
не е ракетна наука. Неотдавна ползвах някакви сравнително нови аналогови
ключета в SOT23 от ADI, ако имаш три свободни цифрови изхода с такива
можеш лесно да направиш от един аналогов вход 8, при 0 до 5 волта размах.
Мога да навляза в детайли, ако те интересува.
Ако ще го правиш цифрово, намери си контролер с достатъчен брой (по един
на сензор) input capture входове. Като разгледаш как работи въпросното
input capture веднага ще ти стане очевидно как да мериш, каквото искаш.
Не е невъзможно да мериш и ползвайки прекъсвания на всеки фронт от
всеки датчик, но това може да е огромна беля. При 250 uS период 10 uS
латентност вече ще вкара грешка много по-голяма от тая на датчика ти,
а слизането под тия 10 uS в неголяма система с много прекъсвания
едва ли ще е лесна работа.

Само ми стана любопитно, понеже предложи операционна система.
И още не ми е ясно къде в 6-те байта държиш информацията за това, в кои свободно
избрани по диска сектори се намира файлът - примерно пръснат на 7 парчета - че и
името на файла. Все неща, които са в самата основа на всяка файлова система, от тях
само се почва всъщност.

Моето "читаво решение" за твоя случай е да сменя датчиците с DS18B20.
Без пекъсване и само с един пин на контролера, можеш да четеш (и записваш) много датчици. Всички са закачени на една жица - всеки датчик си има уникално ID с което се обръщаш към него. А може и само един на жица, като се упростява малко софта.
Незнам точно какво му е по-доброто на SMT-то, но за измервания в кола, едва ли има някакво значение.

@tqi излизаме много извън темата...

Значи аз ти казах, че не правя ФАТ-подобни истории.. Нямам парчета - целият файл се разполага последователно. При двубайтовия вариант първия файл започва от адрес да кажем 0 на сектора, а на адрес 0xFFFE записвам дължината му. Втория файл започва там от където свършва първия и дължината му се записва на адрес 0xFFFC и т.н.
Ако искаш да намериш къде се намира 5-я файл прочиташ последните 4 двубайтови числа в края на сектора - сумираш ги и получаваш адреса на началото на файла. А 5-тото число ти дава дължината на тоя файл.... Това е накратко как става - далеч по-упростено спрямо FAT. Не знам дали изобщо мога да се класирам за "файлова система".. Просто на мен това ми върши много по-добра работа отколкото истински FAT и не ми се е налагало да гоня съвместимост. Ако се наложи ще портна нещо...

Аха, разбирам. Просто нямаш файлова система, наричаш така някаква организация на
някакви твои си данни.