Класс для доступа к EEPROM

[titan83]

Здравствуйте, уважаемые коллеги.
Я сейчас работаю над созданием высокоуровневых классов для удобного доступа к железу нашего устройства на ARM9.
И одна из железок - FRAM на 8 килобайт. Доступ к ней осуществляется по SPI шине. С базовыми вещами (чтение, запись, статусный регистр) - все получается нормально. Но хочется правильный класс, абстрагированный от низкоуровневых команд, а вот тут у меня небольшой затык - не могу определиться с тем, как передавать (и забирать) в класс записываемые данные, можно банально по char*, можно чуть поинтереснее QByteArray, но все что-то не то...
По идее в этой памяти должны храниться все переменные, описывающие текущее состояние устройства, поэтому мне надо добиться проецирования некоей структуры напрямую в FRAM, чтобы при любом изменении новые данные сразу оказывались в FRAM без лишних усилий, типа вызова метода записи.
Извиняюсь, если получилось сумбурно, но все же надеюсь, что кто-то подскажет наиболее оптимальную организацию данных в моем случае.
Спасибо.

[Fregloin]

ну передавайте указатель на вашу структуру и ее размер, типа

Код:

struct variables_on_device {
int vars[100];
char vars2[300];
...
};

int MyClass::writeData(void * data, size_t dataSize)
{
//пишем в память кусок ваших данных
}

MyClass device;

variables_on_device deviceVars;

device.write(&deviceVars,sizeof(deviceVars));

Я конечно не открыл для вас что то новое, но во всех WinAPI такой подход, который уже не одно десятилетие работает.
А можете конечно все и через QByteArray передавать, если так удобней.

[navrocky]

Я бы сделал класс, объект которого - настройки конкретного устройства, для изменения настроек используем get/set методы, для отправки изменений в устройство используем метод commit(). Отдельный commit() необходим для оптимального общения с устройством, чтобы не на каждый чих гонялись данные.
FRAM

В методе commit() формируем бинарную структуру настроек и кладем ее в FRAM. В конструкторе считываем FRAM с устройства и раскладываем ее в приватные поля класса.

Как-то так.

[titan83]

Спасибо большое за ответы.
На данный момент реализовал класс для доступа к аппаратной части (как раз read-write).
Далее сделаю по принципу navrocky - это будет очень разумно и уменьшит связанность графической и ядерной частей.

[vizir.vs]

Я организовываю общение с устройством следующем образом.
1-ый уровень - мастер соединения. В этом мастере настройки соединение и команды на чтение/запись с определенного адреса.
2-ой уровень - устройство. В этом устройстве хранится инфа об адресах устройства, его статусы и прочее. В этом же классе реализованы гетеры и сеторы. Ну и мастер является приватным членом этого класса.
3-ий уровень - гуи. В гуи уже идет запрос инфы по требованию и ее отображение.

[titan83]

Я организовываю общение с устройством следующем образом.
1-ый уровень - мастер соединения. В этом мастере настройки соединение и команды на чтение/запись с определенного адреса.
2-ой уровень - устройство. В этом устройстве хранится инфа об адресах устройства, его статусы и прочее. В этом же классе реализованы гетеры и сеторы. Ну и мастер является приватным членом этого класса.
3-ий уровень - гуи. В гуи уже идет запрос инфы по требованию и ее отображение.

Спасибо - вы подтвердили правильность подхода.