ghost_gluck

Если грузовики Volvo, то будет CAN с SAE J1939 и SAE J1708/J1587. Для легковых - не подскажу. Если CAN, то идентификатор расширенный 29bit. В CAN - 8 байт данных. Но если надо передать больше - разбивается на несколько пакетов.

Для Debian/Ubuntu Linux попробуй --build=i686-pc-linux-gnu или --build=i686-pc-linux, должно собираться. Свой toolchain собирал ./configure --target=arm-elf --prefix=[toolchain-prefix] --enable-interwork --enable-multilib --with-float=soft узнать архитектуру и т.д. можно через uname. uname -ms -m - print the machine hardware name -s - print the kernel name (linux, *bsd, aix, etc..) Готовый toolchain, инструкцию по сборке можно найти http://gnuarm.org/ http://gnuarm.org/support.html собирал себе таким образом. Бинарники армовские c использованием syscall компилил и исполнял через qemu-arm. Ниже приведен пример, как заставить qemu-arm исполнять бинарники. /usr/bin/qemu-arm - путь к бинарнику эмулятора.

Тут немного не не согласен, т.к. 1. Архив созданный Winrar, WinZip, InfoZip в качестве OS - показывает DOS. (проверил у себя.) 2. ZipInfo выдает: Archive: uCOS-II-V277.ZIP 1034029 bytes 22 files End-of-central-directory record: ------------------------------- Actual offset of end-of-central-dir record: 1034007 (000FC717h) Expected offset of end-of-central-dir record: 1034007 (000FC717h) (based on the length of the central directory and its expected offset) This zipfile constitutes the sole disk of a single-part archive; its central directory contains 22 entries. The central directory is 2229 (000008B5h) bytes long, and its (expected) offset in bytes from the beginning of the zipfile is 1031778 (000FBE62h). There is no zipfile comment. Central directory entry #1: --------------------------- MICRIUM/SOFTWARE/uCOS-II/Doc/WhatsNewSince-V200.pdf offset of local header from start of archive: 0 (00000000h) bytes file system or operating system of origin: MS-DOS, OS/2 or NT FAT version of encoding software: 2.0 minimum file system compatibility required: MS-DOS, OS/2 or NT FAT minimum software version required to extract: 2.0 compression method: unknown (99) file security status: encrypted extended local header: no file last modified on (DOS date/time): 2004 Nov 26 17:38:18 32-bit CRC value (hex): 00000000 compressed size: 46361 bytes uncompressed size: 90317 bytes length of filename: 51 characters length of extra field: 11 bytes length of file comment: 0 characters disk number on which file begins: disk 1 apparent file type: binary non-MSDOS external file attributes: 000000 hex MS-DOS file attributes (21 hex): rdo arc The central-directory extra field contains: - A subfield with ID 0x9901 (unknown) and 7 data bytes: 02 00 41 45 03 08 00. There is no file comment. Приведен один файл и детальная инфа на него.

Попробуйте поиграться со степенями компрессии. Раньше 7-Zip поддерживал только 9 и 6, если не ошибаюсь. У меня нет Advanced Password... от элкомсофт, а то бы подключился. Ломаный он криво работает. <{POST_SNAPBACK}> InfoZip - очень похож на PkZip и компрессию можно регулировать от 1 до 9, что я и делал. Пробовал подбирать во всех режимах - ничего. Еще раз повторюсь, что метод компресии я не увидел. И не увидел Advanced ZIP Password Recovery.3.54 Advanced.Archive.Password.Recovery.v2.20, а только pkcrack - взять тут хттп://www.unix-ag.uni-kl.de/~conrad/krypto/pkcrack.html

Может быть, но я специально пробовал создавать шифрованные архивы и во всех метод был виден. Использовался InfoZip, WinRar. Либо использован новый метод сжатия, что в полне возможно, буду еще пробовать.

