AN1338 ( http://www.microchip.com/stellent/idcpl ... e=en554836 ) e bootloader за цялата гама PIC32. Поддържат се следните медии:
- UART;
- USB HID;
- USB MSD;
- SD card;
- Ethernet;

Липсва I2C и CAN

Мисля тия дни да го изтествам.

Много скоро ще се заема с CAN bootloader за PIC32, а и за dsPIC30. UART bootloader-а бачка безгрижно на до 3 мегабита. Пробвано.

Хубавото е че при PIC32 софтуера е разделен на библиотеки, и фактически трябва да се подмени само translayer.c и translayer.h. Е, и да се предвидят командите за работа с CAN месиджи, ама това е по-скоро бял кахър.

Един интересен аспект е че понеже целия bootloader може да се набута в RAM паметта, може да се направи така че да може да се ъпдейтва и самия bootloader. Но и с това ще си играя на по-късен етап.

Сега човъркам изолиран USB-CAN преходник пак с PIC32, и после веднага подхващам и CAN bootloader-а.

Използвам TI ISO1050, нямам забележки. За CAN bootloader Microchip имат едно дърто AN247, на което сега погледнах вече го няма и сорса в сайта им, само PDF-a е останал. Това ме навежда на мисълта, че са свалили софтуера умишлено, с цел преработка. Mоже и да публикуват в скоро време нещо готово за CAN. Мен също ме интересува за dsPIC3x и за TMS320.

За преходник използвам MCP2515DM ( 2бр. за $55 , USB PIC18F4550 + MCP2515 ), PICDEM CAN LIN2 ( PIC18F4580 към UART ) и/или PEAK USB adapter. PEAK-a има документиран DLL интерфейс към него, пробвал съм го, работи безпроблемно. Ако ще правиш CAN bootloader ( не само за PIC ), то е хубаво да поддържаш PEAK USB адаптера тъй като дефакто е стандарт.

Един кратък списък на bootloader-ите на Microchip:

1). AN851, Introduced 2002, PIC18F and PIC16F87x devices.

2). AN1157, "A Serial Bootloader for PIC24F Devices", 01/24/2008, based on AN851 but for PIC24F. Use the same protocol between HostPC and microcontroller.

3). AN1310, "High-Speed Serial Bootloader, PIC18 & PIC16 devices", 02/03/2010. The host software is written in Qt C++
and support both Windows and Linux OS. Based on An851 but the boot memory is moved at end of the program memory.

4) AN1388, "USB, UART and Ethernet bootloader for PIC32 Devices", 01/16/2012

5) AN1094, "Bootloader for dsPIC30F/33F and PIC24F/24H Devices", 05/18/2007

6) AN1302, "An I2C Bootloader for the PIC16F1XXX Enhanced Core", 12/17/2009

7) AN247, Boot v7 CAN bootloader на Microchip.

Serial PIC Bootloader ( picpgmboot ), това е проект който намерих в Интернет. Кода за микроконтролера е на CCS C, протокола е обикновен Intel HEX файл ( в моят bootloader също за протокол използвам Intel HEX формата ). PC софтуера на picpgmboot се разбира с моят bootloader.

9) PICKit2 Bootloader. Това е bootloader-a на Microchip за PICKit2 програматора. Процесора е PIC18F2550. Кодът и за микроконтролера и за PC софтуера е отворен, протокола много прилича на AN851 протокола.


Повече от странно е, че нямат един стандартен протокол и host софтуер, който да поддържа цялата им гама.

Благодаря. Много полезна и сбита информация.

За изолатори до момента използвах ISO7221M, и след него MCP2551. Без забележки, поне от малкото, което съм опитвал. На мегабит скорост. Чак после се усетих че TI предлагат ISO1050 а и AD предлагаха нещо, и реших да мина на ISO1050, но едва вчера пристигнаха и тепърва ще сглобявам.

Ще поразгледам PEAK, щом се брои за стандарт.

Благодаря, пак. Много ценно инфо ми даваш.

ПП: Иначе в момента за комуникация с dsPIC30-ката ползвам USB-FT232 на мегабит скорост (пусках го и на 3 мегабита - работи), от там в UARTА на междинна PIC32-ка, и през неговия CAN препращам към dsPIC30-ката, която е на друга платка. CAN шината е изолирана двустранно с ISO7221. Двете платки са части от проект в ранен етап за управление на заваръчна машина. dsPIC30F4012-ката е върху контролера на телоподаващото устройство, a PIC32-ката върху контролера на инвертора. Понеже е на ранен етап, а сефте хващам PIC32-ка, сложих му комуникация и през UART-а че най-лесно се подкарва, ама не си е работа така.

Ей му картинката на контролера на телоподаването. Управлява четков мотор с редуктор, с обратна връзка с енкодер върху оста на мотора. Идеята е прецизно управление на скоростта, ускорението и спирането, и изпращане на данни за това до PIC32-ката, дето управлява инвертора. Вътрешната комуникация ще е чрез изцяло изолирана CAN шина със собствено захранване. И съответно през нея трябва да се ъпдейтва и софтуер, да се прави диагностика по време на разработката и т.н.


