Page 1 of 3
API для SECU
Posted: Tue Jan 15, 2013 6:36 pm
by serge__5518
Обсуждаем создание API для SECU. Набор функций для "сторонних" разработчиков программного обеспечения. Данные функции должны обеспечить простой доступ к контексту SECU как со стороны PC, та и со стороны БК.
Предлагается следующий набор набор функций:
1) Настройка аппаратной части для связи с SECU
bool SetPtotocolSecu(unsigned int aSpeed, unsigned int aPortNo);
2) Подтверждение установки связи с SECU
bool TestPtotocolSecu(void);
3) Чтение версии программного обеспечения SECU, типа процессора, CRC прошивки и др.
bool GetSecuInfo(??????);
4) Чтение данных из RAM SECU в структуру fw_data_t
bool GetActiveContextSecu(fw_data_t* aFw_data_t );
5) Запись данных в RAM SECU из структуры fw_data_t
bool SetActiveContextSecu(fw_data_t* aFw_data_t );
6) Экспорт данных из структуры fw_data_t в файл S3F
bool ExportTablesToS3F(fw_data_t* aFw_data_t, AnsiAtring& aFileName);
Re: API для SECU
Posted: Tue Jan 15, 2013 6:49 pm
by serge__5518
[quote="STC"]Есть класс CComPort, в нем реализована настройка и работа с портом.[quote]
Ок!
Если просмотреть исходники менеджера то есть классы более высокого уровня. Я остановился на CCommunicationManager для обмена с SECU и CFirmwareDataMediator для работы с таблицами и настройками (они подтянут класс CAppSettingsManager как минимум).
Можно ли использовать эти классы? Или их использование "тянет" за собой инициализацию большого числа объектов?
Re: API для SECU
Posted: Tue Jan 15, 2013 8:36 pm
by STC
Я остановился на CCommunicationManager для обмена с SECU
В принципе можно и с него, он выполняет вспомогательную функцию для инициализации и переключении между загрузчиком и прошивкой (обмен данными). За обмен данными с прошивкой отвечает класс CControlApp. За обмен данними с загрузчиком отвечает класс СBootLoader.
Класс ССontrolApp содержит весь необходимый функционал для приема и посылки пакетов в SECU-3 в режиме прошивки. Метод SetEventHandler(EventHandler* i_pEventHandler) устанавливает адрес объекта, который будет получать пакеты от SECU-3. Объект должен быть экземпляром класса унаследованного от интерфейса IAPPThreadEventHandler. Вызовы функций:
Code: Select all
virtual void OnPacketReceived(const BYTE i_descriptor, SECU3IO::SECU3Packet* ip_packet);
virtual void OnConnection(const bool i_online);
производятся из "неродного" потока, поэтому тебе прийдется столкнуться с классом CControlAppAdapter. Этот класс получает приходящий поток данных и направляет его объектам подписавшихся на получение данных. Если не ломать существующую архитектуру, а только адаптировать ее под себя, то больших изменений и мучений наверное быть не должно.
CFirmwareDataMediator тебе пригодится тоже. Этот класс не тянет за собой ничего лишнего, так что с ним будет еще проще.
CAppSettingsManager тебе не нужен, так как он связан с окном настроек менеджера.
Re: API для SECU
Posted: Tue Jan 15, 2013 8:58 pm
by serge__5518
STC wrote:Если не ломать существующую архитектуру, а только адаптировать ее под себя, то больших изменений и мучений наверное быть не должно.
Благодарю. Надо "переварить" все сказанное -).
Да, рассуждаю именно так - адаптировать имеющийся код. Написать внешние функции под интерфейс в шапке.
Смущает наличие "ненужных мне" объектов в этих классах. Если инициализировать указатели на них нулевыми значениями - наверно будет нехорошо -)
P.S.
Обновил файлы анализатора. Чтобы можно было посмотреть, скинул несколько логов(dir Logs) и свою прошивку (dir Soft).
Re: API для SECU
Posted: Tue Jan 15, 2013 9:25 pm
by STC
Смущает наличие "ненужных мне" объектов в этих классах. Если инициализировать указатели на них нулевыми значениями - наверно будет нехорошо -)
Покажешь какие именно, разберемся. Я тебе все точно скажу.
Re: API для SECU
Posted: Tue Jan 15, 2013 9:30 pm
by serge__5518
STC wrote:Покажешь какие именно, разберемся.
Хорошо. Наверно завтра отпишусь.
Re: API для SECU
Posted: Thu Jan 17, 2013 2:06 pm
by serge__5518
STC wrote:За обмен данними с загрузчиком отвечает класс СBootLoader.
Я думаю, необязательно переносить в API весь функционал менеджера( по крайней мере сейчас-). Некоторые функции лучше оставить за менеджером: заливка прошивки, работа с бутлоадером, настройка параметров. В API дать возможность чтения-записи рабочих таблиц (те, что в ОЗУ) и некоторых параметров. Параметры можно условно разделить на две группы: системные и технологические. Например "Нижнее значение давления ДАД"- технологический параметр а "Смещение кривой ДАД"- системный. Т.о. в API дать доступ к технологическим параметрам.
STC wrote:Класс ССontrolApp содержит весь необходимый функционал для приема и посылки пакетов в SECU-3 в режиме прошивки.
CCommunicationManager имеет в своем составе классы CComPort, CBootLoader, CControlApp, CControlAppAdapter, CBootLoaderAdapter. T.o. создав объект CCommunicationManager, я по идее уже не должен думать о реализации этих объектов(классов) и механизмов их взаимодействия. Я так думаю -).
Хотелось бы использовать по-возможности функции(объекты) более высокого уровня, которые не завязаны с реализацией интерфейса менеджера.
А какой вариант ты бы предложил?
Насчет "лишних" объектов я имел ввиду например CBootLoader и CBootLoaderAdapter.
STC wrote:CAppSettingsManager тебе не нужен
нашел такую строку инициализации класса:
m_fwdm = new CFirmwareDataMediator(params.GetFlashParameters());
Поэтому решил, что CAppSettingsManager будет необходим.
Re: API для SECU
Posted: Thu Jan 17, 2013 4:40 pm
by STC
CCommunicationManager имеет в своем составе классы CComPort, CBootLoader, CControlApp, CControlAppAdapter, CBootLoaderAdapter. T.o. создав объект CCommunicationManager, я по идее уже не должен думать о реализации этих объектов(классов) и механизмов их взаимодействия. Я так думаю -).
В принципе так и есть.
Хотелось бы использовать по-возможности функции(объекты) более высокого уровня, которые не завязаны с реализацией интерфейса менеджера.
А какой вариант ты бы предложил?
Насчет "лишних" объектов я имел ввиду например CBootLoader и CBootLoaderAdapter.
Это и есть самый высокий уровень. CBootLoader и CBootLoaderAdapter предлагаю не выкидывать, а перетянуть к себе тоже. Они ведь будут внутри и никому мешать не будут. Вдруг понадобятся...
нашел такую строку инициализации класса:
m_fwdm = new CFirmwareDataMediator(params.GetFlashParameters());
Поэтому решил, что CAppSettingsManager будет необходим.
метод GetFlashParameters() возвражает структуру
PPFlashParam. Просто заполни ее и передай вместо params.GetFlashParameters().
см. файл PlatformParamHolder.*
Re: API для SECU
Posted: Thu Jan 17, 2013 5:39 pm
by serge__5518
STC wrote:В принципе так и есть.
Попробую с CCommunicationManager. Вопросы будут позже -).
Да, хотел спросить - ты пробовал компилировать менеджер под Builder?
STC wrote:Они ведь будут внутри и никому мешать не будут. Вдруг понадобятся
Согласен. Можно просто не давать доступ из интерфейса API
STC wrote:метод GetFlashParameters() возвражает структуру PPFlashParam. Просто заполни ее и передай вместо params.GetFlashParameters().см. файл PlatformParamHolder.*
Здесь не соглашусь. Хотелось бы пользоваться "стандартными" методами менеджера для всех операций с прошивкой. Как в этом случае проще заполнить PPFlashParam?
Re: API для SECU
Posted: Thu Jan 17, 2013 6:13 pm
by STC
Под Builder компилировать не пробовал, да и не получится скорее всего ничего так как код написан с использованием MFC. Кишки, которые ты вытянешь из SECU-3 Manager тебе нужно компилировать с использованием MS Visual Studio и делать в виде динамически линкуемой DLL. Вызавать функции из DLL написанной на MS VS из программы написаной на Builder думаю можно, так как наоборот сделано в менеджере. В интернете есть инфа как это делать (делается через def файл), там вроде отличие только в наличии или отсутствии подчеркиваний в именах ф.
Здесь не соглашусь. Хотелось бы пользоваться "стандартными" методами менеджера для всех операций с прошивкой. Как в этом случае проще заполнить PPFlashParam?
А это и есть стандартный метод. Хотя ты прав, более правильно будет перетянуть к себе класс
PlatformParamHolder. Ему на вход передается только тип МК и все! (см. enum EECUPlatfrom)