Здравствуйте, landerhigh, Вы писали:

D>>Я до сих пор не услышал ответа на вопрос, а почему нет? Почему за бесплатно не получить возможность кодить в нормальном С++, почему не получить возможность сделать на операционке FreeRTOS, почему не получить просто так больший объем памяти? Разница в цене просто копейки.
L>Это.. ардуино — это gcc. С Александреску шаблонами. На каких МК есть более "нормальный" С++?

Я уже тут задавал этот вопрос... Так как там на "нормальном C++" задаётся размещение переменных в разных типах памяти? )

L>Ну и операционку для мигания светодиодом или открывания жалюзей — это сродни приколу про "Hello World" на Java. Бесплатного ничего не бывает.

Я операционки не предлагал. ) И сам не использую для таких целей (потому что обычно использую несколько мелких МК, вместо одного супержирного). Но замечу, что в случае потребности реальной многозадачности на МК, FreeRTOS является крайне удобным решением.

Здравствуйте, alex_public, Вы писали:

L>>Это.. ардуино — это gcc. С Александреску шаблонами. На каких МК есть более "нормальный" С++?
_>Я уже тут задавал этот вопрос... Так как там на "нормальном C++" задаётся размещение переменных в разных типах памяти? )

Что есть "разные типы памяти"? Ты хочешь динамической памяти от МК с двумя килобайтами оперативки?

Здравствуйте, landerhigh, Вы писали:

_>>Это не идиотизм по одной простой причине: используя процессор типа Cortex-M я без проблем могу работать на полноценном C++14 со всеми его возможностями, а не на убогом Processing/Wiring.
L>У ардуинки под капотом тот же GCC
L>Со всеми его возможностями (с)

Ну там не всё так просто (достаточно взглянуть на свою реализацию библиотеки). Но в целом конечно можно использовать элементы современного C++. Вопрос только в том, зачем тогда так извращаться (если не использовать возможности Processing/Wiring) с этой убогой платформой? Т.е. даже если зачем-то использовать процессоры AVR (что на мой взгляд тоже уже полный бред для новых проектов), то можно это делать по нормальному и даже с элементами C++11: http://geektimes.ru/post/263724/.

Здравствуйте, landerhigh, Вы писали:

_>>Я уже тут задавал этот вопрос... Так как там на "нормальном C++" задаётся размещение переменных в разных типах памяти? )
L>Что есть "разные типы памяти"? Ты хочешь динамической памяти от МК с двумя килобайтами оперативки?

Хы, вообще то это как раз в старших МК и взрослых процессорах память одна (ну кэши не считаем), вот AVR отличается целой коллекцией типов (я про всякие EEPROM, флеш, SRAM и т.п.) )))

Здравствуйте, alex_public, Вы писали:

L>>Что есть "разные типы памяти"? Ты хочешь динамической памяти от МК с двумя килобайтами оперативки?

_>Хы, вообще то это как раз в старших МК и взрослых процессорах память одна (ну кэши не считаем), вот AVR отличается целой коллекцией типов (я про всякие EEPROM, флеш, SRAM и т.п.) )))

А вот это к C++ как раз никакого отношения не имеет. Просто особенность платформы, с которой нужно считаться.

Здравствуйте, alex_public, Вы писали:

_>Ну там не всё так просто (достаточно взглянуть на свою реализацию библиотеки). Но в целом конечно можно использовать элементы современного C++. Вопрос только в том, зачем тогда так извращаться (если не использовать возможности Processing/Wiring) с этой убогой платформой? Т.е. даже если зачем-то использовать процессоры AVR (что на мой взгляд тоже уже полный бред для новых проектов), то можно это делать по нормальному и даже с элементами C++11: http://geektimes.ru/post/263724/.

Я понятия не имею, что такое Processing/Wiring, но у меня есть библиотечка, которая реализует навороченную логику КА на вполне себе C++11 шаблонах. Работает на ардуинки искаропки (с)
Адресовать строки напрямую из флеша — тоже мне проблема, все решается одним шаблонным классом.
Никогда со сторонней сетевой библиотекой не работал? Где чтобы обработать ошибку на клиенте, нужно встать на голову? Вот там треш, угар и содомия.

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

P.S. называть платформу убогой —

Здравствуйте, landerhigh, Вы писали:

L>Здравствуйте, Denwer, Вы писали:

L>>>Это.. ардуино — это gcc. С Александреску шаблонами. На каких МК есть более "нормальный" С++?
L>>>Ну и операционку для мигания светодиодом или открывания жалюзей — это сродни приколу про "Hello World" на Java. Бесплатного ничего не бывает.
D>>Вообще то контекст обсуждения был далек от ардуино, сравнение было уже между 32 и 8 битным МК.

L>Может, я и диод, но где в нижеотквоченном

L>

L>Почему за бесплатно не получить возможность кодить в нормальном С++

L>битность?

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

Здравствуйте, landerhigh, Вы писали:

L>Я понятия не имею, что такое Processing/Wiring, но у меня есть библиотечка, которая реализует навороченную логику КА на вполне себе C++11 шаблонах. Работает на ардуинки искаропки (с)
Товарищ явно не работал с Ардуино, ибо сыплет штампами, а не оперирует фактами.

L>В общем, какие-то унылые наезды, и спор ради спора. Ардуинка вне конкуренции, когда хочется что-то сделать для себя на коленке по-быстрому. Наличие коммюнити, туториалов и кучи всяких шилдов решает.
Я вот на выходных спаял плату, и нужно было быстро проверить, работает ли она (для реального конечного продукта софта ещё не написано). Нагуглил ардуиновские либы к железякам, и уже через пять минут я знал, что всё спаяно верно.
Без Ардуинки мне бы пришлось напедалить какой-то тестовый код для такой проверки, и потом, если бы оно не заработало, гадать, что именно не работает — железо или мой наколеночный тест. А в моём случае я точно знал, что софт работает.
Конечная схема у меня будет без Ардуинки (пока выходит запихнуть всё в компактный 14-пиновый attiny841), но прошивку для него ещё только предстоит написать (в выходные педалил "софтовую" реализацию I²C).

L>P.S. называть платформу убогой —
+1

Здравствуйте, landerhigh, Вы писали:

_>>Хы, вообще то это как раз в старших МК и взрослых процессорах память одна (ну кэши не считаем), вот AVR отличается целой коллекцией типов (я про всякие EEPROM, флеш, SRAM и т.п.) )))
L>А вот это к C++ как раз никакого отношения не имеет. Просто особенность платформы, с которой нужно считаться.

Ну так мы как раз особенности (убогости) платформы и обсуждаем. Так расскажи как же нам "на нормальном C++" задать размещение переменных в разных типах памяти? )

Здравствуйте, alex_public, Вы писали:

_>Ну так мы как раз особенности (убогости) платформы и обсуждаем. Так расскажи как же нам "на нормальном C++" задать размещение переменных в разных типах памяти? )

К языку это никакого отношения не имеет. Особенность платформы, с которой можно работать.

P.S. размещать "переменную" в ROM — сильное требование.

Здравствуйте, landerhigh, Вы писали:

_>>Ну так мы как раз особенности (убогости) платформы и обсуждаем. Так расскажи как же нам "на нормальном C++" задать размещение переменных в разных типах памяти? )
L>К языку это никакого отношения не имеет. Особенность платформы, с которой можно работать.

Ну т.е. ответа не будет? ) Почему-то я не удивлён... )))

Здравствуйте, alex_public, Вы писали:

L>>К языку это никакого отношения не имеет. Особенность платформы, с которой можно работать.

_>Ну т.е. ответа не будет? ) Почему-то я не удивлён... )))

Не будет. Проблемы не существует, точнее, она не стоит обсуждения от слова совсем.
Если это для кого-то — проблема, то у меня для них две новости.

Здравствуйте, qwertyuiop, Вы писали:


Q>Может для каких-то недокомпиляторов это и так, но Atmel не виноват в том, что вы пользуетесь такими недокомпиляторами. Пользуйтесь Atmel Studio и будет вам щастье. Вот пример простой программы обработки прерывания:
Q>

Q>ISR(INT0_vect)
Q>    {
Q>    PORTC &= ~_BV(PC1);                // снимаем флаг "ответ получен"
Q>    }
Q>

atmel studio — это gcc-avr вообще-то За макросом ISR как раз и стоит gcc-шный атрибут, который функцию помечает специальным образом, после чего для нее генерируются специальные пролог и эпилог

Атрибут нестандартный и скажем на IAR другой способ пометки таких функций

Здравствуйте, qwertyuiop, Вы писали:

