# PIC mikrokontrolleri >  Pic iespējas

## konis22

Esmu ar pic16f84 uzrakstijis dažādus softus,bet šis man iepatikās.Reāli uz 2 vadiem ar uart interfeisu far komunicēt ar 16f84.Esmu uzrakstijis primitīvas komandas kā piemēram pirms iegūst datus par pic kāju statusu vajag ielogoties picā ar paroli.ja parole nepareizta tad atsūta caur uart atpakaļ paziņojumu ka nepareiza parole,ja pareiza sistēma paziņo ka parole ir ok un tālāk var darboties pa portu statusiem vai vienaloga ko pats ir uzrakstijis.Viss notiek ar 9600 bps pie 4 mhz.Protams ja grib ātrāk tad vajag tikai pamaiīt bitraitu portam un kvarcu kā arī citu pic modeli.bet kapāc rakstu!!! Gribēju pajautāt kādam kas ko tādu ir taisijis.Kā jūs domājat vai ir iespējams ka pic saprot vārdu kas sastāv no ascii teiksim ''exit''
Mana doma bija tāda ka tajā brīdī gad spiež pogu pa portu dati visu laiku staigā pa komunikāciju kopni 2 vadiem un pic filtrē katru burtu un liek kautkādā buferī tad kad nospiež enter buferis tiek lasīts un salīdzināts ar atsīfrējumu tabulu un tad izpildās komanda.otrs variants ir tād ka katru simbolu ko pic saņem varētu skaitīt kopā ar nākošo un tad pēc summas kautkā likt veikt zttiecīgo darbību.Varbūt vēl kādam ir kādas idejas?????  ::   Bet tas mazais zvērs var ne to vien. !!!!!

----------


## 0xDEAD BEEF

Priekš viena vārda exit tev vajag staigāt pa stāvokļiem. Ja vēlies filtrēt vairākus vārdus, tad bez bufera neiztikt.
Un vispār tas ir iespējams un tas ir elementāri, bet tev pašam būs vieglāk, ja kodēsi C, nevis ASM. Tad arī varēsi izmantot strcmp/memcmp..  :: 
Beefs

----------


## java

iesakat labu bezmaksas C kompilatoru priekš pic.

----------


## Delfins

gcc

----------


## 0xDEAD BEEF

Nokačā no microchip lapas to kompileri! Daži ierobežojumi sāksies pēc 60 dienām, bet tās fīčas tu tāpat neizmantosi!
Beefs

----------


## JDat

man, kā BEISCānim assembleristam patīk GCBASIC http://gcbasic.sourceforge.net/
Viegli var uzrakstīt sarežģīto penteri (IF THEN ELSE SELCT CASE utml) un ir dažas standarta bibliotēkas priekš LCD  utml sīkumiem. Pēc tam MPLABā pieslīpēju asm nianses un priecājos par dzīvi. Bet nu tas viss ir gaumes jautājums.

----------


## konis22

Vai tie līmeņi izpaužās tā kad izdomā visas komandas kas varētu būt un tad aptuveni kā alfabētā sāk ar pirmo burtu un tā uz leju kamēr tiek līdz pilnai konkrētai komandai????? a->a a->b  a->c  utt. Vai kaa tā ja????  ::   Man bija doma vienu brīdi tāda kad vienā cipā glabājas visas komandas respektīvi masters ar kuru komunicēt un tad tālāk tas ccips sūta otram picam jau savā interfeisā konkrēti ko darīt .Tas interfeiss starp abiem pic būtu štrunts bet tā laiļoti daudz komandas varētu uzrakstīt nezinu kā īsti to izdarīt.Nu prieks ka vismaz šitik tālu esmu ticis. Jā es ar asm tikai strādāju jo nezinu kautkā citas valodas pagaidām nesaista.Bet ceru ka tikai pagaidām.  ::   Vēl pamocīšos paskatīšu ko jūs man tur sasūtijāt un tad kas prātā nāks.

----------


## next

Auzaas iebrauci.
Nav nekaadas vajadziibas veidot taadu literaaru komunikaaciju starp vairaakiem piciem.
Var buut nepiecieshamiiba komuniceet ar aareejaam iekartaam - modems, gps un tamliidziigi.
Nu tad par taadaam konkreetaam lietaam vajag spriest.

----------


## konis22

