Автор Тема: Armduino Scada  (Прочетена 3689 пъти)

ivo1204

  • Напреднали
  • *****
  • Публикации: 987
    • Профил
Armduino Scada
« -: Apr 22, 2012, 13:37 »
Здравейте,

Продължавам  темата  за  'Arduino Scada', като този път се надявам да се включат повече хора с конструктивни постове.

В края на предишната тема,    @ laskov e дал линк към Ардуйно с ARM.
  http://news.idg.bg/news/59348_proektat_arduino_predstavi_platka_s_arm_procesor

И това вече е остаряло, преминаването на ядро ARM Cortex-M4 е въпрос на време.

Затова трябва да говорим по общо за нещата, но пък без да имаме 'железото', не става,  и ако трябва да се спрем на конкретна платка, бих ви препоръчал
STM32F4DISCOVERY
 http://www.st.com/internet/evalboard/product/252419.jsp

Достъпна /и в България / и много евтина, например

http://uk.farnell.com/stmicroelectronics/stm32f4discovery/board-eval-stm32f4-discovery/dp/2009276

Тук основното е да знаем, че въпреки написаното на нея, че работи с Уиндовс-ХХ, работни среди и драйвери за нея има и под Линукс, и няма никакъв проблем от ОС, напротив, ще се чустваме доста по комфортно.

Действително всички официални работни среди, включително Eclipse базираните, не предлатат свободна и отворена версия за Линукс, затова няма да се занимаваме с тях.  Eclipse e свободен, просто трябват малко повече настройки.

GCC e комприлатора, който ще ползваме, впрочем имаме случай на стандартен toolchain за ARM , и все пак оптимизиран за Cortex-Mх . Впрочем в приложеният скрипт са и източниците, а платката не се флашва, а зарежда и стартира от RAM. Така че редактирайте го с правилната  директория и от него ще се орентирате какво става.

 
« Последна редакция: May 28, 2012, 15:33 от ivo1204 »
Активен

ivo1204

  • Напреднали
  • *****
  • Публикации: 987
    • Профил
Re: Armduino Scada
« Отговор #1 -: May 02, 2012, 21:09 »
Както   @ laskov посочи, Ардуйто с АРМ има.За тях са написани библиотеките libmaple:
http://leaflabs.com
https://github.com/leaflabs/libmaple
Сега, за същият микроконтролер какъвто е и на STM32F4 Discovary се разработва и нова платка и се портват библиотеки. И клонинги.
http://www.netduino.com/netduinogo/specs.htm
Също и независими разработки.
http://www.ghielectronics.com/catalog/product/349
http://code.google.com/p/multipilot32/source/browse/

За STM32F4 Discovary могат да се ползват Open Source библиотеките
libopencm3,
http://www.libopencm3.org/wiki/Main_Page
както и официалните: http://www.st.com/stonline/stappl/resourceSelector/app?page=resourceSelector&doctype=FIRMWARE&SubClassID=1521

Или по точно  stm32f4discovery_fw.zip

http://www.st.com/internet/com/SOFTWARE_RESOURCES/SW_COMPONENT/FIRMWARE/stm32f4discovery_fw.zip

Дебугер и програматор
 https://github.com/texane/stlink

ARM  плагинги за Еклипса
http://sourceforge.net/projects/gnuarmeclipse/

В Еклипса
http://gnuarmeclipse.sourceforge.net/updates

компилатор
https://github.com/esden/summon-arm-toolchain

или
G++
wget https://sourcery.mentor.com/sgpp/lite/arm/portal/package9740/public/arm-none-eabi/arm-2011.09-69-arm-none-eabi-i686-pc-linux-gnu.tar.bz2

Полезен линк
http://jethomson.wordpress.com/2011/11/17/getting-started-with-the-stm32f4discovery-in-linux/
Активен

ivo1204

  • Напреднали
  • *****
  • Публикации: 987
    • Профил
Re: Armduino Scada
« Отговор #2 -: May 10, 2012, 11:02 »
Разбира се, трябва да споменем и 'openocd', за който се препоръчва компилиране от git,
 http://sourceforge.net/projects/openocd/develop
но си го имаме и като пакет – apt-get install opeocd / Убунту /.
По две думи и за други неща – сорс кода на gcc за ARM  се подържа и от mentor /G++/ , и от  linaro
http://www.linaro.org/
Освен това, ще забележите, че имаме в пакетите на Убунту поне още два arm toolchain-a 'gcc-arm-linux-gnueabi' и 'gcc-arm-linux-gnueabihf', те са друга работа.
С две думи нещата които ни вълнуват са – малки библиотеки, т.е. gcc  с newlib:
http://sourceware.org/newlib/
 второто нещо е дали може да използваме хардуерните възможностти на STM32F4xx в Discovary за изчисления с плаваща точка / DSP-то /. 
