Согласен полностью, что задача получения времени очень сильно зависит от юз кейса. К тому же никто не отменяет того, что современные микроконтроллеры или SoC'и содержат в камне модуль RTC(не уверен, что на всех камнях он именно так называется), который как раз независимо от нагрузки центрального ядра сам ведёт подсчёт секунд, миллисекунд, минут и т.д. и выдаёт уже основной программе, либо другой интегрированной схеме время в атомарном виде.
Интересно:
1. Спорят уже компании давно, что мешало то раньше перейти на OpenJDK тем более с ресурсами Гугла?
2. Затронет ли переход на OpenJDK code base стандартизацию API Андроида? Иначе говоря, JCK будут проходить или просто стянули API + имплементацию?
Ну начнём с того, что для нормальной работы Linux + openJDK на AllWinner A10 нужна не хилая конфигурация, которая может стоить не дёшево.
Вы запускали openJDK на Raspberry PI с Raspbian?
По поводу лицензии, можно купить модуль от Gemalto со встроенной Java ME Embedded и использовать в ваших проектах. Это коммерческая платформа со всеми вытекающими.
По поводу милливатов, Java ME Embedded включает API для Power Management. Да и в принципе, можно сделать JVM, чтобы она работала энергоэффективно, а можно нативное приложение написать не энергоэффективно. ИМХО, JVM тут может жить.
По поводу Java on a bare metal. Если у вас конечное встриваемое устройство, на котором должна работать ваша прошивка, то зачем вам оверхед в виде операционной системы распределения времени с громадным функционалом? Особенно если Java машина устраивает вашим задачам.
А вот на SunSPOT'ах Squawk бегал отлично. Памяти мне хватало с лихвой.
Да и stm32 настолько широкая линейка. От F0 до F7 и это только F линейка. Причём там есть такие MCU, у которых 2MB Flash и 256KB RAM на борту, что уже больше чем у описанной в посте K64 от Freescale.
Судя по Википедии: «The most recent processor, Poulson was released on November 8, 2012.». По всей видимости, что-то не так с Итаниумом. Это то я и отметил для Эльбруса. Могут столкнуться с тем же, что и Итаниум
Поддерживаю Эльбрус как отечественного производителя и надеюсь, что они найдут инвесторов в данный проект помимо оборонки и т.п…
Но у меня есть некие сомнения. Судя по архитектуре, многое делает компилятор вместо аппаратного обеспечения. И там же, кстати, аналогия на x86, где процессор сам выполняет анализ входного потока команд. Это интересное решение, однако я верю, что оптимизировать компиляторы в x86 можно до бесконечности, как и оптимизировать саму микроархитектуру процессоров x86, ARM и т.п., так как там это уже заложено. Если архитектура Элюбруса не подразумевает, что аппаратно будет что-то анализироваться и оптимизироваться, закладываясь только лишь на компилятор, то я боюсь, что это в какое-то время просто поставит в тупик и придётся разрабатывать новую архитектуру, которая уже будет таки заниматься обработкой входного набора команд.
Плюс отсутствие нативной хардварной обработки потока команд может означать, что код, компилируемый JIT компиляторами интерпретируемых языков, таких как Java, будет работать не оптимально.
Есть много статей по поводу сравнения, я лично вынес для себя, что IaR по футпринту делает код меньше. У меня на практике было так, что еле влезали в Flash контроллера, поэтому подобная оптимизация была очень нужна.
По поводу производительности… Не думаю, честно говоря, что сильно отличается на большой системе. В отдельных небольших юз-кейсах — скорее всего есть отличия, но в общем…
clang'ом не пользовался, но вот armcc очень даже не плохо, на мой взгляд :)
Ну в таком случае GCC чуть ли не единственный полноценный вариант. Есть у него только вопросы по оптимизации и т.п., но если не критично, то отличное решение.
Имеется ввиду, что потенциально можно портировать Java ME-E на широкий класс устройств, если есть такая потребность. От кого идут потребности — вопрос, касающийся каждой платформы в частности.
К сожаление не знаю scope API на вашем телефоне. Для вашей задачи необходимо:
1. CLDC 1.1+
2. MIDP 2+
3. JSR135
4. Опционально можно JSR234, там есть крутые темы эквалайзера и т.п… Фактически дополняет JSR135
1. Это реализуется внутренними механизмами JavaME и перешло ещё с мобильных телефоном, где запускался один Джава рантайм и приложения жили каждый в своём изолированном пространстве.
1. Спорят уже компании давно, что мешало то раньше перейти на OpenJDK тем более с ресурсами Гугла?
2. Затронет ли переход на OpenJDK code base стандартизацию API Андроида? Иначе говоря, JCK будут проходить или просто стянули API + имплементацию?
Вы запускали openJDK на Raspberry PI с Raspbian?
По поводу лицензии, можно купить модуль от Gemalto со встроенной Java ME Embedded и использовать в ваших проектах. Это коммерческая платформа со всеми вытекающими.
По поводу милливатов, Java ME Embedded включает API для Power Management. Да и в принципе, можно сделать JVM, чтобы она работала энергоэффективно, а можно нативное приложение написать не энергоэффективно. ИМХО, JVM тут может жить.
По поводу Java on a bare metal. Если у вас конечное встриваемое устройство, на котором должна работать ваша прошивка, то зачем вам оверхед в виде операционной системы распределения времени с громадным функционалом? Особенно если Java машина устраивает вашим задачам.
Согласен, что это не очень удобно, но обходимо :)
Да и stm32 настолько широкая линейка. От F0 до F7 и это только F линейка. Причём там есть такие MCU, у которых 2MB Flash и 256KB RAM на борту, что уже больше чем у описанной в посте K64 от Freescale.
Но у меня есть некие сомнения. Судя по архитектуре, многое делает компилятор вместо аппаратного обеспечения. И там же, кстати, аналогия на x86, где процессор сам выполняет анализ входного потока команд. Это интересное решение, однако я верю, что оптимизировать компиляторы в x86 можно до бесконечности, как и оптимизировать саму микроархитектуру процессоров x86, ARM и т.п., так как там это уже заложено. Если архитектура Элюбруса не подразумевает, что аппаратно будет что-то анализироваться и оптимизироваться, закладываясь только лишь на компилятор, то я боюсь, что это в какое-то время просто поставит в тупик и придётся разрабатывать новую архитектуру, которая уже будет таки заниматься обработкой входного набора команд.
Плюс отсутствие нативной хардварной обработки потока команд может означать, что код, компилируемый JIT компиляторами интерпретируемых языков, таких как Java, будет работать не оптимально.
По поводу производительности… Не думаю, честно говоря, что сильно отличается на большой системе. В отдельных небольших юз-кейсах — скорее всего есть отличия, но в общем…
clang'ом не пользовался, но вот armcc очень даже не плохо, на мой взгляд :)
Про клиента вы ранее не говорили. Он у вас тоже на ARM Cortex-M4?
У меня также интересный случай был с FLASH latency. Надо бы тоже описать.
Другой вопрос — дебагинг.
Имеется ввиду, что потенциально можно портировать Java ME-E на широкий класс устройств, если есть такая потребность. От кого идут потребности — вопрос, касающийся каждой платформы в частности.
1. CLDC 1.1+
2. MIDP 2+
3. JSR135
4. Опционально можно JSR234, там есть крутые темы эквалайзера и т.п… Фактически дополняет JSR135
2. Это ссылка на скачивание Java ME Embedded. www.oracle.com/technetwork/java/embedded/downloads/javame/index.html
Лично у меня лицензия показывается при нажатии мышью. На крайний случай, зарегаться там не сложно :)