Объем кода для Mega64

_PM_

Чисто интересно, есть ли такие задачи, которые требуют всего объема памяти кода Mega64?

Реклама

sema

а еще есть ATMega128 и ATMega256!!!

зачем то ведь их выпускают

Реклама

pomidor

во флеши мелкоконтроллеров часто хранят разные табличные значения (гляньте на асмовскую директиву .db и .dw)- картинки, звуки, адреса адресов табличек - много памяти не бывает, а ножек мало etc

_PM_

не, ну это понятно что я могу константой туды забить битмап.
А вот кода!

Реклама

pomidor

тогда че-нить вроде Ethernut'а (на М128) из протеусовских примеров, но тоже с константами

Реклама

BCluster

Почему бы и нет? Вот у товарища видел проект примерно 50 кб кода. Бывает и больше )
Когда и Билл Гейтс сказал что 1 МБ оперативной памяти должно хватить для всех нужд )

Реклама

_PM_

В вопросе присутствует философская подоплека.

Смысл: есть ли такие задачи которые полностью занимают 64к кода. НО НЕ ПОТОМУ
ЧТО написаны левой ногой, а потому что задача большая. Т.е. насколько можно
выжать АВР.

Например: много кто говорит, но я пока не видел истинно векторного управления
асинхронными двигателями реализованного на АВР. Теоретически бандвиза и
мипсов хватает. Хватает и размера флеша.

НО не хватает программеров, которые могут это впихнуть туда. Очередной виток
эволюции индустрии разработки ПО. Когда возможности уже опережают фантазию.
А хардварная промышленность уже рвется за мипсами и гигами(мегами).

Видать перевелись программеры в старых традициях доса и прямого доступа к аппаратуре. Да и откуда им взяться. Традициям.

_PM_

А не замахнуться ли нам на Вильяма нашего Шекспира?

НАПИШЕМ ОСЬ!

ARV · Сообщение **ARV** » Вс апр 26, 2009 10:14:36

задняя левая нога тут совсем ни при чем, и ОСь не нужна, и векторное управление (которое, кстати, в полном объеме явно не по силам AVR).
использование printf() и математики с плавающей точкой - это где-то 6К, если вычисления используют математические функции (синусы там всякие и логарифмы) - это еще столько же, плюс константы, плюс собственно алгоритм... не заметишь, как набегает 32К... а там и до 64 недалеко. как правило, наибольшую проблему доставляет диалог с пользователем, которому подай нормальные текстовые сообщения, подсказки, меню и т.п. - все это при кажущейся простоте отнимает кучу FLASH...

BCluster

Видать перевелись программеры в старых традициях доса и прямого доступа к аппаратуре.

Соглашусь с вами лишь частично. Вот есть некий камень, допустим AVR, мне надо написать на него софт. Я взял Си написал этот софт за полчаса, сделал устройство и радуюсь. На асме трудозатраты были бы значительно больше. А на Си можно написать достаточно производительную задачу - если конечно делать это с умом. Положим она будет несколько медленнее ассемблерной - но если производительности процессора хватает - почему нет.
Отсюда вывод - надо искать компромиссные варианты. Мне жалко жизнь тратить на то, что можно сделать на порядок быстрее.
То, о чем вы говорите явно проявляется в настольных системах - делают аццкие видеокарты уже ддр5 и прочая хрень. Пишут на объектном директ3д игры и радуются. Потому что это ПРОСТО.
А вот есть компания id Software, та что quake и doom сделала. Они на опенгл делают игры - они имеют намноого меньшие требования к системе .
Объектное программирование штука очень хорошая - но есть задачи где лучше его не использовать.

_PM_

2BCLuster

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