Сега ,да сглобяваме нещата.
Платката идва без УСБ кабели, трябват ни 2, мини, който отива към вградения STLink/V2. За програмиране, дебъг, а също и захранване. Версия две на st-link-a е коренно различна от версия 1, и не прави никакви проблеми. С нея работи перфектно st-utils.
 https://github.com/texane/stlink
Просто я стартираме ./st-util и толкова, нямаме повече грижи.
st-util e gdbserver, и слуша на прорт 4242
Когато стартира, тя се свръзва с платката, червеният светодиод става зелен. Ако не може, не е вкюъчена платката например, st-util  се самозатваря, иначе остава като демон.
Затова като викаме   arm-none-eabi-gdb
му даваме връзка :
 target extended localhost:4242
За да си направим средата удобна, st-utils си я слагаме в
run->External tools-> External tools Configurains
и я стартираме преди да дебъгваме/флашваме.

Другият е 'micro USB' и е към OTG USB порта. Това, което първо ще направим е и доста тудно, ама нужно. Да го направим този порт 'virtual com port', термитал, с който да комуникираме. И ще е /dev/ttyACM0.

.....

На следващият етап избираме софтуера, който да 'преизползваме'. За съжаление, 'официални' примери за CDC драйвер за STM32F4xx няма, има няколко от други източници.
Ще започнем до примера в libopencm3, защото е компактен и дава представа за какво става дума.
http://libopencm3.git.sourceforge.net/git/gitweb.cgi?p=libopencm3/libopencm3;a=blob_plain;f=examples/stm32/f4/stm32f4-discovery/usb_cdcacm/cdcacm.c;hb=651917aeb4b76afbb6c4a859e9a7aab4978b5008

В 'main()', „rcc_clock_setup_hse...“ конфигурира честотата на пратката, имаме 120 и 168 Мхц опция. За УСБ то обаче, ни трябва точно 48Мхц ,иначе просто няма да работи.
 'rcc_peripheral_enable_clock', 'gpio_mode_setup',  'gpio_set_af'
са ясни още по наименованията си . Първо включваме честотата на съответната периферия, конфигурираме крачетата,  GPIOA, GPIO_AF10, GPIO9 | GPIO11 | GPIO12 са
4-те линии към микро УСБ-то.
'usbd_init(..)' и с usbd_register_set_config_callback (cdcacm_set_config); закачаме фукцийте, обслужващи съотретното действие.
Фактически имаме 3 точки на достъп – 0x01, 0x82,0x83. 0X83 e контрол, а другите за блоков обмен едната за предаване а другата за приемане на данните.
  static const struct usb_device_descriptor ,...
static const struct usb_endpoint_descriptor....
static const struct usb_interface_descriptor....
Това са дескрипторите задържетелни по УСБ стандарта, което нашата дискавари трябва да представи на РС хостта. Защото тя ще работи само като 'device' /OTG може да и двете /.И като такава, тя може да работи само на пълна скорост FS, не и на хай-спид.
While (1)    usbd_poll();
Това фактически е безкраен цикъл, в който usbd_poll() върши обслужване на усб-то, дали нещо е дошло, и дали има нещо за пращане и т.н.
Тук е мястото да споменем, че усб-то може да се обслужва по два начина – както тук, с poll, или чрез прекъсвания.
 И при двата начина обаче имаме голям проблем.  И той  е при изпращане на данните.Когато изпращащия данните буфер се изпразни , хардуера вдига прекъсване, и чака нови данни. И ще го вдига постоянно, като ще яде яко ресурсите на системата.
 За този проблем трябва да се погрижи софтуера.
Причината да не използваме тоя пример е, че той е базиран на STM32F107, не на нашият чип STMF407. И фактически използва драйвера на 107 като връзва нашият dev към този на 107 драйвера. Вероятно проблем няма, но ако има, едва ли ще има някой нерви да сравнява двата чипа.
Други примери, вероятно и те трансферирани от STMF107 и STM32F103 или по нови, има в този пост се разисква проблема -> 'Help transfering data to PC' 
и са дадени линкове  https://my.st.com/public/STe2ecommunities/mcu/Lists/STM32F4DISCOVERY/Flat.aspx?RootFolde

Обаче ще пролзваме в случая този
https://www.das-labor.org/trac/browser/microcontroller/src-stm32f4xx/serialUSB

с надеждата сторо да има и 'официален' пример. Пречината за избора е, че библиотеките за дискавъри ще се обновяват и изчистват грешки, още не са стабилни, /да не кажа ужасни/ и затова ще може да продобрямаме драйвера.


   


« Последна редакция: May 14, 2012, 10:41 от ivo1204 »
Активен

ivo1204

  • Напреднали
  • *****
  • Публикации: 987
    • Профил
Re: Armduino Scada
« Отговор #3 -: May 14, 2012, 11:26 »
Защо точно ни трябва да ползваме виртуален ком порт през УСБ? Имаме освен нашият  CDC, още  DFU и HID класове USB и за тях има и работещи примери, STM32F4 Discovary идва със заредено демо, в който се ползва HID клас драйвер, и то работещ в OTG – и хост, и девайс, както го включиме.
А DFU пък си е пък стандарт за флашване на фъруера, така че и той трябва да е бетон.
Ами, тъй като темата е 'Armduino Scada', заглавието предполага, че ще имаме нещо общо ис двете, и че е продължение на предишната - 'Arduino Scada'. В нея , вързахме Ардуйното с Proview Scada-та.
Сега, вчера по точно, гледам  Proview са пуснали и версия за Убунто 12.04,
http://sourceforge.net/projects/proview/files/proview/proview_4.8.4-1/
И в нея има Arduino UNO. И ще ползваме неговият интерфейс, иначе ще трябва да пишем и компилираме наш, а с това вече е ни стане много.
http://gitorious.org/proview/mainline/blobs/master/otherio/exp/rt/src/pwr_arduino_uno.ino

----
 Предполага се, че сме инсталирали Eclipse, закачи сме му плагините за ARM и сме указали компилатора и st-utils /като External Tools  /.
 Project->Properties->C/C++Build ->Environment->
Add -> PATH  value expample: /my_compilers_top_dir/arm-2011.09/bin
 
В смисъл, готви сме да пишем код и компилираме. И тъй като се предполага, че ще има бая пъти да корегираме,зареждаме  и тестваме кода, остава ни една важна екстра – STM32F407 притежава достатъчно RAM, за да си заредим нашата програма там и да я тестваме, без да ползваме FLASH паметта. Не че ще я съсипем, имаме 10 000 гарантирани цикли на запис, но е значително по бързо зареждането в RAM. В Еклипса такава екстра – да щракнеме 'Дебъг в РАМ' нямаме, за това трябва да ползваме лоудер скрипта, xxx.ld, и без това трябва да го имаме някъде, а най добре да си имаме два – за 'всичко в рама' и нормален. Впрочем направо давам моя от проекта, номера е флаш или ром е заменено с 'рам'.
И го посочваме,с опция   -Т  за линкера:
Project->Properties->C/C++Build ->Settings->ARM Sorsery Linux GCC C Linker ->General->Script file (-T)
Друго каквото трябва да направим / то зависи от конкретните библиотеки, в случая тези на STM32F4Discavary firmware / е да експортираме символи, които  ще се дават в командния ред към GCC-то.
Нашата платка има външен кварцов генератор 8Mhz. Библиотеките /за stm32f4/по подразбиране слагат 25Mhz, а на нас ни трябва в командния ред -DHSE_VALUE=8000000 .
Project->Properties->Paths and Symbols->Symbols :
HSE_VALUE=8000000
STM32F4XX
USE_STDPERIPH_DRIVER
USE_USB_OTG_FS

----
Разбира се, редно е първо да се опитаме да минем тънко, без да набутаме всичките библиотеки в нашият проект. Естествено, правим една папка src, пишем файл main.c с void main(){}; и ... той се компилира.
Това е така, защото компилатора си слага неговите 'старт ап' файлове и билиотеки, нашият случай обаче не е такъв. Ще срещнем флагове като  -nostdlib, който забранява включването и на старт ап на компилатора, и на код от библиотеките, или пък -nostartfines -nodefaultlibs  поотделно.
Линкер скрипта , след като го включим, пръв ще даде грешка. Впрочем да не закопаваме много надълбоко , просто ни трябва горе долу да знаем кое за какво го правим и какво слагаме в 'манджата'.
 Компилатора знае по подразбиране адреса на който предаде управлението след Reset, и това е грешно предположение. Защото адреса е зает. А пък и ние решихме, че ще ползваме рама първоначално. И като решихме да ползваме
  https://www.das-labor.org/trac/browser/microcontroller/src-stm32f4xx/serialUSB
първият файл, който ще 'пейстнеме' e  startup_stm32f4xx.s /разбира се там вече е нашето сиромашко main.c / Да не забравя, трябва да сменим разширението 's' с голямото 'S', щото Еклипса не разпознава правилно и не се компилира.
Тук се слага стек пойнтера, така че да може да викаме с call. Копират се праменливи в рама, и др неща, както и при другите процесори, нищо неочаквано. След това на
97  bl  SystemInit  - викаме    SystemInit()
98 /* Call the application's entry point.*/
 99   bl  main викаме main()
пак нищо неочаквано.
Другото са векторите и най-важният – Reset Hendel който сочи началото на кода.Всичките обявени за weak, меки, така че ако ги предифинираме, компилатора няма да мрънка.
Особенното тук е друго, хардуерно, в този момент ние сме още с системен клок 16Мнц, от вътрешният тактов генератор, HSI. И първата ни работа е да превключим на истинската ни работна честота.
Тази SystemInit() се намира във файла system_stm32f4xx.c  .
Там се задават и другите честоти, а и нещо важно за нас
 
 /* Configure the Vector Table location add offset address */

#ifdef VECT_TAB_SRAM
 SCB->VTOR =SRAM_BASE |VECT_TAB_OFFSET;
 Vector Table Relocation in Internal SRAM
#else
 SCB->VTOR = FLASH_BASE |VECT_TAB_OFFSET;
/* Vector Table Relocation in Internal FLASH */
#endif
  Демек, да си добавим и  'VECT_TAB_SRAM'  в експортираните символи ако ще ползваме само РАМа за кода, /таблицата с векторите се сочи от хардуерен регистер /
За да си свърши обаче работата  SystemInit(), има още файлове да включим. Например ни може да подозираме, че RCC->CFGR е някякъв бит/бита  от регистър, но всичко това е описано в stm32f4xx.h, главният файл който задължително трябва да включим.
Той от своя страна изисква няколко файла, които не са само за STM32F4, а за CortexM4 изобщо. core_cm4...
Тук е дефинирана и HSE_VALUE 25MHz,  а и ако сме дефинирали USE_STDPERIPH_DRIVER се включва и протребителският
stm32f4xx_conf.h
кайто чрез коментиране  просо на
#include заглавен файл
прави  Еклипс базирани среди като CooCox например едва ли не да изглеждат като автоматични. Отваряме го и коментираме каквото не ни е нужно, това е.
 

STM32F407, и другите, при включване работи абсолютният минимум от  периферията, почти всичко е изключено. Включително към периферията не се подава и тактова честота.
В system_stm32f4xx.c се кофигурират  основните честоти, но не се пуска към устройствата.
Преди да се опитаме да включим нещо, ние му подаваме тактова честота, и то не само на него, а по целият път към него, както и на свързаните с него  други.
Разбира се, можем и без библиотеките, става въпрос за включване на няколко бита от регистри. Обаче като опрем до УСБ то, нещата стават прекалено сложни, така че по добре отсега да ползваме библиотеките.
В библиотеките на периферията, за включване на честотите са написани   stm32f4xx_rcc.c/stm32f4xx_rcc.h ,  за работа с gpio, stm32f4xx_gpio.c /stm32f4xx_gpio.h , тия определено ни трябват, слагаме ги. / и ги откоментирваме в stm32f4xx_conf.h/.
Хубаво е отсега да отделим файловете в различни поддиректории, особенно тези, който ще бъдат редактирани, /като stm32f4xx_conf.h например, хедер, ама ако го плеснем при хедерите ще ни е крайно неудобно, а пък  променен с нещо файл, и сложен в кюпа може да ни подлуди!/.
Тъй като пускането и кофигурирането на дадена периферия най-често е установяване на разни битове и групи от битове в разни регистри, библиотекиге дефинират стрктури, които ние ползваме. Пример,
 typedef struct
{
  uint32_t GPIO_Pin;  /*!< Specifies the GPIO pins to be configured.
                                       This parameter can be any value of @ref GPIO_pins_define */


  GPIOMode_TypeDef GPIO_Mode;     
......... 

}GPIO_InitTypeDef;

Ние искаме да пуснем краче 4 .
Дефинираме такава структура
GPIO_InitTypeDef  my_gpio_init_struct;

След това я попълваме
my_gpio_init_struct .GPIO_Pin = GPIO_Pin_4
.....
  И я предаваме / по адрес / за инициализация на регистрите.
GPIO_Init(GPIOA,&my_gpio_init_struct);
Та да не чудим на тия дълги писания – просто е като попълване на таблица.

« Последна редакция: Jul 31, 2012, 13:53 от ivo1204 »
Активен

Подобни теми
Заглавие Започната от Отговора Прегледи Последна публикация
Arduino SCADA
Предложения за български проект
ivo1204 52 22555 Последна публикация Oct 23, 2011, 22:48
от GB_bg