чем больше думаю тем лучше понимаю что мне это пока не по зубам, слишком много подводных камней вылезло, идея следующая :

Хочу взять пик 18f258 (цена 6 $) пик имеет апаратный кан и uart на борту, и написать программу которая будет пересылать пакеты туда обратно (типа елм)

Процесоры перебирал долго, с учетом того что мне всеравно на чем делать (не работал ни с тем ни с другим) смотрел и пики и avr , пик понравился больше, может я и не прав, если что поправьте , только с аргументами (такие как пик это вчерашний день не принимаю)

Теперь о первых трудностях, если брать на ком порт низкую скорость (типа 9600) то проблем особых нет, но это неприемлемо с моей позиции хотябы потому что я хочу работать и с мегабитным каном, ну хоть изредка, а если в 100 раз ниже скорость будет то никакого кеша не хватит, тем более что памяти в пике мало. Поэтому надо скорость побольше, например 115200 http://www.carcd.ru/forum/public/sty...IR#>/smile.gif но вылезла другая проблема, достаточно интенсивно поводить мышкой в винде и теряются байты, тоесть надо делать с апаратным контролем приема-передачи, мне это уже не по зубам, по крайней мере пока, так как с контролерами никогда не работал.

Если делать серьезный протокол в котором все это будет учтено то ресурсов пика может и не хватить, я так понимаю что почти вся свободная озу (1.5 Кб) пойдет под кеш.

Подобный проэкт уже есть и реализован, вот только реализация мне не нравится http://www.canpic.com/CANPIC_software1.htm

Пишу в первую очередь к людям котоые с контролерами плотно работают и вот с какой целью, стоит ли начинать ??? и по зубам ли все это

Сделать я могу и сам, только получится как из под топора если не хуже , если идея нравится то давайте обсудим, одним словом жду мнений

Поставь своей проге приоритет реалтайм и ничего не будет терятся. Кстати байты могут терятся если ты пытаешься одновременно еще и монитор кома юзать. Аппаратно не надо ничего делать.



Пик рулит!

Год назад делал КАН в КОМ.

Апаратная база старая 51 контроллер внешний КАН и внешняя ОЗУ.



Сейчас вплотную работаю с процессорами СИГНАЛ.



Это улучшеный 51-й.

На борту у них есть и кан и два КОМа но цена около 150 гр.

на мой взгляд плюс его в том что отладчик под сигналы стоит 400гр.



вообще тема очень интересная.

Давай в понедельник пообщаемся.

Денис, а ты это сделал уже, что в ссылке написанно?

Я к сожалению не силен в Си. http://www.carcd.ru/forum/public/sty..._DIR#>/sad.gif

Пик мона найти и с памятью поболее.

Я вот думаю как конвертнуть прогу на ассемблер.

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

проба пера для контролеров pic18f258 кан в rs232

Команды идут в ascii

PW и PR соответственно запись и чтение регистра пика

O Режим работы после команды следует 2 числа (например O80 режим настройки контролера) , равнозначно pw6f80

B установка скорости кана , пример В01f805 (это 3 команды pw7001, pw71f8, pw7205)

R чтение cancon и canstat регистров , (PR6e и PR6f)

M и F маски и фильтра сообщений соответственно, формат MnMask где n номер маски (1 или 0) Mask 4 байта, фильтр аналогичен, только n от 0 до 5



T , вид TidDldata где Id 4 байта DL 1 байт (длинна сообщения) и data до 8 байт

1 байт 2 ascii символа, ввод команды по коду 13

данные от контролера идут просто байтами, без преобразования в ascii , програма написана без использования прерываний, если приходит сообщение то оно просто передается в rs232

пожелания по протоколу обмена принимаются, если это конечно комуто интересно



ссылка на русское описание кана для этого пика

Ссылка на калькулятор для регистров установки скорости работы кана

Пока одно пожелание:

при написании АСМА активнее пользуйся ТАВ ом.

Для Дениса от другого Дениса, как обещал .

Посмотрел, вроде шняга какаято, а вроде и нет...

малость переписал, исходник тут http://deniss.kiev.ua/progrramers/

почти все команды передаются в ascii и заканчиваются кодом 0dh (перевод строки)

команды :



'B' установка скорости, вид BXXYYZZ + 0dh где xx первый делитель yy второй и zz третий



'M' маска приемника вид MxXXYYZZKK + 0dh где x номер маски 0 или 1 для каждого из приемных буферов, XXYYZZKK сама маска



'F' аналогично маске, только № фильтра от 0 до 5



'O' запись управляющего регистра контролера Oxx + 0dh где хх значение (00 открыть, 80 закрыть, режим настройки) все выше перечисленые команды доступны только в режиме настройки



'T' передача сообщения, вид T1HHHHHHHHLLDATA + 0dh HH-заголовок, LL длинна сообщения и дальше сообщение(data)



'R' чтение статусного регистра



'S' програмирование быстрой передачи , SmHHHHHHHHLLDATA + 0dh HH-заголовок, LL длинна сообщения и дальше сообщение(data)

m-id передачи в диапазоне 90h-BFh