А ето и какво прави с мотора:
http://www.youtube.com/watch?v=JqxNEAugQ_s

Жълтото е скоростта, а червеното - дютито контролера със среда около 5-цата. Нагоре е ускорение, а надолу - спиране. Тия данни също ги "точа" по CAN шината.

Като стана въпрос за буутлоудъри, да питам. Не, че съм заритал, но е добре да имам рън-тайм боотлоудър за PIC24F по UART. Целта е дистанционно префлашване, ако се наложи. На UART-а е закачен GSM модул. Той трябва да управлява префлашването. Особеното при мен е, че проца включва GSM модула и затова преминеване през ресет е нежелателно.

Лео, това съм го правил по следния начин - като исках да префлашна процесора го карах да си дърпа програмата от ftp сървър, записвах я в една външна SPI памет, вдигах един флаг в нея и после рестартирах процесора. Като тръгне процесора си проверява въпросния флаг и ако е вдигнат вижда дали има валидна нова версия на програмата и се префлашваше от въпросната памет.

С 24-ки не съм се ровичкал достатъчно, но на 32-ката може да стане. Не е нужно да ресетваш принципно. Може просто да извикаш bootloader-а с команда през UART-а например. След това - по общия ред. На PIC32-ката можеш дори да заредиш bootloader-а в RAM паметта и да го накараш да върви изцяло от там, особено ако не ползваш интеръпти. Не знам на PIC24-ката дали е възможна тая галимация.

ПП: Картинката горе вижда ли се, или да взимам мерки?

Тази комуникация включва ли зареждане на нова програма или е просто част от работата на устройството ?
Като междинна платка ще ти е много удобна MCP2515DM-BM, както писах и по-горе вървят в комплект по 2 бр., общо за $55. Host PC софтуера не е с отворен код, но протокола на обмен по USB между Host PC и MCP2515DM-BM е описан тук . Примерчето работи под Ubuntu 10.04 LTS, под Windows не съм го изпробвал. Но ако ще си правиш USB <-> CAN адаптор с PIC32 не се занимавай с MCP2515DM-BM.
Аз използвам dsPIC30F5015 като CAN възел, 250kbps, J1939 протокол, нямам забележки.

Може би ще ми се наложи да направя CAN bootloader за dsPIC30F/33F/E/TMS320, като цяло съм се насочил за протокол да използвам директно HEX файла, чете се един ред, маркера за начало на реда ( ':' ) ще се комбинира с броя байтове в записа и типа на записа в един байт, следва адреса (или отместването на адреса) и самите данни. Контролната сума ще се премахва от HEX записа, тъй като всеки CAN пакет си има CRC16, така че става ненужна. Ако един HEX запис не се събере в един CAN пакет ( някои се събират, но повечето не ), се изпраща колкото пакети са нужни, като от втория пакет нататък първия байт ще съдържа последователния номер на пакета ( за тази цел може да се използва и CAN ID полето, просто се инкрементира с 1, но това е приложимо ако в CAN мрежата ще са само контролера за програмиране и програматора ), защото е възможно пакетите да пристигнат в контролера не в реда в който ги изпраща програматора. След всеки получен пакет контролера го обработва, прави запис( ако го изисква пакета, щото може и само extended адрес да се съдържа ) и верификация, след което отговаря с ACK(успешен запис) или NACK(неуспешен запис). Тъй като верификация на записа си правия самия bootloader не е нужно да се добавят host команди за четене и верификация, т.е. HEX файла се налива директно ред по ред, ако на някой ред host получи NACK, значи съответния ред не се е записал. Или го повтаря отново ( а ако предходния ред съдържа extended адрес повтаря и двата реда ), или започва отначало. Възможно е при последователни адреси да не се изпраща за всеки запис отместването на адреса, тъй като bootloader-а си прави последователно инкрементиране на адреса. Това ми се върти в главата, не съм го обмислял сериозно, може и да възникнат потенциални проблеми, но същия принцип използвам в мой си UART bootloader за PIC18Fxxxx и нямам забележки.

По принцип при такъв елементарен протокол на обмен между програматора и CAN възела за програмиране ще възникнат проблеми ако мрежата е натоварена ( примерно в CAN мрежата на един автомобил достига до 90% натоварване ). Но на мен ми трябва за смяна на софтуера на контролера през съществуващия му CAN куплунг на кутията - устройството се разкачва от мрежата, закачва се на CAN куплунга на програматора и му се налива новия код. Това се налага тъй като устройството е неразглобяемо, но на куплунг е изведен CAN. Преди време бях гледал как един образ си беше направил bootloader за PIC18, като използваше само MCLR пина и WDT , нещо като 1-бит жицата на Dallas, с времеви слотове.



