Может кто-нибудь мне разжевать плиз, как собственно данные с датчиков, антенн, шин всяких считываются кодом прошивки? Все это просто мапится по адресам памяти и читается в виде байтиков или все сложнее? За ссылки на статьи и всякие ликбез-научпоп-материалы отдельная благодарность заранее.
Ох, мой моск... Есть примеры кода прошивки для работы со всем этим добром? Спасибо за ключевые слова в любом случае.
Да это, собственно, обычное дергание ногами gpio портов. Только по протоколу. https://www.rpi.edu/dept/ecse/mps/Coding_SPI_sw.pdf https://www.robot-electronics.co.uk/i2c-tutorial В ардуинах там, наверное, попроще будет, с какими-нибудь готовыми фреймворками.
saleae logic 16 и ch143a eeprom в ютубе забей да посмотри, создай файлик с началом org 0x7C00 use16 и концом dw 0xAA55 и стартани qemu-system-x86_64 -hda filename общая логика будет понятна. ну а дальше всё от чипа.
Здрасьте это снова я. Вопрос по прерываниям, исключениям или чем бы они там ни были. Если железка хочет сообщить прошивке о каком-то внеплановом событии, типа пакет пришел или данные обновились, как и начиная откуда это дело обрабатывается? Данные от внешних устройств вообще как-то кешируются ожидая пока у диспетчера до них руки дойдут? ARM конечно же.
Ничего не понятно, но очень интересно. Я правильно понимаю что процедура инициализации регистрирует таблицу прерываний и завершается, а дальше уже процессор дёргает процедуры в соответствии с приоритетом? Соответственно нет прерываний - нет исполнения? И если так то как завершается инициализация? Возвращает куда-то, уходит в цикл, есть опкод для этого? Заранее благодарю.
Механизм прерываний такой же как везде: событию назначается обработчик в таблице векторов прерываний и в зависимости от приоритета процессор исполняет наиболее важный обработчик, переключение происходит прозрачно для обработчиков. Контекст (содержимое регистров) вытесненного прерывания сохраняется, при возвращении к нему восстанавливается. В важных ответственных участках кода (или в тех участках, где код обращается к общей для разных прерываний памяти) прерывания маскируются, то есть блокируется механизм переключения. Примитивное устройство прошивки это когда в прерывание ресет вся полезная нагрузка помещена, более продвинутое - в прерывание таймера. В обоих случаях прерывания интерфейсов имеют бОльший приоритет и прерывают собой основной алгоритм.
Так погодите-ка... Сам Reset_handler уходит в while (1)? Это норма? Это типа слип? Процессор же не крутит этот цикл?
Это не значит, что исполняя бранч, указывающий в самого себя, контроллер много жрет энергии. В самом контроллере могут быть технологии, которые это интерпретируют как простой, но алгоритмически выглядит так.
Ох как мне стр. 17 понравилась из arm-exceptions.pdf "x86 CPU - PIC8259A" вот такой вот ARM... такой же))).
Обычно есть инструкция процессора а-ля WAIT которая замораживает его до наступления какого то внешнего раздражителя, в т.ч. прерывания. Важна была еще с 80-х годов как раз чтобы понизить энергопотребление всякого embedded.
Припомнилось бородатое время, когда какому-то ЦПУ (вроде АМД) требовался драйвер, ибо в режиме простоя он дико молотил тактов.. прожка вроде звалась cpu_idle.exe
Помню, для AMD на чипсетах nForce 2 была утилитка S2kCtl с драйвером, который каким-то образом отцеплял процессор от шины в моменты простоя. Позволяло понизить температуру градусов на 10. А потом изобрели C-States, и не стало романтики слайдеров с ручным переключением делителей, когда, перекрутив, можно было повесить систему.