Neenu variants jau ir taads ka es komuniceeju ar masteru tas dod savaa interfeisaa komandas uz kontrolieri kas nolasa meerijumus un komunicee ar manu pc atpakall.Taa es domaaju.Jo savaadaak tajaa briidii kad izpildaas kautkaadas komandas sleivaa (kontrolierii) nav nekaadas iespeejas ar vinnu komuniceet un nesaprot kas notiek.A ja irstarpaa 1 kontroleirs kas atbild tikai par interfeisu lai sannemtu datus tad veel kaut kas var straadaat.Taada doma.gps nebuus ne arii kas taads janu vieniigi uart interfeiss.Doma ir vienkaarssa.Lai var komuniceet ar dzelzi taa kaa apmeeram teiksim ar cisco swich komandrindaa.nekas cits.

----------


## JDat

Es savulaik uztaisīju nosacīti līdzīgu uz AVR. Man bija tā: PC nosūtīja 4 baitus uz kontrolieri. Paketes sākuma baits, dati,dati paketes beigu baits. Daudz čakarējos, bet uzrakstīju. Princips apmēram tāds: saņemot baitu, izsaucas receive interrupt, kurš noglabā baitu atmiņas apgabalā un indicē, ka ir saņemts baits un jāapstrādā buferis. Main loop regulāri skatās vai nav saņemts baits. Ja saņemts, tad sagatavo vietu atmiņā nākoša baita saņemšanai un indicē receive interruptam, ka tagad atmiņa ir gatava nākošā baita saņemšanai (nākošā atmiņas šūnā). Pēc tam main loop analizē datus atmiņas buferī. Pārbauda vai ir pareizs starta un beigu baits. Ja viss ir Ok, tad parāda uz displeja datus no datu baitiem. Ja ir kļūdaini dati, tad ignorē. Tas viss mistrojums bija nedaudz līdzīgs Ring Buffer lietai. Protams atmiņa nav bezgalīga un vienā brīdi atvēlētā atmiņa ir pilna, tad attiecīgi procedūra, kas atbild par bufera uzstādījumiem, pāriet uz atmiņas apgabala sākumu. Un tā tālāk. Pa cik main loop izpildījas neskaitāmi vairāk reizes ne kā ir datu ātrums (MCU freq: 7 koma cik tur MHz, īss main loop, seriālais ātrums bija 9600 vai tml), man nebija problēmu ar to ka varu nogulēt seriālodatu apstrādi. Manā gadījuma buferim bija atvēlēti 16 vai 24 baiti, kas ir 4-6 reizes vairāk ne kā uztvertās paketes garums. Apmēram tāda ideja. Protams tas viss plikā asm ir čakars. Čakarējos, jo nezinu C prieksh AVR kontrolieriem. Ja ideja skaidras, tad var pielietot arī PICam.

----------


## sharps

Principaa cik saprotu, tad runa vareetu buut par RS485. Vienaa tiiklaa vareetu seedeet vairaaki kontrolieri lidz 32 fiziski. Katram pieshkjirtas adreses. Pamatvariantaa visi kontrolieri klausaas tiiklu. Viens no kontrolieriem paargaajis "runaashanas" rezhiimaa un izsuuta specifisku komandu ASCII koda veidaa. Ahhaaa visi nu saak gaidit naakamo komandu - adresi ar kuru no klausiitaajiem shis runaa. Tad naakamaa komanda ir pasha runaataaja adrese. Taalaak jau ir dati un ja vajag arii cheksummas.
Shaadu principu lietoju PICiem ar iebuuveeto USART. RX/TX izejas pievienotas RS485 mikrenei, kura savukaart ar A/B kanaaliem savienota ar citaam liidziigaam RS485 mikreneem. To mikreni sauc ST485.

----------


## 0xDEAD BEEF

Un kā tu risināji problēmu, kad vairāki kontrolieri sāk runāt vienlaicīgi?  :: 
Beefs

----------


## JDat

Nu jā, man nebija vairāki kontrolieri. Bija tikai 1 kontrolieris, kas savienots ar PC caur RS-485. Tātad half duplex. Pēc 4 baitu sūtīšanas no PC uz MCU, MCU atbildēja ar 1 baita datiem. Seriālajā terminālī varēja redzēt 5 baitus ar datiem. 4 baitu ko PC pats sūtīja 5. baits, no MCU. Pāreja no RS485 uz RS-232 bija uzlodēta uz dibām 3 kiloomu pretestībām. Bija ideja attīstīt to projektiņu lai var pieslēgt 48 MCU pie centrālās kastes (kurā arī MCU), bet interese pazuda, jo pasūtītājam vairs nevajadzēja to sistēmu. Tajā sistēma tīks bija līdzigs zvaigznei, kur no centrālas kastes aizvelkas vadiņi uz katru gala iekārtu. Pa tiem vadiem tiek dota komanda ar kuru tagad runās centrālais. Kaut kas līdzīgs CS pinam cietajā loģikā.