Забрал. Разбираюсь. Есть еще Advanced ZIP Password Recovery. Буду пробовать, но мне интересно, почему неизветный метод архивации. Пока что посмотрел, удивило compression method: unknown (99) сейчас пробую различные методы сжатия. на normal - ничего не получилось. пробовал pkcrack - она у меня не смогла подобрать пароль даже к тому, что Advanced archive password recovery и Advanced ZIP Password Recovery подбирают. Буду искать чем еще вскрыть. Интересный архивчик, а особенно с неизвестным методом архивирования. За основу брались файлы QuickRefChart-Color.pdf README ucos_ii.c т.к. размер одинаков. Я думаю, что у меня не получилось в виду нормального архиватора, т.к. паковал WinRar'ом, испробовал на всех методах сжатия. Но там судя по всему Normal. Интересно, каким архиватором его паковали. т.к. ZipInfo 2.31 не знает данный метод компроессии. Тоже и с 2.41 метод не известен. Взял последний Zip от InfoZip. пробую. Попробовал - ничего. pkcrack - не смог, но это был единствееный, кто -что-то пробовал делать, а не ругался на метод архивации.

Присоединюсь к предыдущему оратору. А если ты работаешь с Linux, то судя по всему используешь tcpdump. погугли на тему windump - порт под винду с использованием WinPcap. Ethereal тоже использует WinPcap.

Могу посоветоват следующее: 1. Если можешь получить дерево каталогов и файлов запиши их мена и размеры. 2. Потом попробуй попросить у кого нибудь, README или менее значащие файлы от дистриба 2.77, посмотри могут подойти и файлы от 2.76, но которые есть в твоем архиве и совпадат по размеру. 3. Далее есть софтина которая по известным файлам которые есть в архиве подберет парольк архиву или разархивирует его. PS. к сожалению доступа к upload у меня нет.

1. Да будет, т.к. очередь у тебя на 5 коннекций. В listen число 5 меняешь, на количество нужное тебе. 2. Есть множество варинтов написания у тебя fork - один из простых, но расход памяти большой, т.к. fork создает копию родитлея и запускает в нем потомка, соотвественно размер в памяти увеличится на размер родителя. Через threads - будет получше в целях экономии памяти, да и по времени. Совет: в качестве примера и оценки враианта смотри здесь хттп://club.shelek.com/viewart.php?id=73

Субж. Из признаков: ManufacturerID - 0x98 (Toshiba) DeviceID - 0x57 По секторам подходит TC58FVT641, но есть проблемы при стирании если делать ChipErase то он выполняется очень быстро(1сек и ничего не стирает). Если тереть по секторам то трет до 66 а потом все. Очень долго висит на одном секторе, т.е. невозможно получить статус завершения операции. Помогите плз. Заранее спасибо.

С этим согласен, но у меня нет другого выбора, по вышеописанным причинам. А именно: - не знаю адресов котроллера прерываний и значения его регистров. - не знаю адресов программирования таймеров и значений регистров. Но с этми думаю разобраться в ближайшее время. Если можно ткните носом, где можно взять русское описание по uC/OS-II, английское есть. Если такового нет, придется учить английский. Большое спасибо. Буду продолжать свои изыскания.

Имеется устройство - старый CDMA800 телефон c процом MSM5100(ARM7TDMI). Я решил его использовать как платформу для тестов. Немногое удалось выудить, но этого хватает для эксперементов. Что касается основной системы(фирмвари) нет, т.к. телефон пока через JTAG подключен, и соотвественно я на ходу программлю его. Возникает несколько вопросов. Вопросы: 1. Можно ли использовать RTOS или многозадачную OC для работы при условии незнания регистров таймера и контроллера прерываний(соответственно их программирования)? 2. Если да - то направьте в сторону правильного пути. Если нет подскажите способ реализации. PS Из RTOS систем есть uC/OS-II. PPS Усторойство интересует как тестовая платформа с LCD, IRDA, RS232. Заранее спасибо.

Имеется устройство - старый CDMA800 телефон c процом MSM5100(ARM7TDMI). Я решил его использовать как платформу для тестов. Немногое удалось выудить, но этого хватает для эксперементов. Что касается основной системы(фирмвари) нет, т.к. телефон пока через JTAG подключен, и соотвественно я на ходу программлю его. Возникает несколько вопросов. Вопросы: 1. Можно ли использовать RTOS или многозадачную OC для работы при условии незнания регистров таймера и контроллера прерываний(соответственно их программирования)? 2. Если да - то направьте в сторону правильного пути. Если нет подскажите способ реализации. PS Из RTOS систем есть uC/OS-II. PPS Усторойство интересует как тестовая платформа с LCD, IRDA, RS232. Заранее спасибо.