psL

Видимо никто не претендует на ваше право окучивать старушек за 5 копеек;) Ну а идеи, "идеи витают в воздухе" http://hxc2001.free.fr/floppy_drive_emulator/index.html

Зачем "писать из головы"? Есть ГОСТ формализующий стадии проектирования. Другой вопрос, что "вольный заказчик" "вольному разработчику" по такой схеме работу не может предложить. Дорого это... просто всем интересно, как сделать законченное устройство с usb-msd, ethernet, 2МБ буфером и, возможно, cpld за 10-12$

для студентов лучше не PIC, а avr - arduino, stm32 - discovery, nucleo или даже RPi, поскольку это все мэйнстрим и в плане трудоустройства будет попроще.

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

Это нужно, например, для создания централизованной системы мониторинга на основе этих 500 устройств. nagios\nrpe - для запуска команд монитринга на устройстве; puppet\ansible - для централизованного управления параметрами парка устройств; Или nagios им тоже с нуля написать? :laughing: C lwip можно разве что через snmp v1 все это обьеденить, а лезть на 500 устройств через веб-интерфейс настраивать - не комильфо.

Вот не знаю, зачем давать советы из разряда "...до основания, а затем..." Интересно, как для lwIp реализовать следующее: управление puppet\ansible, мониторинг nagios\nrpe, доступ по ssh...? Один месяц для такой задачи как-то оптимистично.

можно сделать сделать образы с текущей системы, а потом залить эти образы на usb-flash или nfs. Для этого определяете что в каком разделе лежит через cat /proc/mtd и делаете образы dd , например так: http://wiki.openwrt.org/doc/howto/generic.backup Потом из этих образов собираете rootfs и кладете его на usb-flash или nfs. Ну или тупо скопировать всю фс на usb-flash или nfs и поменять параметры u-boot или fstab ну да, lwIp конечно круче полноценного tcpip стека... :rolleyes: Видимо основная ценность прошивки в ПО управления модемом по spi. Если это ПО есть в исходниках или его можно запустить на сторонней системе, то имеет смысл поменять процессорный модуль. В противном случае видимо это будет разработка системы почти с нуля. Кстати, Это не nand "глючит". Это особенности работы jffs на NFC freescale. Здесь http://www.spinics.net/lists/u-boot-v2/msg05730.html например пишут, что нужно использовать ubifs

кстати, есть вычислительные модули в SODIMM конструктиве, которые более привлекательны с точки зрения использования в "профессиональной" аппаратуре, но дороже микрокомпьютеров http://uk.rs-online.com/web/p/processor-mi...t-kits/8268825/ По поводу "правильного" раздела: что делать с другими популярными микрокомпьютерами/модулями/DK? количество обсуждаемой информации что для RPi, что для arduino скорее подходит для подфорума процессорной архитектуры. Зачем ориентироваться на тех, кто "не знает"?

еще немного и убийцо MODBUS будет готов...

"метров 10-15" это с БЛА что ли?

тема загрузчика не раскрыта. Что у вас в качестве загрузчика? u-boot? Как вы выполняете uname -a? Консоль? ssh?

Интересно, чем данная плата выделяется из легиона остальных отладочных плат под ARM с похожей функциональностью, что под нее выделили отдельный раздел?;)

внешняя флешка - это usb флешка чтоли? сомневаюсь, что он умеет грузится с mass storage. это нужно корень монтировать на usb

на самом деле в key-value данные хранятся по хешу key, т.е. по целому, а не по строке, а ТС предлагает вместо хеш-функции использовать перечисление. Вообще непонятно зачем это в таком виде нужно, поскольку key-value используется для скоростной выборки данных, а тут всего 12кБ - т.е. можно просто последовательно перечитать весь носитель за миллисекунды. Хранить данные можно друг за другом, например в виде index, type, data, crc. Придумать случай, когда программа не знает размера структуры данных в eeprom затрудняюсь. А так - есть всякие bson, protobuf и т.п., но это в данном случае наверное тяжело будет.

Если еще актуально. При конфигурировании BSP выбирается тип платы (./configure <selected board>), к конфигу платы привязан соответствующий fex. Т.о. править нужно этот fex, потому что script.bin собирается из него.

С spi eeprom видимо будет удобнее вообще через sysfs работать, т.к. объем небольшой На веб-сервер в линуксе грузится архив обновления методом post, скрипт на стороне сервера проверяет целостность архива и распаковывает его, ну а дальше - в зависимости от содержимого архива: либо меняются отдельные файлы, либо перезаписываются образы разделов, либо подкачивается обновление из репозиториев. В случае перезаписи разделов нужно больше памяти,ну и корень нужен другой в ram В случае обновления из репозиториев видимо придется как-то изголяться в offline. Думаю, обновление через веб через загрузчик - это как-то сложно. Обновление через загрузчик удобнее для обновления с каких-то внешних носителей. Типа нажали три кнопки - загрузчик пошел по другой ветке, нашел образы на sd карте, все перепрошил и загрузил.

если кристалл установлен, земля при отсутствии непосредственного контакта между полигонами на плате может звонится через него.