E>>Три пространства — как я понимаю для экономии на размере указателя. Ну и возможно более простая архитектура процессора получается — разные команды чтения из разных областей

Q>Нет, это как раз для того, чтобы одновременно читать команду из памяти команд и, выполняя ее, обращаться к памяти данных по другой шине в то же самое время. Впрочем, сейчас и АРМы есть с несколькими шинами, причем там такая экзотическая архитектура, что ее нельзя отнести ни к фон-Неймановской, ни к гарвардской. Бывают отдельные шины для периферии для того, чтобы при работе DMA она не занимала шины команд/данных и тем самым не тормозила работу процессора, есть еще много всякой экзотики.

Ну собственно на том же stm32 шин много. Все это разруливается процессором, он к разным областям памяти обращается по разному, плюс DMA / etc работают по своим шинам. Это не мешает иметь общее адресное пространство. Просто не все адреса в нем равноправны, если flash со специальной процедурой записи, есть периферия, есть ОЗУ

Q>Image: arm_pipeline.gif

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

Здравствуйте, alex_public, Вы писали:

_>Это как раз всё тривиально. ) USB не нужен, нужен программатор (цена 200 рублей). Паять на свою плату, которую ты будешь разрабатывать для устройства.

А зачем это все делать, если можно не делать?

_>Это отдельный вопрос. В таком случае действительно может быть смысл в покупке готовых плат. Однако это совсем не означает выбор ардуинки — готовых плат и на STM32 полно.

Не спорю. Но ардуинки дешевы, широко распространены, под них масса шилдов. В типовых применениях скорости хватает — зачем больше?

Т.е. когда я выбирал ардуинку, я тупо взял на атмеге, ибо самая распространенная. Когда-нибудь это изменится, армы захватят все. Но пока то это не так

_>Ну это скорее просто плата на STM32 построенная по идеологии ардуинки (не знаю запустится ли на ней этой фреймворк или нет, в любом случае он не нужен). Т.к. у неё есть SWD выход, то без проблем можно с ней работать в нормально режиме, игнорируя ненужные части. Это как раз дешёвый вариант на случай плохих отношений с паяльником. Но лучше естественно самому сделать чистую платку.

Фреймфорк не нужен? Можно без него, но с ним часто удобнее. Собственно громкое слово фреймворк обозначает достаточно тонкую обертку над железом

_>Я же не собираюсь повторять их устройство с кучей ненужных компонентов) И я тебе кажется уже продемонстрировал, что свой вариант будет дешевле (если конечно не считать производства платы и затрат времени, но для процесса разработки это в любом случае удобнее выходит).

Дешевле? Я схожу на почту 1 раз, а ты — 10. Это дороже Опять жеж, придется самому паять, автомат явно паяет лучше тебя. Нужна макетная плата или нужно заказать печатную плату для себя. В одном экземпляре — она получится золотая.

Не, если цель — потренироваться в пайке и это доставляет удовольствие — почему нет. Но мне к примеру хочется решить конкретную задачу, и это прозе всего сделать купив готовое


_>>> Причём это будет полноценный 32-ух битный процессор, с популярным ядром Cortex, со всеми вытекающими из этого плюсами.
E>>Какими плюсами? Вот у меня конкретная задача — читать входы, писать выходы, управлять димером, читать температуру по 1-wire. Ардуинки мне для этих целей выше крыши. Какие преимущества я получу, если куплю рассыпухой stm32f1xx?

_>Лучше stm32f0. ) Преимущества в экосистемы ARM'ов, с которой несравнится даже ардуинка, т.к. туда входят все современные средства разработки (т.е. я работаю с МК в том же окружение, что пишу программы для Андроида (Cortex-A) и Винды (x86)).

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

Ну и кстати, я пишу в эклипсе для винды, м3, авр, ардуинок. Что не так?

_>Дёшево — не принимается, уже показано.
не показано

_>Куча шилдов — да, одно из преимуществ ардуинки. Но только для любителя.
Так я и есть любитель

_>Можно не уметь паять — не принимается, полно плат и на STM32.
Полно. Насколько они совместимы друг с другом и с шилдами?

_>Можно не иметь отладчика — да. Но я не очень вижу смысл в экономии 200 рублей.
да тупо проще старт. Кроме того, зачем он, если задача простая?

