[jcxz 184]

8 часов назад, haker_fox сказал:

Каким образом, что-то вариант не приходит подходящий в голову).

Банальным переполнением стека. Или выходом индекса массива за допустимый диапазон.

8 часов назад, haker_fox сказал:

Да, этот вариант я тоже рассматривал. И даже маленько поигрался в компилятором javac. Вот только не понял, как можно заставить компилятор обращаться к своему API? В си/си++ я бы сделал таблицу указателей на функции. Ну вот, похоже, что без указателей никуда. А в случае с явой. Напишу, например код

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

Грубо говоря: создаёте базовый класс

class Gpio { virtual void PinSet(); virtual void PinClr(); }, 

а от него уже порождаете необходимых наследников

class GpioPinA : public Gpio { void PinSet(); void PinClr(); };

class GpioPinB : public Gpio { void PinSet(); void PinClr(); }

и т.д. И создаёте массив классов Gpio инициализируя его нужными экземплярами дочерних классов.

За детали я не ручаюсь - давно уже с явой дело имел, может что-то забыл. Может это и невозможно. Так что если есть более сведущие товарищи - поправьте меня.

8 часов назад, haker_fox сказал:

Т.е. если программа зависнит (зациклится) её можно будет "прибить"? Можете пояснить чуть подробнее, каким образом можно понять, что программа слишком долго находится в цикле, и как прекратить её исполнение?

Точно так же, как это делает WDT в традиционных устройствах. Т.е. - сам WDT не определяет, проверяемая программа говорит ему что она исправна.

8 часов назад, haker_fox сказал:

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

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

8 часов назад, haker_fox сказал:

Такое решение мне не приходило в голову, но это тоже вариант!

Вообще, из тех вариантов, что я написал, самый оптимальный как мне кажется - парсер асм-листинга. Это будет работать значительно быстрее чем эмуляция в режиме интерпретатора. Защиту памяти системного ПО при этом лучше возложить на MPU, а контроль адресов переходов - программной эмуляцией.

1 час назад, haker_fox сказал:

Ах да, и ещё одна причина - сегодня контрооллер на cortex-m3, завтра на mc68000. Прикладное ПО не должно быть аппаратно зависимым.

Такое ощущение, что строите какого-то супер-пупер-мега-сферического-коня-в-вакууме.   Который никогда не будет достроен.

Без обид, просто впечатление 

[Kabdim 0]

Добавлял луа в своё, по моему убеждению нужно будет добавлять и lua-отладчик на целевой железке, либо писать эмулятор железки на компе. Минус в том что базовый тип double не очень то подходит для embeded.

Быстрое гугленье говорит что есть интерпретаторы для standalone webassembly, который по духу весьма похож на то что вам нужно. Тут и полная отвязка от железа и возможность писать на множестве языков. Одна беда эти проекты написаны либо на go, либо на rust. Так что полагаю что этот вариант для "сильных духом" на текущий момент. Хотя wasmi выглядит на первый взгляд рабочим вариантом для эмбедеда.

[mantech 34]

1 час назад, Kabdim сказал:

Одна беда эти проекты написаны либо на go, либо на rust. Так что полагаю что этот вариант для "сильных духом" на текущий момент.

Скорей для тех, кому делать нечего, а руки чешутся 

2 часа назад, haker_fox сказал:

Ах да, и ещё одна причина - сегодня контрооллер на cortex-m3, завтра на mc68000. Прикладное ПО не должно быть аппаратно зависимым.

Тогда и порты делайте одинаковыми, а то совсем независимым не получится... Пример - виртуалка на МХ6 порт включения модема PC3,  а на allwinner A20 - PH4.  Алгоритм-то один, прогу переписывать не надо, но порты другие, номера уартов другие и т.п.  Конечно, можно сделать условной компиляцией или по ИД чипа, но это нужно учесть...

[AlexandrY 2]

19 hours ago, haker_fox said:

1. Пишется на Си, возможно Си++.

ресурсы этой железки весьма скромные: LPC1768, 64 кб ОЗУ, 512 кБ ПЗУ.

На Cи не модно. 
Нынче даже exe-шники под Windows пишут на JavaScript.
И вопрос даже не в том JavaScript или не JavaScript, а в том какой из движков JavaScript взять.

Мне кажется https://duktape.org/ самый честный и компактный. 

 

 

[haker_fox 60]

2 hours ago, jcxz said:

Без обид, просто впечатление 

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

5 minutes ago, AlexandrY said:

Нынче даже exe-шники под Windows пишут на JavaScript.

Уф, не очень силёнв этом: java и javascript вроде не одно и тоже?!

 

Уф, надо думать, спасибо коллеги за изобилие информации!!!!

