[alexunder 4]

Приветствую!

Для конфигурации ИМС используем набор регистров, доступных по интерфейсу SPI. Регистры бывают разной длины (как правило, не больше 14 бит), отдельные поля внутри регистров так же могут быть разной длины.

Для первичного тестирования поведения чипа в статическом режиме я сделал форму, в которой содержимое отдельных полей каждого регистра может меняться на лету.

Пример такой формы с картой регистров представлен на картинке ниже. Регистры расположены по вертикали, содержимое регистров (отдельных битовых полей) - по горизонтали. Внутри каждой ячейки отображено имя поля и его текущее значение. Принцип работы прост: оператор нажимает на ячейку, меняет значение, форма отсылает команду по SPI, оператор наблюдает, что происходит с ИМС и т.д.

Для каждого проекта своя карта регистров, которая "подцепляется" к форме из JSON файла.

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

Наверняка многие сталкивались с задачами удобного отображения конфигурации регистров. Буду рад, если кто-нибудь поделится своими или чужими визуальным решениями.

 

[Arlleex 131]

Analog Devices, например, делают утилиты для работы с демобордами. Вот морда для управления синтезатором ADF4351

 

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

[jcxz 184]

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

Наверняка многие сталкивались с задачами удобного отображения конфигурации регистров. Буду рад, если кто-нибудь поделится своими или чужими визуальным решениями.

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

[k155la3 26]

Я бы использовал Ваш дизайн, но с коррекцией как у AD Arlleex те использовал комбо-боксы для битовых полей внутри регистра. 

При этом не существенно, что там в битах. Левее (правее) - отображать значение регистра в HEX и бинарном (побитно), с указанием разрядности регистра.

Такая абстракция ближе к описанию регистров из документации. То что у AD - сложнее связать с регистрами из док-ии., но для работы с прикладной ф-ей

(покрутить настройки) может и более удобно.

? а какой софт использовать собираетесь ?

 

 

[alexunder 4]

6 hours ago, jcxz said:

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

В идеале так и должно быть. Но функционал регистров меняется от проекта к проекту, а сочинять функционально-ориентированный интерфейс как у AD из сообщения @Arlleex для каждого чипа лень да ни не всегда требуется. Например, на картинке в первом сообщении в середине есть несколько 9-битовых полей - это ЦАПы для установки внутренних смещений. Их можно было бы обернуть в источники напряжения с установкой напряжения, а не кода. Но в другом проекте их может не быть вообще. На моей картинке есть так же регистр адреса столбца (чип - КМОП сенсор изображения) - rowaddress, а в других проектах адрес может выбираться не через регистр, а внешними синхр. импульсами. В общем, карта битовых полей - наиболее универсальное средство в моем случае.

 

 

 

 

5 hours ago, k155la3 said:

Я бы использовал Ваш дизайн, но с коррекцией как у AD Arlleex те использовал комбо-боксы для битовых полей внутри регистра. 

При этом не существенно, что там в битах. Левее (правее) - отображать значение регистра в HEX и бинарном (побитно), с указанием разрядности регистра.

? а какой софт использовать собираетесь ?

 

 

Спасибо. Да, отображения в недесятичных форматах давно нужны.

Софта нет как такового. Эта форма общается с программой на Питоне, а последняя по интерфейсу CameraLink с платой, на которой находится тестируемый чип.

[AlexandrY 2]

6 hours ago, alexunder said:

Софта нет как такового. Эта форма общается с программой на Питоне, а последняя по интерфейсу CameraLink с платой, на которой находится тестируемый чип.

А какими тулсами сделана ваша программа и как она общается с Питоном? 
Это вообще под Windows программа? Странный вид окна. 

[alexunder 4]

3 hours ago, AlexandrY said:

А какими тулсами сделана ваша программа и как она общается с Питоном? 
Это вообще под Windows программа? Странный вид окна. 

Конечно же Windows, просто Windows 7 :) Форма сделана на C# с использованием (стыдно признаться) WinForms, собрана в DLL (SpiRegistersTable.dll). У формы есть несколько делегатов, которые будут вызываться на события по обновлению поля регистра, запросу на чтение всех регистров и т.п.

public event EventHandler<RegFieldEventArgs> FieldChangedEvent = delegate { };
public event EventHandler<SeqcRestartArgs> SeqStartEvent = delegate { };
public event EventHandler ReadAllRegs = delegate { };

Затем эта DLL подцепляется к Питону:

# импортируем сборку, используя CLR
import clr
clr.AddReferenceToFileAndPath("SpiRegistersTable.dll"));
from SpiRegistersTable import RegsControlForm; # из пространства имен библиотеки SpiRegistersTable вытаскиваем нужный класс

regs_ctrl = RegsControlForm(default_spi_cfg, 'notdef', False); # создаем экземпляр формы RegsControlForm
# подписываемся на делегаты формы
regs_ctrl.FieldChangedEvent += field_change_handler;
regs_ctrl.SeqStartEvent += start_sequence;
regs_ctrl.ReadAllRegs += synchronize_registers;

# обработчики событий 
def field_change_handler(*args):
    pass; # обработка изменения поля регистра
    
def synchronize_registers(*args):
    pass; # вызов чтения всех регистров из DUT

Мы используем Питон, реализованный на C#, именуемый IronPython. К такому питону посредством CLR легко подцепляется всё что написано на .NET. В свое время это сделало его очень популярным, но Microsoft забросили его в последние годы (как и многие другие замечательные вещи) и теперь проект не развивается. Мы постепенно переходим на обычный Питон (именуемый также CPython), но и в него можно "протащить" дотнетовские сборки.

В общем же Питон используется для быстрого написания тестовых скриптов инженерами-тестерами. Как показывает практика, это намного эффективнее использования компилируемых языков. А уж из Питона "видна" вся тестовая система, включая шину SPI, на которой сидит тестируемый DUT, на которую "выплёвываются" посылки, сформированные обработчиками событий от формы.

 

[AlexandrY 2]

Как то очень уж заморочено. 
Неужто не было чего поудобнее? 
Например визуальный фреймворк типа ucProbe? 

[alexunder 4]

7 minutes ago, AlexandrY said:

Как то очень уж заморочено. 
Неужто не было чего поудобнее? 
Например визуальный фреймворк типа ucProbe? 

В чем именно замороченность? По-моему, все очень просто.

uCProbe - это какой-то очередной LabView, заточенный под работу с конкретными МК и вообще он для эмбеда. А у нас не эмбед совсем.

[_pv 52]

имхо от именно битовой карты регистров толку не особого нет. только место занимает.

сделайте определение отдельных полей, причем зачем там вообще JSON?, их по идее из хедера просто брать надо, чтоб два раза не описывать регистры.

#define REG_MA 0x01

  #define MA_addr REG_MA, 1, 1     //reg address, size_bits, offset

#define REG_TUNER 0x1F

  #define ptunerbits_videobuf REG_TUNER, 5, 5 

и потом из этого получится куча полей ввода/чекбоксов (для 1битных значений), которую при желании можно группировать по регистрам как на картинке Arlleex.

[AlexandrY 2]

1 hour ago, alexunder said:

В чем именно замороченность? По-моему, все очень просто.

uCProbe - это какой-то очередной LabView, заточенный под работу с конкретными МК и вообще он для эмбеда. А у нас не эмбед совсем.

Ну как, во-первых вам надо одновременно работать с двумя языками и переключаться между средами. 
Во вторых нужно на память знать имена ивентов в одной среде чтобы вручную писать их в другой. 
Т.е. вся типозащищеннсть и антибажность C# идет лесом. 
Ну да, конечно можно сказать, что у вас два монитора и копипаста работает без проблем, но...    
Про тайминги даже молчу.
Кстати, почему не эмбед ? Потому что прога на Win7? 

[k155la3 26]

Спасибо за инф.

То что в Вашем посте - скорее "табличный" вид с "примесью" формы. То что у AD - "форма" в чистом виде.

JSON, конечно, легкочитабельный. Надо ли Вам вообще использовать какой-либо стандарт, учитывая что в него придется "впихивать" специфические описания регистров и битовых полей. Мне намного удобнее было описание формата сделать в своем формате (текстовый) и обрабатывать своим-же парсером (в нем указывались вид-представление, литерал-комментарий итд ). Одно значение - одна текстовая строка. 

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

 

[alexunder 4]

25 minutes ago, AlexandrY said:

Ну как, во-первых вам надо одновременно работать с двумя языками и переключаться между средами. 
Во вторых нужно на память знать имена ивентов в одной среде чтобы вручную писать их в другой. 
Т.е. вся типозащищеннсть и антибажность C# идет лесом. 
Ну да, конечно можно сказать, что у вас два монитора и копипаста работает без проблем, но...    
Про тайминги даже молчу.
Кстати, почему не эмбед ? Потому что прога на Win7? 

Уважаемый Александр! Вы зачем-то придрались к (весьма гибкой и удобной) реализации маленькой толики тестовой системы.

Мне несложно оперировать двумя языками. Я лишь единожды подготавливаю общий инструментарий для инженеров-тестеров, а тем требуется только знание Питона для написания тестовых скриптов и их адаптации под конкретный чип. С типозащищенностью и "антибажностью" C# все в порядке как всегда :) Но дело даже не в этом, т.к. тема совсем о другом.

Тестовая система предназначена для первичных тестов, а далее, рутиной обмерки характеристик аналоговых ИМС (КМОП сенсоры). Система (как правило в виде одной "материнской платы") обладает программируемыми источниками питания, процессором в ПЛИС для генерации сигналов управления испытуемой ИМС а так же системой сбора кадров изображения и "упаковки" оных в CameraLink. Программы для процессора пишутся на простом Си-подобном языке, вот там-то и обеспечивается жесткий тайминг. Компилируются и вызываются эти микропрограммки из Питона, куда возвращаются полученные изображения. Само собой никакого риалтайма на питоне! Но из Питона оператор может управлять чем угодно: запускать программку в ПЛИС, собирать кадры изображений, проводить их обработку, генерировать отчеты и т.п.

В данной теме я лишь обсуждаю UI для дерганья отдельными битиками внутри регистров конфигурации большого аналогового зверя (как например, на картинке внизу)!

 

 

 

[Reanimatorr 0]

Форма как форма, ничего особенного.

Немного напомнило аналогию с Modbus и популярной утилитой Modbus Poll.

Там из набора регистров собираются так называемые WorkSpace.

По виду набор окошек из табличек 2 столбца много строк.

1 столбец описание, 2 столбец значение.

Далее конфигурится удобное расположение нужных для работы параметров рядом друг с другом, чтобы не смотреть на ненужное и не искать нужное в разных концах свитка.

Получается довольно годно.

Битовые поля не используем, сейчас не время 8-битников, регистров не жалко.