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

Я или "в базар не въезжаю", или просто трудно понять любителей жабы на стм и пр. мелких армах... Ну возьмите любой планшетик на какой-нить оси, типа линуксодроида, там уже все есть, и жаба-машина и графика и сеть... пишите и радуйтесь, но ЗАЧЕМ всю эту тягомоть тянуть на мк, заточенный под сишные стандалон-решения???

Ага, только умные люди постарались сделать за вас всю гразную работу, чтоб вы даже не задумывались о выделении/освобождении памяти, зачем, ее же так много. Вот только тема о Cortex-Mx и в данном случае это пустая беседа из разряда "21 век на дворе, а почему вы пишите на C/C++". Умиляет

потому что в своё время под шарп не нашлось tcp-стека совместимого с оборудованием
а как вы реализуете исключения на си ?

Exception
Handler

мы ж говорили об утечке памяти
мне кажется, что вы совсем не о тех исключениях
пример, если что:


если что-то пошло не так:
- освобождаем буферы
- закрываем файлы
- можем делать это вложенно внутри одной функции
- можем откатываться на неопределённое количество уровней вызовов в разных функциях
- можем проанализировать причину исключения, всех исключений
и всё это в три строчки, без всякого шаманства, как в вашем примере

Мы о разных вещах говорим, в примере я вам показал саму кухню железячного механизма исключения на Cortex-M3/4.
Спорить тут бесполезно, я не принижаю достоинства Java, напротив, высокий уровень абстракции и кроссплатформенность это гуд, возможно это стало не последней причиной в выборе Java как платформы для Android-приложений, но никто не знает что стоит за Java-машиной, и как она транслирует слой абстракции на платформу. Удобства оборачиваются повышенными требованиями к ресурсам платформы, от того для Cortex-M это пустой звон.
А исключения на голом C обрабатываются макросами setjmp() и longjmp()

Это не так. Программа на Яве мультиплатформенна до тех пор, пока мультифплатформенны библиотеки, на которые она опирается. С тем же успехом мультиплатформенна программа на Си.

Т.е. хэлловорлд мультиплатформен и возможно даже переносим на уровне байт-кода, а вот что-то посложнее уже большой вопрос


Это ж все о С++, да? Кстати в данном коде в Яве файл будет закрыт при сборке мусора (т.е. неизвестно когда), а в плюсах - при выходе из блока

На данный момент нашел только 1 IDE, в котором есть возможность разрабатывать Java ПО для мк - MicroEJ

Есть альтернативы?

Это в исходном тексте 3 строчки. Но это всё должно обеспечиваться. Любой язык верхнего уровня не устраняет проблемы, а скрывает их. Чем больше возможностей, тем больше код который их обеспечивает. Но это ведь тоже кем-то написано. Не уверен, что без косяков. В случае чего запаришься искать.
Вот и получается что вся эта многоплатформенность, как бы это сказать, не совсем полная. Например отладили Вы код на писишке и радуетесь. Запускаете на МК, компилируя той же студией и из того же проекта и те же исходники, - короче всё тоже.... И бац что-то не так. Потому что библиотеки разные движок разный, компилятор не тот на самом деле ... А что же тогда то? Да только среда разработки. К этому ли стремились?

Предполагается, что качество библиотек выше качества прикладного кода Их просто больше применяли и тестировали.

Прям таки закрыт?
С чего это он будет нормально закрыт если нормально не смог быть открыт.

Вся эта мишура работает только на процессорах с виртуальной памятью. Где процесс можно взять и убить спокойно, а памяти море.
На Cortex-M такой код неприемлем.

Я рассматривал случай нормальной работы, без вылета исключения. В Яве надо или явно закрывать файл в finally или использовать try-with-resources. В плюсах есть деструкторы, этот момент упрощается.


Тут выше приводили примеры микро JVM. Я с таким не сталкивался, интересно насколько существенные там ограничения



А за счет чего эта независимость? Просто переферия даже в рамках STM32F1 - F2 - F3 - F4 местами довольно сильно отличается. Я уже молчу про STM - другой производитель.

Там написан какой-то "толстый" слой совместимости, который эмулирует возможности, отсутствующие в железе?
Или возможности по использованию железа ограничены?
Или для использования железа мы пишем вставки на Си (прощай платформонезависимость) ?

К примеру, в F373 есть автонастройка скорости УАРТа. А в F2/F4 ее нет. Что будет с кодом на Java, который использует эту функцию, при запуске на F4?

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


Здесь с Вами соглашусь. 2500$ на экземпляр как бы обязывает ... Просто ограничения будут очень мелким почерком ... В принципе продукт есть - всё можно почитать, возможности оценить.

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