[_pv 52]

1 hour ago, Kabdim said:

Добавлял луа в своё, по моему убеждению нужно будет добавлять и lua-отладчик на целевой железке, либо писать эмулятор железки на компе. Минус в том что базовый тип double не очень то подходит для embeded.

в luaconf.h есть -DLUA_32BITS , хотя fpu у lpc1768 всё равно нет, но float будет всяко быстрее double,

ну и начиная c 5.3 целочисленная арифметика внутри тоже поддерживается, так что print(3+2) и print(3.0+2) уже не одно и то же.

а в eLua есть возможность убрать плавающую запятую совсем, так что lua_number будет целочисленным.

[AlexandrY 2]

2 hours ago, haker_fox said:

Уф, не очень силёнв этом: java и javascript вроде не одно и тоже?!

embedded Java компилируется в нативный код так же как и Cи, а embedded JavaScript интерпретируется.
Хотя Visual Studio Code написан на JavaScript и не отличить по быстроте от нативных приложений. 
Но главное,  что для Java нормальных открытых проектов под микроконтроллеры как-то не видно.

 

[mantech 34]

2 часа назад, AlexandrY сказал:

Нынче даже exe-шники под Windows пишут на JavaScript.

Идиотов и лентяев у нас на века припасено...К сожалению

24 минуты назад, AlexandrY сказал:

для Java нормальных открытых проектов под микроконтроллеры как-то не видно.

Наверно потому, что большинство функционала ненужно и тяжело для МК...

[Kabdim 0]

3 часа назад, _pv сказал:

в luaconf.h есть -DLUA_32BITS , хотя fpu у lpc1768 всё равно нет, но float будет всяко быстрее double,

ну и начиная c 5.3 целочисленная арифметика внутри тоже поддерживается, так что print(3+2) и print(3.0+2) уже не одно и то же.

а в eLua есть возможность убрать плавающую запятую совсем, так что lua_number будет целочисленным.

Рад что они взялись за ум. По личным ощущениям я больше луа в проекты брать не буду, даже после этого.

 

Еще в копилку идей есть MicroPython.

3 часа назад, mantech сказал:

Скорей для тех, кому делать нечего, а руки чешутся 

Почему бы и нет. Я посматриваю за развитием раста и с каждым годом они его пилят в правильном направлении и с приличной скоростью. Что на фоне тех же ++ вызывает просто слезы умиления. Да и у них есть подгруппа которая отвечает за удобство использования раста в ембедеде. Так что в плане собрал, запустил и отладил без экспертных знаний по всем участвующим подсистемам, у них там уже вполне приемлемо.

[AlexandrY 2]

41 minutes ago, mantech said:

Идиотов и лентяев у нас на века припасено...К сожалению

Наверно потому, что большинство функционала ненужно и тяжело для МК...

Да нет, там лицензирование скорее убило развитие.
Я на embedded Java программировал GSM модули еще лет 10 назад. А тогда они были на хилых ARM7 и хватало ресурсов. 
Это была проприетарная Java с закрытыми сорсами. 

 

[Kabdim 0]

Ничего себе вы лихо перескакиваете в аргументах с Java на JavaScript и обратно. При том что это в корне два разных языка.

[AlexandrY 2]

4 minutes ago, Kabdim said:

Ничего себе вы лихо перескакиваете в аргументах с Java на JavaScript и обратно. При том что это в корне два разных языка.

В корне разными языки делают только либы. 
На embedded у вас с какими угодно языками будет все тот же набор либ там из FatFS, lwIP и проч. по мелочи. ну и стандартные либы Си 
 

[Arlleex 131]

5 минут назад, AlexandrY сказал:

В корне разными языки делают только либы...

Java даже не похож на JavaScript, к тому же JS - скриптовый язык для браузеров и вовсе некомпилируемый...

[Kabdim 0]

Позвольте не принять ваше преложение свести тему к флейму. Для справки java - типизируемый язык, а JavaScript типчный представитель нетипизированных языков. Не говоря уж о более глубоком разборе. Ну и библиотеки, как вы уже отметили, у них настолько же разные. А то что механизм проброса вызовов нативного кода существует, то это не делает язык одинаковым с любым другим у которого есть аналогичный механизм.

[AlexandrY 2]

4 hours ago, Kabdim said:

Позвольте не принять ваше преложение свести тему к флейму. Для справки java - типизируемый язык, а JavaScript типчный представитель нетипизированных языков. Не говоря уж о более глубоком разборе. Ну и библиотеки, как вы уже отметили, у них настолько же разные. А то что механизм проброса вызовов нативного кода существует, то это не делает язык одинаковым с любым другим у которого есть аналогичный механизм.

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