Кой да е bootloader ще ти свърши работа, просто при получена команда RESET, ще прави джъмп към предварително дефинирана точка в Application кода, вместо да се ресетира. Извикването на bootloader ще става по аналогичен начин: при получена команда през GSM модула се извиква bootloader, след което чака да получи пакетите.

Замисъла е такъв:
- Между вътрешните "възли" на машината има локална CAN шина, работеща на мегабит. Тя ще е къса физически (не повече от метър), от усукана двойка, екранирана и изолирана от всички платки, и със собствено захранване от 5V, вървящо по същия кабел. Мисля да използвам кабел като на за USB, защото си има и усуканата двойка, и захранването и екранировката. Всичките тия мерки защото в една заваръчна, разбирай покрай инвертор с мощност 5 киловата и нагоре, сам се сещаш че се случват "интересни" нещица по отношение на всякакъв вид смущения.
- Един от "възлите" на машината е панела за управление, на който ще има дисплей, копчета, ротари енкодер и прочие. Тоя панел за управление ще има различни варианти за външна комуникация - по изолиран RS232, по външен изолиран CAN, по TCP-IP върху оптика, USB, и каквото още ти дойде на акъла.
- По време на нормална експлоатация всичко (ъпдейт на фирмуер, качване на заваръчни програми и прочие) ще става през тая външна комуникационна връзка. От друга страна, по време на разработката и дебъгването ще се ползва предимно вътрешната CAN шина, като тоя преходник ще е просто един от възлите по шината.

В общи линии това съм измъдрил. На всичкото отгоре и ъпдейтите на фърмуера трябва да са кодирани по някакъв начин, поне към основните модули, чиито процесори имат достатъчно ресурс за такова нещо, защото иначе машината много лесно ще се "клонира", понеже хардуера така или иначе не е велика трудност да се направи, но софтуера, особено за управлението на инвертора, си е едно доволно времеемко занимание, което човъркам сигурно половин година вече, а тепърва ще трябват и експерименти в реални условия, което е истинското загуби време, и може би най-скъпата част от проекта.

Ако ще го правиш са собствен гъдел е ок, но ако ще го правиш да се продава не е ли по-разумно да оставиш само един интерфейс на дисплея, и след това да предлагаш адаптори от този интерфейс към външния свят ? По този начин дисплея ти става евтин ( а и цялото изделие ), а на клиента според нуждите му се продава подходящия адаптор.


Сигурно се случват , ние въртим един 200kW електромотор, генерираме едни 30кW и нагоре мощности, чат пат текат по 1000А тоци, от време на време се изпаравят 600А MOSFET-и, като цяло сме почти готови с крайния вариант на изделието. Остана един J1939 да насосаме да поддържа съобщенията на конкуренцията.

Еми, дисплея и интерфейса въобще, пак се управлява от PIC32MX795, защото за дисплея ще ползвам 320х240х8 TFT, което иска едни 76к памет, а аз искам да ползвам вътрешната му. А е удобно, защото към дисплея друга периферия няма да има - и таймингите и всичко се генерира от DMA трансфери през паралелния порт + интеръпти за развивката, което товари процесора около 5-6%. От друга страна, тая PIC32-ка си има и 2 CAN контролера (един за вътрешната и един за евентуална външна шина), UART, USB, и ETHERNET. Просто хадруера за външна комуникация ще е малка отделна плака на слот към платката с дисплея, и в зависимост от това каква свързаност иска клиента, ще се слага съответния вариант със съответния хардуер върху него. Понеже за самия преден панел кой-знае каква производителност и бързодействия не е нужна (всъщност най-много ресурс ще отива в чертане на това, дето излиза върху екрана), то той може да се използва безгрижно и за комуникацията с външния свят.

Съвсем случайно попаднах на фрий CAN bootloader за dsPIC30F4012 тук:
http://www.bylogix.it/projects.php?l=en&i=54

Направо в десятката.

Току що пуснах заявка за сорса (както фирмуера, така и PC софтуера), и да видим какво ще стане. Правен бил за преходника на тия хаймани:
http://www.canusb.com/products.htm

А ето преходник със все схемите и платките, който пише че е съвместим като протокол с горния:
http://www.mictronics.de/projects/usb-can-bus/

Прочети внимателно какво пишат италианците , PC софтуера им е за Lawicel CANUSB адаптор, а Lawicel CANUSB адаптора е виртуален COM порт

Ако решат да ти пратя сорса ( което малко ме съмнявам, въпреки че го обещават ) постни тук, интересно ми е форматът на протокола, кода не ме интересува

Като изключим драйвера, PC софтуера въобще не ме плаши. Това, дето искам да видя най-вече е софтуера, набутан в PIC-льото. Или по-точно готово работещо решение, за да си съкратя малко мисленето че много неща станаха вече.

Точно така ще е, но това го прави GSM-модула - дърпа своя софт и софта на проца от ftp-то, буферира го в RAM-а и след това префлашва себе си и проца (през UART-а). Последното ми остава да направя.