DmitryV

Контроллер хотел взять с MAC, что-нибудь из LPC23xx. Хотябы в этой части разбираюсь :) Уже делал на нем сетевой девайс, правда, напрямую подключенный к отдельной линии. Не понял. На один и тот же PHY нельзя завести и RX и TX? Пожалуйста, поясните мысль. Точно также как и старые хабы (не свитчи) решали, как и решается этот вопрос обычно: MAC по средствам PHY ждет свободной среды и занимает ее. Разве недостаточно того, что внтурення линия (внутри девайса), соединяющая 2 входа Ethernet от обоих "отвязана" средствами трансформатора (magnetic)? Почему-то мне казалось, что обычные старинные хабы именно так и работали? Нет? -- Дмитрий

Большое спасибо, очень похоже на то, что нужно. Правда, высоковат уровнем в OSI (читай - лишнего много). Поясните, пожалуйста, чем плохо мое изначальное предположение о том, что для реализации хаба (просто тупо повторяющего концентратора) достаточно меджду "входным" и "выходным" портами устройства (состоящим каждый из разъема + magnetic) сделать ответвление на чип физического уровня, соединенный по ®MII с контроллером? Не, костылями и провайдингом тут не пахнет :) С IP адресами разобраться - задача не хитрая. По поводу безопасности - тут, скорее, задача не отгородить устройство от внешней среды, а наоборот. Т.е. доказать, что оно не тырит проходящие пакеты и внешние данные и не пересылает налево. Оно и ежу понятно, что там, где есть что спереть из канала передачи, все как следует зашифровано. Однако, заказчик/пользователь не всегда ёж :) Это мои личные предположения. Подробности пока что все. Хочется сделать прототип с описанными возможностями, не привязанный к какой-то конкретной цели. Как любят некоторые выражаться "обкатать технологию". Для меня тут многое новое. И не лишайте меня возможности учиться на своих ошибках предложениями "купи свич, кинь еще провод и не парься" :) -- Дмитрий

Поясните, пожалуйста, что Вы имеете в виду :) 1. Надо по существующей сети ethernet управлять твердотельным реле + собирать информацию с датчиков + выдавать эту информацию в виде web-нитерфейса. 2. Поскольку линия уже СУЩЕСТВУЮЩАЯ, то хочется именно встроиться в ее разрыв, а не тянуть еще один провод. Прошу подкинуть хотябы один part number или способ как это реализовать, чтобы было за что зацепиться. -- Дмитрий.

Добрый день! Есть необходимость подключить свое устройство в разрыв существующей линии передачи данных (UTP5). PHY/MAC - 10/100 Mbit Etehenet (1G - сомневаюсь, но пока не надо). Сразу возникла мысль, что должна существовать специализированная микросхемка (или трансформатор?) для реализации "разделения" линии по аналогии с хабом или свитчем, однако, поиск не принес результатов. Ну не ставить же 2xPHY и ретранслировать все через микроконтроллер. При помощи каких средств можно реализовать такое подключение своего усройства? Может быть просто разъем+magnetic на входе + такой же комплект на выходе, а внутренюю линию заводить прямо в микросхему PHY? -- Дмитрий

Варианты: 1. В стартовом коде не убрана заглушка для программного прерывания (SWI). Это надо сделать в двух местах, или ОС не будет работать. Еще нужно сделать IMPORT SWI_Handler. 2. Может быть ошибка в синхронизации между задачами. Попробуйте для начала сделать мигание в одной задаче.

Добрый день! Вопрос программирования CC2430 уже обсуждался, однако, изучив следующие темы, не пришел к однозначному ответу: http://electronix.ru/forum/index.php?showtopic=34905 http://electronix.ru/forum/index.php?showtopic=19163 Вопрос. Чем можно запрограммировать отдельный модуль CC2430 (не в сотаве отладочника SmartRF)? Самопальные программаторы делать нет желания, да и их тоже надо чем-то программировать :) Хочется просто взять и купить готовый. Чем дешевле - тем лучше. СС2430 имеет "SPI-like" интерфейс для программирования. Это тоже самое, что называется C2 interface или нет? Подойдут ли следующие девайсы? - FlashBlaster2 - CCBA04 (видимо подойдет, но где его достанешь-то?) - Silabs USB debug adapter - Silabs EC2 serial adapter Как учитывается система команд интерфейса программирования 8051 MCU в составе CC2430? Или она она и та же везде, где используется этот "SPI-like" интерфейс? Иначе еще софт для программирования писать придется... ЗЫ. Может у кого-нибудь есть лишний программатор в небезвозмездное пользование (СПб) ? :)

Скоро - это скоро. Направил запрос компетентным органам. Ответят - сообщу тут.

На данный момент такой загрузчик существует (по крайней мере, для LPC2148) и находится в стадии тестирования. Скоро появится в доступе и будет прошиваться при производстве новых чипов. Вроде бы для 23хх тоже будет. Работает методом заливки HEX на USB Mass Storage Device, коим будет являтся контроллер с прошитым загрузчиком, т.е. даже без дополнительного софта.

