Хорошо. Беру слова назад. С + ассемблер, но по крайней мере до 20-30 МГц -- с уклоном в сторону последнего, т.е. после переноса и до окончательной сборки, конечно.
Вид для печати
Хорошо. Беру слова назад. С + ассемблер, но по крайней мере до 20-30 МГц -- с уклоном в сторону последнего, т.е. после переноса и до окончательной сборки, конечно.
8051@1Мгц вполне терпимо исполняет код, собранный из С. И это с учетом одного-единственного 16-разрядного регистра. Для спека должно быть получше...Цитата:
Сообщение от TomCaT
Кто-нибудь находил версию GCC для зетника? А то перерыл дофига ссылок- одни огрызки информации, ни сорцов ни бинарника. А то была б маза собрать его же исходники для спека :) Ибо писать с нуля- весьма ресурсозатратно...
Та же фигня. Но есть открытый компилятор из ACK, причем его можно оптимизировать. Имхо, эта задача на порядок проще, чем писать back-end к gcc.Цитата:
Сообщение от Vitamin
Подробнее можно? Не слышал о таком чтото...Цитата:
Сообщение от maximk
Гм... Иногда проще написать заново, нежели переделывать уже написанно :)Цитата:
Сообщение от maximk
ACK = Amsterdam Compiler Kit.Цитата:
Сообщение от Vitamin
http://tack.sourceforge.net/
Целый пакет из средств разработки. Компилятор C, как и другие (еще поддерживаются несколько языков) производит промежуточный код, а back-end'ы из него создают код для целевой платформы. Причем, как транслировать промежуточный байт-код в реальный описывается на специальном языке. И соответствующее описание для генерации кода z80 уже есть! Но, как и сказано в доке, оно не оптимально, ибо за основу был взят вариант от i8080.
Почитал, завтра скачаю и попробую под никсами собрать и попрогонять. Хочется посмотреть асм на выходе. Ибо все существующие кросс-компилеры такую хрень городят... Разве что IAR по слухам весьма достойно себя ведет (надо достать попробовать).Цитата:
Сообщение от maximk
Практически каждый раз пишу под каждый LCD процедуры вывода, поскольку каждый LCD очень отличается от предыдущего. Практически везде использую поддержку окон, она, конечно, стандартная и написана только на assemblere. Последние попытки использовать предлагаемые библиотеки закончились тем, что вывод символов, конечно же разной ширины, выглядил как прин на "васике", хоте нет наш "васик" примерно в 10-ть раз быстрее. Короче скорость просто ужасная и подходит для отображения каких-нибудь крайне статических изображений. Мало того, я постоянно занимаюсь тем, что подрабатываю на фирмах где меня просят ускорить вывод информации на LCD'шки. Вот на следующей неделе еду делать работу для компании Квазар-Микро, которая выставляется на выставке на стендах. Их программисты не могут на 25 мипсовм "интеле51" сделать нормальную анимацию. Я же программирую только на асме, скорорсть разработки, конечно не лучшая, примерно неделя для любой задачи с переферией(а значит и LCD), а остальное это уже мелочи, которые долизываются по ходу дела. В последний раз делал прибор месяц тому назад с LCD 240х128 (epson), за день был написан полностью модул графики со всеми окошками, шрифтиками и другой мелочью. Поэтому не вижу смысла писать на Си, только тратить время на поиск, - "а почему же это всё так тормозит..." ...Цитата:
Сообщение от Vitamin
Немного оффтопа, но с рациональным зерном
Я для себя выбрал другой подход. Библиотека заточена под работу с дисплеями 128х64 (8 строк по 128 байт, пиксели вертикально). Но благодаря буферу позволяет работать с дисплеями с любой(!) организацией растра (успешно работал на многстраничном дисплее с "растровой" организацией). Естественно, тормознее (перекидывание буфера целиком на экран), но зато "все внутри".Цитата:
Сообщение от Robus
Ну и библиотека пользовательского интерфейса. К ней в комплекте программа-конструктор и конвертер в С.
И путем каких манипуляций ты ее портируешь на другие процессоры? Переписывание?Цитата:
Сообщение от Robus
Вышеупомянутый 8051 на 1мгц запечатывает весь экран (с прямой отрисовкой в дисплей) примерно за 0.4с. Это с пропорциональной печатью с обработкой (особенно трудно реализовывать наклонный шрифт в силу структуры).Цитата:
Сообщение от Robus
Мдя :) Помнится ради хохмы написал прогу под 470 (48 мипс вроде, но не уверен), которая по последовательному каналу принимала кадры изображения, распаковывала их в реалтайме на экран. А другая прога на компе из авишника конвертила и слала. До 25фпс выдавало при размере кадра в 1к, сжатие в 1.5...3 раза получалось. Все ограничивалось скоростью порта- до 200кбит только выжимал (далее конвертер не позволял). Надо будет ради прикола попробовать эту же фишку на 8051...Цитата:
Сообщение от Robus
У меня в боекомплекте периферия- 6 счетных каналов (16-разрядные счетчики импульсов), жк-дисплей (символьный, с тупой организацией), лсд-матрица (примитив...), последовательный порт, плюс внутри математика. И все это на одном 8051 и на С. Прога писалась очень долго, ассемблерный вариант уже почти неуправляем (постоянные доделки-переделки), сейчас переписываю на С.Цитата:
Сообщение от Robus
Второй вариант отличается графическим ЖК, 8 счетными каналами, 2 последовательными портами. Проц тот же самый, прога изначально писалась на С, благодаря чему доработка относительно проста.
А что тратить время? Надо включать логику! :) В основном цикле программы разные не критичные ко времени процессы (пользовательский интерфейс, пост-обработка данных, печать в буферы и т.п.), а прием данных и предварительная обработка на прерываниях. Ставишь контроль-точки установки/сброса уровней между блоками подпрограммы-обработчика и смотришь на осциллографе кто и сколько чего жрет. А потом уже переписываешь критичные участки на асме. Ну и плюс чисто алгоритмическая оптимизация.Цитата:
Сообщение от Robus
Целиком и полностью согласен. Это некий "юношеский комплекс" - писать все на АСМе... Причем нисколько не обоснованный. Как показала практика и опыт - продумывание алгоритма и распределение по приоритетам задач - гораздо более эффективный способ сделать, "чтобы не тормозило", чем переписывание всего на АСМе. Куски на асме - другое дело (например в обработчиках очень критичных ко времени прерываний). Но все на асме - изврат :)Цитата:
Сообщение от Vitamin
Я смотрел. Фигня. Но дело в другом. Чем с нуля писать кодогенератор под монстрообразный gcc можно попробовать (если конечно есть желание, а ведь именно об этом шла речь :) ) _оптимизировать_ уже существующий back-end из ACK.Цитата:
Сообщение от Vitamin