eta4ever27 мая 2015 в 20:24

НЕ Arduino за 55 центов

3 мин

105K

DIY или Сделай сам

+46

Комментарии 26

abrakada 27 мая 2015 в 21:01

А какое энергопотребление у этого дисплея? Я вот тоже парочку заказал таких же с алиэкспресса, а сейчас собираюсь аккумуляторы подбирать, так что информация бы пригодилась.

eta4ever 27 мая 2015 в 21:06

Напрямую зависит от количества зажженных пикселей. Я не мерял, но Adafruit говорит, что стоит рассчитывать примерно на 20 мА.

abrakada 27 мая 2015 в 21:08

Это в среднем или на какое-то определенное количество пикселей?

eta4ever 27 мая 2015 в 21:24

Скорее, максимум. Видел упоминание сейчас, что примерно 20 мА при полностью зажженном дисплее.

abrakada 28 мая 2015 в 04:28

Спасибо, вы меня обнадежили

assad77 28 мая 2015 в 09:14

я измерял потребление у себя на 1.3 spi oled дисплее при заженных 10-20% пикселей (те выведен только текст.)
да, получилось около 20мА.

svd71 28 мая 2015 в 06:35

Для меня такие железки только хобби. Чесно говоря и чип понравился, но есть довольно жирная ложка дегтя: отсуствие симулятора.

При проектировании схематики в протеусе и интеграции его с авр-студио разработка превращается в удовольствие с возможностью пошаговой отладки. Потому как в Протеусе можно и дополнительную обвязку протестировать. Может я, конечно, обленился, но купленные пучком на алиекспрессе меги8 у меня еще не закончились. И судя по всему с таким симулятором будут еще долго использоваться.

Хотя, при заимении другого удобного тулчэйна и дешевых чипов с лучшими характеристиками, с удовольствием переползу.

TimReset 28 мая 2015 в 08:20

А как у вас обвязка в Протеусе работает в плане соответствия реальным данным? Я читал, что Протеус для моделирования аналоговых схем не очень подходит — он больше по микросхемам. Не могли бы Вы привести пример проекта с обвязкой? Сам я пробовал в Протеусе моделировать — в нём всё работало, а в железе — нет. Хотя тут может мои незнания повлияли — сам я больше по ПО, чем по железу :) И вообще, может статью напишете по разработке в Протеусе, а потом воплощение в железе? :)

svd71 28 мая 2015 в 13:01

На самом деле моя работа в нем занимает первоначальный вариант. До сборки в железе. И не стоит забывать, что это небольшие любительские поделки, по большей части состоящие с микроконтроллером — проще сказать концептуальная модель. Там хвалиться особо не чем.

Допустим я делаю с детьми робота на сервах. И мы с ними придумали новый метод обработки нескольких серв. Первым делом делается модель в протеусе с этими несколькими сервами и там исследуется.

Потом вот заказываем, допустим, Keyjoys(аналог джойстика от PS). Изучаем модель управления джойстиком команд с выводом в терминал UART. При такой разработке понадобилось несколько кнопок прикрутить и не забыть сделать вывод на радио-мудиль по SPI. На каждом этапе можно посмотреть как будет вести себя программа и реагировать собранная система. При этом еще реальных железок нет.

На такие самоделки точность обычно никчему — я ведь не сердечный стимулятор изобретаю. Зато сокращен до минимума процесс работы и отладки с реальным железом. Когда этим делом занимаешься профессионально — то есть в основное время, то вырабатываются некоторые небxодимые рефлекс — допустим, всегда проверить напряжение. Но когда такое дело хобби и есть обязательства перед семьей, то такие изыски в свободное время чреваты горелыми кристаллами.

И кроме того, пытливые детские умы могут в мое отсуствие проверить какую либо электронную гепотизу, исключая вероятность того, что будет испорчен как минимум компьютер. А как максимум пожар или поражение электротоком.

