0,0
рейтинг
18 ноября 2014 в 17:14

Разработка → Запускаем Java Runtime на 256KB оперативной памяти

image
Действительно, с выходом Java ME Embedded 8.1, полноценный Java-рантайм теперь доступен на плате Freescale K64F, которая несет на борту 256KB RAM и оснащена процессором на базе архитектуры ARM Cortex M4. Еще одной важной особенностью нового выпуска Java ME SDK стала поддержка Eclipse IDE. Страница нового релиза Java ME Embedded 8.1 здесь: http://www.oracle.com/technetwork/java/embedded/javame/embed-me/overview/index.html

Платформа Java ME Embedded 8.1 специально создана для того, чтобы перенести все полезные функциональные возможности Java на устройства с ограниченными аппаратными возможностями и даже, микроконтроллеры. Появление платформы Java ME Embedded, во многом, обусловлено развитием нового направления в информационных технологиях, Интернета Вещей (Internet of Things, IOT). Развитие IoT связано как с новыми возможностями, так и с новыми проблемами. Часть задач, таких как безопасность, работа с сетевыми подключениями, общение с внешними интерфейсами UART, I2C, SPI, GPIO успешно решает Java ME Embedded 8.1. Использование Java вместо нативных инструментов сокращает время выпуска продукта и открывает доступ к значительным трудовым ресурсам. Кстати, а вы знаете, что команда разработки Java ME Embedded почти полностью находится в Санкт-Петербурге? Что еще интересного приготовили наши разработчики вы узнаете дальше…


Некоторые компании уже строят на базе Java ME Embedded коммерческие продукты. Например, компания Gemalto выпускает 3G-модули EHS5 и EHS6 http://m2m.gemalto.com/products/industrial/lga/ehs6.html, а компания ProSyst объявила о создании mPRM — облачного сервиса управления и обновления устройств на базе Java ME Embedded http://www.prosyst.com/about-us/news/detail/?tx_ttnews[tt_news]=51&cHash=c52a9db34219b226c722b9d7b08b9f0a Интерес к использованию Java ME Embedded в качестве гибкой альтернативы нативным программным платформам растет с момента выпуска Java ME Embedded 8, а версия 8.1 является логичным продолжением успеха.

image

Как я уже говорил, новая версия приносит Java ME Embedded в мир микроконтроллеров на базе процессоров с архитектурой ARM Cortex M. Freescale K64F представляет собой платформу прототипирования для серии Freescale Kinetis K64 с очень привлекательной стоимостью. Форм-фактор K64F совместим с Arduino R3 и позволяет использовать массу плат расширения. FRDM-K64F построен на базе MK64FN1M0VLL12 MCU (120 MHz, 1 MB Flash, 256 KB RAM, low-power, crystal-less USB, 100 Low profile Quad Flat Package (LQFP)). FRDM-K64F имеет трехцветный диод и две кнопки, подключенные к GPIO портам, а также, акселерометр-магнетометр FXOS8700Q. Вся встроенная периферия доступна и может быть использована в Java ME приложениях. Как обычно, лучший способ начать работать с платформой — прочесть Getting Started Guide Getting Started Guide

image
Примерно неделю назад, все формальные участники Eclipse PMC (Project Management Committee), Eclipse IP Team и EMO (Eclipse Management Organization) дали добро на выпуск плагина Mobile Tools для Java TM (MTJ) 2.0, на базе которого работает Java ME SDK. Теперь создавать приложения в Eclipse Java ME, разворачивать и отлаживать их на встроенных платформах также просто, как писать приложения на Java SE для дестктопа.

image
Еще одной приятной новинкой Java ME SDK 8.1 стал встроенный программатор Java рантайма для Freescale K64F. Вы можете воспользоваться им сразу после установки Java ME SDK.
1. КликнитенаDevice Manager 8.1 в Windows Tray2. Нажмите на кнопку Flash и выберите ваше устройство, заранее подключенное через USB K64F.
3. Наслаждайтесь: Java ME SDK самостоятельно прошьет ваше устройство свежей версией рантайма Java ME Embedded 8.1
image
image