"Телевидение. Будет одно сплошное телевидение."
Всё это интересно, конечно. Но если посмотреть вокруг, почему-то не видно оглушительной повсеместной победы жабы в мире МК. Наверное, на это есть какие-то причины, не правда ли? Кроме заговора сишников, конечно

ну да, сишники упорно продолжают писать для контроллеров по десять центов
с нетерпением ждём контроллеров по центу

Ну да, вот пока не сделают аппаратную поддержку жабы в мелких мк - "кина не будет"

Боюсь, что если даже и сделают, кина всё равно не будет

Повнимательнее посмотрел на эту бяку IS2T. Вообщем жуть. Явы виртуальной там оч и оч мало, что удивило можно сишные куски добавлять, отдельно компилить и тп. Вообщем солянка мультивитаминная какая-то у этих французов. Причем ява старая сановская вторая или третья 2006 года, не выше! То есть совсем не развитая, поэтому 29 кило всего. И классов не более 4Кило, что то еще от 8-битников осталось. Короче нет вам этой виртуальной явы как думалось. Хотя SDK полный всего.


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


Начиная с Cortex-M4 все там нормально получается в тех рамках виртуальной ява машины. Гарбаш колектора там трудятся прилично.
65К классов вам думаю будет достаточно для многих задач. Многих привлекала простая реализация TCP/IP стака и его уровни.

мне эта SDK тоже жутко не понравилась
есть альтернативы?
как собрать аналог самостоятельно из классического эклипса? сейчас программлю под арм испод эклипса + GCC. Как это довести до "программить для явы"?

уже делали, правда не в самых мелких МК - оказалось никому не нужно.

да тут не нужно, там нужно.


Никак. Самому взять недоделаную виртуальную яву, из любимого GCC и сваять, ограничившись ненужным.


Это вы про андройд, то что он никому не нужен? Ну не скажите ...

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

Как я понимаю для начала вам надо определиться с JVM, а дальше смотреть инструкции к ней - стандартный ли там компилятор, как загружать полученное в процессор и т.п...

Да и без МК тоже оглушительной победы не наблюдается...
Оценивать язык, по простоте обработки исключений, как то не убедительно ... Как говорится: Женитьба существенно помогает решать проблемы, которых у неженатых вообще нет.
Сначало вводим принцип написания, где реалтаймовое динамическое выделение памяти, а потом радуемся изяществу сборщика мусора.

я про Jazelle, которая в мелких МК (хоть ARM9х и похороненный атмелом AVR32AP нельзя назвать мелкими МК, линукс запустить могли, но судя по википедии даже был даже ARM7 c буквами EJ) как-то не прижилась, за ненадобностью.
из кортексов -M выпилили совсем.
в последних -А вроде бы тоже нету, им, как в анекдоте про лося и 50гр, похоже дури и так хватает, справятся и без аппаратного ускорения.

да, это было оригинальное решение - запретить явное уничтожение объектов
в дотнете почему-то решили сделать так же криво
в результате имеем полностью непредсказуемое, по задержкам, поведение программы
хотя вот за остальное, типа качества сбора мусора, я не беспокоюсь

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

Ну вот я явно уничтожил объект - а как быть со всеми ссылками на него? Получается, надо все эти ссылки обнаружить и обнулить? ИМХО, с GC это малосовместимо.

А если исключить GC, то в чем преимущества Явы перед теми же С++?


Сборка мусора приводит к остановке всей программы. В ряде применений это может быть критично

Небыло такого никогда, ищите ошибку в проге.

судя по вашим сообщениям - у вас минимум десятилетний стаж разработки на шарпе
борланд си билдер был глючный преглючный
почему-то в отличие от своей сестрёнки дельфи



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

Сборщик мусора не только освобождает память от ненужных объектов, он ее еще и дефрагментирует ее...

Это ж каком ?


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




на самом деле зависит от сборщика мусора.

Тот, который не стопает, захватывает глобальную критическую секцию на каждую запись ссылки - что вообще говоря тоже не гуд

исключения != плюсы
я бы предпочёл нормально работающий на каком-то оборудовании полный фреймворк
просто подождём поздней осени и f7

Зачем ждать чего то? Пошите под любой андройд на тойже яве.

подсчёт ссылок на объект - это тривиальная задача, успешно решённая до появления явы-какавы или си бимоля. см. COM технологию.
Как это совмещать - рекомендую книгу Джэфри Элджера C++ = там очень интересное и побуждающее чтиво.

сборщик мусора приводит не только к остановке программы (если рассматривать форточки). а приостанавливает работу многих сервисов из ядра системы.
связано с тем, что мелкомягкие давно пытаются (не безуспешно) подсадить на си бимоль всех кто пишет под форточки, явно или не явно.

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

Голова не болела?