Starp citu, tā arī bija mana pirmā sastapšanās ar AVR. MCU tur bija ATmega48. Tas bija pamatīgs lēciens no PIC16F84. Uzreiz sajutu starpību perifērijas lietās. Protams man joprojām patīk PIC koncepcija darbam ar perifēriju. Praktiski visos gadījumos pa taisno baiti bitus vai raksti baitus iekšā reģistros. Nav jāizmanto R16 (vai tml) ja gribi ielādēt kādā reģistrā (piem MCUCR). Vārdu sakot visur savi plusi un mīnusi. Par to jādiskutē atsevišķi.


Atgriežoties pie tēmas: Topika autoram itkā vajag no PC seriālā prta vadīt vairākas iekārtas. Varbūt noder idejas, ko šitas onkulis ir uztaisījis. http://www.sbprojects.com/sbbus/sbbus.htm

Itkā viens PC seriālais ports runā ar 127 iekārtām. Diez vai der gatavs risinājums, bet darbības princips var noderēt.
Es visdrīzāk izvēlētos Lantronix Serial server vai tml risinājumus, ja man tas atmaksātos.

----------


## next

Juus te par citaam lietaam runaajat.
Topika autors grib veidot komandrindas interfeisu un nesaprot tas noeediis lielu dalju no resursiem un labuma nekaada.

----------


## JDat

Vārdu sakot, idejas esmu pasviedis. Varbūt ne tajā labākajā veidā izklāstītas, bet tomēr ir. Nedomāju ka man te jāpostē palagi ar saviem netīrajiem un nepabeigtajiem kodiem...

----------


## JDat

Rezumēšu savus spamus utml.
1. Autors uztaisīja software bitbang seriālo portu.
Es arī uztaisīju software bitbang seriālo portu ar PIC16F84, pagaidām tikai variantā, ka PIC sūta datus uz PC. Gribēju lai būtu "pa nopietno" un bez interrupt (jo interrupt bija citam mērķim svarīgs). Es izmantoju 19,6608 MHz kristālu (Ja atmiņa neviļ), ko dalot šo frekvenci ar 1024 sanāk 19200 bit/sec. Main loop sagatavo datus un katra cikla beikgās pārbauda vai taimeris nav pārpildījies. Ja ir, tad nosūta katru bitu. Main loop protams pietiekoši iss lai nerada problēmas serial port laikiem. Zinu ka to vajadzēja taisīt ar IRQ, bet tajā situācijā nevarēju. Vēl neesmu domājis par variantu uztvert datus no PC. Ja vajadzēs tad ar laiku pieviesīšu.

2. Autoram vajag nosūtīt dažus baitus no PC uz kotrolieri (komanda vai parole). Kā to izdarīt. Var mēģināt tā kā es aprakstīju sava AVR gadījumā. Jāizdala daudzums X no RAM reģistriem kur glabāsim ienākošos datus. Jārealizē kaut kādā veidā lai vairāki baiti visu laiku tiktu rakstīti atmiņa viens aiz otra. Principā tas saucas buferis. Jābūt attiecīgam kodam, kas seko līdzi buferim. Sagatavo adresi kur rakstīt nākošo baitu utt, jo Interruptam ieteicams būt maksimāli īsam un tikai nolasīt nākošo vietu kur saglabāt baitu un viss. Tālāk nāk kods, kas analizē buferī saglabātos datus un attiecīgi izdomā vai dati ir pareizi un ko ar tiem darīt.

3. Ja vajag runāt ar vairākām iekārtām pa vienu un to pašu datu kanālu, tad nāksies pagooglēt un vajadzēs likt lietā daudz izdomas lai viss strādātu korekti.Varbūt der konceptuālā ideja no http://www.sbprojects.com/sbbus/sbbus.htm

4. Varbūt ir vērts visu vai vienu daļu realizēt pa ethernet. Ja nav variantu ar ethernet iekārtai, tad varbūt ir vērts pamēģināt kaut ko no Serial over ethernet.
Pieliec mazu shēmiņu pie aparāta, kuram ir serial ports. Shēmiņa sūtīs seriālos datus pa ethernet uz PC un visi būs laimīgi. Savulaik skatījos uz Lantronix XPort. http://www.lantronix.com/device-netw...ers/xport.html. Tikai neesmu dzīvē izmēģinājis.

5. Daži te prasīja kaut ko par kompilatoriem (iespējams offtopic). Man iepatikās GCBASIC http://gcbasic.sourceforge.net/. Protams tam kompilatoram ir pietiekoši daudz kļūdu, bet ja vajag ātri uzrakstīt kodu, tad ar šo var uzģenerēt koncepciju un pārvērs asm kodā. Rezultātā pietiks ātri pārbaidīt uz simulatora (vai tml) asm kodu, ja vajag pielabojam kļūdiņas un nedaudz optimizēt kodu. Man vajadzēja ātri uztaisīt kino skaitītāju un tur man pietika ar pliku GCBASIC. Asm kodā pat neiejaucos (neskaitot to, ka bija jāpielabo laika konstantes). Neder tiem kas necieš BASIC un tiem kas nezin asm.  :: 

Sorry par palagu. Laikam lasot EPJA palagus, zemapziņā kaut kas izmainās uz slikto pusi.

----------


## konis22

::   Paldies visiem par postiem.Bet runa iet par rs232.Ideja ir kad vienā tīklā sēž kautvai 100 pic sērijas iekārtas paralēli uz 2 vadiem.Viss notiek tā.Kad kādai no iekārtām ir kas sakāms tad tā pārliecinās vai jau kāds nesūta datus.Tass viss būtu pupu mizas.Kā arī ja es vēlos tad varu izsaukt tīklā jebkuru mcu vai tā saucamo pic iekārtu un komunicēt tieši ar viņu.Es jau uzrakstiju tādu skriptu kad varu komunicēt ar konkrēto iekārtu bet tikai tādā veidā kad man ir viens pic masters uz kuru sūta ascii simbolus un tad tas tālāk pa to pašu 2 vadu līniju jau savā protokolā komunicē ar citām iekārtām,bet atbildi jau sūta iekārtas reālā ascii simbolu veidā atpakaļ.Tas viss arī būtu pupu mizas :0 bet noslāpums jau tur kad gribētu ar pic komunicēt reāli ar konsoles palīdzību.Teiksim tā mcu 122 print satus un momentāli atnāk dati par visām komandām kas ir paredzētas konkrētajai iekārtai.Problēma ir tikai tur ka nevaru salīdzināt datus ko nosūtu uz pic ascii veidā ar kautkādu tabulu kurā ir atšifrējumi kas jādara ja piemēram uzrakstu print. Kā lai pic salīdzina visus tos datus ar kautko kamēr rakstu jo katrs burts iet reāli uzreiz un ortā galā nevaru izdomāt kālai pic saprot ka rakstu print nevis prins vai princ utt.  ::

----------


## JDat

domāju ka prasās izmanto RS-485 šņorslēgumu. kāpēc? Tāpēc ka tad katrs var PIC var visu laiku klausīties kas notiek tīklā un arī kontrolēt ko pats sūta. Ko darīt ja nu tomēr sanāk ka 2 PICi absolūti vienlaikus sāk sūtīt? ka katrs sūtītājs konstatēs problēmu? Padomā kā uzkonstruēt half duplex tīkla shēmu ar RS-232. man liekas ka lielāks čakars ne kā ja to pašu dara ar RS-485. Bez fiziskajiem savienojumiem, nāksies arī viltīgi izdomāt tīkla darbības algoritmu, lai konstatētu kolīzijas(jau pieminētā situācija ar vienlaicīgu sūtīšanu) un daudzas citas lietas. Var pamēģināt CAN bus principus lietot. Tad kad izdomāsi tīkla darbības principu lai būtu maksimāli maz negaidītu pārsteigumu, tad var ķerties klāt kodēšanai. No Fizikās tikla uzbūves lietām var noderēt šitas links: http://www.rs485.com/ Tur ir visi pričindāļi un shēmas priekš RS-485. Un vispār... nebaidies no tā biedējošā RS-485. Tas nav ne kāds jauns protokols. Tas ir veids kā savienot kontrolieru vadiņus tīklā. Iekš RS-485 tu bez jebkādām izmaiņām varēsi sūtīt savus seriālos datus. A tas SB-projects SB-Bus tev neder vismaz idejas līmenī?

Nāksies vien tev pašam pārlasīt kaudzi ar teoriju. Es negribu viso to teoriju drukāt šajā forumā. Palikšu vēl par grafomānijas fanātiķi.  ::

----------


## next

Nu labi, nevaru iestaastiit ka taa ir blenja, lai taa arii buutu.
Pirmkaart izmet f84 un njem f628 tur vismaz dzelzisks rs232 iraid.

Pirmais variants peec paartraukuma no rx kraameet visus ascii kodus buferii un sanjemot enter simbolu analizeet kas tur uzkraajies.
Otraa variantaa var taisiit "state machine" un saliidzinaat ascii virknes ar sagaidaamajiem paraugiem uzreiz peec simbolu sanjemshanas.
Taadu pieeju kaadreiz sauca par asociatiivo procesoru - principaa vareeja uztaisiit no adresu regjistra un ROM (uC jau toreiz nebija kur dabuut).

----------


## next

Koliiziju noveershana parasti notiek taa ka raidoshais verkjis klausaas kas notiek paarraides kanaalaa.
Ja konstatee paarklaashanos, partrauc raidiishanu un iztur pauzi (pauzes ilgums katram potenciaalam raidiitaajam savs).
Pirms raidiishanas uzsaakshanas paarliecinaas ka citi konkurenti klusee.

----------


## JDat

Next! Par F84 šitādam mērķim: Pilnīgi piekrītu. Te prasās pēc gruntīgāka MCU.
F84 der lai apgūtu MCU kā sugu un lai fiksi primitīvas lietas izdarītu. Varbūt primitīvas lietas var ari 628 taisīt, ja pamati apgūti.

Par to network lietu, man ir tāda sajūta, ka te prasās pēc nopietnas domāšanas un sistēmas plānošanas. No pirmās reizes var nesanākt.

Varbūt autoram ir vērts būvēt nevis 100 MCU tīklu, bet gan pakāpeniski attīstīt sistēmu.
Uztaisīt "daudzbaitu komandas" kodu.
Uztaisīt 1 MCU sarunas ar PC pa RS-485.
Tas uztaisīt ar 2 MCU un PC
tad ar 3 un testēt uz nebēdu.
Skaties ka gadiņš ir pagājis un nesteidzoties būs uzbūvēts supertīkls.

Mani ārī ļidzīgas tīklu būvēšanas nedaudz interesē, bet nu tas tā, offtopicam.

Par kolīziju novēršanu ir daudz versiju un viena ir tieši tā, ko next tikko aprakstīja.
Ja autors nedaudz saprot RS-485 būtību, tad uzreiz kļūs skaidrs, par ko next runā. Kāpēc vajag tā un ne citādi.

----------


## konis22

Var arī izmantot 628 mcu protams.Bet viss slēpjas tajā ka man ir tikai 2 vadi gnd un datu liinija taakaa seriaali visam jaanotiek taa vai taa.  ::  Labi palobīšu ko jūs man te sasviedāt iespējams ka sanāks kas prātīgs.Par kolīzijām nav ko uztraukties jo dati ies reti no atsevišķām iekārtām un lielākoties tiks komunicēts pāc pieprasijuma ar kādu no dzelzi.Nutāda doma. Starpcitu vai kāds no jums kas progu mcu nedzīvo valmierā????  ::

----------


## sharps

> Un kā tu risināji problēmu, kad vairāki kontrolieri sāk runāt vienlaicīgi? 
> Beefs


 Pavisam vienkaarshi. Pilniigi vienlaikus neviens runaat nevar. Tikko viens saak runaat, taa paareejie visi klausaas kursh tad buus iistais ar kuru runaa. To realizee ar paartraukumiem. Kad runaataajs ir pateicis savu sakaamo, tad tiek izsuutiita specifiska komanda ASCII veidaa tiiklaa, ka luuk es visu pateicu. Sheit arii klausiitaaji iziet no paartraukuma.

Jaa un veel viena nianse par to ST485 chipu. Ar vinja paliidziibu (iestatot 1 vai 0 uz atbilstoshajaa kaajaam) ir iespeejams panaakt ka runaat un klausiities vienlaikus nav iespeejams. Saakumaa ir jaapadod 1 vai 0 uz chipu un tikai tad var veikt attieciigas darbiibas. Protams kljuudas iespeejamiiba vienmeer pastaav.

Var rikoties gluzhi preteeji. Tikai galvenais kontrolieris uzdod jautaajumu un adresaats atbild. Sheit kljuudas iespeeja ir mazaaka.

----------


## JDat

Tik un tā ko darīsi ja tomēr 2 nejauši rāidīs vienlaikus? Nex aprakstītais mehānisms saicās Collosion detection (CD) Vēl ir variants kad mākslīgi algoritma līmenī mēģina izvairīties no tādas situācijas. Tas saucās Collosion Avoidance (CA). Tas arī ir tevis pieminētais "noprašņāšanas" algoritms. MCu uz savu galvu ne ko nedrīkst sūtīt. Drīkst sūtīt tikai PC. PC regulāri noprašņā visus MCU pēc kārtas: vai kāds negrib kaut ko sūtīt uz datoru. PC sūta paketi pirmajam kontrolierim, ja kontrolieris atbild: man viss OK, tad PC prasa otrajam MCU. Ja kontrolierim ir ko teikt, tad kontrolieris attiecīgi pasaka tikai pēc tam, kad PC ir prasījis (devis tiesības runāt). Apmēram tāda ideja. Protams, ja iedziļinās tad tur ir vēl daudz nianses, kuras es neesmu aprakstījis. Šo informāciju teorētiskos nolūkos var vikipēdijā palasīt. 

CAN bus diezgan amizantā veidā tiek galā ar kolīzijām, līdz ar to ir vērts izskatīt šo variantu kā vienu no tīkla uzbūves veidiem. Pirmkārt tā pati vikipēdija var pastāstīt. Pa cik interesējos par kosmosa kuģu elektroniku, atradu interesantu rakstu par CAN lietošanu kosmosa kuģos. Dažas idejas var noderēt arī uz zemes. http://esamultimedia.esa.int/docs/gs...p_a_99_A93.pdf

----------


## JDat

Sharp! Enīvei! No sākuma jāzdomā visi principi un tīkla darbības aloritmi, tikai pēc tam vari domāt vai realizēsi ar interrupt vai kaut kā savādāk. Kā jau teicu, sāc palāpeniski:
Uztaisīt "daudzbaitu komandas" kodu vienam MCU. Un tā lai ne kas negļukotu.
Tāla uztaisīt sitēmu, kur viens MCU sarunas ar PC pa RS-485 (vai pa CAN, ka varēsi).
Tas uztaisīt ar 2 MCU un PC
tad ar 3 un testēt uz nebēdu.

Uz katru nākošo soli pārej tikai tad, ja iepriekšējais strādā stabili. Savādāk toč ne kas nesanāks un paliks EPJA CNC virpas līmenī.
Te tiešām prasās pēc disciplināras un pārdomātas būvēšanas.

----------


## sharps

> Sharp! Enīvei! No sākuma jāzdomā visi principi un tīkla darbības aloritmi, tikai pēc tam vari domāt vai realizēsi ar interrupt vai kaut kā savādāk. Kā jau teicu, sāc palāpeniski:
> Uztaisīt "daudzbaitu komandas" kodu vienam MCU. Un tā lai ne kas negļukotu.
> Tāla uztaisīt sitēmu, kur viens MCU sarunas ar PC pa RS-485 (vai pa CAN, ka varēsi).
> Tas uztaisīt ar 2 MCU un PC
> tad ar 3 un testēt uz nebēdu.
> 
> Uz katru nākošo soli pārej tikai tad, ja iepriekšējais strādā stabili. Savādāk toč ne kas nesanāks un paliks EPJA CNC virpas līmenī.
> Te tiešām prasās pēc disciplināras un pārdomātas būvēšanas.


 
Tur es tev pilniigi piekriitu. Uz papiira jaaizliek pamatideja, kuru pamazaam arii realizee. Jaasaak ar elektriskaas sheeminjas uzziimeeshanu un salodeeshanu, ko rekomendee attieciigo chipu razhotaaji. Sheemai jau pashos pamatos ir jaabuut stabilai bez gljukiem. Peec tam tik kjeros klaat pamatsoftinju rakstiishanai un testeeshanai uz shiis sheeminjas.
Tas man arii tika dariits. Daru jau to gadus divus un veel joprojaam to uzlaboju, gan softu gan hardwari.

Runaajot par MCU, tad ieteiktu autoram tieshaam njemt PIC16F628A. Ar iebuuveeto USART buus mazaak probleemas nekaa uz PORTiem rakstiitam seriaalim.

----------


## konis22

Jā idejas ir labas jums.Pārlasu unmēģinu ko izlobīt.Par konkrētu aptaujāsanu biju iedomājies.Reāli bija tā jau uztaisīts ka neviens tīklā nerunā kamēr viņu konkrēti neaptaujā.Visas komandas pārējās ir vienādas čipā tikai atšķirās izsaucamā adrese un identifikācija ko sūta uz pc.Teiksim cips133 konstatējis to un to tad pēc uzaicinājuma ieiet menu un var ar vienādām komandām kas parasti sastāv no cipariem pajautāt kautko ko vēlas.Piemēram 1 tad enter iegūst datus par 1 porta stāvokli vai vienalga ko pats ir izvēlējies.Tad 2 enter iegūst citus datus.Tad piemēram sūta 0 enter un pic atsūta cips 133 exit tad tīkls brīvs un strādāt var ar citu čipu.Tas viss bija ok bet variants tāds ka jāizmanto 1 masters kas saprot uart un tad attieciigi izmanto savu protokolu ar tīkla iekārtām.
Palasot šos postus reizēm tāda sajūta ka būtu interesanti visiem satusēt kur reāli.Domāju būtu interesanti.  ::

----------


## JDat

Mēs visi esam traki, reizēm stipri aizņemti un, protams, dažiem patiktu paļarkstēt klātienē.

Par adresēm. Man tā bija problēma, jo projekts bija specifisks. Tavā gadījumā pilnīgi pietiktu uzlikt DIP slēdžus un katram MCU ar slēdžu palīdzību uzstādīt unikālu adresi. Daudz sarežģītāk ir, ja nelieto DIP slēdžus. Tad gan sāk vilkt pēc hi-tech lietām un risinājumiem. Vēl ir variants nošipikot ideju no DS18b20 termodevēja protokola. http://datasheets.maxim-ic.com/en/ds/DS18B20.pdf Varbūt ka to ideju un algoritmu var pielietot saviem mērķiem. Var arī dinamsiksi pieš'hirt adreses. Teiksim nospiec pogu uz MCU un tas ieiet adreses uztveršanas rezīmā, tad PC viņam iedod adresi. MCU adresi saglabā un lieto, kamēr nesaņem citu no PC. Kaut kā tā. Tiešam daudz variantu un risinājumu.

Vispār vajadzētu sākt ar kopējās koncepcijas uzmešanu un izplānot globāli. Pēc tam tikai pāriet nianšu līmenī.

----------


## konis22

Es biju iedomājies tādu sistēmu.Reāli jau darbojās vismaz simulatorā.Kad piemēram rakstu ascii cips133 tad visu laiku tiek filtrēti tie dati kas iet pa datu kopni un visas iekārtas seko līdzi.Piemēram cips visiem būs vienāds a tad kad būs cipari teiksim tie 133 tad 132 jau vairs nederās tāpat kā 134 a 133 vienīgais izpildīsies līdz apstiprinājumam.kas spiedīs enter tad tas čips uzreiz izpilda pārējās darbības kas programma tiek prasītas.Reāli filtrēt pa burtiem ir štrunts 1 līmenī teiksim ja inicializācija ir izieta tad proga iet uz 2 līmeni kur jau nav tāda koda kas atļau būtu vienāds ar chips133 tur jau citas komandas'.Reāli ir tā kad filtrē 9 bitus tad apstājas gaida nākamos 9 bitus un tā kamēr iziet visi 7 simboli.Varbūt pārāk pliekani uzrakstiju bet pagaidām man tā viss sanāk.Runājot par skicēm un shēmām kautkādā mirklī iesviedīšu savu vienkāršo shēmu no proteusa. :: 
Ja izmanto master mcu tad aptuveni 2 rindās var uzlikt 100 komandas kas katra atšķiras.vismaz manā gadījumā pāru pārēm.

----------


## sharps

ieteiktu veel vienu lietu par koamandaam. iesaku taas izveeleeties peec iespeejas vinkaarshaakas. piemeeram exit var panjemt kaa vienu komandu no ASCII bukjetes. tad tev nebuutu jaasuuta teksts exit.

----------


## JDat

Man sāk rasties sajūta, ka konis22 kaut ko nav sapratis no citu ieteikumiem.

----------


## jeecha

Kaadeelj izmisiigi jaacenshaas izgudrot velosipeeds, pietam ar kantainiem ritenjiem un bez seedeklja.

Komandu "parseeshanai" jau sen eksistee vispaarpienjemti algoritmi. Njemam googlee mekleejam un izveelamies adekvaatu konkreetajam uzdevumam un kontroliera resursiem.
Tas pats ar datu nosuutiishanu starp kontrolieriem - lasam kas ir RS-485, CAN, LIN, I2C, SMBus un atkal izveelamies adekvaatu konkreetajam uzdevumam.

----------


## JDat

> Kaadeelj izmisiigi jaacenshaas izgudrot velosipeeds, pietam ar kantainiem ritenjiem un bez seedeklja.
> 
> Komandu "parseeshanai" jau sen eksistee vispaarpienjemti algoritmi. Njemam googlee mekleejam un izveelamies adekvaatu konkreetajam uzdevumam un kontroliera resursiem.
> Tas pats ar datu nosuutiishanu starp kontrolieriem - lasam kas ir RS-485, CAN, LIN, I2C, SMBus un atkal izveelamies adekvaatu konkreetajam uzdevumam.


 Beidzot atradās kāds, kas pateica kaut ko tiešām sakarīgu. Pārējie, pirmkārt jau es   ::  , bārstījās ar savām zināšanām par tīklu niansēm. Protams, ka to visu var atrast iekš google un sagremot pats. Bet nu, nav labuma bez ļaunuma. Varbūt kāds kaut ko jaunu uzzinās vai atcerēsies labu lietu, kas jau sen ir izgudrota...

----------


## java

> gcc


 A tu pats buildoji gcc pic kompilatoru? Padalies.

----------


## M_J

Bet kāpēc gan neizgudrot savu velosipēdu? Lielie "brendi" to tik vien dara. Tai CAN maģistrālei, kas ir uz Mercedes ar to CAN maģistrāli, kas ir Audi kopīgi ir tikai fiziskie sprieguma līmeņi. Datu apmaiņas protokols katram savs. Vēl trakāk - mersim nodeg BOSCH ģenerators, vietā uzliekam identisku Hellas ražojumu, kas saņemts caur dīleri un paredzēts konkrētajam auto, visus šasijas nummurus ieskaitot, bet visas auto sistēmas jūk prātā, jo izrādās Hellas ģeneratoram datu apmaiņas starp ģeneratoru un motora vadību caur LIN līniju notiek savādāk kā BOSCH ģeneratoram. Dīlera diagnostikas aparatūra neparedz tādu opciju, kā iespēju izvēlēties to vai citu datu apmaiņas protokolu. Stulbākais, ka šie datu apmaiņas protokoli nekur nav jēdzīgi dokumentēti, baigais kara noslēpums! Protams ir veči kas ir izstrādājuši "praktikuma darbus" un šos datu apmaiņas protokolus vairāk vai mazāk atkoduši, kaut ko var atkost pats. Bet vai ir jēga? Vismaz auto jomā kaut kādi vienoti standarti un protokoli ir murgi un māns.

----------


## next

Veel 5kapeiku iemetiishu.
Nevajag domaat ka vietaas kur taads komandrindas interfeiss lietojas viss taa godiigi tiek uztverts un atshifreets.
Uztveereejs atshifree mesidzhu tiktaal cik tas nepiecieshaams ambivalences noveershanai.
Paareejie burti vairaak logfailam domaati.

----------


## marizo

RS 232 signālu galus jau nevar tā vienkārši visus kopā savienot.
RS485 ir traucējumnoturīgāks, var taisīt garāku datu līniju un, atkarībā no izmantotajām interfeisa/draivera/bufera mikroshēmām, slēgt pie līnijas 32 un vairāk raiduztvērējus.
Izmet 84, tas noderēs citur, ņem 628(A)!
Ja gribi vienkārši:
uztver asci, salidzina ar to, kas apzimē datu pārraides sākumu. Ja sakrīt- uztveram nākamo un salīdzinam, tā līdz enter.Kā pa trepīti kāpjam, un nokrītam, ja saņemam kaut ko nepareizu.

----------


## konis22

Jā ar vienu simbolu man šobrīd viss jau strādā.Labums tāds ka nevar iegūt neko no pic kamēr nav ierkstīta parole.Strādā skaisti.Katra uzrakstītā simbola vietā parādās * un ja nepareiz tad wrong password a ja pareiz tad system redy. Pie izejas vienkārši ir jānospiez q un enters tad iziet no sistēmas un neko nevar izdarīt.Prasa arkal paroli.  ::   Prieks ka kautkas sanāk.Lasot jūsu postus atkal ko jaunu būšu iemācijies.Paldies

----------


## JDat

Ko lai saka. Iemācies programmēt.   ::

----------


## JDat

Pēc būtības programmēšana ir māksla domāt nevis konkrētas programmēšanas valodas zināšanas. Programmēšanas valoda, tas ir tikai instruments. Ja tu māki lietot instrumentu, tas vēl nenozīmē ka tu māki strādāt. Ko es gribēju pateikt. Tev ir jāizdomā sistēma, ka kontrolieris var saņemt vairākus baitus, saglabāt atmiņā un apstrādāt tos. Tad kad izdomāsi kā to izdarīt teorijā, tad varēsi arī uzrakstīt programmu, kas to izdara uz kontroliera. Kā jau Jeecha teica: Vai nu raksti pats bufera un parsēšanas kodu vai paņem gatavu.

----------


## konis22

Tur jau tā problēma kad nav neviena ar kuru normāli parunāt par šīm te tēmām aci pret aci.Tad būtu lielāka skaidrība un arī lielākas iespējas ko izdarīt.Tapēc jautāju vai kāds nav no valmieras puses. ::

----------


## JDat

ko tad tu gribi runāt? paprasīji, dabūji atbildi. paprasīji vēlreiz to pašu, dabūji pārmetumus. tāda dzīve.   ::

----------


## konis22

Nejau par šito tieši bet gan par vēl visko citu kas saistīts ar programmēšanu.

----------


## JDat

> Nejau par šito tieši bet gan par vēl visko citu kas saistīts ar programmēšanu.


 Ja programmēšana uz PC, tad laikam boot.lv vai tml. Par kontrolieriem laikam ka šis ir vienīgais forums.

----------