Позвольте еще один вопрос касательно GDB. Собрал gdbserver для uCLinux на LPC2468 при помощи такой-то матери, запускается, пишет: # /mnt/mmc/gdbserver 192.168.200.3:1234 /mnt/mmc/main Process /mnt/mmc/main created; pid = 62 Listening on port 1234 Запускаю arm-elf-gdb (из дистрибутива kgp_arm-bu2.18.50.20080115_gcc4.3.0.20080111_newlib1.16.0.20080115_gdb6.7.50.20080108 либо свой собранный под cygwin - без разницы): This GDB was configured as "--host=i686-pc-mingw32 --target=arm-elf". (gdb) file D:\\main.gdb Reading symbols from D:\main.gdb...done. (gdb) target remote 192.168.200.100:1234 Ответ: Remote debugging using 192.168.200.100:1234 warning: Remote failure reply: E01 0xa02a0050 in ?? () (gdb) step Remote communication error: Bad file descriptor. Cannot find bounds of current function (gdb) Терминал LPC: Remote debugging from host 192.168.200.3 <1>Unhandled fault: alignment exception (0x5000001) at 0xa1d13eec Internal error: Oops: 0 [#3] Modules linked in: spi rtc sfr pwm i2c adc lpc2468mmc lpc2468eth CPU: 0 pc : [<a0055f18>] lr : [<00000000>] Not tainted sp : a1d13eec ip : 9ede1000 fp : a1d13f0c r10: a1d36820 r9 : 00000000 r8 : a01d09e4 r7 : a01d097c r6 : a1d13f2c r5 : a1d13f28 r4 : 00000001 r3 : a0000093 r2 : 00000000 r1 : a0000013 r0 : 00000000 Flags: NzCv IRQs off FIQs on Mode SVC_32 Segment user Process gdbserver (pid: 61, stack limit = 0xa1d12194) Stack: (0xa1d13eec to 0xa1d14000) 3ee0: a1d37dec a1d13f64 00000004 00000000 a1d37dc0 3f00: a1d13f58 a1d13f10 a0035a34 a0055ec8 00000000 00000001 a1d13f2c a1d13f28 3f20: a1d37dec a1d13f64 a01d09ec 9ede1000 a1d36820 a1d36820 00000001 00000000 3f40: 0000003e a1c5fe88 00000000 a1d13f78 a1d13f5c a001e4a8 a0035908 00000000 3f60: a1c5fe88 a1d12000 a1d12000 a1d13fa4 a1d13f7c a001e7c4 a001e40c 00000001 3f80: 00000000 00000001 0000001a a001b800 a1d12000 00000000 00000000 a1d13fa8 3fa0: a001b680 a001e6b0 00000001 a002a8ec 00000001 0000003e 00000000 a1c5fe88 3fc0: 00000001 00000000 00000001 00000000 00000000 00000000 00000000 a1c5fee0 3fe0: 00000000 a1c5fe80 a1c4b6d8 a1c4b684 80000010 00000001 ffffffff ffffffff Backtrace: Function entered at [<a0055eb8>] from [<a0035a34>] r8 = A1D37DC0 r7 = 00000000 r6 = 00000004 r5 = A1D13F64 r4 = A1D37DEC Function entered at [<a00358f8>] from [<a001e4a8>] Function entered at [<a001e3fc>] from [<a001e7c4>] r4 = A1D12000 Function entered at [<a001e6a0>] from [<a001b680>] Code: 0a000006 e10f1000 e3813080 e121f003 (e59c2004) SIGSEGV # Соответственно, адекватно работает только команда "continue". Вопрос: что делаю неправильно? в чем может быть проблема?

Спасибо за информацию! А откуда линкер узнает, где и как размещать бинарник в памяти?

Добрый вечер! Правильно ли понимаю, что cross compile toolchain - это набор binutils + gcc + gdb, сконфигуренных и скомпиленных для соответствующей аппаратной платформы? Чем отличаются arm-elf-tools (arm-elf-gcc и т.д.) от arm-linux-tools (соответственно, arm-linux-gcc)? Сам собирал RedBoot при помощи arm-elf- и linux на эту же платформу при помощи arm-linux-. Все работает и не жалуется. В другой ситуации, uClinux для LPC2468 собирается arm-elf, но не хочет arm-linux. В чем тут разница, чего не понимаю? Где можно взять относительно свежие бинарники этих тулчаинов для linux? На какие параметры целевой платформы надо обращать внимание, чтобы собрать самому? Или там просто типа configure --target=arm-elf?

Не исключаете возможность того, что все-таки стартует, но ничего не выводит? В конфигурации ядра поищите Serial Drivers или что-то в этом духе. Сам имел такую же проблему с "не запуском", причем с родным циррусовским ядром.

Если правильно понял суть вопроса, то в общих чертах технология такая: 1. Написать программу + Makefile руками или, например, используя Eclipse (удобнее, мэйкфайлы руками не придется делать). Компилер использовать arm-elf-gcc. Если делать это все под Linux, то компилить можно прямо из Eclipse, под виндой - либо использовать toolchain, собранный под cygwin, либо IDE использовать для удобства, а компилить все равно линуксом. Указать компилеру -Iпуть_к_kernel/include. 2. положить программу в rootfs и персобрать его (другой вариант - скинуть программу на USB MSD флэшку - при отладке гораздо удобнее) 3. перепрошить rootfs. Ну а дальше можно приступить к прикручиванию gdb и прочих прелестей :)

MPEG1 Layer 3 44100, Stereo 128 (20%) - 256 (25 %) kbps, CBR вроде бы так, если не путаю

С phy придется разобраться и написать (подредактировать) под него немножко кода. Уровни выше - можно взять любой готовый проект и плясать уже от него. В частности, для lpc2364 есть стек NicheLite, проект easyWeb и т.д.