Миландр

если и делать, то не через DFU. Как показывает практика : весьма ненадежный класс, очень много проблем на стороне компьютера с поддержкой драйвера USB DFU. Кроме того, места на реализацию в ROM контроллера он займет больше чем HID или урезанный вариант CDC.
зачем это чтобы закачать 128кБайт ... ?
И сейчас загрузку можно делать через USB прикрутив на UART дешевый ATTiny или что подобное, в памяти программ которого как массив констант будет лежать ваш апплет для USB, загружающийся в RAM. 8 килобайт хватит для того чтобы работу через USB HID записать и еще останется, чтобы на этом микроконтроллере что-то сделать, например зарядное устройство аккумуляторной батареи. Так делается и для Atmel (где "родной" загрузчик через USB работает плохо) и и для STM32F103 (где только через UART).

Интересная информация...

Касаемо
- вопрос в том, чтобы использовать встроенное в микроконтроллер железо и/или софт для связи с компьютером без сторонних микросхем. Вообще самое крутое, это http://microsin.net/programming/arm/upd ... t-iap.html, - но тут свои вопросы есть: защита данных и т.п., зато есть навроде во всех компьютерах, а ещё лучше WiFi и тогда получим https://ru.wikipedia.org/wiki/Smart_TV



Я думаю, размер MASK ROM можно и увеличить...

_________________
Hack the Planet!

ну через Ethernet конечно круто- и не безопасно... Вот локальный USB... благо интерфейс реализован аппаратно...

чуть по позже как изучу контроллер- попытаюсь реализовать программно...

Offtop - вообще вот интересная тема гуляет http://www.gaw.ru/html.cgi/txt/app/micr ... AVR309.htm

_________________
Hack the Planet!

без проблем будет работать, но ... только с внешним генератором.
Возможные 6-10 МГц внутреннего генератора (согласно описанию) на корню убивают любой интерфейс жестко привязанный к частоте.
Легко реализуемыми остаются UART (есть возможность подстройки скорости) и SPI (поскольку тактируется снаружи).

_________________
О сколько нам открытий чудных
Готовит просвященья дух,
И опыт - сын ошибок трудных ... (Пушкин)

Пергаменты не утоляют жажду ("Фауст",Гете)

В перспективных разработках планируется добавление 2-го UART в 1986ВЕ8Т.
Хотелось бы в стойком МК иметь UART c возможностью аппаратной блокировки посылок с 9-м битом и аппаратной реализации распознавания адреса при организации микропроцессорных сетей с использованием дублированных каналов RS485 с применением стойких приемопередатчиков. В настоящее время используем возможность манипуляции битами четности, что не совсем удобно из за необходимости обрабатывать прерывания от UART при приеме "чужих" посылок. Использовать CAN проблематично из за отсутствия стойких приемопередатчиков.

Не, Сегодня точно убедился что хочу 1986ВЕ91 в Пластмассовом корпусе lqfp144.
После того как сегодня плясал с бубном с внешней периферией для того чтобы расширить порты на 16 линий+ мультиплексор на 8 портов, Причем я знаю это уже есть на кристалле- только корпус не позволяет...

она уже больше 10 лет как гуляет

Yura в этой ветке писал "Спецификация это спецификация, ТУ это ТУ. Приемка "5" поставляется по ТУ. Спецификация - это просто описание".
Хотелось бы, чтобы Миландр при оформлении документации был ближе к Российским стандартат=ГОСТам.

Есть техническое описание ТО, так и называёте это так, а спецификация по ЕСКД это совершенно другое.

Поддерживаю.

_________________
сочувствующий…

Просьба разработчики Миландр ответить на вопрос/хотелку ... Будет или нет?
Хотя сейчас уже и идет платка на K1986BE1QI - с более большим функционалом периферии но K1986BE92QI мне очень понравился, и при этом я огорчился - просто отличный кристалл с хорошей достаточной периферией загнали в "плохой" по выводам корпус.

PS. Кто по мимо меня еще поддерживает предложения или нет? Или все сидят на оборонке- и подавай металл?

Если бы была возможность доработать МК семейства 1986ВЕ9х, то хотелось бы:
1. Добавить хотя бы три (а лучше больше!) аппаратных таймера-счетчика. Причем необязательно выводить их входы-выходы на ножки МК. Также очень хотелось хотя бы один таймер сделать 32-разрядным. У STM в этом плане всё гораздо гармоничней (см, например, STM32L152).
2. Иметь внешние прерывания по фронту сигнала. Сейчас прерывания возникают только по уровню, что неудобно.
3. Сделать отдельные аппаратные прерывания (с отдельными обработчиками) по каждому каналу DMA. Когда одновременно используется много каналов DMA, очень неудобно отслеживать в единственном обработчике, по какому же каналу возникло прерывание. Например, в STM32L152, ADuCM360 это сделано.
4. Добавить I2C slave.
5. Добавить прерывание по завершению преобразования ЦАП.

Пожелания упорядочены по убыванию степени актуальности.

хотя бы регистр состояния каналов, чтобы быстро определить: кто занят, а кто - закончил.

это как? В курсе, как работает R-2R ЦАП?

Виноват, что криво сформулировал свою мысль. Имел в виду прерывание по "DMA underrun" для ЦАП, как это сделано в STM32xxxxx и других камнях.

Есть макросы USE_JTAG_A и USE_JTAG_B (1986ВЕ9х). Может есть смысл сделать USE_SWD_A и USE_SWD_B? Неделю вечера убивал, пытаясь работать с SWD и одновременно дергать неиспользуемые ноги JTAG. Может кому в будущем поможет.