spf

Группа Google scmrtos-ru (рассылка) Краткие сведения и правила PS: Группа зарегистрирована на Google т.к. рассылка на sf.net имеет сложности с отображением писем с кирилицей на www интерфейсе.

High Speed CAN: - PCA82C250 - TJA1040/41/50 - ATA6660 - MCP2551 - UC5350 - L9615 - SI9200EY ...

Так в чем собственно причина поиска замены? Может не стоит ограничиваться PCA82Cxxx? Сейчас просто море аналогов при лучших параметрах.

Если Си, то обязательно прочти: "ВЕРЕВКА ДОСТАТОЧНОЙ ДЛИНЫ, ЧТОБЫ… ВЫСТРЕЛИТЬ СЕБЕ В НОГУ" - Ален И. Голуб

Согласно поиску по базе в песках таковые имеются: LPC2194JBD64, LPC2294JBD144,SJA2020HL-622,SJA2020HL-623

Так на какой пример смотрели и что сделано на практике? Это максимальная потребляемая мощность во вторичной цепи?

Это можно было утверждать лет пять назад и то уже с оглядкой. Сейчас ситуация сильно изменилась. CVS это не стандарт, а в свое время самая широкоиспользуемая система и не более того. Новое поколение систем иногда поддерживают похожий интерфейс, сделано это для упрощения перехода на них со старого доброго CVS. В новых проектах пользовать CVS уже давно нецелесообразно. (основные недостатки перечиснены на первой странице сайта Subversion) Если вас не заботят эти недостатки, то вы пользуете и CVS не в полной мере.

Цитата с wikipedia: "As of December 2007, Perforce is licensed to more than 250,000 users at 4,500 organizations[2]." И это при том, что проект стартовал аж в 1995 году. Слабовато как-то. ;) Да и наличие самого лицензирования (а может еще и оплаты деньгами) не назвал бы положительным моментом. Их ставят в один ряд обычно от непонимания последнего, как минимум. ;) Явно вы с subversion плотно не работали. (Или пробовали самые первые выпуски)

Так рядом же лежит и одноименный архив, в нем пример для нескольких МК, должны работать. Примеры загрузщиков работают, проверял в свое время для mb90F497\F387\F546. Так всё же из 16-bit MCUs, там все есть. Открываешь нужный МК, смотришь раздел документов или примеров для него.

Ни разу даже не пытались симулировать это дело, думаю не будет работать это в Softune. Сравни с "правильным" вариантом, примеры от fujitsu по работе с flash рабочие.

+1 в правилах вообще-то написано разборками не заниматься в форуме, а когда это начинают модераторы, то это уже не является правилом и примером для подражания. Форум для начинающих для начинающих и создан, предполагает снесходительного отношения, как я себе понимаю.

В Си нет определения битовые переменные, но есть битовые поля в структурах. Которые можно использовать в качестве битовых переменных. Но речь похоже не об этом, надо работать с выводом порта, для это должно быть объявлено в заголовочнике компилятора для используемого контроллера что-то типа sbit P1_0 = 0x90; sbit P1_1 = 0x91; Если есть желание работать с другим именем вывода, то его можно "переименовать" при помощи #define #define INPUT_PIN2 P1_0

+1 Не имеет смысла плодить лишние сущности, дробить, выделять. Все равно по началу будут вопросы задаваться еще и в форумах по контроллерам. Народ долго привыкает к новым разделам, если их еще и сразу будет несколько, то получится распыление, а надо наоборот, аккумулирование. (пример - форум CAN, до сих пор приходится переносить общие вопросы из микроконтроллеров в отдельный специальный форум)

Эхе-хе, вот не пойму почему надо подобные вопросы задавать именно в теме новостей по оське. Неужели так трудно сделать новую конкретную тему? Указанные мейки не надо пытаться запускать, они вспомогательные. Надо запускать GNU make находясь в каталоге 1-EventFlag, он сам найдет makefile. В последнем можно порулить параметрами сборки и путем до тулчейна. В ближайшем будущем будет выпущен релиз 3.01 в виде архивов, а пока можно получить последние версии из репозитория subversion.

Схему в студию, так не понять. Зачем развязанный источник если нет опторазвязки? Почему на TxD ноль? (Его же <ноль> и получаем на RxD, но тогда на шине не должно быть ничего) Провода шины случайно не перевиты?

