Рисовать можно ЧТО УГОДНО.
Формируете объект ГРАФИК с точкой привязки и при регенерации этот объект будет рассчитываться НА ЛЕТУ в координатах экрана.
Можно перекрывать объекты, задавать их направление и скорость движения...
Тут главное понять, что реальное время на дисплее ограничено инерцией зрения...
ОЗУ, вероятно, самая экономичная часть кристалла в смысле потребления...
В статике - да, и то под вопросом(насколько экономичней миллион ячеек триггеров по сравнению с остальными вентилями ядра) но в динамике статическая память потребляет довольно много за счет работы дешифраторов адреса(они там 1024-разрядные), хотя это потребление растет логарифмически с ростом объема памяти.
Я помню еще микросхемы L2(или это был L3-кеш?) кеша на 486-м процессоре довольно сильно грелись но они были всего лишь на 16кб и 70нс.
Дешифратор не переключается весь. В нем работает по конкретному адресу лишь несколько вентилей. Остальные находятся в статике.
Насколько я помню, в 486-х была НЕ CMOS, а N-MOS технология... Это другая песня и другое потребление...
Нет, там часть кеша была на внешних микросхемах, вне кристалла. 1024-разрядный Дешифратор в static RAM представляет из себя 1024 10-входовых элемента "И" Может быть где-то используется каскадное включение более мелких дешифраторов но это снижает быстродействие. А теперь представь что каждый вход этих элементов сидит на шине, и если при переходе с адреса 0 в 1 необходимо подтянуть к "1" всего 1024 входа, то при переходе 511->512 опрокидывается в 10 раз больше входов, и нужен ток по шине питания чтобы перезарядить все эти емкости. Всё равно, даже в самом простом случае в дешифраторе происходят очень масштабные процессы. При этом еще 8/16 входов из каждой линейки подключаются к шинам 1024-разрядного мультиплексора. Это тоже еще тот "хор". Ситуацию спасает лишь то что емкости входов отдельных вентилей достаточно малы, но это все еще гораздо больше чем происходящие процессы в ядре и обращение к такого размера static RAM может оказаться гораздо энергозатратней чем работа самого ядра. Причем если память не сегментировать, то энергетическая стоимость обращения к ячейке памяти зависит только от объема блока адресуемой памяти в котором находится ячейка. К флешу это в принципе тоже относится, там такие же дешифраторы используют.
Вот кстати, интересно провести эксперимент - простую программу которая секунду крутится в цикле(не в слипе), а другую секунду интенсивно использует RAM. Интересны будут данные по потреблению в эти моменты на чипах с разными объемами набортной RAM.
Хотя, инженеры небось не дураки и на самом деле RAM-ка сегментирована блоками. ну, скажем по 8К. На каждый такой блок - своя часть дешифратора и стробируемый повторитель шины адреса. Таким образом несколько снижается быстродействие, но обращение к ячейке вызывает только изменение на входах лишь 8К вентилей.
Здравствуйте. Скажите пожалуйста подойдёт ли прошивка ATmega8-PU для ATmega8A-PU.
1. Вы сейчас в интернете
2. Вы на сайте Radiokot.ru
3. Вы читаете
5. Вы не заметили что отсутствует пункт 4
6. Вы сейчас это проверили
7. Вы улыбаетесь
8. Поставь себе в подпись и нас будет больше
Да, подойдет.
Блин, кто-нибудь уже создаст FAQ по AVR, чуть ли не каждый день одни и те же вопросы про "A - не А", "PU - PI", "чем V отличается от А и L", всех в даташит посылать?
Неправильно собранная из неисправных деталей схема нуждается в отладке и сразу не работает... (С)
Нарыл в своей "мусорке" AT89C2051, хотел применить куда-нибудь и... Сайт Atmel'а молчит, только PDF'ка. Ни среды разработки, ни компилятора... Понимаю, что совсем древняя, но не выбрасывать же - "старый конь..."
Здравствуйте! Помогите пожалуйста с такой проблемой...
Начинаю изучать STM. На симуляторе гоняю stmf1xx, а проекты отлаживать нужно на stmf0xx. Как потом проект перенести на МК? Нужно только ножки и файлы заменить или что-то ещё?
Здравствуйте! Какой лучше спаять USB-программатор для AVR? Чтоб без дополнительного гемора цеплялся к распространенному ПО типа AVRStudio и т п. Желательно еще чтоб Пони прог его видел.
Спасибо, серьезная разработка
Вот нашел еще универсальный, и под АВР и под СТМ32, но его нечем прошить А я тут хотел еще СТМы осваивать, неплохо было бы иметь универсальный программатор...
Не стоит так уж гнаться за универсальностью. под STM32 программатор является одновременно и отладчиком. Универсальный не будет работать отладчиком, а значит надо будет еще один...
Универсальный нужен только в одном случае - когда приходится заниматься прошивкой на выезде и заранее не знаешь с чем иметь дело. Это довольно специфичная работа.
Понятно. Но я как-то отладчики и не юзаю. Обычно отлаживаю в шпротеусе, а шью байтбластером через LPT-порт. А щас вот решил новый комп делать, соответственно задумался о USB. Да и девайсы приходится извлекать из штатного места для апдейта - иногда задалбывает, а тут с ноутом можно будет подлезть.
Кстати STMы в шпротеусе отсутствуют - чувствую, там целое дело будет по их освоению...
А шьются они, как я понял, по USART, т. е. через COM-порт напрямую (через MAX).
Нет, шьются они по своему собственному протоколу ST-Link, а то что их можно перешивать по UART-у это заслуга предварительно зашитого в него загрузчика. Голый камушек не всякий прошьешь таким образом, насколько я слышал загрузчик с завода имеется только у новых более современных камней. А так, если прошить предварительно загрузчик - можно сразу по USB прошивку заливать, или по собственному радиоканалу или даже через ИК - тут фантазии есть где разгуляться(угу, одной кнопкой настукивая морзянку!) - вся реализация в ваших руках.
JTAG=байтбластер? Т. е. можно и АВРовким программером шить? Ведь она мало чем отличается от альтеровского байтбластера в прямом понимании этого слова.
И кстати что скажете на тему программаторов на базе FT232/245?
А я тут хотел еще СТМы осваивать, неплохо было бы иметь универсальный программатор...