вместо "или" нужно читать "ИЛИ" ) Например так: struct proc { int param; int (*do_)(int arg, struct proc* proc ); }; int do_or(int arg, struct proc* proc) { return arg | proc->param; } int do_and(int arg, struct proc* proc) { return arg & proc->param; } int do_proc(int arg, struct proc* proc) { return proc->do_(arg, proc); } struct proc procs[]={ { .param = (1<<5) , do_or }, // 0 { .param = (1<<7) , do_or }, // 1 { .param = (1<<31) , do_and }, // 2 }; ... do_proc(0x12, &procs[1]); // установка бита 7 ...

а не проще ли просто выделить под настройки отдельный раздел на mtd устройстве и смонтировать его как хочется (/etc в rw)?

можно запрашивать SDO одной нодой у другой

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

Как на счет такого эксперимента: берете плату со сгоревшим контроллером, выпаиваете его и замыкаете цепь TX, DE на землю, можно миллиамперметром. Диптрейса нет, но еще заметил, что входной оптрон подключен к GNDD, а блокировочные конденсаторы - к символу "земля". При этом на гербере не видно, что некоторые полигоны объединяются явно (нет переходных). У вас случайно земля не объединяется через кристалл? Попробуйте явно объединить все земляные полигоны проводом.

насколько понял, у символьных индикаторов на ее основе один семисегментный знак разбит на два адреса в 4битном озу. Один семисегментный знак - это 8 бит. Т.е. нужно преобразовать выводимый символ в 8 битное поле по таблице bcd, а затем вывести это поле тетрадами по нечетному/четному адресам.

например, здесь Односвязные списки

Если это продолжение про HT1621, то может как-то так сделать? // сдвиги для каждой половины знака #define SHIFT_HALFSIGN0 0 #define SHIFT_HALFSIGN1 4 // сегменты #define SEG_A(x) ((x<<3)<<SHIFT_HALFSIGN1) #define SEG_B(x) ((x<<2)<<SHIFT_HALFSIGN1) #define SEG_C(x) ((x<<1)<<SHIFT_HALFSIGN1) #define SEG_D(x) ((x<<0)<<SHIFT_HALFSIGN0) #define SEG_E(x) ((x<<1)<<SHIFT_HALFSIGN0) #define SEG_F(x) ((x<<2)<<SHIFT_HALFSIGN0) #define SEG_G(x) ((x<<3)<<SHIFT_HALFSIGN0) #define SEG_H(x) ((x<<0)<<SHIFT_HALFSIGN1) // дешифратор: const uint8_t bcd[] = { SEG_A(1)|SEG_B(1)|SEG_C(1)|SEG_D(1)|SEG_E(1)|SEG_F(1)|SEG_G(0), //0 SEG_A(0)|SEG_B(1)|SEG_C(1)|SEG_D(0)|SEG_E(0)|SEG_F(0)|SEG_G(0), //1 SEG_A(1)|SEG_B(1)|SEG_C(0)|SEG_D(1)|SEG_E(1)|SEG_F(0)|SEG_G(1), //2 SEG_A(1)|SEG_B(1)|SEG_C(1)|SEG_D(1)|SEG_E(0)|SEG_F(0)|SEG_G(1), //3 SEG_A(0)|SEG_B(1)|SEG_C(1)|SEG_D(0)|SEG_E(0)|SEG_F(1)|SEG_G(1), //4 SEG_A(1)|SEG_B(0)|SEG_C(1)|SEG_D(1)|SEG_E(0)|SEG_F(1)|SEG_G(1), //5 SEG_A(1)|SEG_B(0)|SEG_C(1)|SEG_D(1)|SEG_E(1)|SEG_F(1)|SEG_G(1), //6 SEG_A(1)|SEG_B(1)|SEG_C(1)|SEG_D(0)|SEG_E(0)|SEG_F(0)|SEG_G(0), //7 SEG_A(1)|SEG_B(1)|SEG_C(1)|SEG_D(1)|SEG_E(1)|SEG_F(1)|SEG_G(1), //8 SEG_A(1)|SEG_B(1)|SEG_C(1)|SEG_D(1)|SEG_E(0)|SEG_F(1)|SEG_G(1), //9 SEG_A(1)|SEG_B(1)|SEG_C(1)|SEG_D(0)|SEG_E(1)|SEG_F(1)|SEG_G(1), //A SEG_A(0)|SEG_B(0)|SEG_C(1)|SEG_D(1)|SEG_E(1)|SEG_F(1)|SEG_G(1), //B SEG_A(1)|SEG_B(0)|SEG_C(0)|SEG_D(1)|SEG_E(1)|SEG_F(1)|SEG_G(0), //C SEG_A(0)|SEG_B(1)|SEG_C(1)|SEG_D(1)|SEG_E(1)|SEG_F(0)|SEG_G(1), //D SEG_A(1)|SEG_B(0)|SEG_C(0)|SEG_D(1)|SEG_E(1)|SEG_F(1)|SEG_G(1), //E SEG_A(1)|SEG_B(0)|SEG_C(0)|SEG_D(0)|SEG_E(1)|SEG_F(1)|SEG_G(1), //F }; void lcd_put(int pos, int sign) { uint8_t s=bcd[sign]; uint8_t addr=pos<<1; write_nibble( addr, 0x0F & (s >> SHIFT_HALFSIGN0)); write_nibble(++addr, 0x0F & (s >> SHIFT_HALFSIGN1)); } (код не проверял)