ВходНаше всё Теги codebook 无线电组件 Поиск Опросы Закон Суббота
20 апреля
982244 Топик полностью
Связанные сообщения
Hal
Подскажите как сейчас правильно организовать в микроконтроллере программные таймеры?2020-10-23
Выводы контроллера всегда управляются в контексте управления каким-либо более крупным аппаратным ресурсом. I2C-шиной, например. ...2019-12-17
Железо нужно симулировать не на уровне битов и фронтов сигналов, а на уровне высокоуровневых операций (например, чтение-запись б...2019-11-07
От проекта зависит. Насколько чётко выделена аппаратно-зависимая часть и насколько абстракции используемые в старом проекте реал...2019-05-24
Собственно можно код запускать в эмуляторе процессора (qemu), которому привязать симуляцию нужной аппаратуры, или заменить HAL н...2019-02-06
Когда ПО прибора запускается на обычном ПК. Для этого обычно ПО разделяется на два слоя, как минимум: платформо-независимый (бол...2018-05-23
Одни абстракции заменяются на другие, которые тоже нужно учить, документировать и запоминать, учитывать возможные побочные эффек...2015-07-23
Жалкая паделка финских студентов написана на 100% на C, из ассемблера только вектора прерываний, crt и ещё мелочи, в C30 v3.31. ...2014-04-10
Да, трэш угар и содомия. Иногда абстракции через край, поэтому я имею такое мнение, что иногда и не грех в исходники прямо вписа...2013-12-29
Не совсем. Над HAL может быть ещё один слой, уже нужный для совмещения разных программных интерфейсов. Т.е. есть модуль A, котор...2013-10-25
Полезны аж 3 прослойки (ассемблеристам дальше лучше не читать):2011-10-13
fk0, легенда (28.02.2020 00:09, просмотров: 609) ответил POV_ на АСМ - не торт, но 8 бит-то тут при чем? Если нет необходимости паралельно (прерывания-гиперлуп) менять многобайтные переменные, то нет проблем...
При наличии полноценного компилятора не при чём (не хуже чем 16 бит). Но как правило с этим проблемы. Для всех кроме AVR у многих до сих пор C89 не в полном объёме... Со стандартной библиотекой (не работающие printf, ага) тоже плохо. Дело конечно не в разрядности CPU, но есть корреляция, что на более высокоразрядном CPU компилятор и библиотека более качественные. Медленная работа наконец. Где на 16/32 битном одна инструкция, на 8-битном несколько. Да и оптимизация никакая (AVR vs PIC не говоря уж ARM/MIPS vs PIC). Странные ограничения (не более 256 байт локальных переменных на функцию у PIC18, из-за баночной организации памяти). Гарвардская архитектура с невозможностью хранения текстовых строк в flash или адресации их как "const char*" (единственное что у пиков сделано по-человечески), в итоге секция .rodata либо съезжает в ОЗУ (которого и так кто наплакал), либо код становится не переносимым. Отсутствие в процессоре специфических команд атомарного изменения переменных (актуально при наличии RTOS): bit set and test, fetch and add, compare and swap, не позволяющих эффективно реализовать примитивы синхронизации (мьютекс) и lockless алгоритмы. Отсутствие аппаратной защиты памяти, в итоге многие ошибки вместо исключения ведут к непонятным глюкам. Да много чего ещё... У всех ARM более-менее приличный отладчик например. CF8051F120 тоже программировал (лет 15 тому назад): был ворованный KEIL и силабсовская среда. В итоге в кейле как бы можно всё, но на практике ничего: отладка через uVision тормозит адски и глючит (фирменный адаптер EC2). В силабсовской среде ничего делать вообще невозможно, но кое-как позволяет программировать и отлаживать, и подхватывает символы от Keil. В итоге собирал через Keil, потом научился через Makefile (потому, что в Keil нужные крыжики с опциями от компилятора не натыкать было), отлаживал если нужно было (чего пытался избежать) в силабсовской IDE (где показывалось дай бог половина переменных и было пошаговое исполнение и брейкпоинты, больше ничего), код писал в Vim. Для упрощения отладки был HAL для ПЦ с которым основная часть программы собиралась и имитировала работу -- большинство багов ловилось на ПЦ. Так же отлаживал printf'ом в компорт. Запомнилось, что несмотря на 100МГц работает всё чертовски медленно из-за протаскивания всех переменных программы через игольное ушко одного регистра DPTR. Второй DPTR Keil не умел использовать или его не было у процессора, не помню. Вообще это от модели памяти зависило -- тормозило в large. В small можно писать быстрые программки, но в смешном объёме памяти, что было чаще бесполезно и годилось только для обработчиков прерываний. Часть программы (управление ШД) потом переехала на атмегу, где на 8МГц работала в общем веселее... Ещё ручное раскладывание переменных по сегментам (data, xdata, стек и т.п.) помню, ручную расстановку static где можно для ускорения и т.п., фактически работу по оптимизации приходилось делать руками: смотришь ассемблер, понимаешь почему медленно, что-нибудь переписываешь и так в цикле. Программируя под ARM таким заниматься даже не вспомнишь, там компилятор выше тебя на две головы обычно.
[ZX]