kolobok0, тут ява и решетка та что на писюках не интересна никак, тут про JVM в основном речь то, на Cortex-M, точнее с M4 скорее всего. А этот кострат очень живучь для многих приложений, он же переполз на A8...11 и там стал андройдом.

Гуглим, http://stackoverflow.com/questions/1085643...m-for-cortex-m3
половина ссылок мертвые.
IMHO, задаче свое решение.

тогда уж си-диез, нет?

Будет интересно посмотреть на результат какой-нибудь риал-тайм системы на Яве, взлетит ли? Сомневаюсь. Однако, если человеку хочется программировать МК на Яве, пусть программирует.

Jazelle давно есть на жирных Cortex-Axx, но оно и понятно - для Далвика.

Неужели вы думаете, что вшивый МК без MMU будет все за вас чистить и даже дефрагменировать? Для них даже усеченная реализация malloc/free/new/delete используется, а тут такие замашки. Надо выбирать - или только чистим мусор или забиваем на "преимущества" и выполняем пользовательский код

netduino plus 2 работает под микрофреймворком
только с сеткой оне зачем-то конкретно накосячили

Все косяки от того, что существование полноценной JVM без платформы ОС это абсурд. У Oracle нет пункта скачать под IA64 или под Sparc, есть только под ОС. JVM не работает с голым железом. Например, она лишь дополняет работу с памятью, но всё также работая в виртуальной памяти и обрабатывая исключения ОС, если программа полезла в запрещенную область. И память выделяет/чистит она силами ОС. С оборудованием работает через системные вызовы. Портировать JVM легче под ОС, чем под голое железо, хотя бы потому, что вариаций ОС меньше и для работы с ними требуется меньше asm. И, наверное, стека TCP нет в JVM, а есть лишь надстройка над ОС.
Создавая C++ Страуструп не пошел на компромисс монструозность/скорость исполнения кода, и теперь мы пользуем C++ на самых маленьких МК. И да, в нем нет стека TCP/IP и сборщика мусора.

Подсчет ссылок - это такая полуавтоматическая технология сборки мусора. Проблема номер 1 - она не разруливает циклы (но есть штуки вроде weak_ptr, которые помогают это делать вручную). Проблема номер 2 - она тоже не слишком шустрая, и в некоторых случаях проигрывает gc


Ну если сервис написан под .NET, то да, эпизодически в нем происходит сборка мусора

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

Хотелось бы в целом понять. Что именно привлекает автора?
Скажем исключения - для си и для плюсов задача не сказать чтобы архисложная. Здесь больше зависит от того, как написано всё. Если широко используется динамическое выделение памяти или, к примеру, внешние библиотеки ну например FAT, TCP/IP стеки, то действительно, для начала требуется глубоко залезть в эти библиотеки. Если пишешь всё сам и с нуля, то это вообще не проблема.
Как преимущество промелькнула возможность предварительной отладки проекта под писишкой. Ну я тут от обратного иду. Замутил себе симулятор на QT и шпарю. Правда я только GUI и некоторые другие вещи отлаживал. Ну типа клаву, флэш память. Но по хорошему можно и другие вещи прикрутить. Тоже вариант.

Ну если задача браузер написать, то тогда не совсем понятно. Наверное тогда лучше смотреть на более жирные камни с Linux или другой полноценной осью. Мне кажется.

Хотелось бы более конкретно преимущества услышать.

Думаю, под "преимуществами" большинство видит только простоту программирования, чтоб не сидеть с чтением даташитов на мк, а просто впиндюрить программу с псишки... Но легко ничего не бывает, вот и нет ничего путного пока, да и не будет наверно. Могу только предположить то время, когда камни типа аллвиннера,рокчипа и т.п. будут со встроенной памятью, флешкой и будут стоить 3 копейки, что можно будет пихать их в новогодние гирлянды, то тогда мигание этими лампочками можно будет писать на жабе, в браузере или на пхп.... Вот тогда заживем!

ЗЫ. самому как-то захотелось простоты, решил замутить свой мк с вирт. машиной, но только ориентированной на работу с периферией, это еще куда ни шло, а жаба, от нее в таком случае какой толк??

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

Сишники освоят жабу и вздохнут с облегчением

Если честно я сам пока не знаю, как это юзать и зачем. НО вижу в этом дополнительный инструмент для создания устройств и решений.
Поэтому сейчас неспешно изучаю как это юзать и куда можно применить.

Как никак альтернативная ветка эволюции...

А оно и сейчас уже так... Потребность embedded программистах невысокая, зарплата низкая. Рулят различные php, java, и т.п. И з/п у них значительно выше.
По крайней мере у нас.
Причина, наверное, в том, что этих программистов могут нанять конторы из-за бугра. Впрямую или ч/з национального посредника.
Такой вариант с embedded не просматривается ...

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