Что я заметил за 17 лет программирования - это повальное упрощение.
Упрощая и упрощая абстракции все всегда и везде скатывается к
ненужности и унылости. А еще хуже то что в энтом процессе теряется
вся суть предмета. Учебники для чайников не могут породить никого
кроме чайников. Обучение в школе бейсиком приводит к кретинизации
в вузе. Язык определяет мЫшление. Кажется так. Что Вы всё уткнулись
в этот си. Не в языке дело. В задаче и ресурсах. Полагаю нужно мыслить
абстракциями и переносить их в реализацию. Чем ближе к телу (железу)
тем лучше. Если вы будете программировать на Си программу в семантике
Си вы получите просто программу. Если же вы будете писать под железо
на Си вы получите один в один то, что напишете на асме.

К чему я все это размазал. Фанатик детектед систем еррор оккуред.

Переболел я это уже в прошлом столетии

Программим для удовольствия, для развития, мыслим широко и просторно.

Итого: без моралей, мусорного Си кода, религиозных войнов.

ЧТО ПО СИЛАМ АВРу
А) Векторное управление
Б) MP3
В) OGG
Г) Видеопроцессинг
Д) TCP/IP стек
Е) Синтез MIDI потока
Ж) варианты

Прошу, высказывайтесь/ Нужно понимать всю глубину наших глубин (с) не мой

GP1 · Сообщение **GP1** » Вс апр 26, 2009 13:54:06

ARV писал(а): как правило, наибольшую проблему доставляет диалог с пользователем, которому подай нормальные текстовые сообщения, подсказки, меню и т.п. - все это при кажущейся простоте отнимает кучу FLASH...

На 100% поддерживаю, был у меня проектик где из 14К кода - 13К занимал пользовательский интерфейс

BCluster

mp3?) круто ) Есть готовые реализации? Видеопроцессинг... мдя, ну не буду спорить.

NiTr0

tcp/ip - легко, midi - думаю тоже проблемы не будет...
mp3/ogg - нереально ИМХО, хотя - если пошаманить с оптимизацией и приближенными вычислениями - кто его знает (глубоко в алгоритмы не вникал за ненадобностью). Полноценные цифровые (аудио)фильтры - максимум 3-4 штуки при 16 кспс частоте дискретизации, и ресурсы кончились, какая там видеообработка...

_PM_

Забыл с пунктами вопросики проставить

МП3 на грани. Реализаций нет. Как то пробовал. Памяти мало было. А вот видео
как раз возможно. Ну конечно не HDTV но можно.

Когда то давно делал реализацию целочисленного декодера OGG Влезло в АRМ.
AVR - не знаю.. =)

BCluster

ну звиняйте, ARM это не AVR)

__Alexander

Не улыбнули так улыбнули. Тут говорят о декоде МП3 на АВР.... а ну-ка, примерчик, хотя бы временный и под лицензией. Пусть АВР не тянет, но сам алгоритм. Не смешите тапочки.

Могу упростить задачу. Возьмите МП3 файл, откройте его в текстовом редакторе, берите листок бумаги и ручкой раскодируйте хотя-бы пять байт этого файла после заголовка, чтобы получился синус.

А по сути, были проекты, занимали 50% от 64к, и при этом подвергались модернизации, добавление других примочек, что приходилось переходить на М128. Так что, любой проект не может быть полностью завершенным - можно многое чего придумать даже в простяцкую задачу.

_PM_

Поиском по сети можно найти проект нативного проигрывания мп3 на java. Есть также целочисленные варианты для процев не имеющих FPU. В частности первый с ограничениями, но работает (на java). При наличии боле менее оперативки, можно попробовать портировать на AVR

_PM_

В частности вот http://www.javazoom.net/javalayer/javalayer.html. Есть варианты для JavaME. Портировать видимо можно. Но память нужна уже внешняя.

nictrace

сейчас все гонят за прибылью, прошивки пишут черт-те на чем, отлаживают полчаса и в продажу. Поэтому дешевле взять кристалл с памятью в 10 раз (или в 8*) больше необходимого, чем потратить время на качественное программирование на ассемблере.
Кто видел девайс, к которому не выходят обновленные прошивки после выпуска?