что касается воплощеня в железе, то чато обхожусь растровой платой. Хотя бывает заЛУТиваю что либо на текстолите. Сейчас вот фоторезист хочу попробовать — уже и УФ лампочку прикупил. А если и проектирую такую плату, то в Eagle CAD-soft, a совсем не в Протеусе. Это обуславливается большей свободой в разработке футпринтов. Да и часто проще найти в сети уже готовый элемент.

eta4ever 28 мая 2015 в 08:38

Я на Протеус не полагаюсь. Да, он моделирует AVRки, это прикольно. А вот если к ним подключено что-то сложнее светодиода, то начинаются чудеса. Вот, например, пытался я моделировать схему управления из предыдущей публикации. Местами работало, местами получалась откровенная хрень.

Int_13h 28 мая 2015 в 09:18

Да ладно, Протеус — удобный инструмент, только надо пользоваться правильно и не желать невозможного. А использование инструментов сильно облегчает жизнь инженера.

eta4ever 28 мая 2015 в 10:12

Я не спорю, что это очень крутая и полезная штука. Но всецело полагаться на него тоже нельзя. Я сталкивался как с тем, что в Proteus схема работает, а в железе — нет (при 100% совпадении деталей), и с обратной ситуацией — тоже.

svd71 28 мая 2015 в 13:08

Есть такой момент. Но связан о часто с невнимательностью в мелочах: фьюзы неправильно выставленны, некоторые ноги по умолчанию в симуляции себя ведут по другому, чем с железом (например непдключенный AVCC у АВРок приведет к неработе порта С, хотя в симуляции все прекрасно).

eta4ever 28 мая 2015 в 13:14

Я по большей части про аналоговые вещи. С симуляцией собственно AVR у меня все хорошо было, в том числе что касается ЦАПа и компаратора.

svd71 29 мая 2015 в 08:59

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

И раз считал H-Bridge для микромотора на имеющихся в наличии биполярниках. Потом это дело решил в Протеусе обкатать с теми же значениями. Схема не завелась. Пришлось изменять параметры сопротивлений. В железке с новыми значениями тоже не заработало, зато с ранее расчитанными очень даже начала работать.

kibergus 28 мая 2015 в 18:19

Зато с stm32 можно делать пошаговую отладку на реальном железе. А с avr… тоже можно, но когда я в последний раз смотрел, за это удовольствие надо было заплатить совсем негуманные деньги.

sguwenka 28 мая 2015 в 07:43

Растровое изображение подготовлено с помощью утилиты LCD Assistant. Полезнейшая в хозяйстве вещь, скармливаешь ей однобитный bmp-файл, а она выдает в текстовом виде байтовый массив, пригодный к употреблению в C.

Простите, не могу с этим согласиться. На выходе получаются нечеловеко-читаемые массивы. Изменить картинку в паре мест, изменить любой другой ресурсный файл — и снова всё конвертировать? спасибо, не надо.

Отработал для себя следующий вариант.
1. В makefile проекта создаётся цель convert, должна входить в зависимость для цели исполняемого файла. Цель представляет любые входные файлы (ресурсы) в виде бинарных объектников:

all : 
	...
	$(MAKE) convert
	...

convert:
	@echo --- start objcopy...
	$(OBJCOPY) -I binary \
			   -O elf32-littlearm \
			   -B arm html\ethernetindex.txt html\ethernetindex.o
	$(OBJCOPY) -I binary \
			   -O elf32-littlearm \
			   -B arm html\arsenal.gif html\arsenal.o
	$(OBJCOPY) -I binary \
			   -O elf32-littlearm \
			   -B arm html\ascii_girl.txt html\ascii_girl.o
	@echo --- done...

2. В скрипт линкера *.ld добавляются эти объектники. Если файлы вызываются редко, то в секцию .text. Можно и в .data, если скорость важна или динамическое изменение содержимого подключенных файлов:

	.text :
	{
		...
		*(.text)                   /* remaining code */
		*(.text.*)		
		html/arsenal.o
		html/ethernetindex.o
		html/ascii_girl.o
		...
	}