Свежую информацию и новости о Java ME Embedded и Java ME SDK вы всегда можете найти в нашем блоге https://blogs.oracle.com/javame/
Задать интересующие вас вопросы о Java для встроенных устройств лучше всего здесь: https://community.oracle.com/community/java/java_embedded/java_me_embedded
Великолепный источник информации по Java ME Embedded — это сайт docs.oracle.com/javame.
Александр Белокрылов @alexbel
карма
36,2
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (58)

  • +2
    Жесть, 256кб.
    Я сильно впечатлен работой Оракла.
    • 0
      спасибо
  • 0
    35$ многовато
    • +3
      Это девелоперская плата, сам MCU стоит меньше 10$. Но суть от этого не меняется. Впихнуться в такое маленькое устройство было действительно непросто. Разработчики сломали немало копий, но добились своего.
      • –1
        Не понятно зачем нужны теперь эти подвиги.
        • +2
          Всегда будут находиться области, где самый совершенный и современный набор инструментов не подходит, а нужна какая-нибудь хитрость.

          С другой стороны — в космос раньше брали (может и сейчас даже берут) консервы в обычных жестяных банках. Дешевле оказалось залить в ракету лишние сто литров горючего, чем строить технологическую линию по производству «более легкой космической упаковки».

          Где применение j2me? В банкоматах ставят windows. В телефоны android. На ноутбуки макос. На МКС? Но зачем экономить на спичках — проще нарастить солнечную панель и доставить оперативку. Может быть в каких-нибудь детских игрушках J2ME найдет свою новую инкарнацию? Ой, сомневаюсь…

          Закопайте стюардессу.
          • +1
            Gemalto и Telit, две компании, которые занимают ~80% рынка беспроводных модулей 3G. Gemalto уже 2 года выпускают модули с Java ME Embedded. Модули эти используются и в банкоматах тоже. Java ME Embedded находит сейчас своих пользователей в самых разных отраслях. Автомобилестроение, медицина, умные дома. Везде, где требуется сбор данных, их предварительная обработка и безопасная передача в Облако.
            • +1
              На запрос «j2me» (это актуальный для меня запрос!) хедхантер выдает 1 (одну!) вакансию иос-разработчика.
              Словосочетание «Java ME Embedded» вообще там не встречается.
              Вы как-то можете это прокомментировать?
              • +1
                Слишком рано. Технологии чуть больше года.
                • +3
                  Технология как бы не на самом дешевом MCU работает, требует лицензию на каждое устройство…
          • +1
            А мне вот грустно, что J2ME не продолжила развиваться на мобильной платформе и сейчас вот лишь идёт вялотекущий процесс в сфере микроконтроллеров. Если включить фантазию и представить себе смартфон на J2ME как прямую эволюцию последних ява-мобильников — у такого устройства было бы немало плюсов. Энергопотребление, требовательность к ресурсам, жёсткая системная политика в отношении доступа приложений к автозапуску/сети/камере и пр., никаких незакрываемых процессов в фоне и так далее.
          • +2
            Ну есть ещё много вещей не требующих гигабайтов и гигагерцов, где может пригодиться j2me. Ну например, навскидку — бытовой кондиционер, погодная станция, контроллеры всевозможных двигателей, насосов, различные сигнализации и тд.
          • +1
            В сберовских терминалах на кассах супермаркета, в которые карту вставляешь
          • 0
            в блакбери java есть
  • +3
    цена все ещё имеет значение в Embedded мире
  • +2
    истересно, сколько ест рантайм. Т.е. сколько остается, собственно, приложению =) И сравнить бы с .Net Micro Framework
    на netmf.ru написано:
    Достаточно сказать, что минимальный размер загрузочного модуля .NET Micro Framework составляет 250 Кб.… Кроме того, минимальный объём оперативной памяти микроконтроллера, работающего под управлением .NET MF составляет всего 64 Кб.
    • –3
      Runtime занимает меньше 185 KB, т.е. свободного хипа остаётся больше 60KB
      • +1
        Напоминает Squawk virtual machine на stm32. Встроенной памяти мало и народ подключал внешние модули, только чтобы jvm с hello world запустить
        • +1
          А вот на SunSPOT'ах Squawk бегал отлично. Памяти мне хватало с лихвой.

          Да и stm32 настолько широкая линейка. От F0 до F7 и это только F линейка. Причём там есть такие MCU, у которых 2MB Flash и 256KB RAM на борту, что уже больше чем у описанной в посте K64 от Freescale.
          • 0
            Есть одно отличие — jvm в статье и Squawk это разные виртуальные машины java.
            Большая часть самого Squawk была написана на java…
            MCU с большим объемом RAM памяти и FLASH а так же более высокими частотами, встроенным FPU и т.п. по стоимости приближаются к Allwinner A10/13 и SOC на MIPS 74Kc. А там уже полноценный linux, обычная java и т.п. Да и лицензии на openjdk не нужны

            Какой тогда смысл в таких извращениях как bare metal jvm!?

            Если экономим на милливатах, то java тем более лишняя…
            • +1
              Ну начнём с того, что для нормальной работы 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 машина устраивает вашим задачам.

              • 0
                Ну начнём с того, что для нормальной работы Linux + openJDK на AllWinner A10 нужна не хилая конфигурация, которая может стоить не дёшево.

                Это разовые расходы на всю партию, а лицензии на Java ME Embedded на каждое устройство…
                Вы запускали openJDK на Raspberry PI с Raspbian?

                Нет, но я запускал jamvm на mips платформе под openwrt.

                По поводу милливатов, Java ME Embedded включает API для Power Management. Да и в принципе, можно сделать JVM, чтобы она работала энергоэффективно, а можно нативное приложение написать не энергоэффективно. ИМХО, JVM тут может жить.


                JIT, GC-то ведь никуда не деть! В любом случае, jvm упрощает работу разработчику, но за магию платит аппаратное обеспечение временем выполнения и памятью…

                По поводу Java on a bare metal. Если у вас конечное встриваемое устройство, на котором должна работать ваша прошивка, то зачем вам оверхед в виде операционной системы распределения времени с громадным функционалом? Особенно если Java машина устраивает вашим задачам.


                Если нужна детерменированность, то java доступна только с извращениями. А полноценная ОС может потребоваться, если нужны большинство из функций уже в ней реализованных и абстрагирование от аппаратного обеспечения.
          • 0
            В SunSPOT как бы и частоты выше и пямяти достаточно.
            Its first processor board included an ARM architecture 32 bit CPU with ARM920T core running at 180 MHz. It had 512 KB RAM and 4 MB flash memory. A 2.4 GHz IEEE 802.15.4 radio had an integrated antenna and a USB interface was included
  • 0
    А как там дела с беззнаковыми типами? Мне слабо представляется разработка под микроконтроллеры без них.
    • 0
      А какие проблемы? Если размер числовых типов вам известен, то отсутствие беззнакового типа в жаве вас не должно напрячь.
      • 0
        Ну например чтобы производить арифметические действия придется использовать больше памяти, постоянно конвертировать, следить за переполнением, помнить об операторе >>> и т.п. Видел в некоторых библиотеках попытки формализовать все это, вынести типовые операции в статические методы.
        Погуглив, обнаружил что в java 8 добавили такие методы, что радует!
        • +2
          И самое интересное, что в java me embedded 8 как раз таки нету этих методов:)
        • +1
          Не понимаю, что вы имеете в виду. Целые числа в машинном представлении — это поля. И поле над числами со знаком подобно полю над числами без знака. Так что о каких накладных расходах может идти речь, если операций всего две: сложение и умножение. Не могли бы вы привести пример, который наглядно бы продемонстрировал некомфортную работу в отсутствии беззнаковых чисел? (деление одной битовой маски флагов на другую битовую маску не предлагайте — это изврат, а операция беззнакового сдвига имеется)

          Возможно, в языке стоило бы иметь операции циклического сдвига или еще какие-нибудь, что есть в ассемблерах — поиск первого ненулевого бита например. Но это тема для разговора про Java в целом, а не про Java ME
          • 0
            Немного разобравшись в теме стало понятно, что операции сложения и умножения в java действительно выполняются корректно как для знакового так и для беззнакового представления числа, так как используется дополнительный код. Это отнюдь не очевидно.
            Все же помимо умножения и сложения есть еще деление и остаток от деления, не понимаю почему вы назвали это извратом, мы ведь не только о маске флагов говорим, мы можем работать со значением счетчика например.
            Еще есть сравнение, преобразование в строку, которые тоже не одинаково выполняются для знакового и беззнакового представлений, да мало ли какие еще операции можно придумать. Навскидку — задание длины массива, размера буфера.
            Не зря ведь в java se 8 добавили методы по ссылке выше.
            Если java считает число знаковым, а разработчик беззнаковым — надо думать над каждой операцией, правильно она сработает или нет.
            Самый безопасный способ — преобразовать в переменную более широкого знакового типа, что влечет больший расход памяти, но избавляет от массы других проблем.
          • 0
            Целые числа в машинном представлении полями не являются, так как можно умножить восьмибитное 2 на восьмибитное 128, получить переполнение (256 не влезет в восемь бит и даст 0). Таким образом, получили, что при таком представлении целых существуют делители нуля: 2*128=0
            Делителей нуля в поле быть не может.
            image

            Так что в машинном представлении целые — в лучшем случае — кольца вычетов по разным модулям. Например, восьмибитные неотрицательные целые — кольцо вычетов по модулю 256. Операция умножения должна здесь трактоваться как многократное сложение.
            • +1
              Да, перепутал поля с кольцами. Спасибо. Посыл остается тот же самый — работа с знаковыми числами и работа с беззнаковыми числами амбивалентны.
              Это просто дело привычки.
              У «сишников» возникают разные хитрые вопросы для собеседований — какой тип имеет размер массива? int, unsigned? size_t? Как сравниваются знаковые с беззнаковыми? А если это вычисляемое выражение, в котором перемешаны те и другие значения?
              Не стоит заводить «религиозные войны» какой из подходов лучше. Я лишь опять хочу заметить, что правильно написанный код на жаве не будет иметь существеных оверхедов в сравнении с сишным из-за отсутствия беззнаковых типов.
    • +1
      Да всё там отлично со всеми типами данных, описанными в JLS :) Но так как в Java нет беззнаковых типов, то их нет и в Java ME Embedded.

      Согласен, что это не очень удобно, но обходимо :)
  • 0
    JavaScript на контроллерах STM32: Espruino
    • +1
      Раз пошла такая пьянка, то и Lua на MCU работает
      • +2
        Lua интересно начиналась, и даже подавала некоторые надежны. Только от них больше года уже ничего не слышно.
  • –10
    Ох уж эти извращенцы!
    Жабке и на нормальном компьютере места нет: это говно вообще нигде не нужно!
    А тут еще и на микроконтроллер.
    Эдакая беговая корова: подкованная и оседланная.
    • +6
      Конечно, на ассемблере можно написать все что угодно, но жизнь слишком коротка. :)
      • –1
        Си — не, не слышал?
        • –1
          Попробуйте на си перепрошить тысячи устройств разом.
          • 0
            Вы так непонятно выразились, что вас не поняли.
            Дело скорее в том, что для каждой новой процессорной архитектуры вам потребуется свой инструментарий — всякие там компиляторы, линкеры, дебаггеры, профайлеры…
            А жава-программа будет в принципе одинаково работать что на одном процессоре, что на другом — достаточно портировать на новый процессор *только* виртуальную жава-машину! Вы делаете новый телефон, на котором, допустим, процессор не 64, а 85-разрядный (пример так себе) с другой системой команд и адресацией памяти. Чтобы все существующие программы на си на нем работали — надо их все перекомпилировать и найти ошибки. Чтобы работали все жава-программы — надо только портировать на этот процессор жава-машину.
            • 0
              Именно. Так же можно подменять ваш код на «горячую» удаленно, что является просто супер плюсом.
              Можно даже написать маленький софт, который будет автоматически обновляться с центрального сервера сам.
            • –1
              Проблема всех виртуальных машин — производительность, а для микроконтроллеров это очень важно. Наличие сборщика мусора добавляет ещё одну проблему — непредсказуемые задержки в работе кода, что не очень вяжется с realtime-применениями. Java не имеет механизма указателей, а, значит, становится затруднительной реализация эффективных алгоритмов. К тому же, код на Java просто обречён на постоянные выделения памяти в куче, что тоже снижает скорость.

              В общем, за портируемость приходится платить — в том числе, и размером рантайма (как его кода, так и потребляемой RAM).
          • 0
            Какое отношение имеет ЯП к перепрошивке устройств?
      • –4
        Мне вот интересно: у ардуринщиков мозгов изначально не было или это им ардуйня мозги разъедает?

        А насчет ассемблера — Керниган и Ритчи давным-давно придумали отличный язык программирования высокого уровня. Он настолько прижился, что больше никакой ЯП не способен его затмить. С воистину прелестен!

        А безмозглые ардуринщики пусть хоть жабкоскрипт в свои поделки пихают. Лишь бы в ширпотреб эта дрянь не лезла!
  • 0
    А что можно купить аналогично Arduino, чтобы на нём java запускалась? В статье упоминается Freescale K64F с Cortex M4 но в продаже в России я его не нашёл.
    • 0
      Если речь идет о JavaScript:

      Из гитхаба Espruino:
      1. Linux — WORKING
      2. STM32VLDISCOVERY — WORKING — limited memory so some features removed
      3. STM32F3DISCOVERY — WORKING
      4. STM32F4DISCOVERY — WORKING
      5. STM32F429IDISCOVERY — WORKING over serial (A9/A10). No USB and no LCD support
      6. HY STM32 2.4" — WORKING
      7. HY STM32 2.8" — WORKING — limited memory so some features removed
      8. HY STM32 3.2" — WORKING
      9. Olimexino — WORKING — limited memory so some features removed
      10. Carambola — WORKING — GPIO via filesystem (no SPI or I2C)
      11. Raspberry Pi — WORKING — GPIO via filesystem (no SPI or I2C)
      12. Sony SmartWatch — NOT WORKING — USB VCP support for F2 still needed
      13. MBed platforms — have not worked for a while — full hardware wrapper still required
      14. Arduino — has never worked. Used to compile but probably doesn't any more
      15. LC-TECH STM32F103RBT6 — WORKING, but with some issues (LED inverted logic, BTN needs pullup to work)


      2, 3, 4 — вроде как можно найти в любой забегаловке вроде Чип и Дип.
      • 0
        Нет, именно о Java. Но за ссылки — спасибо.
    • 0
      Raspberry Pi — референсная платформа для Java ME Embedded под Linux ARM
      • 0
        Это да. Но я же просил «аналогично Arduino». Вы же мне предлагаете полноценный компьютер, хоть и одноплатный. На ней и Java SE можно запустить, если уж на то пошло.
        • +1
          Тогда пока только frdm-k64F на farnell.com
          • 0
            Спасибо! Похоже то что нужно :)
            P.S. А это не Вы выступали на JPoint в Москве в 2014 по поводу J2ME? И ещё демонстрировали штативы с Raspberry Pi, феном и лампочкой? :)
  • +1
    Ну что сказать, прогресс не стоит на месте. Если язык C стал когда-то кроссплатформенным ассемблером и упростил переход с одного на новое микроконтроллерное семейство, то Java для встраиваемых еще более упростит разработку. Но конечно не для всех применений это оправдано. Но для определенного сегмента рынка электроники это будет очень хорошим решением с высокой скоростью освоения и скоростью разработки.
    • –2
      Высокая скорость разработки и освоения как правило порождает низкое качество продукта.
      Фиг с ним, когда кривой сайт падает, а вот если холодильник вдруг одновременно включит обогрев No-Frost и экспресс-заморозку, он может и немножко сломаться. Если стиральная машинка начнет заливать воду при работающей центрифуге, она тоже может устроить апокалипсец. Таких примеров можно выдать миллион.

      Э. Дейкстра, кровный враг бедокодеров и оператора GOTO:
      Многократно предостерегал от попыток превратить разработку программ в некий тривиальный процесс; по его мнению, программирование в сути своей — чрезвычайно сложная научная и инженерная деятельность, и никакие новые методы и инструменты не смогут кардинально изменить это положение — они лишь освобождают программиста от части рутинной работы. Попытки же превратить программирование в простое занятие, доступное каждому, обречены на провал.


      • +1
        Все верно, но мы живем в капиталистическом мире мире и если продукт и важна скорость поступления продукта на рынок. Поэтому новые инструменты с высокой скоростью и освоения становятся более востребованными. Можно создать идеальный продукт, но это неимоверно долгая разработка и очень долгое тестирование. В современных временных темпах это может не выдержать конкуренции. Когда-то разрабатывали на чистом ассемблере для процессоров и микроконтроллеров, но сейчас этот сегмент сократился в пользу языка C. Хотя от этого и идет потеря производительности и эффективность компиляции, но скорость вхождения и скорость разработки увеличиваются. Сейчас часть разработчиков C для части тех же задач уступил место С++. Хотя опять же это потеря производительности и эффективности компиляции. А теперь идет переход к Java, а с другой стороны к Arduino-подобным платформам. Это тоже потеря производительности. Но если представить круговую диаграмму всех разработанных электронных устройств на процессорах и микроконтроллерах. Соотношение там меняется.
        Это эволюция.
        А в инженерном плане я вас поддерживаю.
        Недотестированные продукты сплошь и рядом встречаются. Посмотрите например на планшеты, смартфоны. И машины стиральные и холодильники с багами могут быть. И чем сложнее встроенное ПО тем больше там этих ошибок может быть.
        Для этого и существует тестирование. Ну и поэтому некоторым брендом доверяют больше. Ну а потребитель на глючную продукцию все равно находится.
        • 0
          Тесты помогают обнаружить ошибки, но не гарантируют свободы от них.

          Строго формально: никакие тесты не являются доказательством корректности программы (хотя бы потому, что тесты — тоже программы, а значит нужны тесты, потом тесты тестов, потом тесты тестов тестов и так далее).
          Именно по этой причине, программы для ответственных областей пишутся с использованием более жестких подходов и формальных доказательств. А встроенные системы — более ответственный продукт.

          Поэтому зафлуживание индустрии бедокодерами удручает.
          • +2
            При создании сложных программных продуктов появление ошибок является обязательным побочным продуктом.
            Потому что продукты создаются людьми. Большинство из которых ошибаются.
            Если тестирование не делается сразу после разработки его делают потенциальные пользователи продукта,
            которые выступают бесплатными тестировщиками.
            Без тестирования никуда. Если говорить о реальном рынке.

            Подготовка идеального специалиста под конкретную задачу может улучшить положение, но тоже требует времени и денег.
            Если специалист хорошо подготовлен, он будет «стоить» дороже. Если такого топового специалиста за те же деньги можно заменить тремя средними и еще нанять трех тестировщиков. Выбор будет не в его пользу.
            Команда из шести средних людей будет эффективней. И если человек уйдет его будет кем заменить. Это не нарушит структуру разработки.

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

            Так же сейчас спонсируются, разрабатываются и продаются более удобные инструменты для разработки встраиваемых систем. Их рекламируют и популяризируют. Значит потребление растет. А значит количество т.н. вами «бедокодеров» только увеличится. У этих людей мозги по-другому развиты и ставят другие акценты. Ну я не считаю что это плохо. Просто прогресс идет. Раньше без поисковых систем надо было в библиотеке сидеть, а сейчас можно быстро найти информацию. Упрощение процесса разработки дает больше пространство для творчества, если хорошо сделаны инструменты.

            Ну а что-то уйдет в прошлое, как программирование микроконтроллеров на ассемблере (для сложных задач опять же, для порта ОСРВ и сейчас на ассемблере можно написать).

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.