История изменений
Исправление KivApple, (текущая версия) :
Посмотрел. Очень круто.
Однако мой проект имеет несколько иную специфику. Я по максимуму использую C++ и ООП. Например, для моей системы можно написать библиотеку поддержки I2C-расширителя IO, который будет обычными GPIO с точки зрения всех остальных модулей (в том числе его можно будет передать как параметр в качестве пина CE для какой-нибудь NRF24L01). Или внешний АЦП будет ничем не отличаться от внутреннего с точки зрения работы с ним.
При этом когда надо можно достучаться до вещей, особенных для конкретной платформы - помимо реализации методов базового класса каждая реализация периферии добавляет свои собственные методы.
А ещё поддержка Linux. Чтобы можно было собрать проект для Linux-одноплатника с GPIO и прочими интерфейсами и работать с ним как с МК. Разве что риалтаймовость на такой платформе слетит, но она не всегда нужна. Пока, правда на платформе Linux поддерживается только UART, но потом добавлю i2c-dev и GPIO. Благо у меня есть BananaPi, OrangePi и второй CubieBoard.
В далёкой перспективе добавить ко всему этому графический конфигуратор, чтобы можно было настроить периферию (в том числе задать имена объектам) и сохранить в конфигурационный файл. Соответственно, проект сможет иметь несколько конфигураций, выбираемых при сборке, с объектами разных классов (разные реализации одной и той же периферии) и с разными параметрами, но одинаковыми именами. Если основной код будет использовать только методы платформонезависимых классов, то его легко будет собрать под другую плату/МК.
Собственно, сейчас это выражается в примерах в том, что почти вся инициализация периферии МК выполняется в виде глобальных объвлений объектов (параметры передаются конструктору), а основная программа сразу начинает выполнять задачу.
В отличии от Arduino я хочу поддерживать нормальные платформы (ARM) и кастомные платы, а не горстку типовых платок на AVR. Плюс при желании легко дать доступ к аппаратным особенностям. В отличии от конфигураторов типа STMCube кроссплатформенность.
Исправление KivApple, :
Посмотрел. Очень круто.
Однако мой проект имеет несколько иную специфику. Я по максимуму использую C++ и ООП. Например, для моей системы можно написать библиотеку поддержки I2C-расширителя IO, который будет обычными GPIO с точки зрения всех остальных модулей (в том числе его можно будет передать как параметр в качестве пина CE для какой-нибудь NRF24L01). Или внешний АЦП будет ничем не отличаться от внутреннего с точки зрения работы с ним.
При этом когда надо можно достучаться до вещей, особенных для конкретной платформы - помимо реализации методов базового класса каждая реализация периферии добавляет свои собственные методы.
А ещё поддержка Linux. Чтобы можно было собрать проект для Linux-одноплатника с GPIO и прочими интерфейсами и работать с ним как с МК. Разве что риалтаймовость на такой платформе слетит, но она не всегда нужна. Пока, правда на платформе Linux поддерживается только UART, но потом добавлю i2c-dev и GPIO. Благо у меня есть BananaPi, OrangePi и второй CubieBoard.
В далёкой перспективе добавить ко всему этому графический конфигуратор, чтобы можно было настроить периферию (в том числе задать имена объектам) и сохранить в конфигурационный файл. Соответственно, проект сможет иметь несколько конфигураций, выбираемых при сборке. Если основной код будет использовать только методы платформонезависимых классов, то его легко будет собрать под другую плату/МК.
Собственно, сейчас это выражается в примерах в том, что почти вся инициализация периферии МК выполняется в виде глобальных объвлений объектов (параметры передаются конструктору), а основная программа сразу начинает выполнять задачу.
В отличии от Arduino я хочу поддерживать нормальные платформы (ARM) и кастомные платы, а не горстку типовых платок на AVR. Плюс при желании легко дать доступ к аппаратным особенностям. В отличии от конфигураторов типа STMCube кроссплатформенность.
Исправление KivApple, :
Посмотрел. Очень круто.
Однако мой проект имеет несколько иную специфику. Я по максимуму использую C++ и ООП. Например, для моей системы можно написать библиотеку поддержки I2C-расширителя IO, который будет обычными GPIO с точки зрения всех остальных модулей (в том числе его можно будет передать как параметр в качестве пина CE для какой-нибудь NRF24L01). Или внешний АЦП будет ничем не отличаться от внутреннего с точки зрения работы с ним.
При этом когда надо можно достучаться до вещей, особенных для конкретной платформы - помимо реализации методов базового класса каждая реализация периферии добавляет свои собственные методы.
А ещё поддержка Linux. Чтобы можно было собрать проект для Linux-одноплатника с GPIO и прочими интерфейсами и работать с ним как с МК. Разве что риалтаймовость на такой платформе слетит, но она не всегда нужна. Пока, правда на платформе Linux поддерживается только UART, но потом добавлю i2c-dev и GPIO. Благо у меня есть BananaPi, OrangePi и второй CubieBoard.
В далёкой перспективе добавить ко всему этому графический конфигуратор, чтобы можно было настроить периферию (в том числе задать имена объектам) и сохранить в конфигурационный файл. Соответственно, проект сможет иметь несколько конфигураций, выбираемых при сборке. Если основной код будет использовать только методы платформонезависимых классов, то его легко будет собрать под другую плату/МК.
Собственно, сейчас это выражается в примерах в том, что почти вся инициализация периферии МК выполняется в виде глобальных объвлений объектов (параметры передаются конструктору), а основная программа сразу начинает выполнять задачу.
Исправление KivApple, :
Посмотрел. Очень круто.
Однако мой проект имеет несколько иную специфику. Я по максимуму использую C++ и ООП. Например, для моей системы можно написать библиотеку поддержки I2C-расширителя IO, который будет обычными GPIO с точки зрения всех остальных модулей (в том числе его можно будет передать как параметр в качестве пина CE для какой-нибудь NRF24L01). Или внешний АЦП будет ничем не отличаться от внутреннего с точки зрения работы с ним.
При этом когда надо можно достучаться до вещей, особенных для конкретной платформы - помимо реализации методов базового класса каждая реализация периферии добавляет свои собственные методы.
А ещё поддержка Linux. Чтобы можно было собрать проект для Linux-одноплатника с GPIO и прочими интерфейсами и работать с ним как с МК. Разве что риалтаймовость на такой платформе слетит, но она не всегда нужна. Пока, правда на платформе Linux поддерживается только UART, но потом добавлю i2c-dev и GPIO. Благо у меня есть BananaPi, OrangePi и второй CubieBoard.
В далёкой перспективе добавить ко всему этому графический конфигуратор, чтобы можно было настроить периферию (в том числе задать имена объектам) и сохранить в конфигурационный файл. Соответственно, проект сможет иметь несколько конфигураций, выбираемых при сборке. Если основной код будет использовать только методы платформонезависимых классов, то его легко будет собрать под другую плату/МК.
Исходная версия KivApple, :
Посмотрел. Очень круто.
Однако мой проект имеет несколько иную специфику. Я по максимуму использую C++ и ООП. Например, для моей системы можно написать библиотеку поддержки I2C-расширителя IO, который будет обычными GPIO с точки зрения всех остальных модулей (в том числе его можно будет передать как параметр в качестве пина CE для какой-нибудь NRF24L01). Или внешний АЦП будет ничем не отличаться от внутреннего с точки зрения работы с ним.
При этом когда надо можно достучаться до вещей, особенных для конкретной платформы - помимо реализации методов базового класса каждая реализация периферии добавляет свои собственные методы.
А ещё поддержка Linux. Чтобы можно было собрать проект для Linux-одноплатника с GPIO и прочими интерфейсами и работать с ним как с МК. Разве что риалтаймовость на такой платформе слетит, но она не всегда нужна.
В далёкой перспективе добавить ко всему этому графический конфигуратор, чтобы можно было настроить периферию (в том числе задать имена объектам) и сохранить в конфигурационный файл. Соответственно, проект сможет иметь несколько конфигураций, выбираемых при сборке. Если основной код будет использовать только методы платформонезависимых классов, то его легко будет собрать под другую плату/МК.