INFERION

Жрет МНОГО ресурсов. Там арифметики будет много. МК будет с максимальной скоростью АЦП (50 килосэмплов) снимать данные, проводить расчёты и задавать новый режим. Паралельно ещё отчитываясь индикации о текущем стостоянии, температуре и т.п., и ещё должно оставатся время на реагирования на внешние прерывания, или какой-нибудь сигнал. Вся программа построена на прерываниях, никаких циклов между ними (разве что команда sleep).

Long Cat

Жду схему.

INFERION

Вот:

Но она ещё не раз будет перерисовыватся. Я ведь с МК почти незнаком...

Long Cat

Вижу схему электрическую: что-то куда-то соединено, но без скачивания даташитов на микросхемы мне ничего не ясно.

Опишите принцип работы и назначение узлов устройства в двух словах.

INFERION

PIC18F26J53 - сам МК.
TPS63020 - преобразователь.
BQ24155 - контроллер заряда Li-ion.
LTC2631LM12 - ЦАП.
INA138 - датчик тока
TSV631 - ОУ.

Непойму только зачем тебе такие детали, если схему разрабатываю и прошивку пишу я...

Long Cat

В противном случае, моя помощь будет состоять только из утвердительных качаний головой.
Чтобы давать советы, мне нужно быть "в теме".

Кстати о прерываниях. Какой-нибудь временной расчет сделан? Накладок не будет?

Почему выбрана такая частота дискретизации, почему нельзя взять меньше?

INFERION

К частоте семплирования серьёзной привязки нет. Можно и меньше, но нежелательно. Стабилизатор ведь, и реагировать должен как можно шустрее.
Никаких временных расчётов не потребуется. Не будет успевать - просто медленнее будет работать, что не катастрофично. Но я постараюсь сделать так, чтоб ресурсов хватало с запасом. Это всё симулятор покажет...

Мне сильно мешает максимально допустимое напряжение питания этого МК. К нему нельзя подключать литий напрямую, в отличии от AVR. Но блин у AVR такая куча недостатков перед этим чипом, что проще с этой проблемой както разобратся...

Long Cat

Если не будет успевать, может зависнуть наглухо, обрабатывая одну и ту же пару из двух прерываний, и не замечая третьего.

Симулятор, особенно в отношении работы с ШИМ, может показать все, что угодно, кроме правды.

Именно из-за любителей симулятора возникают чудесные глюки микропроцессорных устройств, которые сложно воспроизвести. Обычно, их списывают на брак микропроцессора.

Работа программы должна быть математически обоснована, а не проверена на частном примере в симуляторе.

Для AVR есть график зависимости максимальной частоты от напряжения питания. На полной скорости при заниженном питании они не работают.

По поводу частоты семплирования: будет ли успевать микросхема - стабилизатор реагировать на команды от ЦАП?
Возможна ведь и ситуация возникновения очень неприятных колебаний выходного напряжения - как это учтено?

INFERION

Ну, я не такой уж и ламер в этих вопросах . До трёх прерываний одновремено дело не дойдёт. А если дойдёт - я это увижу. Да и очередь там всётаки есть. Может прерывания и будут накладыватся, но во время обработки предведущее снова не выскочит. Можно неважные вообще игнорировать. Есть же в PICах низкоприоритетные прерывания... В любом случае это уже мои проблемы. По-моему производительности тут выше крыши, благодаря тому, что все тупые ресурсоёмкие операции полностью обрабатываются на железном уровне. МК только руководит. Задал параметр один раз, и дальше этот параметр поддерживается уже самостоятельно...

Стабилизатор самостоятельный, у него своя ОС, и МК можеет напряжение задавать вообще без АЦП, полагаясь на линейность ЦАП и стабилизатора. Если будет какая-нибудь неприятная ситуация - она спокойно устранится программным методом. Но сейчас этого не предвидится. Да и 12,5кГц (у АЦП то 4 канала, и только каждый 4-й семпл несёт информацию о состоянии стабилизатора) любой стабилизатор осилит без проблем, иначе это будет вообще непригодный эстонец...

ШИМ мне симулировать и ненадо. Там нечего и проверять. Просто записать значение в регистр сравнения и всё. А железо уже само всё сделает, а если и неправильно сделает - к катастрофе это не приведёт. Схему вообще невозможно убить кривой программой. Она может только неправильно функционировать, но на это есть дебаггинг. Так что все возможные неприятности пока что можно отбросить, и потом уже по мере необходимости их устранять программно. Переписать код - это не детали перепаивать...

Так я за это с самого начала и пишу. Реально я с AVR только 8МГц и выжму, но мне этого может и хватить. Вот только периферия тогда серьёзно толстеет. I2C на программном уровне, SPI занят 25-й тинькой, внешний АЦП. Если избавится от программного I2C, который жрать будет практически все ресурсы (обмен данными то постоянный), то прийдётся ещё и мультиплексор на SPI цеплять. И кварц чуть ли не треть платы занимает...

Long Cat

А если повесить Tiny25 на I2C?