_>Документация, сообщество и т.п. — это как раз у ARM'ов покачественее (ну я не про Миландр )
_>Библиотеки — спорный вопрос. Библиотеки общего назначения как раз получше у АРМ'ов, т.к. там можно спокойно использовать взрослые решения. Зато у ардуинок есть готовые библиотеки под все свои бесчисленные шилды.

Вот вот

Здравствуйте, enji, Вы писали:

_>>Это как раз всё тривиально. ) USB не нужен, нужен программатор (цена 200 рублей). Паять на свою плату, которую ты будешь разрабатывать для устройства.
E>А зачем это все делать, если можно не делать?

Что именно? Плату свою? Ну для нормальных устройств (не помигать светодиодами) её же всё равно надо делать, даже если взять за основу готовую плату с МК. Конечно есть всякие шилды готовые и можно попытаться обойтись этаким бутербродом. Но это должны точно совпасть необходимые параметры плат, их набор и т.п. В общем в итоге убежав от одних проблем (создания одной своей платки), получаешь множество других.

_>>Это отдельный вопрос. В таком случае действительно может быть смысл в покупке готовых плат. Однако это совсем не означает выбор ардуинки — готовых плат и на STM32 полно.
E>Не спорю. Но ардуинки дешевы, широко распространены, под них масса шилдов. В типовых применениях скорости хватает — зачем больше?

Ну цены то, как мы видели, одинаковые. А вот шилды — это действительно фирменная ардуиновская вещь. ))) "Зачем?" — это мы уже выше обсуждали. На мой вкус дело не в быстродействие, а в удобстве использования взрослых (это в смысле не из мира МК) инструментов.

E>Т.е. когда я выбирал ардуинку, я тупо взял на атмеге, ибо самая распространенная. Когда-нибудь это изменится, армы захватят все. Но пока то это не так

Согласен. Причём думаю, что если бы не появление ардуинки, то это уже давно произошло бы. )))

E>Фреймфорк не нужен? Можно без него, но с ним часто удобнее. Собственно громкое слово фреймворк обозначает достаточно тонкую обертку над железом

Всегда стараюсь использовать в своей работе готовые сторонние библиотеки (зачем писать самому что-то, уже готовое и отлаженное), но при этом терпеть не могу всяческие фреймворки. Понятна моя мысль? ) Да, а фреймворки, замахивающиеся на уродование языка вдвойне хуже. Причём последнее уже не просто дело моего вкуса, а известный вопрос, который подробно обсуждали на этом форуме. Правда не в контексте ярдуинки, а на других примерах.

_>>Я же не собираюсь повторять их устройство с кучей ненужных компонентов) И я тебе кажется уже продемонстрировал, что свой вариант будет дешевле (если конечно не считать производства платы и затрат времени, но для процесса разработки это в любом случае удобнее выходит).
E>Дешевле? Я схожу на почту 1 раз, а ты — 10. Это дороже Опять жеж, придется самому паять, автомат явно паяет лучше тебя. Нужна макетная плата или нужно заказать печатную плату для себя. В одном экземпляре — она получится золотая.
E>Не, если цель — потренироваться в пайке и это доставляет удовольствие — почему нет. Но мне к примеру хочется решить конкретную задачу, и это прозе всего сделать купив готовое

Это только в том случае, если ты обойдёшься для своего устройства исключительно голой платкой с ардуикой. Но мы же говорим не про учебные примеры, мигающие светодиодиками? ) Соответственно тебе потребуется или искать комбинацию готовых шилдов (если наберутся подходящие по параметрам) или всё равно делать свой. Причём в итоге у тебя получится устройство в несколько раз больше моего (т.к. бутерброд) и содержащее кучу ненужных компонентов.

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

_>>Дёшево — не принимается, уже показано.
E>не показано

Были же ссылки на али) Готовые платки стоят одинаково смешные деньги (меньше 200 рублей).

_>>Можно не уметь паять — не принимается, полно плат и на STM32.
E>Полно. Насколько они совместимы друг с другом и с шилдами?

Ну как раз самые дешёвые платки на STM32 выполняют в форм-факторе ардуинок, так что шилды от ардуинки туда легко встанут (хотя я против этой кривизны). Другое дело что для них там вряд ли будут готовые библиотеки, как в ардуинке. Хотя написать их опять же нет проблем, тем более, что в STM32 почти все выводы переназначаются как хочешь. В общем все возможности пойти по кривому пути есть и на STM32.