1. Make mak'y рознь. Можно конечно предположить что речь идет о наиболее распространенном -- GNU Make. Материалы по GNU Make на русском от Владимира Игнатова: Эффективное использование GNU Make. Перевод руководства к версии 3.79 2. Цель непонятна. Что в конечном итоге надо получить при запуске make? При одном запуске получить два варианта результатов? ----------------- Посмотрел в пример ARM7_LPC2106_GCC от FreeRTOS (в недрах примеров навалом makefile, причем все сделаны левой ногой, по принципу работает и ладно :) ) Стройного понимания принципов работы make из этих примеров не получить. Запуск make из батника это вообще не по-пацански ;) . Видимо надо в однин результирующий файл собирать объектники, компилированные в разных режимах. В makefile должны быть четко заданы цели, зависимости и правила для получения целей. Расшифрую то, что у тебя в примере # Все файлы списка OBJ_ARM(во время работы будет принято ./Src/crt.o) # получаются из одноименных файлов с расширением .c #(во время работы будет принято ./Src/crt.c) $(OBJ_ARM) : %.o : %.c $(CC) -c $< -o $@ # Все файлы списка OBJ_ARM(во время работы будет принято ./Src/crt.o) # получаются из одноименных файлов с расширением .cpp #(во время работы будет принято ./Src/crt.cpp) $(OBJ_ARM) : %.o : %.cpp $(CC) -c $< -o $@ # Все файлы списка OBJ_ARM(во время работы будет принято ./Src/crt.o) # получаются из одноименных файлов с расширением .s #(во время работы будет принято ./Src/crt.s) $(OBJ_ARM) : %.o : %.s $(AS) -c $< -o $@ Так так происходит многократное переопределение правила для получения цели (Src/crt.o), остается правило где .o зависит от .c (порядок вытеснения надо уточнять), файла Src/crt.с нет и нет правила для его получения. Make не знает что ему делать, поэтому выпадает в осадок... В примере ARM7_LPC2106_GCC # Цель rtosdemo.elf зависит от всех файлов из списков ARM_OBJ, # THUMB_OBJ, CRT0 и Makefile # Все файлы _OBJ в соответствии с записанными правилами зависят от одноименных # исходных файлов. rtosdemo.elf : $(ARM_OBJ) $(THUMB_OBJ) $(CRT0) Makefile $(CC) $(CFLAGS) $(ARM_OBJ) $(THUMB_OBJ) -nostartfiles $(CRT0) $(LINKER_FLAGS) # Все файлы списка THUMB_OBJ зависят и # получаются из одноименных файлов с расширением .c (THUMB_SRC) $(THUMB_OBJ) : %.o : %.c $(LDSCRIPT) Makefile $(CC) -c $(THUMB_FLAGS) $(CFLAGS) $< -o $@ # Все файлы списка ARM_OBJ зависят и # получаются из одноименных файлов с расширением .c (ARM_SRC) $(ARM_OBJ) : %.o : %.c $(LDSCRIPT) Makefile $(CC) -c $(CFLAGS) $< -o $@ Списки THUMB_OBJ и ARM_OBJ НЕ пересекаются. Можно сделать иначе, через целе-зависимые значения переменных. Делается одно правило получения .o из .c, но для одного из списка указывается особенные переменные. Вариант (не проверял данный файл, но в своих makefile'ах такая конструкция работает): ARM_OBJ = $(ARM_SRC:.c=.o) THUMB_OBJ = $(THUMB_SRC:.c=.o) $(THUMB_OBJ): THUMB_FLAGS = -mthumb rtosdemo.hex : rtosdemo.elf $(OBJCOPY) rtosdemo.elf -O ihex rtosdemo.hex rtosdemo.elf : $(ARM_OBJ) $(THUMB_OBJ) $(CRT0) Makefile $(CC) $(CFLAGS) $(ARM_OBJ) $(THUMB_OBJ) -nostartfiles $(CRT0) $(LINKER_FLAGS) %.o : %.c $(LDSCRIPT) Makefile $(CC) -c $(THUMB_FLAGS) $(CFLAGS) $< -o $@

Тогда бы не возникало подобных вопросов, там все для этого как раз уже есть. Вот тогда и изобретайте ее некое подобие...

Может подойдет makefile: ifndef TEST $(warning Вывод текста ) endif Результат работы: [running 'make ' in 'E:\Temp'] makefile:4: Вывод текста

Или FatFS PS: Последнее обновление Dec 15, 2007.

Непонятно, почему вообще остановились на CAN? Может достаточно и простого LIN? Какие требования к каналу передачи данных?

По поводу SPI можете почитать например там, у некоторых не удается его пользовать и на линии в 20см. Если вам нужен самый малый корпус МК с CAN то может вам подойдет MB90F387(или аналогичные чипы посвежее). Имеется девкит EU KIT MB90F387-CAN от e-tools.org

Cходи на caxapa.ru в базу данных Все поля, кроме CAN (укажи 1), сделай пустые. Надави кнопку "Обновить". И выбирай те, которые подходят. Кстати, они все с АЦП. PS: Я бы не рекомендовал ограничиваться 8-битами ядра в новых разработках. Если надо самый дешевый, то это уже искали, см. подфорум по CAN. И эту тему можно было бы туда оправить.

Попрошу не отдаляться от темы. У меня CRC лежит именно там, где мне это надо. Не об этом речь. Пример приведен из рабочего вариант для простого CRC16(CCITT), в нем нет ошибок. Что только не предлагают, но все не по теме... Вот пример кода для расчета CRC для MODBUS unsigned int Crc16AddBlock(unsigned int cur_crc, unsigned char *p_data, unsigned int data_len) { do { unsigned int i = 8; cur_crc = cur_crc ^ *p_data++; do { if (0x0001 & cur_crc) { cur_crc >>= 1; cur_crc ^= 0xA001; } else { cur_crc >>= 1; } } while (--i); } while (--data_len); return cur_crc; } PS: только не надо ёрничанья

Именно всей Flash. Читал. Более того -- все работает и в симуляторах и в железе. В коде пишем (F1611) extern unsigned short Flash_CRC; sum = crc16_ccitt(0,(unsigned char *)0x4000, 0xFFFF-0x4000+1); if(sum != Flash_CRC) Линкеру говорим: -Hff -J2,crc16,,Flash_CRC,INFO=(CODE)4000-ffff В мапе получаем: Symbol Checksum Memory Start End Initial value ------ -------- ------ ----- --- ------------- Flash_CRC 0x60d3 CODE 4000 - FFFF 0x0 И этот вариант я знаю, мне хочется другое - заставить IAR посчитать CRC так же, как считается в MODBUS.

Это понятно, не написал, что тогда вычисление контрольной суммы всего кода длится недопустимо долго (разбивать на несколько вызовов не предлагать, это уже сделано). Знаю, что есть вариант формирования таблицы в памяти, память есть, но хочется, чтобы была одна функция для подсчета CRC. Да, CRC прошивки, всей flash-памяти.