фон-нейман

[dibr]

А эта ваша ородруина (точнее клон digispark на attiny85, но IDE там используется ардуинное) меня удивила. Я как-то не привык, что бывают компьютеры с не фон-неймановской архитектурой (а если и бывают, что это может вдруг оказаться моей, а не компилятора, проблемой), а тут вдруг. "Фон-Нейман", если что, это когда код и данные выполняются из одной памяти, а "Гарвардская архитектура" (это которая не фон-нейман), соответственно, когда данные и код "не могут быть смешаны".

Короче, я как-то привык, что байт кода и байт данных - это одинаковые по "цене" байты. И что если нужно для какого-то массива данных проделать какое-то действие (в моём случае "массив" - это положения ножек-глазиков-лампочек монстра, а "действие" - собственно дрыгание и мигание), то надо собрать массив элементов данных в "массив[элементов]" данных, и в цикле делать "действие(массив[элемент++])". Потому что можно, конечно, массив в массив не собирать, а написать много строчек вида "действие(данные1); действие(данные2); ... действие(данныеN);", но данные при этом один фиг окажутся внутри кода, плюс добавится много повторяющихся операций по засовыванию их в регистры/стек/whatever для передачи "действию" и вызов "действия", поэтому байтов в сумме понадобится больше, а зачем.

У attiny85 - 512 байт оперативной памяти "для переменных", и 8кб флэша (доступно около 6кб, остальное под бутлоадер) "для кода". Массив данных целиком ложится в оперативную память, в результате при 10 байтах на элемент и с учётом оверхеда на всё остальное, у меня получилось максимум 44 строчки-действия, дальше память заканчивалась.
А если делать через "действие(данные1); ... действие(данныеN);" - расходуемая оперативная память не изменяется, и хотя на каждое действие в результате расходуется больше памяти - это "память кода", которой у нас более чем в 10 раз больше, поэтому и действий можно упихать больше. При этом дело не в том, что "память кода" - типа read-only, а в переменные можно писать: волшебные слова типа const ничего не изменили, массив по прежнему ложился в оперативку. Видимо, данные в "памяти кода" реально нельзя адресовать как переменные, только использовать как операнды команд. Отдельно, кстати, непривычно что процессор похоже выполняет программу прямо из флэша - переписывание в "shadow RAM" как-то привычнее. Хотя, флэш там мелкий, может быть его можно адресовать быстро и "в лоб", а не как в флэш-карточках.

Впрочем, я уложился в 42 действия, так что пока некритично :-) Но забавно.

Comments

[tarnyagin.livejournal.com]

Код в студию!
Подозреваю (сам с ардуиной не), что для RO данных надо явно прописывать сегмент.

[dibr.livejournal.com]

https://pastebin.com/0VU76SnF

(извинити за неровный потчерк, писалось "на один раз").

...соответственно, замена

struct pt { int delay; int led1; int led2; int m1; int m2; }
scr[] = {

...на

struct pt { const int delay; const int led1; const int led2; const int m1; const int m2; };

const struct pt scr[] = {

Ничего не изменила. А куда ещё можно запихать const - я не придумал.

[blackyblack.livejournal.com]

Через const во флэше размещать можно на каких-то более современных процах, типа арма. Для меги и тайни const не катит.

[tarnyagin.livejournal.com]

Код в студию!
Подозреваю (сам с ардуиной не), что для RO данных надо явно прописывать сегмент.

[alxt.livejournal.com]

Ну прямо как i8051. Ковырял, страшно подумать 20 лет назад. Только С у меня е было, ассемблер не вдохновлял. Написал эдакий Ada-- 🙃
Да, 512 байт ОЗУ и от 2х до 8 КБ флота.

[ufm.livejournal.com]

На форте надо писать.

[juunitaki.livejournal.com]

PROGMEM

http://www.nongnu.org/avr-libc/user-manual/pgmspace.html

[dibr.livejournal.com]

Спасибо, поизучаю! :-)

[blackyblack.livejournal.com]

Там надо размещать массив в памяти кода с атрибутом __flash или типа того. Напрямую адресовать его нельзя, но можно сделать char a = mas[i]; и уже этот a будет размещён на стеке и с ним можно творить всякое.

[dibr.livejournal.com]

Ородруинская среда разработки (Arduino IDE 1.8.2) __flash ("__flash int mydata[] = .... (http://www.atmel.com/webdoc/avrlibcreferencemanual/porting_1iar_porting_flash.html)") не съела. А вот PROGMEM из комментария выше - вроде работает (запускать не пробовал, но ошибок не выдаётся).
Видимо, разные компиляторы.

[ex0_planet]

Ошибок не выдается, но работать все равно не будет. Это старая проблема gcc-avr: класть-то в progmem он кладет, но не генерирует правильный код для работы с этой памятью; точнее, он считает все адреса принадлежащими RAM, и в любом случае генерирует код для RAM. Для части функций из libc там доступны дубликаты с суффиксом _P, а если работать самому, то надо использовать pgm_read_byte/pgm_read_word, итд, итп. Аналогично с eeprom.

[dibr.livejournal.com]

Да, про the pgm_read_* я уже прочитал, но ещё не тестировал. Будет время (если захочется усложнить дрыгоножество и глазомигательство) - проверю :-)

[blackyblack.livejournal.com]

Да, это я, по привычке, для IAR написал. Для GCC другой синтаксис.

[mikell.livejournal.com]

Когда я в 1999 году пришел в embedded, у меня был процессор PIC16F84. 1Kслово памяти программы, 68 байт оперативки. И в нагрузку - программирование на ассемблере. Си - роскошь.

И изделия получались вполне себе приличные, много чего до сих пор в производстве находится. :)

[zg.livejournal.com]

nor-flash как бы для того и есть, чтобы из него код выполнять сразу. раньше такое в смартфонах даже было. потом видимо стало дешевле больше рам ставить.