3. При включении файлов в проект, при линковке в сгенерированном map-файле можно найти, какого вида сформировались ссылки для подключенных ресурсов (для этого в *.ld надо прописать KEEP(html/arsenal.o) в первый раз, если в коде нет ссылок на ресурс). Например:

 html/arsenal.o()
 .data          0x0800abd8      0x69b html/arsenal.o
                0x0800abd8                _binary_html_arsenal_gif_start
                0x0800b273                _binary_html_arsenal_gif_end

Кроме того, в том же map-файле или в файле определений символов можно найти ещё сгенерированные константы:

*.sym:
0000069b A _binary_html_arsenal_gif_size

*.map:
_binary_html_arsenal_gif_size                     html/arsenal.o

4. Сгенерированные ссылки и константы являются глобальными, и мы можем использовать их в своих си-файлах:

extern char _binary_html_arsenal_gif_start;
extern char _binary_html_arsenal_gif_end;
  char *arsenal_start = &_binary_html_arsenal_gif_start;
  char *arsenal_end = &_binary_html_arsenal_gif_end;

Более того, если у вас файл имеет определённую структуру, то можно делать ссылку на структуру (файл распологать в секции .data!) и потом динамически обновлять содержимое файла через поля структуры… В общем у кого на что фантазии хватит.

1 раз повозиться с настройкой проекта — зато потом можно «на лету» подключать/изменять любые ваши ресурсы!

Vooon 28 мая 2015 в 08:15

А зачем добавлять обьектники в ld, разве не достаточно включить их в список обьектников для линковки?
Думаю что секцию можно указать objcopy.

sguwenka 28 мая 2015 в 08:28

Можно, наверное! Не думал об этом ;)
objcopy --add-section .text.rc*
как-то так наверное, в синтаксисе не уверен — надо проверять.

eta4ever 28 мая 2015 в 08:35

Спасибо за совет. Но это немножко другой уровень. На текущем мне не нужно вообще знать, что существует Makefile и какая-то линковка. Ну, то есть, я изображаю процесс «ардуино-стайл».

barabanus 28 мая 2015 в 09:00

На выходе получаются нечеловеко-читаемые массивы.

А в вашем случае — человекочитаемые?

eta4ever 28 мая 2015 в 09:07

Если надо прямо-таки читаемые, то надо реализовывать файловую систему, в нее класть ресурсы, и обрабатывать их программно. Ну, это не совсем та задача, которую хотелось бы решать при наличии 16 килобайт флеша.

sguwenka 28 мая 2015 в 09:11

Вообще-то да, т.к. создание объектников происходит на стадии компиляции всего проекта. А до этого момента работа может вестись напрямую с самим ресурсом.

burjui 28 мая 2015 в 12:40

Если у вас много таких ресурсов, то вместо того, чтобы писать каждый раз

 $(OBJCOPY) -I binary \
            -O elf32-littlearm \
            -B arm html\xxx.gif html\xxx.o

Лучше сделать так:

.SUFFIXES: .txt .gif .o

.txt.o:
         $(OBJCOPY) -I binary -O elf32-littlearm -B arm $< $@

# аналогично для gif

после чего просто добавить объектники в список и внести объектники в зависимость:

OBJECTS = main.o ethernetindex.o arsenal.o ascii_girl.o

all: $(OBJECTS)
        ...

Тогда make соберёт ресурсы автоматически при сборке цели all и не будет собирать ресурсы каждый раз заново, если исходные txt и gif не менялись.

НЛО прилетело и опубликовало эту надпись здесь

eta4ever 28 мая 2015 в 13:16

Тем, что mbed — это не просто генератор проекта, а комплекс из IDE, репозитория библиотек и компилятора. С возможностью, кстати, экспорта в проекты «настольных» IDE (не проверял). И уровень абстракции еще выше. Что не умаляет достоинств Cube.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий