Несколько вопросов "для начинающих":

1) Насколько велика опасность остаться без возможности прошивки по USB (при ошибках в программировании)? Что такое "альтернативный вариант загрузки" — кроме того, что при удержании RESET более 10 с отключается watchdog в документации ничего не сказано.

2) Можно ли использовать альтеровские Byteblaster/USBblaster для программирования Blackfin через JTAG?

3) В исходниках настроена только конфигурация Debug. Есть какие-то проблемы с использованием оптимизаций?

4) Прошивка компилируется с Warning-ами. В основном ерунда, смущает
[Warning ld0151]: You may need to specify an initialization file (.dxe) to set up the registers for external memory initialization. Please refer to engineering notes EE-240, EE-314 (http://www.analog.com/ee-notes) and/or ..Blackfinldrinit_code for more information.

5) В файле "Встраивание ПО.pdf" ничего не сказано про #define LTR031_ENDPOINT - пришлось поволноваться, когда крейт стал определяться как LTR-EU-2. Может быть, есть еще переключатели, о которых стоит знать?

6) Какой ltr030.rbf правильный — в ltr_eu_8_16_fw.zip или в ltr_source_1_0_0_1.zip?

7) Получается ли компилировать прошивку GCC? Проблемы/особенности?

8) Есть ли у LCard файловая система для SD-карточки? Web-сервер? Если нет, что подскажете?

1)  "Насколько велика опасность остаться без возможности прошивки по USB (при ошибках в программировании)?"
- По SPI Blackfin доступна для чтения и записи загрузочная Flash-память. Если ошибка в программировании приведёт к переписыванию загрузочной Flash-памяти, то загрузиться Blackfin уже не сможет, по крайней мере, по основному сценарию загрузки. Оценить вероятность такого события я не берусь. Но оно технически возможно.
На этот случай предусмотрен альтернативный сценарий загрузки. В руководстве об этом сказано, см.
http://www.lcard.ru/download/ltr_hw.zip  п.3.2.3, п.3.2.5

2)  К великому сожалению, нет - Это политика Analog Devices.    Про JTAG см. п. 15.3 в том же руководстве.

6) Прошивки ПЛИС о себе говорят во вкладке "отчёт" LTR-cервера во время инициализации крейта. Последняя версия прошивки FPGA для LTR-EU:  1.00.08. Рекомендуется именно она.

8) Файловая система для микро-SD в настоящее время не реализована.

Александр!

1) В руководстве это не написано, но похоже, что "альтернативный сценарий загрузки" заключается в загрузке заведомо рабочей прошивки, испортить которую через ltr030burn.exe нельзя. Правильно? Правда, в моем случае эта "резервная" прошивка почему-то оказалась LTR031, так-что после "длинного" ресета крейт определяется как LTR-EU-2, а не LTR-EU-8/16.

6) Что-то я запутался в обозначениях прошивок/версий. На сайте написано, что LTR030.rbf из http://www.lcard.ru/download/ltr_eu_8_16_fw.zip имеет версию 1.00.07. Зачем-то при загрузке свежий ltrserver v1.5.3.0 заменяет ее на более старую версию 1.0.6.0 из файла ltr010v3_0_5.ttf. Или это прошивки разных ПЛИС?

Игорь. По обоим вопросам придётся подождать 11 января, коллеги ответят. Прошивку из файла  ltr010v3_0_5.ttf физически невозможно залить в крейт LTR-EU. Эта прошивка от крейта LTR-U. C прошивкой версии 1.00.07 пока вполне можно работать, после праздников выложим обновление.  Для дополнительной информации выложите, пожалуйста, текст из вкладки "отчёт" LTR-сервера на момент основной и альтернативной загрузок LTR-крейта.

«Длинный» RESET
[05.01.11 18:16:31.500] (0) SERVER: Starting up LTR-Server v1.5.3.0 (L-CARD)
[05.01.11 18:16:31.531] (4) CRATE_CTL: LTRServiceCrate thread started.
[05.01.11 18:16:31.562] (4) SERVER: UDP auto-discovery mode enabled
[05.01.11 18:16:31.578] (4) CLIENT_CTL: LTRServiceClient thread started.
[05.01.11 18:16:31.843] (4) CLIENT_INIT: Server: im [192.168.0.111] [192.168.18.1] [192.168.91.1]
[05.01.11 18:16:31.843] (4) CRATE_CTL: Scanning USB crates
[05.01.11 18:16:32.015] (6) CRATE_CTL: USB device, crate: ////?//usb#vid_0471&pid_3131#5&f635d31&0&3#{a5dcbf10-6530-11d2-901f-00c04fb951ed}, PIDString = Crate LTR(HS Mode)
[05.01.11 18:16:32.015] (5) CRATE_CTL: Found 1 USB crate(s)
[05.01.11 18:16:32.015] (3) CRATE_INIT: Connecting USB crate...
[05.01.11 18:16:32.078] (7) CRATE_INIT: Init USB crate: OpenLDeviceByName() ok
[05.01.11 18:16:32.125] (7) CRATE_INIT: Init USB crate: GetModuleName() ok
[05.01.11 18:16:32.171] (7) CRATE_INIT: Init USB crate: GetModuleDescription() ok
[05.01.11 18:16:32.171] (3) CRATE_INIT: Crate Info:
[05.01.11 18:16:32.171] (3) CRATE_INIT: + PIDString = Crate LTR(HS Mode)
[05.01.11 18:16:32.171] (3) CRATE_INIT: + DeviceName = LTR031
[05.01.11 18:16:32.171] (3) CRATE_INIT: + SerialNumber = 2D228300
[05.01.11 18:16:32.171] (4) CRATE_INIT: + DeviceComment = Broaching Creation Date May 14 2009
[05.01.11 18:16:32.171] (4) CRATE_INIT: + BootLoaderVersion = 27.200.198.48
[05.01.11 18:16:32.171] (4) CRATE_INIT: + FirmwareVersion = 1.0.0.1
[05.01.11 18:16:38.625] (7) CRATE_INIT: LoadFPGA() -> ok.
[05.01.11 18:16:38.625] (4) CRATE_INIT: + TTF_FILE = C://Program Files//L-Card//ltrserver//ltr010v3_0_5.ttf
[05.01.11 18:16:38.625] (4) CRATE_INIT: + FpgaName =
[05.01.11 18:16:38.625] (4) CRATE_INIT: + FpgaVersion = 0.0.0.0
[05.01.11 18:16:38.625] (4) CRATE_INIT: + FpgaComment =
[05.01.11 18:16:38.625] (4) CRATE_INIT: + BaudRate = 0x0000
[05.01.11 18:16:38.687] (5) CRATE_INIT: LTR031 [2D228300]: crate service started.

Обычный RESET. Прошивка из http://www.lcard.ru/download/ltr_eu_8_16_fw.zip
[05.01.11 18:18:46.390] (0) SERVER: Starting up LTR-Server v1.5.3.0 (L-CARD)
[05.01.11 18:18:46.390] (4) CRATE_CTL: LTRServiceCrate thread started.
[05.01.11 18:18:46.406] (4) SERVER: UDP auto-discovery mode enabled
[05.01.11 18:18:46.406] (4) CLIENT_CTL: LTRServiceClient thread started.
[05.01.11 18:18:46.421] (4) CLIENT_INIT: Server: im [192.168.0.111] [192.168.18.1] [192.168.91.1]
[05.01.11 18:18:46.421] (4) CRATE_CTL: Scanning USB crates
[05.01.11 18:18:46.453] (6) CRATE_CTL: USB device, crate: ////?//usb#vid_0471&pid_3030#5&f635d31&0&3#{a5dcbf10-6530-11d2-901f-00c04fb951ed}, PIDString = Crate LTR(HS Mode)
[05.01.11 18:18:46.453] (5) CRATE_CTL: Found 1 USB crate(s)
[05.01.11 18:18:47.812] (3) CRATE_INIT: Connecting USB crate...
[05.01.11 18:18:47.812] (7) CRATE_INIT: Init USB crate: OpenLDeviceByName() ok
[05.01.11 18:18:47.828] (7) CRATE_INIT: Init USB crate: GetModuleName() ok
[05.01.11 18:18:47.828] (7) CRATE_INIT: Init USB crate: GetModuleDescription() ok
[05.01.11 18:18:47.828] (3) CRATE_INIT: Crate Info:
[05.01.11 18:18:47.828] (3) CRATE_INIT: + PIDString = Crate LTR(HS Mode)
[05.01.11 18:18:47.828] (3) CRATE_INIT: + DeviceName = LTR030
[05.01.11 18:18:47.828] (3) CRATE_INIT: + SerialNumber = 2D228300
[05.01.11 18:18:47.828] (4) CRATE_INIT: + DeviceComment = Broaching Creation Date Nov 16 2009
[05.01.11 18:18:47.828] (4) CRATE_INIT: + BootLoaderVersion = 27.200.198.48
[05.01.11 18:18:47.828] (4) CRATE_INIT: + FirmwareVersion = 1.0.0.1
[05.01.11 18:18:48.828] (7) CRATE_INIT: LoadFPGA() -> ok.
[05.01.11 18:18:48.828] (4) CRATE_INIT: + TTF_FILE = C://Program Files//L-Card//ltrserver//ltr010v3_0_5.ttf
[05.01.11 18:18:48.828] (4) CRATE_INIT: + FpgaName = LTR-030
[05.01.11 18:18:48.828] (4) CRATE_INIT: + FpgaVersion = 1.0.7.0
[05.01.11 18:18:48.828] (4) CRATE_INIT: + FpgaComment = Прошивка ПЛИС EP1C8 контроллера крейта LTR-EU-8(16). L-CARD
[05.01.11 18:18:48.828] (4) CRATE_INIT: + BaudRate = 0x0000
[05.01.11 18:18:48.906] (3) CRATE_READ: LTR030 [2D228300]: module configuration updated. mconfig=000F
[05.01.11 18:18:48.906] (5) CRATE_INIT: LTR030 [2D228300]: crate service started.
[05.01.11 18:18:48.906] (3) CRATE_WRITE: LTR030 [2D228300]: sending STOP+RESET+STOP to slot 1
[05.01.11 18:18:48.906] (3) CRATE_WRITE: LTR030 [2D228300]: sending STOP+RESET+STOP to slot 2
[05.01.11 18:18:48.906] (3) CRATE_WRITE: LTR030 [2D228300]: sending STOP+RESET+STOP to slot 3
[05.01.11 18:18:48.906] (3) CRATE_WRITE: LTR030 [2D228300]: sending STOP+RESET+STOP to slot 4
[05.01.11 18:18:48.921] (3) CRATE_READ: LTR030 [2D228300]: found new module LTR11 (slot = 4, mid = 0B0B)
[05.01.11 18:18:48.921] (3) CRATE_READ: LTR030 [2D228300]: found new module LTR43 (slot = 3, mid = 2B2B)
[05.01.11 18:18:48.921] (3) CRATE_READ: LTR030 [2D228300]: found new module LTR22 (slot = 1, mid = 1616)
[05.01.11 18:18:48.921] (3) CRATE_READ: LTR030 [2D228300]: found new module LTR34 (slot = 2, mid = 2222)
[05.01.11 18:18:48.921] (4) CRATE_READ: LTR030 [2D228300]: change baud rate to 0x0002

Александр!

Собственно проблем пока нет — прошивка из исходников собирается и загружается, DataHook работает как обещано. Ethernet пока не пробовал. При альтернативной загрузке LGraph не работает, но это не принципиально — основную прошивку обновить удается. Так что вопросы, которые я набросал, скорее для углубления понимания, чтобы уверенней себя чувствовать.

Пытаюсь послать данные в крейт по "пользовательскому" каналу. Следующая программа отрабатывает без ошибок, однако сразу после LTR_Send() ltrserver.exe начинает грузить процессор на 99%, так что приходится убивать процесс ltrserver.exe через TaskManager. В чем дело?

#include "stdafx.h"
#include "ltr/include/ltrapi.h"
#pragma comment (lib, "ltrapi.lib")

int _tmain(int argc, _TCHAR* argv[])
{
    DWORD data[] = {0};
    const int N = sizeof(data)/sizeof(data[0]);

    TLTR ltr;
    int err;

    err = LTR_Init(&ltr);
    if (err) return err;

    ltr.cc = CC_USERDATA; // 2;

    err=LTR_Open(&ltr);
    if (err) goto err_exit;

    err=LTR_Send(&ltr, data, N, 100);
    if (err < 0) goto err_exit;

    if (err != N) {
        printf("sent %u words instead of %u//n", err, N);
        goto err_exit;
    }

err_exit:
.......................

Если ltr.cc ставить в номер реально установленного модуля, ltrserver не виснет. Если в номер свободного слота - выдает ошибку, как и должно быть. Стандартный пример "Generate" на ltr34api компилируется и работает правильно.

CC_USERDATA задуман как односторонний канал от крейта к компьютеру. Запись в него по идее приведет к передаче в крейт данных с некорректным значением поля CYFTMMMM (ltr.pdf 4.5.1), и что получится в результате, я сходу не скажу.
Для корректности нам следовало сделать проверку, чтобы запись в CC_USERDATA игнорировалась. Поставлю в todo, спасибо.

Какой способ можете порекомендовать для передачи данных в крейт? Пробую сделать генератор на Blackfin + LTR34. Надо изредка посылать значения амплитуды и частоты.

Изредка - можно попробовать посмотреть в сторону функции putarray через канал управления (cc_control).
Можно брать данные непосредственно из потока вывода (вместо отсчетов обычного LTR34), сделав некий datahook на запись.
Можно попробовать придумать свой виртуальный модуль, который будет виден в каком-то слоте (не USERDATA, а одном из 16 настоящих) и эмулироваться прошивкой blackfin.

Наряду с прошивкой, стоит заглядывать в исходники ltrserver и ltrapi. Кстати, и их при желании можно модифицировать под свои нужды. Например, преобразовать запись USERDATA в какие-нибудь командные слова.

Сделал в Blackfine генератор синуса и мультиметр (AC, DC, фаза) - вроде бы работает. ltrserver и api получилось использовать как есть. Для «общения» со своими кусками прошивки использую каналы DATA модулей АЦП и ЦАП в ОБЕ стороны – хотелось бы, чтобы эту возможность Вы не забили в следующей версии ltrserver. USER_DATA использую для отладки на ввод в ПК. Было бы удобно иметь этот канал тоже двунаправленным – в чем проблема?

Использовать datahook в прошивке не получилось – пришлось переписывать. Причины: 1) потоковую генерацию в LTR34 естественно синхронизировать по STATUS_PERIOD, которые приходят как команды, а не данные; 2) сырые данные каналов АЦП, для которых все что нужно считает Blackfin, естественно удалять из потока для экономии полосы; 3) необходимо управление с хоста.

В общем, напрашивается альтернативная модель хука в «разрыве потока»: все, что пришло от хоста и ПЛИС как есть отсылается в хук, который сам разбирается, что послать дальше, а что изменить или выкинуть. Подход весьма универсальный и было бы неплохо реализовать его как опцию в стандартной прошивке. Если решите заниматься, могу прислать свой вариант патча.

>Для «общения» со своими кусками прошивки использую каналы DATA модулей АЦП и ЦАП в ОБЕ стороны – хотелось бы, чтобы эту возможность Вы не забили в следующей версии ltrserver.

Ну вообще у всех модулей двунаправленный канал (у модулей ввода из ПК идут, как минимум, команды типа «start adc», «stop adc» и т.д. - это команды для модуля, но ДАННЫЕ с точки зрения крейт-контроллера). Так что это никуда не денется. Мы говорим об одном и том же?
Единственное - у LTR34 специальная обработка потокового вывода (с контролем заполнения FIFO).

>Было бы удобно иметь этот канал тоже двунаправленным – в чем проблема?

USER_DATA в почти готовой следующей версии сервера сделан однонаправленным, исправлено описанное Вами подвисание при записи. Причина: данные от клиента складывались в буфер для виртуального модуля 18, но «забирающий» поток этот модуль не видел, event наличия новых данных, на котором он ждет, не сбрасывался, и получался «короткий цикл» и 100% cpu.

Двунаправленность userdata делать боязно, потому что одно дело обработать приход из крейта слов с недокументированным сочетанием битов CY = 01 (в штатной прошивке их просто нет), а другое - писать в крейт данные, не предусмотренные его архитектурой.

>Использовать datahook в прошивке не получилось – пришлось переписывать.

И правильно Это простейший datahook, так сказать, демонстрационный.

>В общем, напрашивается альтернативная модель хука в «разрыве потока» [...] Если решите заниматься, могу прислать свой вариант патча.
Спасибо, покажем этот пост программисту прошивок ltr.

Александр!

Спасибо, обнадежили

С ltr34 у меня получается такая ситуация. Данных «туда» идет очень мало (только команды на изменение частоты/амплитуды), зато регулярно приходят уведомления о выдаче очередного килосэмпла. Как я понимаю, счетчики заполнения фифо у Вас пойдут в минус. Не случится ли от этого какая-нибудь неприятность через час-другой работы?

Не могли бы заодно спросить у программиста Blackfin, работает ли у него прошивка, скомпилированная с включенной оптимизацией, в режиме Ethernet?

> Как я понимаю, счетчики заполнения фифо у Вас пойдут в минус. Не случится ли от этого какая-нибудь неприятность через час-другой работы?

Эти счетчики нужны, чтобы приостанавливать запись, пока буфер не освободится. Они 64-битные знаковые, диапазон не проверяется, при максимальной частоте дискретизации должно хватить на молмиллиона лет...

Александр! Мелкие аномалии в ltrserver:

1) После аппаратного сброса Ethernet-крейта при "живом" соединении сервер не переподключает его автоматически (в логе появляется "ping failed", но больше никаких действий не предпринимается).

2) Если крейт подсоединен одновременно по USB и Ethernet, то в списке подключенных крейтов он отображается дважды (пустой и с модулями). Работе не мешает.

1) Такая функциональность в текущей версии не закладывалась, флаг «подключать автоматически» определяет, надо ли соединяться с IP-адресом при инициализации сервера.
Предполагается, что верхний уровень все равно ведь должен как-то обрабатывать нештатные отключения, а тогда повторное соединение можно инициировать через server control API.

2) Да, это свойство текущей прошивки LTR-EU, она не выключает до конца USB-интерфейс (чтобы переконфигурировать можно было).

Тут более серьезная проблема появилась.

Режим Ethernet. Штатная прошивка. Запускаю LGraph на регистрацию с LTR11 2 канала по 200кГц. Минут через 10-20 поток данных прекращается. Светодиоды на панели тухнут. В логе ltrserver ничего нового. Крейт пингуется. После рестарта сервера крейт определяется как пустой (mconfig=0000).

В моей модифицированной прошивке то же самое. Здесь могу добавить, что основной тред из main.c крутится — у меня там выдача диагностики в USER_DATA и мигание светодиодом E. Так вот, после облома диагностика продолжает идти, а обе лампочки выключаются. Похоже, что в Release-билде облом случается быстрее (там и замечено).

Выглядит так, как будто бы умирает плиска.

Помогайте.

Игорь. Попробуем после праздников в L-Card воспроизвести данный эффект в этой конфигурации. ПЛИС сама по себе вряд ли умирает. Судя по светодиодам, Blackfin её либо ресетит, либо на перезагрузку ПЛИС пускает из-за какой-то накладки. Ведь, при работе c USB и Ethernet работа с ПЛИСом (и сама логика ПЛИСа) совершенно идентична для обоих случаев. С USB ведь всё работает долговременно без проблем? Что-то мне подсказывает, что настройки SDRAM выставлены некорректно. Проверьте, что SDRAM Latency = 3,  и другие тайминги SDRAM выставите по максимуму для проверки...

Александр! С увеличенными таймингами SDRAM и отключенным управлением лампочками (main.c, тройной if в main_task) прошивка дважды отработала по часу без зависания (во второй раз я отключал еще и управление вентилятором — используется тот же SPI, правильно?). Это еще не статистика – без модификации иногда работала минут по 50. М.б. SDRAM не причем — завтра проверю. Что у Вас? Получилось воспроизвести?

На одном и том же SPI, в том числе, организован и канал доступа к регистрам ПЛИС по сигналу PF5(SPISEL5). В частности, среди регистров ПЛИС есть регистр управления вентиляторами.

Игорь, по-моему, гипотеза про настройку таймингов SDRAМ здесь является основной и её нужно проверить чисто. А именно, в штатной прошивке нужно увеличить только тайминги SDRAM (и больше ничего не изменять), долговременно испытать, и если проблем не возникнет, то снова откатить на штатную прошивку, чтобы подтвердить, что проблема была и мы её успешно умеем лечить. Мне не удалось пока  обнаружить в L-Card такой экземпляр крейта LTR-EU, где обнаруживались бы подобные проблемы.

Игорь, а Вы трафик 1200 кбайт/c случайно не превышаете? Для данной реализации TCP/IP - это практический предел. В частности, если 300 кГц частоту АЦП в LTR11 поставить, то 1200 кбайт/c и получится...

Александр! Чисто вчера проверял дважды — зависла с теми же симптомами через 25 и 14 минут. Между запусками обратил внимание, что вместе с исходниками мне «подсунули» rbf 1.0.0.6. Заменил на 1.0.0.7, но разницы нет.

Косвенные указания, что проблемы могут быть и в SPI: 1) написано на ассемблере; 2) при компиляции HAL с включенной оптимизацией все виснет сразу и совсем.

Еще есть воспроизводимая аномалия: после ресета крейта кнопкой ltrserver с первого раза не получает отклик от LTR11. Если затем перезапустить ltrserver Ctrl-R, модуль находится. Остальные три модуля обнаруживаются устойчиво.

Иногда при подключении крейта к ltrserver в логе появляются странности вроде
[10.03.11 09:25:06.968] (1) CRATE_READ: LTR030 [2D228300]: bad module (slot = 4, mid = FFFF, data = FFCF839F)
иногда — штук 50 сообщений вроде “bad data” (точно не помню). На дальнейшей работе это никак не сказывается, но м.б. как-то связано с зависанием?

Еще есть непонятки с watchdog. В исходниках initialize_wdt(10000) закомментирован. Если включить — сброс происходит, несмотря на clear_extwdt() в основном цикле. Правда, это проверял на модифицированной прошивке — м.б. накривил чего.

Еще есть потенциально опасные неточности в межпотоковой синхронизации и очень странный portENABLE_INTERRUPTS. Пробовал исправлять — эффект не устраняется.

Вчерашний вариант (медленный SDRAM, лампочки отключены) отработал сегодня уже полтора часа и пока не завис. Буду пробовать другие комбинации. Времени отнимает — жуть.

1. Не получение отклика от LTR11 с первого раза и "bad data" связаны с тем, что модуль не был остановлен и после сброса крейта продолжает слать данные.
2. initialize_wdt настраивает внутренний сторожевой таймер Blackfin, а clear_extwdt - сбрасывает внешний. Внутренний сейчас не используется, т.к. внешний более надежен.
3. В чем странность portENABLE_INTERRUPTS? Какие Вами обнаружены проблемы в межпотоковой синхронизации?
4. Какая сейчас скорость сбора данных?

Александр! Да, данные приходят не все. ltrserver показывает ок. 330 кслов/сек, хотя с LTR11 должно идти 400кслов/сек. Ну и что? Ethernet ведь не виснет. Кстати, в РЭ у Вас написано 2500, а не 1200.

Собственно данные меня сейчас не интересуют — мне действительно нужна оцифровка порядка 400ксэмплов/сек, но после обсчета в blackfin для передачи наверх остается раз в двадцать меньше.

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

Игорь, в данном случае я между Вами и Константином не буду "испорченным телефоном". По программированию Блэкфина и скоростям - это к Константину, по аппаратуре LTR и ПЛИС - это ко мне.