_>>Можно не иметь отладчика — да. Но я не очень вижу смысл в экономии 200 рублей.
E>да тупо проще старт. Кроме того, зачем он, если задача простая?

При этом ты по сути платишь за наличие кусков программатора в каждом своём конечном устройстве. Вместо покупки одного навсегда. Это уже не говоря о возможностях отладки — в ардуинках это достигается изменением кода (заметным увеличением), так что отладочный вариант может и не влезть в память. Да и отладка чего-то в реальном времени становится сомнительной.

Здравствуйте, alex_public, Вы писали:

_>Ну так мы как раз особенности (убогости) платформы и обсуждаем. Так расскажи как же нам "на нормальном C++" задать размещение переменных в разных типах памяти? )

Да, С++ — убогий язык, увы. И что? Почему производители контроллеров должны подстраиваться под него? Видишь ли, фон-неймановская архитектура хороша для универсальных компьютеров, где заранее неизвестно какие на них будут выполняться программы, сколько будет занимать памяти код, а сколько данные. У контроллеров назначение иное — их программируют один раз и вставляют в железяку и он там работает до конца жизни. Поэтому для таких применений можно использовать гарвардскую архитектуру как более эффективную.

Сигнальные процессоры заточены на то, чтобы выполнять инструкции вида Sum(Ki*xi), поэтому там областей памяти еще больше: одна для хранения коэффициентов, другая для x-ов, бывает даже третья для записи результатов, ну и для хранения команд тоже отдельная. Поэтому программировать его на С++ затруднительно. Но значит ли это что это плохие процессоры? Просто у них свое применение.

Здравствуйте, enji, Вы писали:

E>atmel studio — это gcc-avr вообще-то За макросом ISR как раз и стоит gcc-шный атрибут, который функцию помечает специальным образом, после чего для нее генерируются специальные пролог и эпилог

Ну, и что? Факт тот, что программисту не требуется "писать пролог/эпилог, сохранять регистры и использовать специальную инструкция возврата.

E>Атрибут нестандартный и скажем на IAR другой способ пометки таких функций

Это плохо?

Здравствуйте, qwertyuiop, Вы писали:

_>>Ну так мы как раз особенности (убогости) платформы и обсуждаем. Так расскажи как же нам "на нормальном C++" задать размещение переменных в разных типах памяти? )
Q>Да, С++ — убогий язык, увы. И что? Почему производители контроллеров должны подстраиваться под него? Видишь ли, фон-неймановская архитектура хороша для универсальных компьютеров, где заранее неизвестно какие на них будут выполняться программы, сколько будет занимать памяти код, а сколько данные. У контроллеров назначение иное — их программируют один раз и вставляют в железяку и он там работает до конца жизни. Поэтому для таких применений можно использовать гарвардскую архитектуру как более эффективную.

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

В отличие от кривой архитектуры AVR. Сколько там видов функции printf у них в стандартной библиотеке? )))

Q>Сигнальные процессоры заточены на то, чтобы выполнять инструкции вида Sum(Ki*xi), поэтому там областей памяти еще больше: одна для хранения коэффициентов, другая для x-ов, бывает даже третья для записи результатов, ну и для хранения команд тоже отдельная. Поэтому программировать его на С++ затруднительно. Но значит ли это что это плохие процессоры? Просто у них свое применение.

DSP — это вообще другая тема, т.к. это не универсальные процессоры. Ты бы ещё FPGA привёл как пример (их кстати тоже можно на C++ программировать).

Здравствуйте, koandrew, Вы писали:

_>>Да, атмел явно очень повезло, что создатели платформы ардуино взяли за базу именно их семейство процессоров. Думаю что без этого они бы давно стухли на фоне более совершенных конкурентов. Хотя у них там вроде как и появились какие-то avr32, но они похоже никому не нужны.
K>Да-да, где-то я уже это слышал. А, вспомнил — от знакомых PICоводов. Тока вот атмеловские процы лучше PICов по всем параметрам — начиная от энергопотребления и заканчивая производительностью. И я уж промолчу про то угрёбищё, которые Microchip почему-то называет "ИДЕ". А в своём сегменте у AVR конкуренты заметно хуже.

http://www.ixbt.com/news/2016/01/21/microchip-atmel-3-56.html новость в тему. Интересно что получится в итоге и будет ли теперь вообще будущее у AVR.