быстрая передача , это вызов заранее запрограмированой строки путем передачи 2 байт а именно Id + 0dh

Hi All



Вернулся с отдыха... http://www.carcd.ru/forum/public/sty...O_DIR#>/11.gif



Почитал... http://www.carcd.ru/forum/public/sty...O_DIR#>/11.gif



Предлагаю не изобретать велосипед и использовать мною разработанный протокол...



Это не текстовый протокол, а пакетный... с контрольными суммами и синхронизацией...



Мое железо я уже предлагаю... стоимость 100 USD, сделано на AT90CAN128



Интерфейс - USB to COM - скорость 921600



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



Посмотреть пример проги можно здесь - http://carcd.ru/forum/index.php?showtopic=8444



Для разработчиков протокол прилагается к железу...

Возможна консультация по организации буферов в Windows для исключения потерь пакетов



Если будут вопросы - ICQ 47108904

или alodin@mail.ru

Сейчас более-менеее буду в он-лайне

to deniss

посмотрите , может поможет при работе с ком в реалтайм

желательно выложить спецификацию необходимых Вам

команд может чем-нибудь помог-бы

не сам так друга попросил-бы из epam-sistems

если не по теме то пожалуйста удали

**

немного инфы по теме CAN

****

добавляю кальк с утилитами загрузки

usb-can

http://www.qprotos.com/datasheet/QuickCAN_1.0.pdf

кто шо думает

А стоит ли разробатывать ?



http://www.mictronics.de/?page=can_bus



Здесь со всеми исходниками и т.т.

Это уже второй клон (теперь как Open Source) известного CANUSB интерфейса от LAWICEL. www.canusb.com. Не знаю, как работают клоны, но оригиналом я доволен. Я в прошлом году софт под него написал.

Может я уже и не сильно помогу. Делал переходник RS <-> Ethernet (все работает без проблем до сих пор).

Общая задумка такая:



1. В МК организовывается обслуживания двух прерываний:

- принятие новых данных от CAN: запихивает принятые данные в FIFO, увеличивает кол-во данных в FIFO и указатель на следующий записываемый байт / блок в FIFO, а в случае отсутствия текущей передачи байта, т.е. когда все предыдущие байты уже были переданы в комп и FIFO пустое принудительно инициализирует прерывание окончания передачи байта

- окончание передачи текущего байта: при наличии данных в FIFO передает текущий байт в комп уменьшая кол-во данных в FIFO и увеличивая указатель на следующий читаемый байт из FIFO.

Такая организация обеспечивает полностью два асинхронных потока, первый принимает все что пришло, а второй по мере возможности передает все что есть в FIFO в комп, они связаны между собой только счетчиком кол-ва байт в FIFO. Можно также организовать проверку переполнения FIFO, если оно полностью забито то не принимать текущий блок от CAN.



2. В ПК хорошо бы реализовать прием всех данных в отдельном потоке (thread), меньше будет влияние GUI и соответственно видны и соответственно оболочка не будет виснуть в случае непредвиденных ситуаций. Избавится от потери байт очень просто, с помощью функции SetupComm(hCom, 0x10000, 0x10000) установить размеры системных буферов, т.е. система сама все пробуфиризирует на уровне ядра, и ни какая мышь и даже просмотр фильмов и 100 % загрузка CPU не приведут к потери данных. Прием данных можно организовать в потоке следующим образом: читаем непрерывно 1 байт, если байт прочитан то он говорит сколько байт будет передано в следующем пакете (данный байт должен быть записан в FIFO в прерывании CAN, так как только там известно сколько было получено байт), место циклического чтения байта можно организовать событие по маске (но для этого нужно хорошо MSDN прочитать). После успешного принятия байта длины пакета читаем весь пакет за одни раз.



3. Если нужна гарантированная передача данных + высокая скорость до ~900 Kb/s и не хочется делать контрольную сумму и прочие проверки, рекомендую вместо MAX 232 использовать CP210x. Это преобразователь RS <-> USB, с МК сопрягается по TxD и RxD, а в винде работает как обычный ком порт, но с гарантированной доставкой данных.

А я правильно понимаю что в этих клонах на AVR ни о каких 1MBit/sec непрерывного трафика и речи идти не может?

Какая реальная скорость.



Думаю на AT91SAM7A3 забубенить.

Хочу поднять тему.

Как у народа с реализациями ?

Появилась ещё одна разработка с набором комманд от Lawicel.

http://www.canhack.de/viewtopic.php?t=24

Возможно реализовать на Aтмелях MSC51 , там есть три контролера в разных корпусах 89C51CC01 , 89C51CC02 и 89C51CC03.

можно глянуть тут _http://www.mictronics.de/?page=can_bus - схемы, исходники и все такое

AVR controlled USB<>CAN Bus Interface на mictronics.de не самое лучшее из того что может быть, я в свое время сделал и забыл , выкладывал все ведь ... http://deniss.com.ua/progrramers/

Всем спасибо за ответ.

Денис ты ж в курсе как никто что я уже почти не в теме = )

Сейчас это больше как хобби