# CNC vadība / mehānika >  DIY fpga motoru kontrolieris

## Epis

darbības princips būs apmēram tāds kad kompis nosūtīs fpga mikrenei komandas (komandu apraksts būs vēlāk) un tad fpga izpildīs tās komandas un ģenerēs motoru Step/dir signālus priekš tik motoriem cik vaidzēs un tik lielā ātrumā cik būs vajadzīgs kautvai 10 Mhz step signālu  :: . 
par signāliem un visu processu tad ideju, iedvesmu tam kā tas apmērām varētu izskatītes es ņemu no  http://www.fpga4fun.com/CNC.html
Vienīgi tajā fpga4fun tas CNC projekts nav pabeigts tur ir ielikts tikai apraksts bet nekādu kodu vēl tādēļ izdomāju sākt pats to progu veidot, jo cik tad ilgi gaidīt var! + nav zināms vai tos kodus tā vienkārši varēs novilkt jo man ir aizdomas kad tie būs piejami ja tiks pirkta tā fpga plete a tās plates es pirkt netaisos, man ir pašam savas. 
+ tajā projektā nav nekas teikts par to kodu veidošanas programmu, jeb komandu veidošanu, vai G-koda konvertāciju sūtāmajās komandās. 
Tagat par pašām komandām: 
sūtītas tiks 3 tipa infromācijas pakas: 
1 paka būs kādi 8biti kurā būs informācija par to kuram motoram tā paka ir domāta un vēlāk šeit var ielikt arī cita tipa informāciju jo brīvās vietas paliks daudz.
2 paka sastāvēs no 16bitiem kurā būs motora paātrinājuma vērtība.
3. pakā būs noejamo soļu skaits, bitu garumu vēl nezinu jo tajā fpga4fun par tās lielumu nekas netika minēts, varētu būt kādi 32biti.

Pēc šitās informācijas fpga kontrollieris arī ģenerēs Step signālus un šeit kā tiks apreiķināta pozīcija un griešanās ātrums.
šeit piemērs no attiecīgā linka kā tiks ģenerēti singāli lai sasniegtu attiecīgo pozīciju.

After 15 clock cycles, our integrator has reached the position +50.
Cycle	Acceleration	Speed	Position
0	0	0	0
1	+1	+1	+1
2	+1	+2	+3
3	+1	+3	+6
4	+1	+4	+10
5	+1	+5	+15
6	0	+5	+20
7	0	+5	+25
8	0	+5	+30
9	0	+5	+35
10	0	+5	+40
11	-1	+4	+44
12	-1	+3	+47
13	-1	+2	+49
14	-1	+1	+50
15	-1	0	+50

Pate loģikas daļa nebūs nekāda sarežģitā jo matemātiskās operācijas kas šeit ir jāizpilda ir ļoti vienkāršan un viņu ir maz šeit pieminētās 2 darbības: 

Âtrums <= Âtrums + Paâtrinâjums ;
Pozîcija <= Pozîcija + Âtrums;

un paātrinājuma vērtība tiks nomainīta kad būs izpildīti visi noietie soļi soļu komandā 

if soļi ="00000000000000000000000000000000" then 
	soļi <= Jaunaie_soļi;              -- ielâdç no FIFO jaunu laika vērtîbu;
	Paatrinajums<=Jaunais_Paatrinajums;   --- ielâdç no FIFO jaunu  paâtrinâjuma vērtîbu!.
else soļi<=soļi-1; 

kā redzams tad šito uzkodēt nebūs īpaši grūti un kad tiks apreiķināts ātrums un nepieciešamā pizīcija un virziens tad varēs ģenerēt Step/dir signālus + salīdzināt viņus ar enkodera datiem priekš PID.

Sarežģitākā daļa šajā visā ir šito komandu Ģenerēšana un lai nebūtu manuāli jāraksta tie cipari šādā komandu formātā kādā no RS232 termināļa programmām tad es tagat domāju uztaisīt G-coda konvertieri, kas no parastā G-koda uztaisīs šitāda tipa kodu failu kur pēc tam varēs sūtīt uz plates. 
No sākuma būs iespējams pārveidot tos G kodus kur kustības virzieni ir taisni (bez apļiem un citiem brīnumiem), un moš vēlāk varētu ari paļa formulu iemest, bet par to varētu domāt tad kad šitas pirmais G-code dekoderis būs gatavs. 

Man tagat ir jau gatavs COM porta sūtīšanas kods kurš sūta informāciju kas ir bitu laukā(array) ielikta, un tik pat labi varētu tas būt jebkāds cits datu tips, int,long utt.. un galvenais kas jāuztaisa ir tas Gkoda konvertieris ko arī mēģināšu uzcept  ::  
domāju pāris nedēļas aizies kamēr to uzcepšu jo visu vasaru neko nopietnu uz visual C#2005 nēsu kodējis tākā paies laiks kamēr atkal iebrakšu, un būs jāpēta teksta filtrēšanas, apstrādes metodes lai to G-kodu nolasītu.

ja ir kādi ieteikumi, komenti, jautājumi tad rakstat   ::

----------


## Epis

šodien uzcepu pamat kodu tam G-coda konvertierim uz instrukcijām un pagaidām ir tikai viena instrukcija G1 lineārā interpolācija un arī F (feedrate)  + 3 asis x,y,z. 
pagaidām vēl programma neģenerē HEX failu ko sūtīt fpga bet ir kods kurš ģenerē tās soļa un paātrinājuma vērtības tikai nēsu vēl to kodu kārtīgi iztestējis un pirmajos testos jau ir bišķi kļūdas bet nevis apreiķinos bet pašā programmas plūsmā, jo pārāk ātri izleca no galvenā cikla + neizslēdzu iespēju kad varētu būt problēmas ar cipariem (ar 0 vērtībām). 

pirmo dienas pusi nočakarējos ar to Gkoda komandu teksta sadalīšanu gabalos un komandas noteikšanu + x,y,z,F vērtību iegūšanu, un otru dienu pusi ņemos ar to vērtību reiķināšanu izrādās kad tās formulas nemaz nav tik vienkāršas, un tas apreiķins ir samērā garš. 
lielākais čakars ir ar tiem ātrumiem piemēram komandai G01 X5 Y10 tad sanāk kad instruments iet slīpi un katrai asij sava ātrums ar to apreiķināšanu ātri tiku galā bet kad atcerējos par paātrinājuma reiķināšanu tad sākās tās paātrinājuma formulas, piemēram 
cik tālu ass aizslīdēs 5 sekundēs, ja tās sākotnējais ātrums 0mm/s ar paātrinājumu 20mm/s ??    ::  
kāds zin atbildi ?

----------


## karloslv

Opā, vidusskolas matemātika būs jāatkārto.

----------


## Epis

sodien atradu formulu pēc kuras reiķina paātrinājuma laiku (zīmējumā otrā formula) izejot no noietā ceļa lieluma un izrādās kad šitā piemērā no fpga4fun soļu ātruma apreiķins kas tālāk ir minēts ir nepilnīgs un tāds stipri novienkāršots. īstanībā jau jāreiķina ātrums katram motora solim attiecīgi pēc tā cik lielu attālums tiek veikts tajā solī nu piemēram 0,005mm vai kāda cita vērtība un tad sanāk kad tā soļa ātrums, nav tāds aritmētiski progressīvs kā minēts apakšējā piemērā (šī progresīja tur sanāk jo Pozīcija netiek palielināta par 1 vienību bet uzreiz tiek palielināta par ātruma vienību, bet tehniski tas nekam neder jo  lai sasniegtu nākošo pozīciju sanāk kad iekārta ies ar konstantu ātrumu starp pozīciju kordinātēm nevis ar nepārtrauktu paātrinājumu katrā pozīcijas vienībā un tas vairs nekam neder jo tad tajā vietā lai izfrēzētu slīpu līniju sanāks nevis taisna līnija, bet gan raustīta ! apstījos tajā linkā tad tur viņi to cnc controller lapu pabeidza bet koda nekāda nav  ::  un arī paši beigaš pierakstīja to kad ir arī jāreiķina tas ātrums katram solim.

un šitās katra soļa ātruma vērtības sanāk kad ir jāreiķina atsevišķi un ja piemēram ātrums kādam mikrosoļu draiverim ir kautvai 100Khz tas ir 100K instrkcijas un ja katra instrukcija ir 8+16+32=56biti sanāk kad nosūtāmais datu apjoms ir 5,6Mb (vienai asij) ja ir 3 tad 16,8Mb un tas tikai priekš 1 sekundes !! līdz ar to šitas variants tos matemātiskos apreiķinus veikt uz kompja vienkārši atkrīt, būs tas viss jādara uz plates un tad sanāk kad fpga platei vaidzēs sūtī pašu G-Kodu kas izmēra ziņā būs ļoti mazs piemēram 1 instrukcijai vaidzētu apmēram 64 datu bitus, kur pirmie 16biti būtu instrukcijas nosaukums un pērējie asu kordinātes  ::  un tad 16 instrukcijas aizņemtu tikai 1Kbitu un ar pāris Mb flash atmiņas pietktu reāli lieai programmai.
beigās iznāk kad man ir uz kompja jāuztaisa tikai Gkoda uz sūtāmo kodu pārveidošanas programma, un tākā Gkoda nolasīšanas kods man jau ir tad atliek tās vērtības sapakot un uztaisīt nosūtāmo failu!  :: 




> Cycle Acceleration Speed Position
> 0 0 0 0
> 1 +1 +1 +1
> 2 +1 +2 +3
> 3 +1 +3 +6
> 4 +1 +4 +10
> 5 +1 +5 +15

----------


## Vikings

Man liekas, ka tu šauj galīgi greizi.
Uztaisi Excelī grafiku  ātrums/laiks un saliec iekšā vērtības, kuras rēķinātas pēc paātrunājuma formulas, man kaut kā liekas, ka līnija ies slīpi uz augšu.
Kā kustinot divas asis līnija var sanākt raustīta?
Manuprāt, apakšā tevis paša minētais piemērs ir ļoti labs uzskates materiāls paātrinājuma algoritma demonstrēšanai.

----------


## Epis

piemēram: 
ja mašina kustās ar paātrinājumu 5m/s un braukšanas ilgums ir 5 sekundes tad 
cik daudz viņa nobrauks pēc 1,2,3,4,5 sekundēm ? 
šeit ir tabula: 
Laiks; Ātrums; nobrauktais ceļa gabals  kopā nobrauktais ceļš
1     5m/s     5m       5m
2    10m/s     10m      15m
3    15m/s     15m     30m
4    20m/s      20m     50m
5    25m/s    25m     75m

Viss itkā ir ļoti vienkārši bet tagat apskaties uz tabulas kuru es ekselī apreiķinā ar tiem pašiem 5m/s bet šoreiz tie būs 5m/s^2 paātrinājums + pa soļiem 5m (ja iedomājamies kad iekārta iet ar 5m soli) tad tās vērtības ir pavisam citas ieskaitot nobraukto ceļu ! jo izrādās kad tas apreiķins pirms tam (vienkāršais) reiķina tikai konkrētu ātrumu ņemot kad katrā sekundē ātrums ar ko mašina brauks būs konstants nevis ar nepārtraukut paātrinājumu un tabulā var redzēt kādi izskatās istie cipari un tie nav ar nekādām aritmētiskām, ģeometriskām progresījām aprakstāmi un nekādas regularitātes tur bez tām 2 formulām iztikt nevar ! 



```
A paātrināj.;	X0sāk. Att m;	X beigu att.m;	V0 Ātrums;	Kopējais laiks;	T laiks
5	   0	   5	    0	            0	          0
5	   5	   10	   7.07	   1.41	     1.41
5	   10	   15	   10	      2	      0 .59
5	   15	   20	   12.25	   2.45	   0.45
5	   20	   25	   14.14	   2.83	   0.38
5	   25	   30	   15.81	   3.16	   0.33
5	   30	   35	   17.32	   3.46	   0.3
```

 Es tagat domāju par tām mērvienībām jo mazākais iespējamais laika intervāls par kādu varētu regulēt visus ātrumus varētu būt  1us un tad ja pārveido 1m/s^2 uz m/us^2 dabūnam 1.0*10^-12 pakāpē kas nenormāli mazs cipars un 32 bitos nesalien līdz ar to jāizpēta tās apreiķinu formulas un to kādus ciparus kādā formātā jātaisa (lai varētu normāli aizsūtīt 16bitos nevis 32 vai 64.

----------


## Vikings

Tajā tabulā taču neko nevar saprat uztaisi bildi lai saprot kurš stabiņš ir kas.
Tagad padomājam loģiski.
Paātrinājums ir lielums, kas nosaka, par cik izmainīsies ātrums vienas sekundes laikā. Ātrumu pēc noteikta laika sprīža varam aprēķināt pēc: Vbeigu=V0+t*a kur V0 - sākuma ātrums, t - laiks, a - paātrinājums. No šīs formulas secinam, ka ātrums ir lineāri mainīgs lielums. Lai iegūtu attālumu, pieliekam beigās vēl vienu t, iegūstam formulu S=S0+a*t^2. Tā kā formulā ir lielums t^2 iegūstam, ka pārvietojums ir nelineāri (kvadrātiski) mainīgs lielums. Ja nemaldos, tad pirmā formula mums ir aritmētiskā, otrā - ģeometriskā progresija, ja no tā paliek labāk.
us nav 10^-12, bet gan 10^-6. Tikpat labi vari mērīt ātrumu um/us vai kaut kā tā un tas jau sanāks sakarīgs skaitlis.

Starp citu, ir iekārtas, kurās smadzene vada atsevišķu asu motoru vadības blokus pa seriālo CAN busu, bet diez vai pa to tiek sūtīts Step Dir signāls, drīzāk noejamo soļu skaits, virziens un tad visiem blokiem reizē tiek dota komanda izpildīt uzdoto.

----------


## karloslv

Ģeometriskā progresija ir tad, kad katrs nākamais skaitlis ir konstantu reižu lielāks par iepriekšējo, x(k+1) = x(k) * c

Visur augstāk jūs nez kāpēc pieņemat, ka paātrinājums ir konstants. Patiesībā tā nav un nevajag būt. Lai kaut ko pozicionētu ātri un pareizi, jālieto atgriezeniskā saite - jālasa pozīcija, jārēķina kļūda un jākoriģē vadības signāli.

----------


## Vikings

Paātrinājums par konstantu tiek pieņemts, jo motors nevar vienā mirklī sasniegt nepieciešamo apgriezienu skaitu. Ir max paātrinājums ar kādu motors var uzņemt ātrumu, tas arī tiek izmantots lai, piemēram, soļu motors neieķīlētos vai neizlaistu kādu soli.

----------


## Epis

šeit tā exel bilde: 

galvenais kur jāskatās ir T laiks kas parāda laiku kas vajadzīgs lai noietu 5m garu attālumu (vienīgi tā T laika līkne ir 1 rūtiņu pa zemu iedomājies kad viņa ir 1 rūtiņu uz augšu) 
tālāk līknē var redzēt Xo sākuma āttālums un X beigu attālums no kuriem apreiķina laiku kas vajadzīgs lai noietu tos 5m kas ir starp beigu attālumu(jeb galapunktu) un sākuma kordināti Xo līdz ar to var redzēt kad Tlaika vērtibas izmaiņās nav nekādas sakarības ne ar ģeometriskām, ne ar aritmētiskām progresījām vai regresījām tā ir jāapreiķina atsevišķi katrai kordinātei ar dotajiem ātrumiem un parametriem visu laiku. 
+ formulā ir vēl Vo Ātrums m/s kas norāda uz objekta ātrumu sākotnējā Xo kordinātē, jeb punktā un to ciparu apreiķina no kopējā laika reiz paātrinājumus.
galvenais kas šeit jāredz kad šeit nav tās aritmētiskās progresījas kas bīj piemērā pirmstam līdz ar to nav iespējams aizsūtīt gatavu paātrinājuma ciparu ko varētu skaitīt klāt motora ātrumam (aritmētiskā progresīja), un līdz ar to ir jādomā kurš veiks tos matemātiskos apreiķinus kompis vai motoru kontrollieris, un pēc maniem apreiķiniem tad ja to dara kompis tad  tehniski lai saglabātu viņa sūtītos datus uz motoru kontrolliera vaidzēs baigi lielo Flash atmiņu vairākus Gb priekš pāris minūtēm tas ir pa traku un tas variants īsti neder, tākā labākais ir to darīt iekš motoru kontrolliera kurš tad arī ģenerēs tos Step/dir signālus pēc apreiķinātajiem lielumiem




> tarp citu, ir iekārtas, kurās smadzene vada atsevišķu asu motoru vadības blokus pa seriālo CAN busu, bet diez vai pa to tiek sūtīts Step Dir signāls, drīzāk noejamo soļu skaits, virziens un tad visiem blokiem reizē tiek dota komanda izpildīt uzdoto.


 Viens no jaunākajiem un plaši izplatītiem šāda tipa motoru vadības standartiem ir tas SERCOS III  un tagat viņš iet arī par 100Mb interneta vadu un itkā tur ir arī uztaisīta loģika piemeŗs priekš Xilinx spartan II FPGA http://www.sercos.com/news/050307a.htm 
bet kur viņu dabūt novilkt un tā tālāk es nezinu un pagaidām man tas arī neintresē.

----------


## Epis

Nut ā pirmais ieskats tajā ko esu uzkodēji un kā izskatās pagaidu progas logs (var ievadīt 3 parametrus(strādā tikai 2 jo padeves ātrumam kodu, jeb G00 instrukciju nēsu ielicis un G kodu ievades logs (tur ir pāris kodu rindas testam) 


visu projektu saarhivētu laikam kad šeit ielikt nevar jo tas upload attachment īsti neiet tādēl ielikšu formas1 kodu lai to palaistu ir jāuztaisa tā forma jāiedod tem lodziņiem attiecīgie vērdi un jāieliek šitas kods Form1 koda daļā tad arī viss aizies



```
using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Text;
using System.Windows.Forms;

namespace G_code_decoder
{
    public partial class Form1 : Form
    {
        public Form1()
        {
            InitializeComponent();
        }
        int L = 0;
        string GkodaTeksts = " ";
        string Test = " ";
        double speed = 0;
        double XkordV, YkordV, ZkordV = 0;
        double Xspeed,Yspeed,Zspeed = 0;   // ātruma reģistri Vecie
       

        private void DecodeTEXT_Click(object sender, EventArgs e)
        {
            //L = Gcode.TextLength;
            L = Gcode.Lines.Length;

            //  string[] RinduTeksts = new string[5]; // līdz 5 kodu rindām
            //   string[] Instrukcijas = new string[5]; // Līdz 5 instrukcijām 1 tekstā

            GkodaTeksts = Gcode.Text;
            char[] RinduDalitajs ={ '\n' };
            char[] SpaceDalitajs = { ' ' };
            // sadala teksta rindas atsevišķos array laokos
            string[] RinduTeksts = GkodaTeksts.Split(RinduDalitajs);
            string SūtamāInformacija = "";

            for (int i = 0; i < RinduTeksts.Length; i++)
            {
                // sadala rindu pa vārdiem katrs vārds atrodās instrukcijas array laukā 
                string[] Instrukcijas = RinduTeksts[i].Split(SpaceDalitajs);
                double speedNEW = 0;
                int Gkomanda = 0;
                double Xkord = 0;
                double Ykord = 0;
                double Zkord = 0;
                // sāk filtrēt katru rindas vārdu ko tas nozīmē un kādus apreiķinus jāveic!!
                for (int ii = 0; ii < Instrukcijas.Length; ii++)
                {
                    string dataString = Instrukcijas[ii];
                    char[] Gopkods = dataString.ToCharArray(); // pirmā koda daļa no kuras vaig paņemt tikai 1 burtu
                    char[] CiparsCH = dataString.ToCharArray(1, dataString.Length - 1);
                    string Cipars = "";

                    for (int iii = 0; iii < CiparsCH.Length; iii++)
                    {
                        Cipars += CiparsCH[iii].ToString();
                    }
                    switch (Gopkods[0])  // skatamies kāda instrukcija būs dekodējot pirmo BURTU!.
                    {
                        case 'F': speedNEW = int.Parse(Cipars);
                            break;
                        case 'G': Gkomanda = int.Parse(Cipars);
                            break;
                        case 'X': Xkord = double.Parse(Cipars);
                            break;
                        case 'Y': Ykord = double.Parse(Cipars);
                            break;
                        case 'z': Zkord = double.Parse(Cipars);
                            break;
                        //   for ( int i=1; i< Gopkods.Length; i++)
                        default: MessageBox.Show("kods beidzies");
                            break;
                    }
                }
                double speedDiference = 0;
                double Xpos, Ypos, Zpos = 0;
                double XspeedNEW, YspeedNEW, ZspeedNEW = 0;
                // ātruma starpības reģistri starp veco un jauno ātrumu katrai asij
                double XspeedDiference, YspeedDiference, ZspeedDiference = 0;
                double XaccelerationTime, YaccelerationTime, ZaccelerationTime = 0;
                double Xacceleration, Yacceleration, Zacceleration = 0;
                bool Xslovest, Yslovest, Zslovest = false;
                double Xtime, Ytime, Ztime = 0;
                double Xtime2, Ytime2, Ztime2 = 0; // laiks kad uzrāviens ir 0
                double Xpos1, Ypos1, Zpos1 = 0; //paātrinājumā noietais soļu skaits!
                double Xpos2, Ypos2, Zpos2 = 0; // atlikušais soļu skaits = Xpos-Xpos1;
                double TopAcelerationTime = 0;
                int CPI = int.Parse(apgriezieniUzMM.Text);
                double accelerationTime = 0; // ātruma laiks kas būs vajadzīgs lai sasniegtu ieprogrammēto ātrumu

                // sākam reiķināt motora signāla ātruma vaidzīgos parametrus!
                if (Gkomanda == 1)  //lineārais variants
                {
                    speedDiference = speedNEW - speed; // šito vispār nevajag!
                    // nosaka jaunās koordinātes pa kurām būs jākustās katrai asīj, bet tās ir jau int32 formā
                    Xpos = (Xkord - XkordV) * CPI;
                    Ypos = (Ykord - YkordV) * CPI;
                    Zpos = (Zkord - ZkordV) * CPI;
                    accelerationTime = speedDiference / double.Parse(acceleration.Text); //šito arī itkā nevaig!
                    double kordSumm = Xpos + Ypos + Zpos;
                    // izreiķina ar kādu ārumu ies katra ass.
                    XspeedNEW = (Xpos / kordSumm) * speedNEW;
                    YspeedNEW = (Ypos / kordSumm) * speedNEW;
                    ZspeedNEW = (Zpos / kordSumm) * speedNEW;
                    // izreiķina kāda ātruma (mm/s) starpība ir starp veco un jauno (pa cik jāpaātrina vai jāpiebremzē!)
                    XspeedDiference = XspeedNEW - Xspeed;
                    YspeedDiference = YspeedNEW - Yspeed;
                    ZspeedDiference = ZspeedNEW - Zspeed;
                    // izreiķina paātrinājuma laiku, kas vaidzīgs lai motori paātrināots līdz vajdzīgam lielumam!
                    XaccelerationTime = XspeedDiference / double.Parse(acceleration.Text);
                    YaccelerationTime = YspeedDiference / double.Parse(acceleration.Text);
                    ZaccelerationTime = ZspeedDiference / double.Parse(acceleration.Text);
                    // nosaka kurai asij ir viss garākais uzrāviena laiks
                    if (XaccelerationTime > YaccelerationTime) // ja X lielāks par Y
                    {
                        if (XaccelerationTime > ZaccelerationTime) // ja X lielāks par Z
                        {
                            TopAcelerationTime = XaccelerationTime; Xslovest = true; Yslovest = false; Zslovest = false; goto Turpinam;//break; 
                        }
                        else TopAcelerationTime = ZaccelerationTime; Xslovest = false; Yslovest = false; Zslovest = true; goto Turpinam;
                    }
                    else if (YaccelerationTime > ZaccelerationTime)
                    { TopAcelerationTime = YaccelerationTime; Xslovest = false; Yslovest = true; Zslovest = false; goto Turpinam; }
                    else TopAcelerationTime = ZaccelerationTime; Xslovest = false; Yslovest = false; Zslovest = true; goto Turpinam;

                Turpinam:
                    // apreiķinam galīgo ass paātrinājuma laiku!
                    if (Xslovest == false)
                    {
                        // apreiķina jauno uzrāviena vērtību
                        Xacceleration = double.Parse(acceleration.Text) / (TopAcelerationTime / XaccelerationTime);
                        Xtime = XaccelerationTime / Xacceleration; // Apreiķina uzrāviena laiku jeb cik soļus motoram jāiet uzrāviena režīmā!
                        goto YslovestCycle;
                    }
                    else Xacceleration = double.Parse(acceleration.Text); Xtime = XaccelerationTime / Xacceleration;
                YslovestCycle:
                    if (Yslovest == false)
                    {
                        Yacceleration = double.Parse(acceleration.Text) / (TopAcelerationTime / YaccelerationTime);
                        Ytime = YaccelerationTime / Yacceleration;
                        goto ZslovestCycle;
                    }
                    else Yacceleration = double.Parse(acceleration.Text); Ytime = YaccelerationTime / Yacceleration;
                ZslovestCycle:
                    if (Zslovest == false)
                    {
                        Zacceleration = double.Parse(acceleration.Text) / (TopAcelerationTime / ZaccelerationTime);
                        Ztime = ZaccelerationTime / Zacceleration;
                        goto NextFormula;
                    }
                    else Zacceleration = double.Parse(acceleration.Text); Ztime = ZaccelerationTime / Zacceleration;
                NextFormula:
                    // Paātrinājuma distances apreiķinu formula X = Xo + Vo*t+1/2*at^2

                    // X = distance          = 
                    //Xo=Sakotnējā distance   = XkordV
                    //Vo =Sakotnējais ātrums = Xspeed
                    //t = laiks = Time
                    //a = Paātrinājums  = acceleration

                    Xpos1 = XkordV + Xspeed * Xtime + 0.5 * Xacceleration * Xtime * Xtime;
                    Ypos1 = YkordV + Yspeed * Ytime + 0.5 * Yacceleration * Ytime * Ytime;
                    Zpos1 = ZkordV + Zspeed * Ztime + 0.5 * Zacceleration * Ztime * Ztime;
                    Xpos2 = Xpos - Xpos1;
                    Ypos2 = Ypos - Ypos1;
                    Zpos2 = Zpos - Zpos1;
//Reģistru vērtību atjaunināšana (update) 
                    XkordV = Xkord; YkordV = Ykord; ZkordV = Zkord; // apdeitojam vecās kordinātes :)
                    speed = speedNEW;
                    Xspeed = XspeedNEW; Yspeed = YspeedNEW; Zspeed = ZspeedNEW;
// Test Teksta ar vērtībām sagatavošana 
                    SūtamāInformacija += ("acceleration X  " + Xacceleration.ToString() + "  Y  " +
                        Yacceleration.ToString() + "  Z  " + Zacceleration + "  Position  X  " + Xpos1.ToString() +
                        "  Y  " + Ypos1.ToString() + "  Z  " + Zpos1.ToString() + "  \n  Speed X  " + XspeedNEW.ToString() +
                        "  Y  " + YspeedNEW.ToString() + "  Z  " + ZspeedNEW.ToString() + "Position  X  " + Xpos2.ToString() +
                        "  Y  " + Ypos2.ToString() + "  Z  " + Zpos2.ToString()+ "\n");
                }
                //MessageBox.Show(" nolasītās kordinātes ir \n" + "Ātrums" + speedNEW.ToString() +
                //    "\n komanda" + Gkomanda.ToString() + "\n X kordināte" + Xkord.ToString() +
                //    "\n Y koordinātes" + Ykord.ToString() + "\n Z kordinātes" + Zkord.ToString());
                
            }
MessageBox.Show(SūtamāInformacija);
        }
    }
}
```

 pagaidām vēl ir jāpiestrādā bišķi pie koda jo kā redzams bildē apakšējā logā tad tur programma izmet acceleration un speed vērtības kurast ika apreiķinātas no Gkoda un pirmo rindu dekodē pareizi, bet otrajā rindā viss nezkapēc uzkarās un vērtību nav tas būs vēl jānoskaidro + vēl jāizdomā par to failu sūtīšanu un kādās mērvienībās tiks sūtīts. 

Šitajā paraugā var teikt jau esu parādījis kad es domāju sītīt uz plati nevis pliku Gkodu, bet jau bišķi apstrādātāku informāciju,kā katras ass ātrumu vai paātrinājumu un noejamā attāluma lielumu vai arī to var interpretēt kā soļu skaitu un tad pēc šitās informācijas arī motoru kontrollieris apreiķinās vērtības. 
šito variantu izdomāju tādēļ kad lai tos apreiķinus veiktu vaidzēja izmantot peldšos punktus, jo izmantojot parastos ciparus(bez komata) īsti nevarēja veikt dalīšanas operācijas un tādēl visi pareiķini iet ar peldošajiem punktiem, pagaidām nezinu vai motoru kontrollierim apreiķinus arī vaidzēs vaikt peldošajos punktos, ja vaidzēs tad būs vien jāreiķina ar peldošajiem.

----------


## Epis

Testējot un labojot kodu aizdomājos kad  ir taču arī negatīvā ass kustība un negatīvais paātrinājums jo piemēram ja ir komanda F50 G01 X10; un pēc tam seko G01 X5 tas nozīmē kad ass bīdās par 5 vienībām atpakaļ! līdz ar to sanāk kad vienas kodu rindas izpildei vaig veikt 3 apreiķinus :
1: paātrinājuma laiks līdz  ātrumam 50 
2: atlikušais laiks kas atkal vajadzīgs lai nobremzētu (būs tāds pats kā ierpiekšējais ja sākuma un beigu ātrumi būs vienādi!) 
3: laiks kurā ass brauks ar konstantu ātrumu. 

Tagat jādomā kā to visu uzkodēt un laikam būs jāmaina pilnīgi visa programmas plūsma jo nobremzēšanas laiku varēs apreiķināt tikai tad kad būs nolasīta nākošā G koda instrukcija līdz ar to viss mainīsies.

----------


## Vikings

Epi, kādēļ nenopērc TurboCNC izejas kodu pa 60$? Varētu izmantot gan darbības principus vai arī vienkārši programmu pielāgot tam, kam tev vajag a tagad sanāk nenormāls čakaris kožot cauri to, ko kāds jau atkodis un pie tam uztaisījis par atklātu. Kad parādīsies finanses es pats domāju nopirkt TurboCNC kodu lai pielāgotu to erozijas mašīnas vadībai un, piemēram, lai pieprogrammētu pa COM portu vadāmu instrumentu mainītāju...

----------


## Epis

nav jau tik viegli arī tajos gatavajos kodos atrast tos kodu gabalus kurus varētu izmanto, ja runā par cnc progām kurām ir atvērtie kodi tad labāk būtu paņemet to Linux EMC progu un apskatītes kas tur ir iekšā, man liekās kad tur varētu būt tas ko man vaig, bet es jau gandrīz esu to jauno Lineāro koda daļu uzcepis (bišķi jāpielabo jo atradu kļūdu testējos), pagaidām tā visa lieta vēl nav pārāk sarežģita, bet kad vaidzēs rinķi kodēt tad būs formulas samērā sarežģitas un tad varētu apskatītes kā EMC progā ir veikti tie apreiķini.
var teikt kad priekš lineārās interpolācijas man vaidzēja nedēļu domāju kad ja es rakātos iekš EMC kodiem tad aizietu vairāk laika jo linuxu nepārzinu.

----------


## Epis

Nupat ieliku pēdējos labojumus savā fizikas aprēķinu formulā priekš Deaceleration vērtību kalkulēšanas un jāsaka kad tās alforitms ir samērā sarežģītas nevis no tā viedokļā kad tur būtu baigās augstākās matemātikas formulas bet no otras puses kad tur ir sarežģitas skarības starp visiem tiem lielummiem un kā viņus aprēķina tādēļ nācās izveidot jaunu klasi G01instruction ar vairākām metodēm(funkcijām) kuras ir piejamas publiski (galvenajam kodam kas viņas izmanto) un daļa ir apslēptās jeb protected kas ir piejamas tikai klases iekšienē un domātas iekšējo aprēķinu veikšanai.
pagaidām debaggojot kodu ir vēl pāris problēmas ar tām vērtībām jeb cipariem kurus vaig pielabot 
šeit tagat var redzēt ko tad īsti programma ģenerēs: speed tā ir konstanta ātruma kustība kurā tiek noietscipars "position" cipars un katrai assij ir savas vērtības.
acceleration ir paātrinājuma lielums un positon norāda cik soļus tas paātrinājums ilgi ies. (tās pātrinājuma zīmes ir bišķi nepareizas (tas būs jāizlabo!)


Parakājos Linux EMC kodā un atradu galveno motion controller kodu Motion mapē  control.c  un visa fizika un kodi ir salikti Kinematics mapē un laikam galvenais un noderīgākais varētu būt tp.c (trajectory planner) kods kur itkā ir apļa un laikam lineārā interpolācija bet kods ir liels un laikam vieglāk būs uzcept apli no 0 nekā pētīt to kodu jo viņs ir C++ valodā bet es izmantoju C#  un aplis īstanībā nav nemaz tik sarežģits viss kas jādara ir jādbūn rinķa līnijas punktu kordinātes un tad starp tām jāreiķina tas ātruma vektoru virzieni un asu ātrumi, sarežģitāk būtu ja gribētu uzkodēt Spline interpolātoru tur EMC progai ir tāds cubic.c kur ir cubic spline interpolātors un kods ir šausmīgi liels tākā tas noteikti būs pēdējais ko varētu kodēt.

----------


## Andrejs

Varbūt es neko nesaprotu, bet kāpēc visa tā fignja ko raksta Epja j-kgs ir vajadzīga?  Ko autors grib panākt?
Ja grib urbt un frēzēt ar CNC, tad vajag vispirms mehanismu kas to dara un vēlams ar gatavu un strādājošu softu.  Pēc tam, ja gribās, var pilnveidot elektroniku un mehaniku, rakstīt savu softu, utt.
Būvēt  un programmēt draiverus bez reālas iekārtas un pieredzes manuprāt nav diezko gudri.
Neesmu pret jaunradi un veselīgu/neveselīgu ziņkāri, bet pat radiomīlētāja-amtiera gadijumā būtu jātiecās uz rezultātu, t.i. strādājošu iekārtu.

Andrejs

P.S.  pašbūvētu CNC taisīju pirms gadiem padsmit - rezultāts neapmierināja. Kopš tā laika lietoju gatavas iekārtas  ::

----------


## Epis

> Varbūt es neko nesaprotu, bet kāpēc visa tā fignja ko raksta Epja j-kgs ir vajadzīga?


 apskaties sākotnējo CNC topiku un izskrien viņam ātri cauri apskaties bildes idejas un tad ganjau sapratīsi priekš kam to vaig.

----------


## Epis

Laikam beidzot esu dabūjis visas vērtības un te attēlā var redzēt ko tad programma dos ārā un tagat atliek tās vērtības kas parādās logā iebāzt bitu datu laukā un aizsūtīt + pirmstam pielikt papildus informācijas paku lai otrā galā saņēmējs varētu zināt ko ar to darīt.

----------


## Vikings

Epi kādēļ visus aprēķinus veic ar pozīcijām? Varbūt vieglāk ir uzreiz pāriet uz soļiem lai atkristu visi šausmīgie skaitļi ar komatiem. Un vispār taisnai līnijai priekš kam vajag tik sarežģītus aprēķinus? Es paņemtu asi, kurai konkrētajā kustībā ir visvairāk soļi, aprēķinātu viņas ātrumu (ātrākā kā nekā) un atkarībā cik soļi šajā kustībā jāveic pārējām asīm tā ari proporcionāli pārējās kustinātu...
Aplis teorētiski nav neko sarežģīts, tikai daudz jārēķina sin/cos...

----------


## Epis

Ja pareizi sapratu jautājumu un pozīcijas nozīmi tad sanāk tā kad bez tiem uzrāvieniem bremzēšanas jau nekas nesanāk un tās vērtības gribi vai negribi ir jāizreiķina un es tad skatījos cik daudz es varu to informāciju pastrādāt un sagatavot priekš darivera uz kompja un tad vairāk par šitām vērtībām neko izkalkulēt nevar jo nākošais aprēķins ir katra soļa ātrums un tad ja būs 100Khz soļa ātrums tad vaidzēs reiķināt katram solim un tas būs jāveic 100 000 aprēķinu un jāsūta rezultāts uz plati un tādēļ es uskatu kad šitās vērtības kuras es tagat no progas dabūnu ir galējā robeža: piemēram ja sūtītu pa taisno G koda komansas (kā instrukcijas tad to varētu sapakot ļoti blīvi kādos 8baitos katrai asij 16bit cipars + pāris instrukiju baiti,
Bet tagat es sanāk sūtu daļēji apstrādātu infromāciju kur 1 instrukciju sadalu 3 instrukcijās (paātrina'jums, fiksēts ātrums,bremzēšana(vai atkal paātrinājums)) tādēļ sanāk sūtīt 3X vairāk baitu bet nākošais solis jau ir pārāk neizdevīgs tas kur vaig 1 instrukcijas  izpildei sūtī miljoniem ciparu. 

Pāris dienas atpakaļ es skatījos cnczonas forumā vai kāds ir mēģinājis tādu programmu uztaisīt kā es un bīj pāris topiki kur tika apspriests jautājums par tādas progas nepieciešamību un secinājums ka tā ir realitāte kad kompis nevar precīzi tos laika intervālus uz Ltp porta ģenerēt un ejot zem windows vai citas OS pat izlaiž kādu soli un arī tika tas linux EMC pieminēts itkā tā ir balstīta uz īstā laika OS bet vienalga ar to ātrumu priekš PID aprēķiniem ir pa maz un tādu progu protasm ir grūti uztaisīt.

šodien paštukoju par cyclone III plates konfigurēšanu un ienāca tāda ideja ka jāpamēģina uz lētākā MAX 3000 32cel cpld 1,2$ uzkodēt loģiku prikš parallēlā flash (atmel AT49BV 1,89$)  kopā būtu 3$ risnājums  ::

----------


## Vikings

Es gan biju domājis kādēļ aprēķinus uz kompja veic uzdotajās vienībās (piem, milimetros) nevis soļos? Tas man vienkārši liekas vienkāršāk...
Un par paātrinājumu man ideja tāda - ja, piemēram, paātrinājums ir 10soļi/s^2 tad var darīt tā, ka, piemēram, 10 reizes sekundē (cipars no gaisa pagrābts) palialini ātrumu par 1soli/s tad arī sanāks 10soļi/s^2. Un kad sasniegts nepieciešamais ātrums tad paātrināšanu izbeigt. Tas pats ar bremzēšanu.

----------


## Epis

Vis ir pareizi tie aprēķini tiek vekti soļos tur lodziņā "apgriezieni uz 1mm" kur ir 100 ir domāts soļi uz 1mm un tie ir 100 un rezultātā pozīcijas vērtība attēlo soļus (nevis milimetrus) un komatus pēctam noņems nost kad to vērtību liks tajā soļu skaitītājā



> piemēram, paātrinājums ir 10soļi/s^2 tad var darīt tā, ka, piemēram, 10 reizes sekundē (cipars no gaisa pagrābts) palialini ātrumu par 1soli/s tad arī sanāks 10soļi/s^2. Un kad sasniegts nepieciešamais ātrums tad paātrināšanu izbeigt. Tas pats ar bremzēšanu.


 īsti nevaru saprast kādi cipari tad tiks aprēķināti ja vari tad uztaisi ekselī tabulu kur paātrinājums būtu 5m/s^2 un laiks kurš jānoiet līdz 4 sekundēm un tad varētu salīdzināt tavas aprēķinātās vērtības ar manējām (laiku kas vajadzīgs lai noietu 5 metrus (1 solis) ja tavu vērtību novirze patiešām nav liela no manējām, tad var padomāt, laigan es domāju kad novirze no manējām būs liela, bet to tik varēs redzēt salīdzinot.

man šonedēļ ir jāstrādā tāpēc progu turpināšu taisīt laikam nākošnedēļ.

----------


## Epis

Tā itkā pabeidzu programmu pievinojot COM portu un kodu kas nosūta datus vienīgi ir problēmas ar pārbaudi jo kad datus saņemu Com porta ienākosāis bufferis ir tikai 4Kbiti atmiņa un laikam būs bišķi vēl jāapskatās kā to lietu atrisināt.
Pamazām jāsāk domāt par signālu ģenerātoru.

----------


## Epis

Apskatījos un redzēju ka nēsu ielicis nekādu kodu par šito programmu, nu tad lai jūs redzētu kādas ir tās īstās formulas un cik briesmīga matemātika tur ir tad šeit arī kodiņš
[attachment=0:bacw60ri]G_code soft.rar[/attachment:bacw60ri]

----------


## Epis

jauns pavērsiens visā lietā.
Es tā domāju, par to soļu signālu ģenerātoru (lineāro, apļa un spline) un varbūt ka vispār nav vērts to taisīt uz fpga, lai to darbu tomēr dara dators, vienīgi lai nav jāčakarējās ar tām programmām (īstā laika datu sūtīšanai), tad tos kompja saražotos soļu signālu datus, noglabāt kādā lielas ietilpības flash atmiņā, es tā skatos tās Flash atmiņs ar katru gadu kļūst arvien lielākas lētāks un tagat 
2GB = 11Ls  
4Gb =18Ls 
8Gb = 28ls 

un izrēķinot tur var saglabāt tīri lielu soļu signālu skaitu it sevišķi ja vidējais (visas programmas garumā) soļu ātrums diez vai būs lielāks par piemēram 20Ksoļi/sekundē un 1 solis aizņemtu 16bitus tad 1sekunde = 20'000*16=320000biti/sek *4asis= 1'280'000b/s *60=76.8Mbiti/minūtē 
tad 2GB flash atmiņā var iebāzt 26.04 minūtes tas ir pilnīgi pietiekami priekš kautkādas normālas detaļas uztaisīšanas 
un ja vidējais ātrums ir 2x lielāks 40ksps tad sanāk 13 minūtes ka arī ir normāli, bet nevienmēr tas vidējais ātrums būs tik liels parasti ir vietas kur viss notiek baigi ātri virs 100ksps un vietas kur lēni, tad vidējasi būs zem tiem 20Ksps
un pietam tādām darbībām kā ass kustība ar vienmērīgu ātrumu, soļu signāla ātrumu pietiek ierakstīt tikai vienreiz un blakus reģistru kas parāda cik daudz tādu soļu lai izpilda  ::  sanāktu kad ar 2 Gb flashku pinlīgi pietiktu priekš tādām mazām vidējām programmām, ja būs lielas progas, lieli ātrumi tad var ņemt kautvai 16Gb flash karti, 
atceros pašā sākumā jau es domāju kā to soļu signālus sapakot(saarhivēt) lai aizņemtu pēc iespējas mazāk vietas un nebūtu jāsūta vesela rinda vienādu ciparu, tākā šo arhivātoru uz visual C# varētu uzkodēt ļoti fiksi man asmā viņš jau ir uzkodēts priekš tās vecās Atmegas128 un tur arī ir dekoderis, un ja būs vēl palikuši tad arī flowcharts zīmēts kur stukoju kā dekodēt, līdz ar to nekas jauns tas nav priekš manis, un ja sīto uztaisītu tad varētu sākt koncentrēties uz īsto lietas būtību motoru kontrolli. 

faktiski agrāk es īsti nebīju iedomājies par to vidējo soļu ātrumu kāds tas vrētu būt visas programmas garumā, un tas nevar būt nekāds lielais, līdz ar to būs iespēja ģenerēt soļus gan ar ļoti lielu ātrumu, kādi 500ksps (rēali līdz pat pāris Mhz mierīgi (uz īsu brīdi vai ar vienmērīgu ātrumu).

man liekās ka šitas ir īstais variants kāds jātaisa, + tas ir vis ātrākais kā var tikt pie tā soļu signālu ģenerātora, un viņu var pilnībā uztaisīt pat bez processora ar parastu statemachine loģiku kas nolasa flashku un ielādē soļa frekvenci Step ģenerātorā.

----------


## Epis

un es nupat izdomāju ka SD flashatmiņas vietā jāliek MT29F8G08MAAWC-ET flash atmiņa tā ir tādā pašā 48 TSOP korpusā kā tā kas man jau stāv uz plates vienīgi viņas tilpums ir 8GB un maksā digikeyā 16$   ::   veikalos tādas atmiņas maksā pie 30-40Ls tākā neko lētāku labāku es atrast nevaru + šī atmiņa ir samērā ātra nolasīšana iet ar ātrumu 40Mhz (40MB/s), un vēl pozitīvai tāds moments ka tas nolasīšanas interfeis ir vienkāršāks nekā tām SD,MMC kartēm vispār es lasīju ka pa to SD,MMC kartes nolasīšanas intefeisu kautkādas licenzes jāpērk (virs 1000$) tākā salīdzinājumā šito čipu var lasīt bez licenzēm, + nav vajadzīgas nekādas FAT failu sistēmas un bīj arī paraug kods priekš xilinx spartan-3 fpga mikrenes loģikā, vienīgi es vēl to nēsu novilcis (tur bīj jāreģistrējās) 
ko sakāt 16$ par 8Gb sanāk ka par 1Gb maksā tikai 2$ (digikeyā)    ::  šausmīgi lēti.

----------


## Epis

Attīstot iepriekšējo ideju par 8Gb flash atmiņu man radās jaunā ideja par pašu fpga mikreni, es izrēķināju ka man ir ekonomiski daudz izdevīgāk taisīt plati uz Lattice ECP2 144 TQFP iepakojumā + 2mb SPI flash šeit exelī aprēķins starp jauno laatice fpga un veco ciklonIII salīdzinājums nav īsti precīzs jo tur ir cena ciklon3 ar BGA256 paku, un paralēlo flash, bet vienalga ja salīdzinātu ciklonu tajā pašā 144 pin pakā ar SPI flash +max 3000 tad vienalga sanāktu par kādiem 4$ dārgāk nekā Lattice sistēma. 
[attachment=0:2i927kmz]Lattice ECP2 vs Ciklon 3 PCB izmaksas_foto.JPG[/attachment:2i927kmz]

+ vēlviens ne mazsvarīgs fakors ir detaļu skaits jaunajā variantā ir 3 čipi, vecajā 4 tākā tas dod papildus lētumu.

+ no svara ir arī iekšējie procesori, Lattice ir OpenSorece LatticeMicro32 kodols kas neko nemaksā, bet par Nios II licenzi jāmaksā 500$, papildus izdevumi, kas nebūt nav mazi un ja es beigās gribēšu to savu plati tirgot, tad samaksājot 500$ par licenzi pastāv reāla iespēja ka es vispār neko nenopelnīšu līdz ar to tas ir lielāks risks. 

+ nav vairs nepieciešamības pēc modulārā dizaina, ka sistēma sastāvētu no 2 platēm, jo tagat nebūs mikrenes ar 256BGA iepakojumu līdz ar to atkrīt vajadzība pēc daudzslāņu dārgas PCB plates, var izmantot jebkuru firmu lētās 2,4 līmeņu PCB un tad izdevīgāk ir likt visu uz 1 plates ( TTL Step/dir izejas un Enkoderu iejas, par konektoriem var ņemt interneta RJ-48 kontaktus, jo tie ir visur nopērkami, ārā nekrīt, un galvenais ka ir ļoti lēti, un nevar sajaukt polaritāti).

Domāju ka jāsāk domāt pie plates projektēšanas, vienīgais ko nēsu izdomājis vai uz plates likt SIN enkodera atbalstu vai nelikt, itkā gribētu lai tas tur būtu, papildus parastajam kvadratūrajam enkderim, bet problēma ir tur ka to PCB tiem opampiem un ADC būs grūti taisīt un es vēl šajā laukā nēsu neko daudz eksperimentējis ar tiem ātrgaitas ADC čipiem. 

Vispār kopš tā topika par to fpga mikreņu cenu kariem, kad es ieraudzīju to lēto lattice mikreni man visu laiku nebīj iekšējā miera, un tagat es izdomāju kautko darīt, jo vaidzēja uztaisīt PCB tai ciklon3 mikrenei, lai nav tā ka es nopērku čipus apskatos un pērku nākošos, vismaz tagat čips ir uzlodēts uz plates un strādā, un to plati es izmantošu viskautkur citur, izņemot CNC kontrollieri, jo sanāks tā kad šito jauno plati es specializēšu tieši priekš šitā cnc kontrolliera līdz ar to cita pielietojuma platei praktiski nebūs, atšķirībā no ciklon3 plates kura ir universāla visā savā būtībā kā 108 IO līnijas ar maināmu voltu līmeni, bet jaunajai būs labi ja 10-20 brīvas IO līnijas kurām būs fiksēts VCCIO 3.3v tākā plate nebūs ar plašu pielielietojumu. un ir tā ka ja brib lai izmaksas būtu minimālas tad Plate ir šauri jāspecializē, jāliek tikai tas kas nepieciešams, un nekā lieka.

Varbūt kāds jautās kādēļ tad es tagat neizmantoju to BGA iepakojuma mikreni atbilde ir vienkārša: šitā NAND flash atmiņai nav Adrešu līnijas, visi dati sūtās un saņemās caur 8bitu datu līniju, līdz ar to tiek ietaupīti ap 20 IO, kas faktiski arī bīj iemesls tam ka man trūka IO vadu un es ņēmu lielo BGA paku, tagat situācija ir savādāka un man der 144 TQFP paka ar ~90 IO vadiem.

Vispār šādu Lēmumu pieņemt ir grūti, jo es jau tik tālu bīju ticis ar to ciklon 3 mikreni ka ir tā stūlbi sākt visu no 0 ar citas firmas mikreni un citām programmām, bet tas ir ekonomiskā izdevīguma vārdā, jo ātri vai vēlu vaidzētu meklēt variantu kā to uztaiīt lētāk un tad būtu vēl smagāk pāriet uz citu fpga firmas mikreni, tākā labi ka nešu vēl sācis kodus drukāt, faktiski man tagat nebūs daļu kodu nemaz jādrukā kā kods priekš NOR Flashatmiņas programmēšanas caur MAX 3000, jo SPI atmiņu varēs prorammēt caur JTAG pataisno tur jau ir gatavas programmu paketes lai to visu izdarītu, līdz ar to pilnīgi iespējams ka es esu izvairījies no kārtējās bedres, un beigās būšu ieguvējs pārejo uz lattice fpga, kā nekā man būs virs 3GMACS jauda tagat   ::

----------


## a_masiks

> bet tas ir ekonomiskā izdevīguma vārdā, jo ātri vai vēlu vaidzētu meklēt variantu kā to uztaiīt lētāk


 Tas tjipa ir 4$ vai 7$ dēļ? Nu kā teiksi... tev labāk redzams... Ēzopa fabulā par lapsu - arī vīnogas pārāk skābas un negatavas sanāca... iesaku izlasīt šamo fabulu... pamācoša.

----------


## Vikings

Nē nu Epi beidz, kas tu domā mums nav jūtu? Mēs visi elpu aizturējuši sēžam gaidam ka nu tik ciklons zāģēs metālu, a še tev, plate vēl nav palaista un jau vajag citu. Nu būs tev čupa ar visādām FPGA platēm, ko tālāk? Nu bāc, tu tikko sagrāvi manas ilūzijas...

----------


## Epis

Aizdomājos līdz vēlvienai lietai kurai jābūt uz plates un tas ir kādam Drošības čipam kas garantētu to ka nevarētu noklonēt Fpga programmu pataisno, un tākā dati uz fpga tiek sūtīti no flash pa taisno tad tos var viegli nokopēt un ieprogrammēt citā fpga un vis strādās, bet lai to nevarētu izdarīt vaig kādu drošības šifrēšanas ierīci, un faktiski vienīgais kaut cik drošais variants kā to realizēt ir izmantot kādu ārēju čipu piemēram ar AES šifrēšanas un dešifrēšanas funkcionalitāti vai arī SHA-1 algoritmu, abus divus uzlauzt ir neispējami (protams ka var tikai ļoti grūti) un tādu programmu varētu ietaisīt iekš kāda maza lēta 8 bit procesora, kā attiny25 ar 8kāju SOIC pakā čips maksā lēti pie 25 gab ap 1,2$, gribēju es skatītes attiny11 virzienā kurš maksā 0,5$-0,3$ betviņam atmiņas pamaz tā AES kriptēšanas proga pēc viena linka 1,5Kbaitus.
http://point-at-infinity.org/avraes/

un drošība ir tur kad sākumā kad iestartē fpga pa taisno no flash atmiņas fpga iekšējā loģika vai procesors uzģenerē nejaušus skaitļus un nosūta ARS šifrēšanas čipam tas to ciparu sašifrē un sūta atpakaļ fpga, pa to laiku fpga arī sašifrē un tad salīdzina rezultātus, ja tie atsķirās tad fpga slēdz sevi ārā un nestrādā, ja viss sakrīt tad vis OK, un uzlauzt fpga programmēšanas failu un tajā atrast to AES šifrātoru, vai procesora kodu kas šifrē nav iespējams, varbūt ir bet tad ir jālien pašā fpga arhitektūrā tik dziļi ka diez vai kāds izņemot pašus ražotājus to var izdarīt. līdz ar to intelektūālais īpaumš vismaz kautcik tiek aizsargāts. + diez vai kāds gribēs baigī čakarēties lai kautko uzluztu jo ieguvums no tā būtu niecīgs.

un tagat sanāk tā dīvaini ka sistēma tagat sastāvēs gan lattice, gan cikon no vienāda skaita mikrenēm (4gab), jo ciklonam tehniski to attiny varētu izmantot lai tas nolasa SPI flashu un konfigurē pašu ciklonu, shēma ir sarežģitāka un par 0,1-0,2$ dārgāka jo būtu jāņem 16pin SOIC mikrene un bišķi vairāk flash atmiņas (ieguvums tāds ka varētu izmantot kādu ADC kanālu, vai tempertūru mērīt (ar iekšējo termormetri). 

Tākā ņemot vērā jauno datu aizsardzības faktu ir bišķi jāpadomā jo detaļu skaits nemainās, un cenas starpība ir maza bet ir, un stūlbi tas ka ciklonam 3 nav uzrādīta vairuma cena, un jāmaksā 500$ par proča licenzi, tehniski varētu mēģināt izmatnot to laticemicro32 jo itkā tas ir pa brīvu un varētu viņa HDL kodu nokompilēt ar Quartusu, bet tur noteikti ka būs kāds čakars, vispār ar ciklonu tā visa padarīšana ir daudz čakarīgāka, un vai ir vērts tā čakarēties ?? 
un tomēr tā 11$ ECP2 mikrene ir daudz jaudīgāka un par 1000 logīkām vairāk tākā maksāju mazāk, dabūnu vairāk, + proča kodols pa velit un tur ir arī 8bit kodols kas arī pa velti tākā mazām lietā 8 bitus lietām 32  ::  ir iespējas un izvēle viengi RAM atmiņas tam čipam pamaz ap 55Kbiti ciklonam ir 400Kbiti.

uz jaunās plates domāju ka jāliek 1Msps 8kanālu ADC vai nu 8bit AD7908BRUZ 4.9$ vai 10 bit ADC108S102C 5.3$ nevaru izlemt, nākošaie daudzkanālu ADC jau maksā  virs 8$ un ātrums virs 2Msps es īsti nezinu vai sin enkoderim tik daudz vaig
lētajā variantā uz 1 kanālu sanāk 125Ksps, bet ja izdomā kādu viltību ka lēnāko enkoderi pārbauda retāk un ātākos biežāk tad kādu kanālu varētu ķert ar 500ksps, vispār jau galvenā sin enkodera fiča ir lielais digitālais ZOOM un tā interpolācija varētu sasniegt 8 bit līmeni (256). 

Tākā vēl ir par daudzām lietām jādomā, var teikt tagat sākās īstā domāšana.

----------


## a_masiks

It kā būtu tur ko sargāt. Projekts pagaidām pat pašam autoram nav vajadzīgs. Kur nu vēl kādam ļaunprātīgam zaglim... Nu... tas ir...  es gribēju teikt - projekta ta nemaz nav...

----------


## dmd

kā nu sanāk? es prezumēju, ka epis droši vien izmanto kādu piratizētu programmu sava ciklona izstrādē?
un ja tā, tad nerodas morālas problēmas, ka no citiem ņem, bet pats neko nedod? 

bet tas tā, pieņemu, ka neviens neņemsies kautko klonēt baigi. tie džeki, kas māk, tiem tavi darbi naher nebūs vajadzīgi, a tie, kas nemāk, uztaisīs vienkāršus kontrolierus un dragās uz nebēdu, nafig lieki ķēpaties.

un tādā ziņā open source ir izdevīgāks - vismaz ja kādu tas ieinteresēs, tad pastrādās pie šitā projekta.

----------


## Epis

Problēma atrisināta neuzmanības dēļ es nepamanīju, ka šitām mazajām lattice ECP2 mikrenēm ir arī Bitstream Encryption un tas ir tām mikrenēm kurām galā ir S burts un katalogā atradu šo LFE2-6E-5T144CES maksā tik pat 11$ un te jau ir 
šeit par to šifrātoru:



> The LatticeECP2/M "S-Series" devices contain non-volatile memory elements that can be used for the storage of a 128-bit customer specific decryption key. Bitstream files can be encrypted with this key prior to programming into the configuration memory. As the encrypted bitstream enters the FPGA it is decrypted using the key stored on the device. This capability provides a method to combat design piracy and overbuilding.


 Tagat situācija ir tāda kā sākumā ar lattice fpga snāk 3 čipi ar ciklon 4, ar xilinx būtu tas pats kas ar ciklon, vienīgi vēl mazāk čipi sanāktu ar Flsh fpga tad būtu 2 fpga un nand flash, bet tās ir dārgas mikrenes.
un vēl šitai mikrenei ir TransFR I/O funkcija kas ļauj fpga iekonfigurēt citu loģiku darbības laikā ļoti ātri, fiksējot visus ārējo IO stāvokļus, ciklonam konfigurējoties visi IO pazaudē savus stāvokļus, spartan3 bīj labāka situācija tur bīj kautkāds partial reconfiguration, bet par IO arī neka skaidri nav zināms, šitā fiča ir laikam tikai Lattice mikrenēm, vispār šitā ir 2006gada labākā fpga inovācija un pagāja gads kamēr parādījās pārdošanā.

Līdz kautkādam līmenim to open sorece ideju var uzturēt piemēram kompjūtera programmu un datu sūtīšanas protokolu, jo tā lieta nebūs nekāda šausmīgi sarežģitā un koderu ir samērā daudz, bet to hardware kodus un loģku tehniski nav jēga, jo reti kurais kautko no tā saprot, un ir spējīgi uzlabot, pagaidām cik esu skatīies CNC zonā tad neviens kas taisa tādu nopietnu elektroniku pārsvarā motoru draiverus savus mikreņu kodus neliek OpenSorce, ieliek kādas atsevišķas daļas, bet tādu gatavu kodus ar kuru ielādējot viss strādā labiem draiveriem neatrast, protams ir visādi kodi bet tie ir pašvakiem draiveriem kur ir tikai pamats tas ir apmēram tādā pašā līmenī ko dod ražotājs, Kā TI ir vesela motoru kotntrolles bibloteka ar kodiem pa brīvu, tad labāk izmantot tos.

cnc kontrollieru kodi arī ir kā piemēram mesanet.com var novilkt fpga loģikas kodu, bet labums no tā nebūs liels, jo tā lieta tur ir sarežģita vieglāk visu no 0 uztaisīt. tākā vienīgi ko ar to kodu var izdarīt ir rakstīt iekšā citā fpga.

----------


## Epis

Ja es izmantošu lattice tad kodi jāzog nebūs jo tur viss ir open sorce ar open sorece wishbone interfeisu uz kura ir taisīta liela daļa Opencores.com kodolu kas ir pa velti, tākā tas ir vēlviens +. 
vaisi pārējie loģikas kodi ir paštaisīties, nios II procism to kvadrātsaknes kodu es novilku, bet tagat man to nevidzēs izmantot, jo to matemātiku veiks kompis.

----------


## Epis

Galīgi piemirsu vēl vienu lietu to ka ADC konvertieris neder Sin enkodera signālu ķeršanai jo tur ir jāmēra laika intervāls starp sinusa viļņa voltu līmeņiem, līdz ar to lai lai piemēram mērītu signāla izmaiņu laiku no 1V uz 1,1V ar augstas izšķirtspējas taimeri kādi 24biti un pūlksteni pie 20Mhz vaidzētu reāli 20msps ADC konvertieri   ::  
Izeja no šīs absurdās 20MSPS ADC izmantošanas ir izmantot Comparātoru+DAC, un tad DAC uzstāda referenci uz 1.1V un komparātors gaida ka Sin enkoderis sasniegs 1.1V un tad ziņos un šajā perjodā tiks noņemta 20Mhz taimera vērtība un iegūts signāla ilguma laiks lūk tā, 
un parakājos pa digikey katalogu un atradu īsto DAC čipu ar 8 kanāliem un sakarīgu ātrumu 6us + visādas citas fičas kā singrona kanālu vērtību uzstādīšana (visi kanāli mainās vienlaicīgi) un datu ielādes ātrums čipa ir tīri labs pa seriālo vadu ar 30mhz clock 8 kanālus varēs salādēt 4us (250Ksps), par comparātoru laikam neko daudz domāt nevaidzēs, paņems kādu lēto ar 3Mhz bandwidth, vienī vaidzēs vēl Opampu pirms comparātora iejas ar regulējamu gain priekš lielu voltu signāliem 12v,24V nolaist līdz 3-4V priekš comparātora,
būs jaapskatās digitālie potenciometri  ::  tai gain regulēšanai.

----------


## Mosfet

Epi tu atkal parādi savu absolūtoto nesaprašanu analogajā tehnika un ADC.Nemācoties pamatus tu esi piemirsis par offset limeni komparātorama pie lielas frekvences , DAC precizitāti un dreifu un vēl citām tev" mazsvarīgām problēmām " un kad te būs vēl 30-40 lpp tad tu varbūt atklāsi ka nekas nav labāks par ADC ar difrenciālo ieeju un ar iekšējo referenci.

----------


## dmd

skaties ar tām open sourcēm. ja tu ņem kautko GPL licenzētu, tad var izrādīties, ka visam, ko tu esi aplipinājis ap to opensourcēto daļu arī jābūt opensourcētam.

----------


## Velko

Nedomāju, ka opensource būs liela problēma priekš Epja. Viņam tak patīk palielīties ar to ko uztaisījis  ::

----------


## Epis

visu vakaru pētīju tos diferenciālos ADC un arī diferenciālos Opampus, un draiverus priekš tiem ADC, un secinājums tāds kad tie opampi visi ir ar lielāku bandwidth par 50Mhz līdz pat Ghz, tik daudz man toč nevaig + maksā šausmīgi dārgi 1 tāds opamps Lētākais iet pa 1.8$ 	EL5176IY  intersil, pārējie lētie 3-4$ un nemaz nerunājot par ADC konvertieriem ar tād diferenciālajām iejām tie arī maksā šausmīgi ~8$ par 2-6Msps 2diferenc.kanāliem vai 4 parastiem, 
protams tās sistēmas ir baigi precīzās ar novirzi pāris mv, bet es domāju ka  priekš mana sin enkodera kurš lēnu griezīsies un izdos parasto Sin vilni kādā 1-2Khz frekvencē (MAX) 

Es skatoties detaļas protams esu ņemis vērā tos visu novirzes parametrus un pēc cenas/ ātruma esu izvēlējies šādas detaļas:                            
AD5308ARUZ  DAC 8ch 	16-TSSOP 	6.04$   0.7V/us 

TLC339CPWR 4x comp  1.11$  1us faling un rising ar 20mv un 2us ar 5mv ofset voltage
vai TVL2354  4x comp    2.6$     300ns faling time pie20mv;  400ns rising time 20mv  un 5mv precizitātei jāpieliek vēl 200ns abiem diviem faktiski šitas comparātors ir samērā prezīzs un tā novirze no maza ofset voltu līmeņa 5mv uz lielu 20mv ir tikai 200ns (5Mhz) līdz ar to lai dabūt tādu precizitāti sanāk ka vaidzētu 5Msps ADC  :: 

un par opampiem nav ne jausmas itkā liekās ka normāls ir TL084 ar 3Mhz bandwidth domāju ka priekš 1-2Khz sinusa viļņa vairāk nevaig lai viņu pielabotu(samazinātu), a varbūt vispār bez opampa laist pa taisno comparātorā, jo tur var grūst  līdz pat līdz 7V man paštaisītais sin fotopārtraucēja enkoderis dos ārā 5V sin vilni  ::  
tehniski sanāk ka varēšu to sin enkoderi nolasīt ar 250Khz tik daudz vaig lai nomainītu visus DAC kanālus un man lielāku ātrumu nevaig, teorētiski 1 kanālu atsevišķi var mainīt ar kādu 2Mhz ātrumu tākā ir iespēja uz lielākiem ātrumiem , ja ptroams būs vajadzība.

----------


## Velko

Tas jau izklausās apmēram šādi:



> MITCHELL: Please tell me you have the gate working again.
> CARTER: We're running another diagnostic, but right now we're stumped. The power's getting through to the capacitors, but for some reason the charge isn't holding. That's causing the control crystal to send feedback into the interface and reset the programming code of the base computer's dialing protocol.
> MARTIN: Whoa! That was awesome! Say that again.
> CARTER: No!
> MARTIN: Oh. Uh, ev-everybody, take five. I've got to get that down before I forget it. "The power getting to the 'flux capacitor' but feedback is not feeding back into the 'feedback face'." This is gold!
> VALA: Hey. Forget about the techno-talk. No one's really interested in it.

----------


## Epis

Vispār cik atceros šitā analogo signālu (sinusa) interpolācija ir tāda miglā tīta un neskaidra, jo kad es eksperimentēju ar tiem LVPECL diferenciālajiem IO fpga vadiem un arī atmegu8 tad tie rezultāti bīj tādi var teikt ciešami jo itkā kautkas sanāca, bet neko kvalitatīvu es nedabūju, varbūt tādēļ ka toreiz es mēģināju uztaisīt nevis sinusa viļņa interpolātoru bet gan SAR ADC konvertieri, līdz ar to tas analogā singāla meklēšanas algoritms bīj tāds pasmags, sinusam tā lieta ir primitīvāka, bet atceroties ADC eksperimentus uz atmegas8 ar 300Ksps tad šeit kautkas sanāca bet paši saprotat ka tas ADC ātrums ir pārāk mazs lai noteiktu kādam 120Khz impulsam  viņa laiku, sanāk ka es tādu 120Khz signālu noteikšu vai nu kā 150khz singālu vai arī kā 75Khz signālu līdz ar to kļūda ir šausmīgi liela, lai precizitāte mērījumos būtu vismaz ar kādu  normālu kļūdu 1-2% tai ķeršanas frekvencei jābūt 50-100x lielākai un tas ir 120x50=6000Khz sanāk no 6-12Mhz tad 120Khz signālu varēs nomērīt ar precizitāti 1-2%  un ja man ir 8 sinusa viļņi tad vaig 8 kanālu ADC kur katrs kanāls skrien ar 6-12Mh naudas izteiksmē tas ir dārgāk nekā FPGA+NAND flash piemēram ja 1 kanāls maksātu kādi 3(ADC1173CIMTC 15Msps) - 4$ tad tas būtu no 24-32$ tikai uz ADC konvertieriem.
skatoties digikeyā atradu tādu vienu ADC zvēru pa 48$ ADS5277 8kanāli katram savs 65Msps ADC + 8x LVDS 250Mbs seriālie kanāli datu sūtīšanai un kā jau visiem krutajiem ADC tur ir diferenciālā ieja, šitas jau būtu baigi labais ADC, un dokumentā kā piemērs kurš varētu to ADC darbināt tika minētas xilinx fpga, paratie proči uz kautko tādu nav spējīgi  :: 

bet lai tādu darbinātu vaidzētu iejā izmantot DIferenciālos opampus signāla pastriprinšānai un tad šitas viss prieks aiziet līdz pat 100$ tikai lai kautkādu SIn enkoderi nolasītu (man tas liekā pārāk dārgi. 

Tad kas labāks 48$ 65Msps ADC vai 11$ DAC+Comparātoru sistēma  ???? 
no PCB izmēru viedokļa viens čips ir labāk nekā 3 bet vai tas ir 37$ vērts  ??

----------


## GuntisK

Epi-ko domaa izmantot par izejas draiviem? Kaa veiksi vadiibu-ar step/dir vai kaa savaaadaak? Un kaa ar mehaaniku?  ::

----------


## Epis

> Epi-ko domaa izmantot par izejas draiviem? Kaa veiksi vadiibu-ar step/dir vai kaa savaaadaak? Un kaa ar mehaaniku?


 Parasto 5 voltu Step/dir caur SN54HC541 buferi un galā veco 4 asu xelotek stepper motoru draiveri (ar 1/8mikrosoli) 

no otra gala būs ieja priekš paratā 5V kvadratūrā enkodera arī caur to pašu bufferi viss ticamāk ka būs 16 izejas un 16 iejas un + 8 Sin enkodera iejas (priekš 4 SIN DIY enkoderiem  ::  ja izmantošu paštaisīto diska SIN enkoderi tad tehniski atlikušās 16 iejas var izmantot viakautkam citam kā limit slēdži utt. un tas pats ar izejām man pāri paliks kādas 6 un no tām varēs slēgt viskautko vai kautko citu. 

viss ir izdomāts izņemot to Sin enkoder dekoder daļu, kur vai nu DAC+comparātors (lēti) vai arī diferenciālo ADC
un šeit ir liela problēma ka jāizmanto tiem virs 10Mhz ADC un viņi visi ir Parallēlie tas nozīmē ka lai tādu ADC darbinātu vaig čupu ar IO līnijām tehniski man pietiktu IO līnijas lai tikai pieslēgtu 1 parallēlo ADC (ir tādi kuros ir 2 diferenciālās iejas) vai arī otra izvēle ir ņemt super dārgo 48$ ADS5277 8 kanālu zvēru un šitam ir seriālais LVDS interfeis ar Data Bit Rate 240 - 780 Mbps   ::   tai lattice fpga max LVDS ir pie 700mbps uz kādiem 200-300 strādāt varētu, līdz ar to beigās sanāk ka ja grib noskanēt 8 sin enkodera viļņus ar minimālu IO skaitu un ātrumu virs 5Mhz nav īsti citas alternatīvas par to 48$ ADC (nekā lētāka nav ar 8 kanāliem) bet tas man liekās Smags overkills priekš tik vienkāršas lietas kā sin enkoderis.

ko domājat par to 48$ ADC ???  der vai neder ? 

vispār es nēsu skaitījis cik IO līnijas man jau ir aizņemtas un cik paliek pāri (domāju ka nekas pāri daudz nepaliks jo NAND flash+FTDI+SPI+32bufferi aizņems jau virs 60IO a man būs tikai kādi 90IO tākā ar mazāk kā 30IO ir jāuztaisa sin enkodera atbalsts, vai arī jāņem BGA256 paka.

----------


## Epis

šitas ir brīdis kad varat kautko ieteikt vai nu ADC, vai DAC+comparātora sakarā, un pilnīgi iespējams ka es to ņemšu vērā, protams tikai tad ja tas būs kautkas labāks par to ko es esu izdomājis, un kā redzat esu nonācis pie 2 variantiem no kuriem viens ir Overkill un otrs atkal pa švaku un neprecīzu pēc Mosfet teiktā
kā redzams tad ir vajadzība pēc 3 varianta "zelta vidusceļa"    ::   kuru atradis vēl nēsu   ::

----------


## zzz

Eeee, nee, epi, kopsh tu nomiikstojies un pazinjoji ka neliksi savaa milzu platee gigaflopiigu dsp, nav vairs nekaadas uzticiibas taviem plaaniem.

----------


## Epis

> Eeee, nee, epi, kopsh tu nomiikstojies un pazinjoji ka neliksi savaa milzu platee gigaflopiigu dsp, nav vairs nekaadas uzticiibas taviem plaaniem.


 es jau teicu ka man vienkārši bīj intrese apskatītes kurš tad procesors ir ar viss lielāko FPU jaudu un zemāko cenu un vai tas procesors var parsist FPGA par attiecīgo cenu, ja iekš viņas saliek FPU hardware un izrādījās ka tāds čips ir  :: , bet ja tā reāli tad to 1GFLOPU dzīvē dabūt nevarēs labi ja sanāks kādi 200Mflopi, jo procis tač iet ar 200Mhz ātrumu un labi ja 50% no instrukcijām reāli ir matemātiskas un tā atlikusī daļa ir programmas plūsmas kodi, tas pats jau arī ir ar fpga mikrenēm šitai ECP2 ir virs 3GMAC jauda, bet reāli sanāks izmantot labi ja 20% no MAX protms var mēģināt spiest ārā MAximumu.

Piemēram ja es nopirktu to 48$ ADC tad man mikrenē plūdīs 10bitu ADC dati no 8 kanāliem ar ātrumu 65Mhz un lai no šīs infromācijas dabūtu ārā to SIN enkodera griešanās detektēšanu ar tiem 10bitiem ir jāveic matemātiskas operācijas kā salīdzināšana ar iepriekšējo vērību to var izdarīt atņemot veco vērtību no jaunās un skatītes vai rezultāts ir 0, vai lielāks par 0 un tālāk tad var to infomrāciju par laika intervālu noņemšanu apstrādāt ar zemāku ātrumu !10Mhz, līdz ar to var pat teikt ka šādus 8 kanālus tas TI zvērs nevarētu pavilkt kaut arī viņam ir jauda 1Gfops šitā lattice 10$ FPga viņu saliek kā mazu bērnu ar saviem 3GMACiem  ::  Tā ir FPGA tīrās paralēlās procesēšanas jauda. 
Pat ja es izmantotu šito Comparātora +DAC variantu es domāju ka TI DSP mikrene šito pavilkt arī nevarētu, itkā liekās ka varētu pavilkt jo šeit vis notiek ar 1 Mhz ātrumu, bet te arī ir paralēlā procesēšana un te ir specifisks signāla meklēšanas algoritms Ti mikrenei jāviec lai sameklētu analogo signālu un noķertu to īsto brīdi + nerunājot par virziena noteikšanu, uz fpga tas viss tiek darīts ar State machine katram kanālam sava loģika un viss strādā paralēli, par to ka TI DSp procis ar šito netiks galā es esu pārliecināts dēļ tā ka es jau mēģināju ko līdzīgu uz Atmegas8 kur uz Max 20Mhz man izdevās to comparātora +DAC sistēmu palaist ar ātrumu tikai ~300-500 ksps un tasprasīja 100% procesora resusrsus un iedomājaties kas notieks ar TIDSP ja viņam būs 8 kanāli jāapstrādā tas ir mision imposible uz to ir spējīga tikai fpga vai CPLD(tas jau ir pierādīts), un pat ja TIDSP zvērs varēs pavilkt tos 8kanālus tad tas aizņems lielāko daļu procesora jaudas, bet fpga labi ja 1000 loģikas kas ir tikai 16%no 10$ čipa, tākā ja iet runa par parallēliem processiem un to apstrādi tad nav nekā labāka par fpga. 
ja man ievaidzēsies tos peldošos punktus baigi tad es padomāšu.

----------


## zzz

I nemaz netaisnojies kaarteejos paladzinjus drukaajot, tam nav nekaadas veertiibas.

----------


## M_J

Mazliet ne pa tēmu - Epis kaut kā uzkrītoši visu laiku rēķina līdz cenu. Nesaku, ka to nevajag darīt, bet ja tas kļūst par noteicošo argumentu rezultāts ir draņķīgs. Ja kaut ko projektē - izvēlies komponentes, kas vislabāk  der tavām vajadzībām. Visu laiku meklēt labāko kaut kādu mistisku veiktspējas/cenas attiecību, piedod, tas man atgādina alkašus kas klīst gar dzērienu plauktiem meklējot labāko attiecību: tilpums x grādi / cena

----------


## Epis

Ir vēlviens variants izmantot iekšējo LVDS komparātorus, vienīgi nav skaidrs cik precīzi ir, es atradu MAXIM MAX9179 LVDS reciveri un tur ir precizita'tes grafiki minimālajam tresholdam pie kura slēdzās līmeņi, domāju ja viņiem tie komparātori ir tik precīzi tad fpga arī vaidzētu būt līdzīgas rpecizitātes  ::  tikai ar augstāku 100mv treshold.

es ieliku Lattice forumā jautājumu par to treshold voltu līmeņu precizitāti, un kautkādiem grafikiem kā šis kur to var redzēt un ja tie inženieri atbildēs un izrādīsies ka tā precizitāte ir pietiekami augstā līmenī tad varētu kautko domāt šajā virzienā, jo kādēļ vispār izmantot comparātorus ja tādi jau ir iekš fpga. 
vispār mana sapņu plate arī tā varētu izskatītes ka uz plates stāv viena varenā FPGA mikrene kuras LVDS comparātorus izmantoju lai ar DAC uztaisītu ADC konvertieri un tad mērītu analogos signālus kādiem 4 soļu motora pinumiem, + SIN enkoderiem un vēl viskautkam citam kur kautkas jāmēra un ADC skaits varētu būt līdz 20-vai pat 30 ar veikstspēju 250-500Ksps  ::

----------


## Vikings

> as man atgādina alkašus kas klīst gar dzērienu plauktiem meklējot labāko attiecību: tilpums x grādi / cena


 Kā kulaks uz acs!   ::

----------


## Epis

man sāk likties ka DAC+ comparātora variants nebūs neko labāks par DAC+LVDSreciver variantu, jo itkā tā comparātora jūtība ir lielāka kādi 5mv, bet tas reaģēšanas ātrums ir tāds baigi švakais un viņš mainās atkarīgā no tā treshold līmeņa 5-20mv, līdz ar to precizitāte būs sūdīga, bet LVDS variantā treshold ir ap 100mv un šeit arī itkā ir tā jūtības pakāpe ja ir kādi 150-200mv starpība tad signāls ātrāk uzlec, bet starpība starp comparātoru ir tur ka šeit ti ātrumi ir citi te vis notiek 1-2ns kas man faktiski neintresē jo clock būs  20-50Mhz robežās kas ir 20-50ns tākā 1-2ns novirze neko apsalūti nemaina, vienīgi šitik jūīgi LVDS kanāli var uzķert trokšņus.

vēl ar DAC+LVDS varētu mēģināt to izšķirtspēju palielināt no 100mv līdz kādiem 2-5mv izmantojot DAC 0,7v/us kāpšanas intervālu ADC signāla meklēšanā, to kāpšanas laiku mierīgi nomērīt piemēram ik pēc 5mv intervāla izmantojot tos pašus fpga LVDS kanālus un tākā DAC ir 8 kanāli tad ar 3 testiem (izmanotjot uzreiz 8 kanālus) es varēšu nomērīt 120mv kāpuma ātrumu ik pa 5mv un tas pēc būtības sanāktu kautkas līdzīgs signa delta ADC kur bīj kautkāds sakars ar signālu kāpuma un krituma laika mērīšanu, lai dabūtu  ļoti lielu izšķirtspēju  ::  




> Ja kaut ko projektē - izvēlies komponentes, kas vislabāk  der tavām vajadzībām. Visu laiku meklēt labāko kaut kādu mistisku veiktspējas/cenas attiecību, piedod, tas man atgādina alkašus kas klīst gar dzērienu plauktiem meklējot labāko attiecību: tilpums x grādi / cena


 Jau pus gadu atpakaļ ka nolēmu taisīt PCB priekš ciklon3 čipa es nevarēju izlemt vai ņemt ciklon3, vai arī ECP2 un toreiz šitas 11$ čips maksāja 15$ un attiecīgi BGA256 čips pie 20$ tas ir par 5$ (25%) dārgāk nekā ciklons3 un gandrīz vai nopirku ECP2, tākā nav gluži tā ka cena ir noteicošā un ja jau es toreiz gandrīz bīju gatavs to čipu pirkt pa dārgo tad šogad janvārī kad ieraudzīju čipa jauno cenu (-25%) es vairs nevaru aturēties un nenopirkt. var teikt ka cenai nozīme ir apmēram kādi 20-30% pārējais ir fičas, programmas utt. 
te var uzskaitīt kādēļ ECP2 man liekās ir man piemērotāks nekā Ciklon3

1. open sorece LatticeMicro32 procis,un arī Wishbone Bus (man naudas nau lai pirktu licenzes) 
2. sysDSP bloki, man tādus vaig to es jau sapratu taisot enkoderi perifēriju un to savu DIY proci.
3. SPI flashatmiņa priekš konfigurācijas - ietaupa nopietnu naudas summu un ir plaša izvēle
4. Drošība AES šifrātors, šitas ir ļoti svarīgs fakts.
5. Cena kas kā priekšrocība parādījās tikai šinī gadā, pirmstam cena sarakstā nebīj.

----------


## Vikings

> vēl ar DAC+LVDS varētu mēģināt to izšķirtspēju palielināt no 100mv līdz kādiem 2-5mv izmantojot DAC 0,7v/us kāpšanas intervālu


 A tu neiedomājies, ka tas varbūt notiek nelineāri un tas var visu to pasācienu sabojāt? Nedzīvojam taču ideālā pasaulē.

----------


## Epis

atradu grafiku AD538 DAC dokumentā kur var redzēt kā viņš reaģē un cik ātri mainās DAC vērtība un tā līkne ir nelineāra un laikam ka tas 0,7v/us ir vidējais lielums + tur vēl ir sava laika aizure kamēr DAC izejā vispār notiek kādas izmaiņas, bet tas jau nenozīmē ka tos lielumus nevarētu nomērīt, to aizturi mierīgi kas pēc grafika ir kādas 400ns un tad mērīt pēc grafika izskatās ka VoutA līkne uzkāpj pa 1,2V tīri lineāri, un pēc tam sākas lēnāks kāpums, tur jau arī nāks klāt pašas PCB celiņu kapacitāte, un citi brīnumi   ::  

šitā visa LVDS lieta ir tāda miglā tīta. 

[attachment=0:2wgx1d1e]AD538_DAC_atrums.JPG[/attachment:2wgx1d1e]

----------


## Vikings

Bāc nu vienu nesaprotu - nah tu tur tā pisinies! Nu un, ka kaut kāds ADC ar nosaukumu X maksā 2, 3 vai varbūt 5 reizes dārgāk kā no kaut kāda DAC un rezistoriem uzlodēts, bet katrā ziņā viņu tu vienkārši vari ielodēt platē un nečakarēties. Epi, beidz taču vienreiz p*st santīmus, noziedo tos 10 vai 20 Ls sakarīgām detaļām un priecājies kā viss iet uz priekšu nevis taisi galīgi greizu ADC "pareģi", ja tirgū ir desmiti vai pat simti dažādu ADC modeļu, kas tev varbūt atbilstu IDEĀLI.

----------


## Epis

ar tiem ADC ir tā kad tādu vidējo variantu nav ir vai nu dārgie vai lētie dārgajiem katram kanālam ir savs ADC, lētajiem viens ADC uz visiem kanāliem līdz ar to  uz 1 kanālu ir 150-250Ksps, bet dārgajam ir 40Msps uz knālu.starpība ir liela.
šeit bilde no Analog device visi 8kanālu ADC ar ātrumu virs 2msps un TI ar ātrumu virs 1msps tā izvēle ir maza vainu ātri vai lēni.
[attachment=0:1bh5bf5d]TI_un AD 8ch konvertieri.JPG[/attachment:1bh5bf5d]

ar 4 knalālu ADC situācija līdzīga vienīgi TI ir THS1007 6Msps 4ch(single) vai 2ch Diferenciālie maksā 8,7$ faktiski šitas ir lētākais veids kā tikt pie Diferenciālā ADC ar kautcik lielu kanālu skaitu 

es tagat domāju moš vispār ņemt tos lētos ADC ar 150-250Ksps uz kanālu piemēram šitas TLV1570 7.6$ 1,25Msps SPI 8ch 
vai otrs variants šito AD7829 9.46$ 2Msps Paralēlais 8ch vai arī divus 4 kanālu lētos AD7904 4ch 4,1$ 1Msps. 

Es tā domāju un izdomāju tā ka tā lielā izšķirtspēja praktiski būtu vajadzīga tikai priekš maziem ātrumiem lai precīzi kautko nopozicionētu, bet uz lieliem tai izšķirtspējai zūd jēga jo tos processus tāpat nevar ietekmēt ātrāk par 1ms (motoriem) kur PID rēķina ar 1khz un viss advancētākajām elektronikām to  PID rēķina ar 10Khz, līdz ar to tā enkodera super ātrumam jēga nav liela pie lieliem motoru ātrummiem jo tāpat tiks ņemta ātruma vērtība ik pēc 1 Khz vai 10Khz, tad ar 125Ksps ADC varēs noteikt samērā precīzu laika intervālu 1Khz signālam ar 7bit izšķirtspēju un tas tā vispār neko precīzi nemaz nav 7biti =128 priekš ātruma intervāla tas ir pašvaki, parastajiem Kvadratūrajiem enkoderiem taimeri skrien ar 10-16Mhz un to ātrumu fiksē, ar 1Mhz jau kautcik pietuvotos.

laikam tagat pats esu beigās nonācis pie tā ka ja ņem ADC tad jāņem tas THS1007 diferenciālais 4ch ADC, vismaz ar to kautko nomērīt varēs  ::  priekš PID matemātikas (būs 10biti pie 1Khz pid frekvences) 

vels ar ārā šitā sinusa enkodera lieta visu pamatīgi iebremzē, varbū vispār nelikt, bet ja nebūs tad man lineārā enkodera ar interpolāciju arī nebūs  ::

----------


## zzz

> tai izšķirtspējai zūd jēga jo tos processus tāpat nevar ietekmēt ātrāk par 1ms (motoriem) kur PID rēķina ar 1khz un viss advancētākajām elektronikām to  PID rēķina ar 10Khz, līdz ar to tā enkodera super ātrumam jēga nav liela


 epi, tu atkal miikstojies. Vispirms gigaflopiigo DSP nomuljljaaji, tagad ar ADC minstinies. Shitaa var aizrunaaties liidz tam ka pat fpga uuber aatrumiem CNC robotaa jeega nav liela un kas tad vispaar paliks paari no milzu projekta, ko?

----------


## dmd

LPT ports :-)

----------


## Epis

vispār apskatoties pagātnē tad līdz šim vēl nav bījis tā ka es PCB plati esu uztaisījis ar pirmo reizi, tākā šajā gadījumā diez vai būs savādāk un pirmā PCB būs tāds protatips kļūdu meklēšanai un tad moš jāiemēģina tas Diferenciālais ADC THS1007 un + arī 4kanālu DAC AD5306 5.2$. 8 kanālu DAC priekš testa būs pa daudz jo nebūs kur pieslēgt un tad redzēs kas labāks kas sliktāks.
ja runā pa to diferenciālo signālu tad nav īsti saprašana kā viņam to opamp buferi taisīt

faktiski tas super ātrums ir vajadzīgs lai tos soļa signālus ģenerētu ar to virs 100Khz frekvenci līdz 1Mhz, un tagat es esu atradis ka to var mierīgi izdarīt ar NAND flash atmiņu, pirmstam ar mazo NOR flash atmiņu man vaidzētu tās signāla vērtības pašam rēķināt tad patiešām vaidzētu to GFLOP proci+ lielu 512Mb SDRAM buferi, jo matemātika tur ir tāda pasmaga, bet nu tas PID arī nav nekāds vieglais algoritms un pie tam 4 motoriem ej un uztaisi to atriezenisko saiti + ar tām visām monitoringa un pielabošanas funkcijām kas faktiski ir galvenais ko es gribu uztaisīt.

----------


## Mosfet

Epi man īsti nav saprotams kā tavs tas sinusa ekonderis darbosies? Jo tad varēsim noskaidrot vai vajag diff ieeju un opampu. Iedod shēmu un pamatprincipu.

----------


## Epis

pagaidām man ir šitas Fotopārtraucējs ITR9904 un pie emitera ir pieslēgts 2,2K un 1,5K rezistori kas iet uz Zemi un starp viņiem ir vads kas ir SIN vilnis kurš pēc bildes iet Comparātorā un tad iekš FPGA + tur arī ir lodētais DAC  ::  
 
rezultātā dabūnam Sinusa vilni no 0-5V(vai manā gadījumā ar rezistoru dalītāju laikam no 0-~3V  to signālu varētu tālāk ielikt kādā Opamp bufferī, vai pārfeidot par Diferenciālo (ja vadu garums būs liels) un tad uz Plates digitalizēt. 
Es protams nezinu kā ir industriālajiem enkoderiem, laikam viņiem iet ārā diferenciālais signāls, un tas noteikti ka ir dažādos voltu līmeņos ir laikam tādi kas iet uz 5v, 12V, 

šeit bilde no rezultāta DAC+comparātors vinīgi es nezinu vai tas ir ar FPGA+comp, vai Atmega8 ar iekšējo COmp, vai FPGA+LVPECL comparātoru, uz bildes faila tas nav rakstīts un esu jau aizmirsis
[attachment=0:rk1iu3jn]FT-DAC-PWM-oscil bilde.JPG[/attachment:rk1iu3jn]

----------


## Mosfet

Sapratu tavu domu, neredzu vienīgi to bildi.

 Analogo signālu pārveidot diff signāla nav vienkārši ir speciālas mkrenes, bet es savos  esmu attteicies no diff ( arī citi atsakās no diff) projektos lietoju sprieguma pārveide vai nu frekvencē 0-5V (1-10 vai 100 kHz) tālaķ vai nu parastie vadi vai gaismas vadi, stŗāvas cilpā 4-20 mA, vai tas uz vietas tiek digitalizēts. Ir vel citas metodes  bet to publiski neapsriedīsim. Man personīgi patīk analogo lielumu pārveide frekvencē un tālak caur ieejas buferi uz FPGA. 
Vienīgi sīnusa signālam ir liels trūkums pie virsotnēm un kritumiem ir zema izšķiršanas spēja tāpēc  būtu jālieto divi kas nobīdīti par 90 grādiem .

----------


## zzz

Mosfet, epis savos paladzinjos murgoja par nanosekundeem un desmitiem megasamplju, taalabad piedaavaajums paarveidot frekvencee ir galiigi garaam prieksh vinja plaanotajiem domas lidojumiem.

----------


## Epis

Man arī ir tāda doma vienam enkoderim likt 2 fotopārtraucējus ar nobīdi 90grādi (vai +-) iemesls ir vienkārš lai varētu noteikt kustības virzienu apmēram tā kā kvadratūrajiem enkoderiem.

Es te tā domāju un matemātiski parēķināju tad teorētiski varētu arī pietikt ar kautvai 125ksps ADC, jo pats Sinusa vilņa ātrums man reāli nepārsniegs nekad 10Khz frekvenci piemēram ja man ir izprintēts disks ar 80melnbaltām līnijām un tas veido 40 sinusa viļņus un man MAX motora ātrums ja ir 3000RPM tad sinusa viļņa frekvece būs 2Khz
un ar 120ksps es varēšu noņemt 60 proves vienam tādam sinusa vilnim un pie tādiem ātrumiem to precizitāti nevaig, galvenais lai zinātu cik ātri tas motors griežās, un ja tie ir reāli 3000RPM tad gribēt piemēram es zināt viņa griešanās ātrumu ar izšķirtspēju 0,1RPM līdz ar to lai to noskaidrotu man vaidzēs kautkādu taimeri kurš skaitītu līdz 30'000  un ar ātrumu 120Ksps es varēšu noteikt motora ātrumu ar precizitāti 0,1RPM ar frekvenci 4hz protams ja precizitāti samzina 10X tas ir 1RPM tad frekvence būs 40hz, un pastāv arī iespēja noteikt aptuveno ātrumu ar lielāku frekvenci, vārdsakot kautkā jau izgrozīties varēs,
otrs ir pozīcijas noteikšana un šeit problēmu nebūs, jo ar ADC jau parādīs cik tālu enkoderis ir aizgājis un ja viņš būs pagājis par kādiem 20 soļiem tad to matemātiski skaitīs klāt pozīciju up/down counetim un būs zināma absalūtā pozīcija, apmēram tas ir tas pats kā izmantot Optisko peli, kas ik pēc kāda laika intervāla 1-2khz izdod ārā pozīcijas nobīdi x,y asīm un man tās vērtības būs ar 120Khz ātrumu kas ir daudz daudz labāk par krutāko Lāzer peli.

Laikam vaidzēs 8 Opampus jo TLV1570 ir imput impedence  718 omi
teorētiski sanāk ka ar diviem TL084 opampiem varētu pietikt vienīgi tur vaidzēs laikam Negatīvo strāvu (-5V) lai viņu vispār varētu darbināt, jo pagājšos eksperimentos viņš man tā arī nestrādāja. 
šeit viņa Load resistance grafiks
[attachment=0:3cj62nhw]TL084- Outputvolt_VS_LoarResistance.JPG[/attachment:3cj62nhw]
nevaru atrast parastā LM324 opampa to Load resistance grafiku, ja tas būtu normāls ta es labāk ņemtu to jo nevaidzētu negatīvo barošanu  ::

----------


## Epis

Un vēl jaunā plate būs jātaisa tā lai visas SMD detaļas lodētos no augšpuses + domāju izmantot krutākus Rezistorus tas ir tādus kur vienā iepakojumā ir no 4-8gabali  ::  maksā maz ~0,1$ 
un to pašu ar kapacitātoriem piemēram 0,1uF 4vienā pakā pa kādiem 0,14$ 1206 iepakojumā  ::  

galvenais bonus ir tāds ka es varēšu piemēram uztaisīt tādu footprint kur kapacitātors pielodēsies ar 2 malējām kājām un zem viņa līdz ar to varēs izvilkt 2 signāl līnijas  ::  un galvenais ka jālodē 1 detaļa 4vietā(4X efektivitāte), vai divu vietā un tākā vidējiem kājas nekur pielodētas nebūs ta viņas salodēs ar alvas piku kopā pie malējām  ::  

+ ar kapacitātoriem šitā es dabūšu lielāku kapacitāti un galvenais ka mazāk jālodē, pietiks ar kādiem 4-5 gabaliem uz visu FPGA (16-20 kapacitātori pilnīgi pietiek), ar šito problēmu lodējot tās sīkās detaļas es jau saskāros pēdējā PCB tur otrā pusē ir čupa ar 0805 rezistoru vietām un tās aizņem tomēr baigi lielo PCB laukumu. 

Tākā jaunā PCB būs ar jaunām progresīvām idejām, lai mazāk jālodē un lielāka kvalitāte + mazāk detaļu, es to visu daru jo man vienkārši ir slinkums tik daudz lodēt.

----------


## Mosfet

Kā tu doma pāraidīt signālu no ekodera uz savu elektroniku , ja raksti ka būs gari vadi?
Op past ne Lm358 ne tl08X nav precīzie.
TLV1570  tā iekšējā ref ir švaka uz temp dreifa 100 ppm/C un plus vēl tā zemā impendance radīs lielas problēmas.

----------


## Epis

> Kā tu doma pāraidīt signālu no ekodera uz savu elektroniku , ja raksti ka būs gari vadi?
> Op past ne Lm358 ne tl08X nav precīzie.
> TLV1570  tā iekšējā ref ir švaka uz temp dreifa 100 ppm/C un plus vēl tā zemā impendance radīs lielas problēmas.


 Ko domā Mosfet par TLC08x sērijas Opampiem (tie ir laikam jaunāki par TL08x)  tam ir 10Mhz Bandwidth un Outputs sink,sorce 57ma un šeit impedence grafiks un tam ir 4opampu pakaTLC085 maksā 2,2$ nav nekāds lētais un šitas single supply no 4,5-16v tākā varētu būt tīri labs ko ?? 

Tas impedence lielais ir tas kas rada bažas, jo skaidrs ka pats fototranzistors tādu jaudu padot nevar.

vada garums varētu būt kādi 2metri-3m, moš to Opampu vaig likt pie paša sensora tad pa vadu plūdīs lielāka strāva un gļuki varētu būt mazāki, un galā pie paša ADC varētu pielikt kādu 1komu pull down rezistoru, lai tos gļukus noņemtu, jo ADC jau ņems to strāvu perjodiski ar maziem impulsiem un tad varētu kautkādi brīnumi notikt kad vads nav noslogots. 

[attachment=0:1h6uxb6k]TLC081a  Opamp Impedence grafiks.JPG[/attachment:1h6uxb6k]

----------


## Vikings

> moš to Opampu vaig likt pie paša sensora


 Aizmirsti par attālinātu opampu no sensora. Ņemot vērā, ka turpat blakus tiks grozīti vairāki soļu motori un špindelis tad analogais signāls būs pilnīgi nelietojams. Labāk taisi kā jau reiz gribēji taisīt - maksimāli tuvu pie sesora analogā daļa (obligāti ekranēta), ADC un procis/PLD, kas ADC mērījumu pārvērš kvadratūrajā vai da jebkādā citā ciparu signālā, kuru mierīgi var raidīt pa vadiem.

----------


## zzz

Ak shausmas! Bet, bet... tad jau sanaak ka uz milzu fpga plates vispaar nekaads simtiem megasamplju 32 kanaalu adc nav jaaliek. Ek, taadas idejas epim sabojaajaat!

----------


## Epis

njā tāda doma agrākā bīja, bet tad otrā galā vaidzēja mikreni ar ātru ADC konvertieri, teorētiski tas ARM7 procis varētu derēt tam ir 400Ksps ADC ar 10bit izšķirtspēju un es jau esu viņu nopircis pa 3,15$  ::  un tad varētu sūtīt datus pa seriālo interfeisu man liekās ka tam LPC2101 MAx clock bīja 10Mhz seriālajam un tad varētu, sūtīt visāda veida informāciju uz fpga un uz ARM proci lai tas tur regulē tos enkodera aprēķinus.

Vispār jau no sākumā būs jāuztaisa tā lai tas viss strādātu uz kvadratūrajiem nekoderiem un tad kautko domāt ar tiem SIN enkoderiem, tākā man liekās ka enkoderu daļā būs jādara tā viens RJ-45 kontakts vienam enkoderim un tajā kontaktā ir 8 vadi un tad viņu nozīme varētu būt tāda
1.GND
2. 5V barošana (priekš enkodera)
3. 5V TTL ieja (enkoder A kanāls)
4. 5V TTL ieja (enkoder B kanāls)
5. FPGA IO (pa taisno) 
6.FPGA IO (pa taisno) galā būs kāds kāds 400 omu rezistors lai nevarētu IO pārslogot un nosvilināt+ trokšņi mazāki) 
7. FPGA IO
8. 3.3V barošanas vads priekš procesora kas nolasīs SIN enkoderi.

3 IO tādēļ lai uztaisītu to SPI komunikāciju datu līnijām SCK, MISO,MOSI varētu tās līnijas noizolēt ar kautkādu iCopler, bet vai ir jēga ?  man liekas ka vaidzēja izolēt ja bija atsevišķi barošanas bloki, bet man tad sanāks ka barošanas bloks būs viens tiem enkoderiem kas atradīsies uz Fpga plates. 




> Ak shausmas! Bet, bet... tad jau sanaak ka uz milzu fpga plates vispaar nekaads simtiem megasamplju 32 kanaalu adc nav jaaliek. Ek, taadas idejas epim sabojaajaat!


 Ej un atrodi ZZZ kādu lētu čipu (zem 10$ kurš varētu nolasīt NAND flashatmiņu ar viņas MAx lasīšanas ātrumu virs 20Mbaitiem/s ar visiem CRC eror check un error recovery.
es zinu ka jaunai AVR32 AP7000 procis to var bet viņš ir kautkā bišķi padārgs digikeyā maksā virs 18$ un ir BGA pakā tākā, labi TI GFLOP procis arī var nolasīt, bet jātcerās ka ar pliku nolasīšanu vien nepietiks vaidzēs arī dekodēt to informāciju un vēl viskautko citu darīt tākā daudzi procesi notiek parallēli viens otram, tad nekā labāka par fpga joprojām nav  ::  
+ nevar zināt kas vispār beigās sanāks līdz ar to jo universālāks čips jo labāk.

ka beigās būs kautkas uztaisīts tad varēs filozofēt kā ko vaidzēja lai to visu padarītu vēl lētāku, labāku utt.

----------


## zzz

> nekā labāka par fpga joprojām nav


 Aga. Taapeec epis ir izgudrojis veel dazhus veidus ka milzu projektu padariit izklaideejoshaaku. Galvenaa ideja ir ka vinsh tak var leekaat no viena fpga razhotaaja uz otru, un ja visu pavilkt garumaa pietiekami, tad pienaaks jauna, veel krutaaka fpga paaudze un protams atkal vecaa plate buus jaamet stuurii un jaataisa uz jaunaakaas. Pa starpaam noder arii visaadi citi siikumi, piemeeram ilgas un mokoshas paardomas cik gigasamplju adc vajadziigs enkodera nolasiishanai.

> nevar zināt kas vispār beigās sanāks 

Latvieshu tautas pasaku par chika kalshanu zini? Visai pamaacosha.

----------


## Epis

> Aga. Taapeec epis ir izgudrojis veel dazhus veidus ka milzu projektu padariit izklaideejoshaaku. Galvenaa ideja ir ka vinsh tak var leekaat no viena fpga razhotaaja uz otru, un ja visu pavilkt garumaa pietiekami, tad pienaaks jauna, veel krutaaka fpga paaudze un protams atkal vecaa plate buus jaamet stuurii un jaataisa uz jaunaakaas. Pa starpaam noder arii visaadi citi siikumi, piemeeram ilgas un mokoshas paardomas cik gigasamplju adc vajadziigs enkodera nolasiishanai.


 Tā ir ideju atlase un no visām trakajām idejām paliek tās idejas kas izrādās viss labākās, bet svarīgi ir tas ka es vairāk vai mazāk esu pārbaudījis visas idejas kas man bīj un to derīgumu, un ja izrādās ka beigās neder tad neder. faktiski visas idejas ir reālas un katrai savs pamatojums kādēļ tā un tā, 
šitas jautājums ir tik smags jo enkoderu veidu ir ļoti daudz un arī datu pārraides veidu ir daudz katram savi plusi un mīnusi un izdomāt visu tā uzreiz nevar, apmēram kā SMD krāsnī parādās visādi jauni nebījuši faktori kā IR staru ietekme, un šeit ja laistu analogo signālu pa 2metru garu vadu tad būtu visādi trokšņi un nezināmie X faktori, kas visu bojā un čakarē, līdz ar to vienīgais veids kā to visu uztaisīt trokšņ noturīgu laikam ir digitalizēt uz vietas, labi ka vikings šito atgādināja, jo es pats bīju piemirsis, bīju ieciklējies uz lētumu, jo tā digitalizācija uz vietas nav neko lēta, (atsevišķa PCB plate mikrene+opampi) 

Tik bieži es tās mikreņu firmas nemainu ar šito ALteras fpga es ņēmos kautkur ap 1,5gadus salīdzinot cik ilgi PIC programmēju tie bīj kādi 2-3 mēneši un tad AVR kādi 4-6mēneši kamēr pārgāju līdz FPGA, un kā redzi fpga ir noturējusi manu intresi veselus 1,5gadus, un lattice fpga noturēs domāju ka vairāk kā 1,5gadus moš kādus 2 gadus.  ::  jo viņiem ir krutas mikrenes. 
+lttice jaunākā XP2 mikrene vēl nemaz nav parādījusies Mouser.com pārdošanā !! faktiski tā ir tāpate ECP2 tikai viņai ir Flash atmiņa no kuras mikrene masīvi paralēlā veidā ļoti ātri iekonfigurējās mazāk par 1ms, līdz ar to šitā paver jaunu Lētumu un PCB izmēra samazinājumu jo nevaig Flash atmiņu ārējo  ::  šitā ir pagājšā gada labākā inovācija fpga pasaulē tākā   būs vēl jāskatās.

----------


## Mosfet

Nu ko lai saku par to TLC08X 
Uzlabots temperatūras dreifs samazināts ofset un ari josla ir platāka. Viss nosaka ko tu gribi, bet vajag skatīties uz precizajiem opamp. Op2xx sērija.
No mana viedokļa 4 op viena korpusā ir nepraktiski labāk 2 x2  nekā viens 4 opamps rodas problēmas ar plati.
Ar to zemo ieejas impendanci ADC tev būs problēmas.

----------


## Epis

Skaidrs par tiem Opampim iespējams ka pāris gabalus nopirkšu priekš Sin enkodera kuru laikam digitalizēs mikrokontrollieris ar ADC konvertieri ( vaig tādu kas ēd maz energījas ir miniatūra un ar ātru ADC, man liekās ka 16bit MSP430F20xx būs īsti laikā un tur ir tas USB stick modulis pa 20$ + 10$ 3plates piespraužamas  ::  tai mikrenei ir 200Ksps 8kanālu ADC un kopā tikai 10 IO vadi jo čipam ir tikai 14kājas.msp430f2002 čips maksā ap 2$ vairumā 1$
es nezinu vai ir kautkas labāks lētāks microchipam, atmelim toč nav to es zinu.mikročipam laikam ka arī nebūs jo viņu 16bit mikrenes maksā digikeyā no 4$ un viņām ir 1Msps ADC bet nu tas ir 2x dārgāk. a 8 bit PICus es kodēt asmā atsakos.

Sāku taisīt PCB uz jaunās Pads2005, un likšu lai plati velk Autorouteris  ::  (man pašam jau tā celiņu vilkšana ir pieriebusies it sevišķi pēc pēdējās PCB BGA čipa vilkšanas, vairāk es neko vilkt negribu.

----------


## Epis

uztaisīju pirmo shēmu IO izejām tā ir RJ-45 legzdas 4vienā kontakti un attiecīgi 3 74HC541 buferi divi ir izejošie un 1 ienākošais līdz ar to sanāk ka uz 1 RJ45 kontakta ir 4izejošie un 2 ienākošie kanāli + 5V un GND (vienīgi šitie kautkā zīmējumā neparādījās un nesavilkās. 

un šeit bilde kā Velk Pads2005 Autorouteris  ::  (via izmērus nebīju uzstādījis nekādus tie ir defaulta izmēri) 
var teikt ka visu savilka smuki un pa īsākajiem ceļiem pāris sekunžu laikā (man aizietu kādas 10 minūtes), un ieregulēt viņu varēja tīri ātri ja visus parametrus liek uz 0,25mm tad pāris klikšķus vaig. 
Vis grūtāk bīja uztaisīt to RJ-45 lielo 4ligzdu kontakta footprint(šitajā programmā to sauc par decal(uzlīme)) 
Vispār oroga ir baigi labā un ar viņu ir vieglāk strādāt nekā ar Pcad2004, man vismaz tā liekās.

----------


## Epis

Ir tā ka man tagat radās jauni argumenti kādēļ tomēr vaidzētu labāk ņemt Ciklon3 nekā ECP2 un tie ir tādi: 

1. Ja es FTDI čipa vietā (4.1$) izmantoju AT90USB82-16MU 3,2$ USB čipu ar super minī 5x5mm 32-QFN iepakojumu  tad faktiski detaļu kopējais skaits ciklonam3 un ECP2 mikrenei ir pilnīgi vienāds, jo tagat ciklonu iekonfigurēt varēs AT90USB82 kurai ir divi SPI porti + USB ports līdz ar to sanāk SPI vadi priekš SPI Flash atmiņas, Seriālās Fpga konfigurēšanas, + atsevišķi USB pieslēguma vadi, un vēl nemazsvarīgi ir tas ka es varu izmantot šo AVR proci arī AES drošības atslēgas šifrēšanai jo kodam vieta pietiks kā nekā čipam ir 8Kb flash atmiņa  ::  

Tātad AT90USB82 pildītu šādas funkcijas: 
1. USB komunikācija
2. FPGA konfigurācija no SPI flashatmiņas 
3. AES šifrātors drošibai un pret kolonēšanu.

tālāk es lasot,pētot un instalējot LAttice ispLEVER starter progu noskaidroju to ka šī bezmaksas iesācēju versija kā visas ir bišķi limitētas, bet kas svarīgi ir tas ka viņā nav atbalsts ECP2S čipam (S-secure ) līdz ar to lai izmantotu to Drošo mikreni vaig pirkt licenzēto progu a tā maksā 695$  ::  tākā faktiski beigās sanāk ka Nios II procesora licenze(500$) man izmaksātu lētāk nekā ispLever programma.

Vēl viens mīnus ko atklāju ir tas ka tai 11$ ECP2 6000Lut fpga tomēr ir ļoti maz RAM atmiņas faktiski tur ir tikai 3 RAM bloki katrs 18Kbiti kopā 54Kbiti, tas praktiski nav necik knapi sanāk Latticemicro32 procesoram atmiņa, jo nu nekādu lielo kodu nevar uzrakstīt ar 1.5Kword(32biti) atmiņu, un vēl man to RAM atmiņu vaig NAND flash bufferim kur jāveic CRC eror check un tad nāk vēl Motora signālu FIFO bufferi, un fakts paliek fakts ka man vaig stipri vien vairāk RAM atmiņas nekā tās ir ECP2-6, normāla atmiņa ir ECP2-12 tie ir 12 RAM bloki kopā 221Kbits ar to man pietiktu tikai tas čips maksā 20$, savkārt Ciklon3 5000 un 10000LE čipiem ir 9K RAM bloki un to tur ir 46bloki kopā tur ir 423,936 biti kas ir 2x vairāk kā ECP2-12 tākā laikam tomēr būs jāpaliek pir ciklona3.
+ mazāki ceļa izdevumi un nav jāmācās jaunas programmas  ::  

Re kā beigās izrādījās ka tāpat nekādu labāka, lētāku sistēmu  par 65nm Cyclone III uztaisīt tomēr nevar, Lai gan sākumā likās ka var bet dziļāk iepazīstot ECP2 mikreni un programmas izrādījās ka tas ir vēl dārgāk. pa programmām tad varētu kautkad iemēģināt ielikt to Open sorece latticemicro32 proci iekš fpga, ja kas man liekās ka es kādu laiku atpakaļ nokompilēju LatticeMicro8 mazo procesora VHDL kodu uz savas ciklon fpga, vienīgi es viņu nekodēju un neprogrammēju iekš fpga toreiz es tikai apskatījos kā viņš uzbūvēts.

----------


## malacis

Tas priecē! Citādi es jau nobijos, ka Ciklons nokļūs miskastē  ::

----------


## Epis

Vairāk es neko jaunu tagat nedomāšu un uz cnc kontrolliera plates stāvēs:

1. EP3C5 144PQFP pakā, vai EP3C10 (vertikālā migrācija tilpuma palielināšanai)
2. AT90USB82-16MU   USB +AES+configurācija
3. SPI flash AT26DF081A-SU 1.6$ 8Mb 
4. NAND Flash 8Gb pa 16$ 

Tākā PCB izmēri būs ļoti lieli, dēļ astoņiem RJ45 ligzdām kuru garums kopā būs ap 11cm, un parliks vienkārši liels tukš laukums, kur nekas itkā nestāvēs tad varētu uzlikt eksperimentālu Ethernet PHY 10/100 MII čipu KSZ8721BL  4,6$ + H1112NL Pulse (kautkāds magnētu transfrmātors, lai izolētu Plati no interneta vada)  šito tā tīri priekš prieka varētu uzlikt  jo ar šito PHY varētu mēģināt uztaisīt kādu no Industriālajiem interneta atablstiem kā SECOS III  un citiem, vispār gribās uzināt dziļāk kā tas internets strādā tādēļ salodēšu vienu PCB ar šādu interneta pieslēgumu. un pārējiem tajā vietā neko nelodēšu, 

Taisīšu kādas 4 PCB, jo 2vas ir pa maz un nākšais ir 4 plates kas ir normāli.
būs laikam jāsāk taisīt.

----------


## Epis

ieliku rakstu savā otrā cncZonas topikā par to savu FPGA motion kontrollieri. nebīju tur neko rakstījis jau vairāk kā 1,5mēnešus, jo nu man tās idejas tik bieži pēdējās nedēļās ir mainījušās ka negibējās neko rakstīt tur kamēr nebūšu īsti izdomājis līdz galam ko kā, arī tādēļ ka angļu valodā rakstīt ir grūtāk un ja es katru savu stūlbo ideju būtu licis gan šeit gan arī tur tad man vispār neatliktu laika domāt un kautko darīt. 

http://www.cnczone.com/forums/showthrea ... 465&page=8

vispār šitas jaunās idejas ceļš ar AT90USB čipu nav no tiem vieglākajiem, jo vaidzēs to USB draiveri VisualC# kodēt un nezinu vēl cik tas būs viegli, vai grūti, itkā kautkādi programmu paraugi Atmel lapā esot, tākā kas zin varbūt paies mēnesis kamēr iedarbināšu AT90USB čipu un uzrakstīšu Fpga konfigurācijas kodu, vienīgais + ir tas ka Es SPI flashatmiņu varēšu iekonfigurēt pa taisno caur USB izmantojot AVr čipu, un pašu AVR ieprogrammēt itkā arī var pa taisno caur USB tur itkā ir defaultā USB bootloderis tākā būs šis viss laiciņš tā kārtīgi jāizpēta  ::

----------


## Epis

Iemēģināju Pads 2005 shemas uz PDF dokumenta konvertāciju un sanāca vienkārši super tajā PDF uz datu līniju signāliem ir salikti tādi kā hiperlinki un nospiežot piemēram uz kādu signālu lapa aiziet uz otru signāla galu lai redzētu kā tas viss darbojās iemēģiniet paši  ::   vārdsakot superīgs PDF failu ģenerātors ir šai PADS2005 progai  :: 
+ nospiežot uz detaļu parādās dati kas tā par detaļu, kāds ražotājs, vārdsakot visa informācija kas bīj ievadīta būvējot detaļas biblotekas failu, to smuki var redzēt 74HC541 buferim kuru es ņēmu no TI biblotekas tur arī uzrādās Ražotājs, Apraksts iepakojums. baigi kruta   ::  

Tur ir shēma ko esu savilcis līdz šim, labā mala ir tas ko savilku šodien (tur viss izskatās smukāk) un kreisā ir pirmie mēģinājumi un vilkšanas testi un tur protams varēja to visu savilkt smukāk. 
Tur ir savilkti visi vadi starp Motora RJ45 konektoriem 74HC541 buferi un Ciklon3 FPGA IO piniem 
Ciklon3 mikrenes IO ir vairākos blokos sadalīts kopā 5 bloki 4no tiem ir katra ciklona sāns un 5 ir konfigurācijas Pini tie ir U4 bloki barošanas pini ir Defaultā noslēpti, viņi parādīsies tikai pie PCB zīmēšanas.
RJ45 konektoriem ir J2, un U5 nosaukumi un pārējie U1,2,3,5,6,7 ir buferi.
Reāli būs vēl tie signāli jāmaina vietām un jālabo, jo galējais izvietojums būs atkarīgs no tā kā uz PCB stāvēs tās detaļas, šitas ir Apmēram lai redzētu kā viss izskatās pagaidām
[attachment=0:26dixhp2]CNC_plate1.pdf[/attachment:26dixhp2]

----------


## Mosfet

Epi tev tas pads ir demo vai pilna versija un ja ir demo tād kādi ir to ierobežojumi, attiecas uz PCB zīmēšanu.

----------


## Epis

Dēmo versijas ierobežojumus uz PCB vilkšanu es nezinu.
Man nekādu limitu nav, bet es zinu ka dēmoversijām limiti būs, jo kad novilku hiperlynx demo tad es tur varēju simulēt tikai tos paraug failus un vēl pāris limiti bīj, domāju kad Evaluation versijām limitiem nevaidzētu būt, bet tām terminš ir īs kādas 30dienas

visās iepriekšējās plates es tā īsti nemaz shēmas nezīmēju, jo reāli kad uzīmē shēmu un sāc vilkt plati tad tie signāli visi ir jāpārvelk un ja man ir kādi 200 signālu vadi (šajā platē būs rekord liels signālu vadu skaits virs 1000 noteikti) tad ja es viņus samainu vietām PCB zīmējumā reāli shēma, ko uzīmēju shēmu zīmētājā, vairs nekam neder, bet šeit var importēt izmaiņas un fiksi pielabot, līdz ar to parādās jēga zīmēt shēmu, + vēl kādēļ jāzīmē shēma? tādēļ ka bez shēmas nemaz nevar dabūt detaļu iekš PCB vilcēja, bet labums ir tāds ka ja negrib vilkt shēmu tad var nohaltūrēt sametot detaļas shēmu zīmētājā uz ātro pāris vadus novilkt un tad importēt haltūrēto shēmu PCB vilcējā un tur tālāk visus signālus pēc savām vajadzībām vilkt, un pēc tam izmaiņas shēmā pārnest uz nohaltūrēto shēmu, vienīgi tad tā shēma izskatīsies kā vadu mudžeklis, bez datu līnijām un būs totāls haus, tākā viss labāk ir uzvilkt pāris datu maģistrāles (pushaltūrēto shēmu kā es to darīju) un tad kautvai uz dullo savilkt tos signālus un pēctam PCB vilcējā signālus sabīda tādās secībās kā vaig un izmaiņas importē atpakaļ shēmu vilcējā ātri tās pievelk pie datu maģistrālēm un lieta darīta ir gatava PCB un arī smuka PCB shēma

----------


## Epis

Pagaidām esu ticis šitik tālu:  līniju vilkšanai šeit izmantoju sākumā Autorouteri kurš velks 1 līmenī, un liku lai velk nevis visu uzreiz bet pa vienam čipam (pēc manas izvēles) savādāk viņš savelk sūdīgi, jo nezin kuram čipam ir augstāka prioritāte, bet vienalga vaidzēja bišķi pielabot un tur es izmantoju Pusautomātisko režimu kurš var pārbīdīt blakusesošos celiņus (līdz 3 ceļiem. tad liku lai velk 2 līmeņos un proga pabeidz vilkt tos vadus kurus nevarēja izvilkt 1 līmenī un te ir rezultāts  ::  
man tagat šitai platei ir attiecīgs shēmas zīmējums  ::  
plates izmēri ir 120x70mm tas ir apmēram tik cik bīj pirmā ciklon II plate 130x75mm

----------


## Vikings

Nu ja māk tad praktiski visu (ja neskaita PDF failu) tevis nosaukto var izdarīt uz PCADa...

----------


## Epis

Apskatījos Pcad Auto routera sadaļu un tur problēma tā ka ir veseli 5 Autorouteri: 
Quick Route
Pro route 2/4
Pro route
SPECCTRA
Situs 

Problēma bīj tur ka neviens tur īsti neko nevilka vismaz uztādīt es nevienu no tiem nevarēju, un dokumentācijas arī nekādas par tiem routeriem, es toreiz ka Pcadu mācījos nedēlu vai pat vairāk tur čakarēju tos autorouterus katko sāka vilkt, bet tā arī neko normālu strādājošu nedabūju, bet ar šito PADS pavisam cita lieta viss strādā un nedēļas laikā var normāli visu iemācīties un tas arī ir svarīgākais ka šito es varu iemācītes, bet ar Pcad nekas nesanāca.

A tu Viking esi kādu notiem Autorouteriem iemācījies uzstādīt lai viņš normāli varētu plati savilkt ??

----------


## Vikings

Gadus divus atpakaļ palaidu autorouteri, šo to iemācījos par iestādījumiem, bet tā sakarīgi es viņu nelaidu, jo vairāk uzticos pats sev. Starp citu, Epi, ir ļoti laba grāmata krieviski, kur autorouteri aprakstīti, bet tā arī neesmu viņiem ķēries klāt. Kad būs kāds brīvāks laiks tad arī varbūt paskatīšos kas tur un kā. Vienkārši man pašam ir slimīgas prasības lai plate būtu ne tikai forši iztrasēta, bet arī forši izskatītos.

Starp citu, iečeko šito saitu, varētu interesēt: http://www.brandner.ee/

----------


## Epis

> Vienkārši man pašam ir slimīgas prasības lai plate būtu ne tikai forši iztrasēta, bet arī forši izskatītos.


 Man ir tā pat ka gribās visu tā baigi čotka sataisīt, un šitajā zīmējumā ko savilka autorouteris vaidzēs manuāli  pielabot, bet te man patīk ka tas labotājs arī ir tāds pusautomāts un var pabīdīt līdz pat 3 bakusesošajiem celiņiem Pcadā tie ir tikai 2vi celiņi, kruta ir tas ka var ja sākumā fiksi savelk plati ar autoruteri var uzreizi redzēt visu situāciju kopumā un tad var sākt domāt par pielabošanu, vecajā vairantā pagāja 2 dienas kamēr savilku visu plati un tad varēja sākt optimizēt un tas prasa vēl pāris dienas, tākā ar sīto progu es tagat sev ietaupu baigi daudz laika  ::  
+ arī shēmu editors ir labāks un tā shēmas labošana, jeb izmaiņu ielikšana strādā tīri normāli, līdz ar to ir vieglāk uztaisīt shēmu un taisot shēmu nav jāodmā kādā secībā Datu līnijas Kājas slegsies savā starpā un kā tas izskatīsies PCB zīmējumā. 




> Starp citu, iečeko šito saitu, varētu interesēt: http://www.brandner.ee/


 Izskatās baigi labā firmā Esi kautko tur pasūtījis ?? labi tas kad viņi tur var daudzslāņu plates uztaisīt un arī Blind VIA. 
Par to Hobby elektroniķu viņu piedāvājumu domāju ka pie ALMIKO būs lētāk taisīt parastās plates, bet ja vaidzēs 4līmeņu tad varētu pie igauņiem.

----------


## Epis

Par pašu CNC kontrollieri tad varētu arī uztaisīt tā kad mana Plate ieraksta STEP/dir signālus no Kompja LTP porta, un tad protams reproducē, vai arī tajā pašā laikā kad signālu ieraksta viņu padod ārā un darbina pašu CNC iekārtu tikai ar nelielu laika aizturi, un tad piemēram ja notiek kādi sūdi kāds motors sāk bremzēt un nevar pavilkt tad iekārta strādās no Flash atmiņas satura, bet kompis turpinās sūtīt progu itkā nekas nebūtu noticis, un pēc tam var vispār kompi atslēgt un laist autonomā režīmā, faktiski šitā bīja mana pate pirmā IDEJA kurai kodu es uz Atmegas128 raktīju, toreiz es apskatījos Oscilā un ieraudzīju tos step signāla gļukus kurus kompis dod ārā un tālāk vairs neko netaisīju, bet tagat kompjiem ātrums pieaug un Tās DOS CNC progas kā TurboCNC pēc vikinga teiktā strādā stabilāk nekā tās kas iet zem Windows OS tad šāda ierīce būt tehniski iespējam ar nelielu digitālo signāla filtru, pret gļukainiem step signāliem. 

Vārdsakot ar šito jauno Plati varēs mēģināt visādus variantus jo tur būs viss nepieciešamais lai spraustu klāt motoru draiverus un enkoderus jo ieju skaits būs pietiekams arī priekš LTP porta signāliem, jo kopā pa 8 RJ45 kontaktiem būs 24 iejas un 24izejas kas saslēgtas ar 6x8ch 74Hc541 buferiem tākā varēs caur Ltp portu saņemt 6 motoru step/dir +nolasīt 6enkoderus un vadīt ar step/dir kautvai 12 motorus (bez problēmām jo tā ir fpga, taimeru, signāl dekoderu pietiks visiem ). 
ja man paliks kāda brīva Io līnija tad es viņai ielikšu buferi un taisīšu viņu kā input. 

Jātaisa pārējo detaļu biblotekas faili, un jāturpina shēma zīmēt  ::

----------


## Epis

Nu tā esu pievienojis Flash atmiņu un arī uztaisīju USB čipa komponenti shēmā viņu var redzēt, bet PCB detaļa ir bet nav redzama  ::  

uz šito brīdi ir palikuši pāri tikai 12 IO tehniski vaidzētu 2 IO vadus savienot ar AT90USB SPI līniju (viens vads jau būs savienots Data0 konfigurācijas līnija tad kopā sanāks 3 vadi priekš SPI), lai pēc iekonfigurēšanās vismaz kautkāda komunikācija būtu iespējama (priekš AES drošības šifrātora  :: 
Pāri paliek 10 IO 
interneta čipu pieslēgt es nevarēšu un tad vienīgi atliek  pieslēgt kādas 2 diodes (kā indikātors ka plate strādā) un varētu pārējās 8 līnijas uztaisīt kā iejas caur 74Hc 541 buferi un parasto Header 10pin konektoru, gadījumam ja pietrūks ieju IO  :: 

Vēl būs laikam jāliek visiem no fpga izejošajiem signāliem pie fpga kājām kādu 220 omu rezistoru 8x matricas, lai varētu izmantot LVds 3.3V singālus vismaz ar defaulta 8ma curent strength, faktiski tas vairāk priekš drošības jo defaultā Quartusā pie LVDS stāv tāds IO stiprums, un tad rezistors atrisinātu šito problēmu

[attachment=0:e82q8p3y]CNC_plate2_ar_Flash.pdf[/attachment:e82q8p3y]
[attachment=1:e82q8p3y]PCB_C3_Flash.JPG[/attachment:e82q8p3y]

----------


## Epis

Visu dienu meklēju, pārskatīju DC-DC konvertierus priekš fpga. to darīju jo kopš pēdējās reizes ir jau pagājis daudz laika, kāds pus gads kad no digikey kautko pirku, un tā pa lielam nekas jau nav mainījies neko labāku, lētāku par savu FAN2001 regulātoru atrast nevarēju, bet tomēr vienu lietu gan es atradu baigi labo tas ir Murata MPD4S014S 3 izeju barošanas bloks šeit bilde no viņu lapas 

efektivitāte 75% iejā var laist no 4.5-13V un 1 izeja ir fiksēta 2.5V viena regulējama no 1V-3.3v un vēlviena regulējama no 1.8V-3.6v Faktiski šitas bloks ir speciāli taisīts priekš FPGA čipiem tā tur ir rakstīs "Great for FPGA App." 
digikeyā viņam cena stāv 4.6$ bet pagaidām viņu vēl nepārdod (non stock) un iespe'jams ka pēc kādiem 2 mēnešiem sāks tirogot.
Es tā parēķināju tad man 2vi FAN2001 + 1 Tlv1117 LDO regulātors, ar visiem kapacitātoriem, induktoriem sanāk 4.68$ faktiski tas ir tik pat cik tas viens Muratas integrētais barošnas bloks, tākā ekonomiski izdevīgāk viennozīmīgi būtu izmantot tādu bloku.
Vēl atradu lētākus 10uF kapacitātorus viens gabals 0.1$ (100gab.apjomā) un lētāku SMD induktoru 3.3uH 690mA 160.0 mOhm 0,24$ (10gab.apjomā) 
pirms pus gada es induktoru (900ma) pirku par 0,64$ un kapacitātorus par 0,44$ tākā šis tas ir palicis lētāks  ::  + šitām jaunajām detaļām ir mazāki izmēri.

----------


## Epis

Laikam būsū izdomājis līdz galav visu barošanas sistēmu un tā sastāvēs no 4 DC-DC regulātoriem: 

1. L5973D ieja līdz 34V izeja būs 5V 2.5A 12.5 W jauda faktiski šito es lieku, lai plate varētu strādāt tad kad nebūs USB pieslēguma, un arī kad būs USB pieslēgums tad protams ar USB 1W jaudu diez vai pietiks, jo es domāju ka tos visus Optiskos enkoderus vaidzēs barot no šitās plates un tad ar 12.5W vaidzētu pietikt visai elektronikai kas slēgsies klāt jo katram RJ45 kontaktam būs 5V barošanas vadi no kuriem ta varēs ņemt to jaudu  
vispār šitas barošanas bloks man izmaksās ļoti dārgi kopā L5973D(1Ls ormixā) + 15uF 2.35A Ekranēts induktors 1$  un īstais Low ESR 330uF 24mOhm kapacitātors 1.5$  izmaksās jau 4.5$  tas ir tik pat cik pārējie 3 DC regulātori kopā   ::  un es vēl neskaitu klāt pārējās detaļas kā diodes, sīkos kapacitātorus, rezistorus un tādā garā tie sīkumi maksās.
Ierpiekšējā reizē atceros ka no digikey pasūtīju neīstos kapacitātorus tie bīj lētie pa 0,5-0,4$ domāju ka ir Low ESR a izrādījās parastie un tā starpība starp Low Esr un parastajiem ir protams pretestībā un Rated ripple current
(mArms/100k to 300kHz) parametrā  un man tagadējam kapacitātoram tas ir 3770 mArms, bet tiem lētajiem ir kādi 400-600mArms līdz ar to lai dabūtu to pašu efektu vaidzētu kādus 5 lētos kapacitātorus kā ar vienu dārgo 

2. FAN2001 regulātrs kas no 5v taisīs 3.3V 1A  šeit visas pārējas detaļas induktori 0.24$ un kapacitātori 0.1$ ir sper lēti salīdzinot ar pirmo barošanas bloku.
3. FAN2001 reg. no 5V uz 1.2V 1A 
4. TLV1117-25CDCYR no 5V uz 2.5V  800ma priekš Cyclone III VCCA (PLL barošanas bloks lai vispār mikreni varētu palaist) 

Kopā plates barošanas sistēma izmaksās ~10$ faktiski tik pat cik Fpga mikrene

Un Tagat aprēķinot cik vispār kopā visa mana tagadējā Ciklon 3 CNC kontrolliera plate izmaksās sanāca 50,34$ reālā cena latvijā būs par kādiem 30% lielāka (atvešana PVN) tas sanāks 65$ par plati Pēc jaunā valūtas kursa sanāk 30Ls   ::   tā tīri normāli var teikt ka būsū ielicies 30latu robežā, un šai cenai mierīgi var likt vēl klāt 10Ls kuros būs visi pārējie izdevumi, tākā 40ls būs plates pašizmaksa (un pašam jālodē)  

Un no visu detaļu vērtības Fpga čipa cena sastāda tikai 24% tas ir 1/4 daļa tākā tas nav tik daudz kā varētu likties, nezinu cik tāda sistēma varētu izmaksāt ar līdzīgu finkcionalitāti bez fpga, ar kādām 8,16,32bit mikrenēm, skaidrs ir uzreiz viens kad ar 1 mikreni būtu stipri par maz, vienīgi tādā gadījumā ja izmantotu papildus CPLD priekš enkoderu kanālu dekodēšanas un arī NanD flash kartes interfeisa, tākā diez vai ir kautkas labāks par fpga šajā situācijā.

----------


## Epis

Šeit jaunā PCB versija, atšķirās ar to kad es nomainīju vienu RJ45 4x konektoru uz D-SUB25 priekš Step/dir signālu izejas, lai pa taisno varētu slēgt klāt savam xelotex draiverim un arī uzliku vēlvienu LTP kontaktu, lai plati var pieslēgt klāt pie Paralēlā porta un laist parastos Step/dir signālus platē, vēl pieliku tāpat D-SUB9 kontaktu kur ir 4 izejas un 4 iejas (tie bīj atlikušie signāli gan jau ka noderēs. 
Uztaisīju platei citu izkārtojumu, tā lai aizņem mazāk vietas, vēl jāuzliek uz plates USB ligzda SPI flash un AT90USB čips + 4 barošanas blokus + konfigurācija, un tad varēs redzēt cik kas vietas aizņem un kā to visu savilkt  :: 
[attachment=0:32s6jrn6]PCB_C3_ar_LTP_izkartojums.JPG[/attachment:32s6jrn6]

----------


## Vikings

Galīgi vairs nesaprotu pamatdomu. Ienāk Step/Dir, iziet Step/Dir, kāds tad uzdevums platei? Estop slēdzi uzmanīt? Man liekas, ka motoru ātruma kontrolei šitas nez kādēļ neder.

----------


## Epis

Pamat ideja paliek: visu darīt caur USB, bet tagat var arī uztaisīt tādu variantu ka to visu CNC programmu varētu ieprogrammēt 8Gb Flash atmiņā vienkārši caur pašu LTP portu izmantojot jebkuru CNC programmu un pēc tam slēgt kompi nost un darbināt visu CNC iekārtu, bez kompja no iekšējās Flash atmiņas, tehniski šitādu kodu varētu es viss ātrāk uzkodēt, jo te jau viss ir sen izdomāts (man stāv Atmegas128 ASM kods priekš Step/dir signālu arhivēšanas un ekstraktēšanas tālāk, var likt klāt tos visus pārējos kodus kā PID kontrolli, un visādām fičām, un tehniski pēc tam kad CNC programma ir ielādēta Flash atmiņā caur LTP portu to pieslēguma vietu var izmantot priekš citiem signāliem, kādiem limita slēdžiem,enkoderiem un citiem sensoriem, jo pirms sākt programmas izpildi AT90USB var pārkonfigurēt fpga čipu ar citu konfigurāciju (kādas 3 konfigurācijas domāju ka SPI flash atmiņā saies mierīgi) kur uz LTP porta 12 ienākošajām līnījām ir cita tipa signālu uztvērēju vai interfeisu, un tā beigās sanāk kad manai platei būs vairāk iejas, izjeas kanāli, kopā sanāks 33 iejas un 25 izejas  ::

----------


## Vikings

Epi, ieteikums - padomā cik reizes Gkods aizņems mazāk vietas nekā ierakstīti S/D signāli? Varbūt ir tomēr vērts taisīt sakarīgu vadības bloku, kas māk apstrādāt kaut vienkāršākās Gkoda komandas? Kā nekā paliek iespēja programmu mainīt un citas konfigurēšanas iespējas, kas ierakstītam signālam nebūs iespējamas...

----------


## zzz

Taaaaa, grandiozaa fpga uuberplate ir dovngreidota liidz prasta gramofona liimenim, kursh truli speelees atpakalj solju seciibu un labaakajaa gadiijumaa mazliet kontrolees ar enkodera paliidziibu vai motorchiki patieshaam vajadziigo soli ir izdariijushi.

Zashibis projekta evoluucija.

Nepaies ne paaris gadi un epim atausiis gaisma ka apmeeram taadus pat rezultaatus vinsh ieguutu iesprauzhot savu hipercnc pa taisno datoraa, bez gramofoninja pa vidu.

----------


## Epis

> Epi, ieteikums - padomā cik reizes Gkods aizņems mazāk vietas nekā ierakstīti S/D signāli? Varbūt ir tomēr vērts taisīt sakarīgu vadības bloku, kas māk apstrādāt kaut vienkāršākās Gkoda komandas? Kā nekā paliek iespēja programmu mainīt un citas konfigurēšanas iespējas, kas ierakstītam signālam nebūs iespējamas...


 Man tagat būs iespēja uztaisīt diva tipa programmas vienu kas signālus raksta no LTP porta otra no USB, un ja es sākumā uztaiso tādu kas raksta no LTP porta tad pēctam kad taisīšu to kura raksta no USB mainīsies tikai Flash ierakstīšanas kods, un pārējais kods paliks kā pamats, kuru apaudzēt ar to papildus finkcionalitāti, tākā ar USB būs pamatos tas pats LTP tikai sarežģitākā līmenī, un ar USB vēl pastāv 3. programmas tips tas ir kā es domāju pirms pāris mēnešiem tos Step/dir signālus sūtīt komandu formā (G-kodu) un pēc tam signālus ģenerēt iekšā iekš fpga, un kā jau pats teici tad ieguvums no tā ir mazais Flash atmiņas patēriņš, līdz ar to ātrāka programmas ielādēšana, bet pārējās visas lietas paliek sarežģitākas jo būs tie step signāli jā'rēķina (smaga matemātika) un šito variantu varētu taisīt pašās beigās ja vispār būs vajadzība, jo parastajā variantā tos step signālus arī ir iespējams bišķi sakompresēt piemēram ja signālam ir vienāds ātrums kādus 2000 soļus tad es rakstīšu flash atmiņā ka motors 1 iet ar X ātrumu 2000 soļus nevis rakstīšu 2000 soļu 16vai32bit ātruma ciparus, tākā šādā stilā sakompresējot to Step kodu tajos 8Gb flash varēs ierakstītkā minimums 1h un MAX kautvai 1 dienu, ja nav nekādas lielas ātruma izmaiņas un ja sūta datus caur USB tad, protams, būs jāsūta paātrinājums arī šādā formātā, līdz ar to lineārās kustības sanāks jau G-koda stilā iekodētas kas nopietni samazina flash patēriņu. 
Vārdsakot kad kodēšu tad redzēs kas ir reāli un kas nav, jo tagat var darīt visādies ir izvēles iespējas ļoti plašas. un galvenais ka būs reāla plate kur to visu iemēģināt.




> Taaaaa, grandiozaa fpga uuberplate ir dovngreidota liidz prasta gramofona liimenim, kursh truli speelees atpakalj solju seciibu un labaakajaa gadiijumaa mazliet kontrolees ar enkodera paliidziibu vai motorchiki patieshaam vajadziigo soli ir izdariijushi.
> 
> Zashibis projekta evoluucija.
> 
> Nepaies ne paaris gadi un epim atausiis gaisma ka apmeeram taadus pat rezultaatus vinsh ieguutu iesprauzhot savu hipercnc pa taisno datoraa, bez gramofoninja pa vidu.


 Tas kad uzliku LTP porta ieju nepadara plati par kautkādu tur sūdu,viss būs atkarīgs no programmām, vienkārši ieliku, lai būtu papildus funkcionalitāte un izmantotu liekos IO vadus tagat man būs izmantoti virs 95% IO, bez LTP iejas bīja zem 80%

----------


## Vikings

> LTP


 Vai gadījumā ne LPT?




> ja sūta datus caur USB tad, protams, būs jāsūta paātrinājums arī šādā formātā


 Sūti Gkodu un nekāds paātrinājums nebūs jāsūta. Vienreiz izmēģināji, uzstādīji un tāds arī stāv visu mašīnas mūžu.

----------


## Epis

> Vai gadījumā ne LPT?
> ja sūta datus caur USB tad, protams, būs jāsūta paātrinājums arī šādā formātā


 Sūti Gkodu un nekāds paātrinājums nebūs jāsūta. Vienreiz izmēģināji, uzstādīji un tāds arī stāv visu mašīnas mūžu.[/quote]

ā jā bīj LPT, kautkā dīvaini nezinu kādēļ aizgāju uz to LTP?, bet intresanti ir tas ka citi arī štio jauc uzspiedu google "LTP port"un man izmeta čupu ar linkiem par paralēlo portu, protams uzspiežot "LPT port"parādās Wikipēdijā par LPT portu, laikam ka būšu googlējot no LPT pārgājis uz LTP  :: 

par to paātrinājumu tad tā nevar vadīt motorus ar vienu paātrinājumu, vienkarš piemērs kas notiek ja divi motori no 0 x,y galdam paātrinās līdz kādiem 200RPM uz X,Y plaknes tas izskatās kā 45grādu taisne, bet ko darīt ja Frēzei jā frēzē kāda 20,30grādu taisne ? tad katram motoram būs savs paātrinājuma lielums kas būs Proporcionāls šim taisnes abiem lenķim kas ir starp līniju un X asi un pretēji taisne Yase, un tad proporcionālā attiecība starp lenķiem būs jāievēro arī paātrinājumā līdz ar to viens motors ies ātrāk, otrs lēnāk tas pats arī ar paātrinājumu.

----------


## a_masiks

A priekš kam sūtīt soļus, kas sarēķināti reālā laikā un vēl papildus ātrumu, kur ātrums jau arī ir attiecība soļi/laika vienībā? Respektīvi -tiek sūtīti tie paši dati tikai citā formātā un pēc tam acīmredzot tiks veiktas mistiskas matemātiskas darbības, kas rezultātā dzēsīs ātruma komponenti atstājot tikai pārvietojuma un laika vienības komponenti. Manuprāt pietiek izvēlēties vienu atbalsta mērvienību - soli vai sekundi un proporcionāli aprēķināt otru. Ja soli, tad izrēķinātiem un zināmiem soļu skaitiem /kas attēlo nepieciešamo traektoriju/ piemēro mainīgu soļu padošanas laika vienību /takti/, tā iegūstot nepieciešamo paātrinājumu un ātrumu.
Ja laiku, tad vienā elementārajā /pašā mazākajā/  laika vienībā padodam mainīgu soļu daudzumu /izlaižam soļus/ lai iegūtu nepieciešamo paātrinājumu un ātrumu, ievērojot noteikumu, ka soļu proporcionalitāte ievēro traektoriju.
Manuprāt vienkāršāk ir taktēt. T.i - mainīt soļa laika garumu, ierobežojot to ar maximāli noslogotā motora ierobežojumiem. Un ātrums kā parametrs te vairs nav vajadzīgs principā - pietiek ar elementārā soļa garuma /laikā/ izmaiņām. Par cik tas var izmainīties ar katru nākamo soli uz vienu vai otru pusi, salīdzinot ar iepriekšējo soli, un kāds ir mazākais soļa lielums laikā.

----------


## Vikings

A klau, Epi, man ir tāda ideja - uztaisi tādu fīču, kas no S/D signāla māk uzģenerēt Gkodu un sūta to atpakaļ pa USB portu. Moš noderēs.  ::

----------


## Epis

Tā starpība nebūs nekāda īpaši liela ciparos starp ātruma ciparu, piemēram ātruma ciparam minimums sanāk būtu 24biti, jo 16 ir pa maz, un ātruma izmaiņu ciparam man liekās ka vaidzēs būt vismaz lielākam par 8 bitiem, jo būs cipari ar zīmēm +- līdz ar to 8 bitos var dabūt tikai 128 kas, protams, ir stipri vien pa maz, tākā vaidzēs ņemt 16bitus kā minimums līdz ar to starpība ir tikai 8 biti tas ir 33% mazāks Flash atmiņas apjoms, tas domāju ka nav nekāds radikālais uzlabojums. faktisku jebkurš šāda tipa pa taisno datu glabāšanas veids nekādas lielas priekšrocības nedod, vienīgi kas dod to lielo efetku ir tas daļēji dekodētais G-kods kuru es lineārajām kustībām tur Flash atmiņas apjoms ietaupītos (ja es izmantotu max soļu komandai 16 bitu ciparu tad ietaupītu līdz pat 64 000X mazāk Flash atmiņas nekā parasti uz vienu G-koda komandu, un te protams ir jūtama starpība, tākā domājat kā gribat glabājot datus pa taisno bez nekādas arhivēšanas neko daudz ietaupīt nevar, bet tākā man būs 8Gb flasha tad tehniski atmiņas pietiek 1 stundai un var netaupīt, 

Ja tā kritisi padomā vai vispār ir jēga baigi kautko arhivēt (tīri naudas izteiksmē), tad sanāk Tā:
flash 8Gb maksā 16$ un šitā fpga 12.8$ tagat es varu nearhivēt un CNC strādās 1h. kopā 28.8$
ja es arhivēju tad  varu izmantot kādu 38-2Mb Flas 2-3$ bet vaidzēs lielāku FPGA 19.2$ kopā 21.2-22.2$ naudas izteiksmē esu ietaupījis tikai 6-7$ un no kopējās Plates vērtības tie ir tikai 12-14%  tākā vai ir jēga rakstīt to šausmīgo arhivācijas, Ekstraktēšanas kodu un matemātiku ja no tā reāli nebūs nekāda ekonomiska labuma  ::  ar  parasto lineāro paātrinājuma arhivēšanu varētu veikt tur kods ir jau sen zināms un laika tas daudz nepatērēs (man jau ir uz Nios II tas C kods ar visu kvadrātsakni  :: , bet ar tiem Apļiem un Spline līnijām es čakarēties negribu.

ieliku barošanas bloku Shēmas un tagat atliek Konfigurācija un USB piesleģums tad būs visai platei shēma gatava un varēs savilkt, tas būs ātri ar autorouteri un pusautomāti  ::

----------


## Epis

šorīt domāju par tiem barošanas blokiem un to ka viņu ir pa daudz un dmāju kā lai samazina viņu skaitu un vienīgais ko varēju izdomāt bīja to 3.3V līmeni nolaist līdz 2.5-2.625V tad tehniski atkristu tas viens TLV1117 2.5V regulātors, bet nu pie šāda voltu līmeņa sākas atkal citas problēmas tādas kad tie 74HC244 buferi vairs neņem 2.5V Loģisko signālu un sāku pētīt TI Logīkas mikreņu katalogu un izrādās ka ir tādas loģikas, kur Vih (High input voltage) minimālais ir 2V sanāk ka šitas variants man der  tās ir tās loģikas kurām VCC ir no 4.5-5.5V un lētākais variants ir SN74ABT serijas čipi, tālāk es veicu Hyperlinx simulāciju lai redzētu kas notiek ar tiem 2.5V TTL signāliem un bez rezistoriem, var mierīgi laist tos signālus pa 5cm seliņu ar 131omu impedence signāls protams ka lēkās, bet tas nebūs bīstami fpga IO pinam (pāri 4V līmeni viņš nepārleks) līdz ar to šitajā 2.5V variantā faktiski atkrīt šitie 100 omu terminācijas rezistori, kas ir pozitīvi, jo mazāk detaļu jo labāk, bet nāk klāt vēl pāris buferi jo ja AT90USB darbināšu uz 5V tad ienākošajiem 2.6V signāliem vaidzēs buferi jo AVR pie 5V barošanas var redzēt 1 pie 3V līdz ar to vaidzēs laist caur buferi.

Faktiski esu aizgājis līdz tam ko iesaka visi fpga lietotāji tas ir darbināt visus IO uz tiem 2.6V jo tad ir mazāk problēmu un risku.

----------


## Epis

Man būs 2 tipa buferi uz plates vieni kas pārveidos no TTL2.6V uz TTL5V tie būs SN74ABT16244A (tas ir 16 kanālu buferis maksā lēti 0,88$)_ un otra tipa buferi kas pārveidos 5VTTL uz 2.6V tas būs vecais SN74HC541 (8kanālu) 

Uzīmēju uz papīra konfigurācijas shēmu kur ir atēlots kā savienosies AVR,SPIflash un FPGA kopā tur vaidzēs 4 kanālus no SN74ABT16244A un 6 kanālus no vesela SN74HC541, 

kopā saskaitīju ka man vaidzēs 2x SN74ABT16244A un 5x  SN74HC541  ::   faktiski buferu skaits starp veco variantu un šito jauno ir vienāds tur man stāvēja 7 gabali  SN74HC541, un tagat kopā arī sanāk 7 gabali. 
PAskaitīju un tad pāreja no 3.3V uz 2.6V es būšu samazinājis detaļu skaitu uz plates par 8 gabaliem (5 100omu rezistori, 2 10uF kapacitātori, un tlv1117). iespējams ka plates izmēru arī varēs bišķi samazināt  ::

----------


## Epis

Izdomāju līdz galam kā slēgšu klāt AVR čipu pie SPI, un fpga šeit shemas bilde:
OCA0 pins vaidzīgs lai varētu padot Clock signālu kad SPI flash atmiņa būs ielikta Datu sūtīšanas režimā tad es slegšu ārā AVR SPI interfeisu un palaidīšu taimeri kas ģenerēs Clock signālu uz OCA0 pina un konfigurēs FPGA  ::   un brīvajā laikā varēs skatītes kas notiek ar citiem konfigurāciju piniem  :: 
[attachment=0:31j5r1i4]AVR_SPI_fpga_shema-C.JPG[/attachment:31j5r1i4]

----------


## zzz

Mja, liidz Maljeevicha Melnajam kvadraatam epja shemochka tomeer iisti nedavelk.   ::

----------


## Epis

neliels oftops par Soļu motoriem un kāpēc tie ir labāki par servo priekš CNC, negribējās taisīt jaunu topiku.

Atradu pierādījumu tam ka soļinieki ir daudz labāki par servo, ja izmanto servo tipa draiveri ar enkodera atbalstu un FOC algoritmu un atšķirībā no servo steperim PID ātrums ir 40Khz, servo no tāda ātruma jēga ir maza tur ar kādiem 2-5Khz pietiek jo servo vienkārši nevar reāgēt tik ātri kā steperis līdz ar to jēgas no tā lielā PID ātruma nav, un ar to jau es esu pateicis ka steperis ir labāks motors jo viņš ātrāk reāģē un stabilāk seko pozīcijai nekā servo motors tākā tas ir ideāls motors priekš precīzas CNC iekārtas, lai nedomātu ka es te kādas pasakas stāstu apskataties paši šito draiveri ar servo kontrolli 
http://www.fastech.co.kr/English/Ezi-SERVO.html

faktiski visas manas trakās idejas par soļu motora draiveri ar enkoder atbalstu un par PID kotnrolli katram motora solim, ar ļoti augstu PID frekvneci (max45Khz  ir izrādījušās patiesas un protams es to nevarēju pierādīt un tas bīj tā uz veselo saprātu un intuīcuju balstīts, bet man ir liels prieks redzēt ka es esu domāji pareizajā virzienā neskatoties pat uz to ka visi apgalvoja pretējo ! dēļ saviem lielajiem AIZSPRIEDUMIEM.

un vēl Cnc zonā šodien izlasīju ka Maris freimanis no tā Geckodrive arī uzskata ka soļu motori ir daudz labāki par servo ar attiecīgu servo kontrolli (viņš tur taisa tādu steper servo draiveri un eksperimentos tas pierādījās. tākā paties prieks. 

lai slavēts soļu motors  ::   kurš visu laiku tika uzskatīts par sliktāku un sūdu kas nav pelnījis enkodera atbalstu un kārtīgu PID kontroli šitie STEREOTIPI ir jāmaina tagat Steperis ir labākais.

----------


## malacis

Epi, man liekas, ka nu tu esi iebraucis auzās. Kā kapeikpisējam tev būtu jāzina, ka vienādas jaudas soļu motors būs dārgāks par tādas pašas jaudas servomotoru (konstrukcija sarežģītāka). Soļu motors tikmēr ir labs, kamēr nevajag enkoderu - to lieliski izmanto arī _"Maris freimanis no tā Geckodrive"_. Ja pieliek enkoderu, es neredzu vairs jēgu soļu motoram. Kur būtu links uz pētījumu _"ka steperis ir labāks motors jo viņš ātrāk reāģē un stabilāk seko pozīcijai nekā servo motors"_?

----------


## Epis

Zinātniskus pierādījumus man nevaig pietiek ar to ka ir izstrādāts reāls produkts kurš padara to motoru labāku par servo, priekš CNC.
 Tajā Ezi-SERVO linkā ir uzskaitīti 9 punkti kur parāda kāds tam draiverim ir labums pār servo draiveriem.

1. labo pozīcijas kļūdu katru 25mikro sekundi (40Khz frekvence, nēsu redzējis nevienu servo kuram PID tik ātri strādātu).
2. nav jātūnē PID gain vērtības, jo motors pats pa sevīm ir stabilāks, un labu rezultātu var ātrāk sasniegt.
3. stabila 0 ātruma pozīcija, kā zināms tad servo motori uz vietas zem slodzes nevar mierīgi nostāvēt, un visu laiku vibrē, soļiniekam šādu problēmu nav tas stāv mierīgi bez vibrācijām.
4.precīzs ar gludu kustību.
5. Liels reaģēšanas ātrums, dēļ tā ka motoram ir ļoti spēcīgs starta grizes moments un ļoti augsta PID frekvence, kas to padara daudz daudz prcīzāku un kvalitatīvāku par servo.
6.augsta izšķirtspēja, tas laikam atkarīgs no enkodera, bet tehniski ar soļu motoru to izšķirtspēju var dabūt krietni lielāku nekā ar servo jo tas ir 50 polu motors (servo tikai 6 poli) 
7.Liels griezes moments, nav vajadzīgi nekādi zobrati un ātrumkārbas, skrūvē pataisno klāt pie Vītņstieņa ar lielu Soli un lieta darīta.
8.Liels ātrums, soļinieku var iet normāli līdz 3000rpm protams griezes moments būs mazs, bet ātrumu dabūt var, lasīju geckodrive viņi ar savu jauno cheap drive testos grieza soļinieku pat ar 10 000RPM (laikam tukšgaitā)tākā ātrumu var udzīt, bet normāli virs 600RPM neviens soļiniekus nevada pie lielām slodzēm
9. Efektivitāte, jo ar šādu draiveri motors padod strāvu lai bīdītu smagumu līdz ar to motors patērē tik enerģiju cik vaig lai veiktu darbu, un tas nozīmē ka motors nekarst, un ir energoefektīvs (kā servo).

Tie bīj punkti (mana īsā versija tiem kuriem slinkums lasīt angļu valodā) tajā linkā arī ir grafiki. 

Pēc būtības es domāju ka tā soļinieka pārākuma atslēga ir tajā ka tas vienkārši ir 50 polu motors, bet servo 6 polu tātad jau pēc polu skaita motors ir ar spēcīgāku griezes momentu, mazāku ātrumu, bet svarīgā īpašiba ir lielāka stabilitāte + augstāks reaģēšanas ātrums, un tie ir 40Khz kamēr servo tikai 5-6. līdz ar to reaģēšana uz izmaiņām slodzē Pēc tiem PID algoritmiem ir krietni vien labāka un iespējamā novirze daudz daudz mazāka, tas nozīmē ka motors ir precīzāks par servo un labāk piemērotāks precīzām iekārtām.
+ līdzvērtīgas jaudas steperis(bez enkodera) ir par kādiem 30-40% lētāks par attiecīgas jaudas Servo(bez enkodera), enkoderi maksā vienādies gan steperiem, gan servo tākā beigās stepera motora sistēma sanāk daudz lētāk par servo.

nezinu cik tas draiveris maksā, bet tas noteikti nav no lētajiem, tākā ja grib kautko tādu tad jātaisa pašam.

----------


## zzz

Man joprojaam ierosinaajums ieviest forumaa forumaa sarkanaas kraasas briidinaajuma ziimi "Maldinosha informaacija" ar ko markjeet postus.   epis to atrautos vienu peec otra.

----------


## Epis

Es tagat domāju cik reāli ir iespējams kautko no tām super fičām ielikt savā FPGA platē, teorētiski enkodera atbalsts man fpga platē būs, bet pietrūkst pašas informācijas par motora vadīšanu (pinumu strāvas vērtības), tehniski to varētu sūtīt Steppera draiveris (kāda maza mikrene ar labu ADC pa seriālo līniju RX,TX LTP porta kontaktā ir 5 iejas vadi tad sanāktu 4 RX līnijas (datu saņemšana 4 motoriem) un 1 TX datu sūtīšana 4 motoriem, tad tehniski caur 1 LTP porta vadu varētu saslēgt 4 motorus tādā vadības režīmā, protams tad jātaisa arī draiveris, kas darbotos šādā režimā, jo tādus nekur nepārdod.

ielikšu izmaiņas tajā LTP porta kontaktā kur 5 iejas bīja savienotas vienā ar OR vārtiem, tagat tur stāvēs buferi. 




> Man joprojaam ierosinaajums ieviest forumaa forumaa sarkanaas kraasas briidinaajuma ziimi "Maldinosha informaacija" ar ko markjeet postus.   epis to atrautos vienu peec otra.


 kamēr kāds nav pierādījis pretejo ka tas ko es uzrakstīju par soļiniekiem ir maldinoša informācija tikmēr tā ir patiesība, teorētiski neviens nevar šo informācijas patiesumu apstrīdēt jo tas ir netiešs tūlkojums (mana interpertācija) no tā Ezi-SERVO draivera apraksta tākā, tad ir jāapstrīd paša Ezi-SERVO draivera unikālās spējas. 

un varētu strīdēties par maniem secinājumiem ka soļinieks ir absolūti labākais CNC motors, jo katrai iekārta ir unikāla ar savām īpatnībām, bet to ka soļinieks ir lētāks par servo tas ir patiess apgalvojums. (es to pirms kāda pus gada (gada)bīju pētījis un salīdzinājis cenas.

----------


## GuntisK

Ja jau stepperi ir tik fantastiski labi, kāpēc lielākajā daļā industriālo iekārtu un robotu, vēl joprojām izmanto servo? Noteikti, ka njesprosta...

----------


## Epis

Vēl jo projām velku un pielaboju sava jaunā PCB shēmu un detaļu izkārtojumu, jo tā shēma man ir jau tik apjomīga, un sarežģita, ka ir baigais čakars, vispār es nezinu ko es darītu ja man nebūtu šitās PADS205 programmas.

Es tagat reāli jūtu atdevi no tā ka esu pārgājis uz labāku programmu un laiks (nedēļa) ko pavadīju mācoties jauno programmu ir pilnībā sevi attaisnojis jo es jau esu ietaupījis vairāk par 1 nedēļu ja to pašu būtu taisījis uz vecās progas




> Ja jau stepperi ir tik fantastiski labi, kāpēc lielākajā daļā industriālo iekārtu un robotu, vēl joprojām izmanto servo? Noteikti, ka njesprosta...


 Atbilde ļoti vienkārša, jo agrāk tādu draiveru steperiem nebīja tādēl viņus vadīja bez enkoderiem un tā viņi ir neefektīvi, un sūdīgi motori salīdzinot ar efektīvajiem precīzajiem servo, var arī atbildēt uz to jautāumu kādēļ tad tādas elektronikas nebīja steperiem tādēļ kad agrāk mikrenes (it sevišķi jaudīgās 32bit DSP maksāja krietni vien dārgāk par 8 bit mikrenēm, un līdz ar to neko lētu uztaisīt nevarēja, jo kā redzat steperim tas kontrolles cikls ir 25us (40Khz) un tur ir pasmagi matemātikas algoritmi to nav iespējams realizēt uz 8 bit AVR, vai PICa tur vaig 70MIPS ARM7 kā LPC2101 (3.3$), nu un tās advancētās motoru kontrolles teorījas kā FOC ir parādījušās salīdzinoši nesen pirms cik gadiem es precīzi nezinu, bet tas nav tik sen kā parastās servo vadības teorījas, kas jau ir kādu pus gadsimtu vecas tākā kā jebkura jauna tehnoloģija ir jāpaiet ilgam laikam kamēr tiek uztaisīti pirmie produkti un tad lai visi saprastu ka steperi ir labāki par servo būs jāpaiet vēl kādiem 5-10 gadiem.

Tur kur vaidzīgs liels griezes moments, augsts reaģēšanas ātrums, stabilitāte nav nekā labāka par soļinieku, jo servo ar ātrumkārbu būs pārāk dārgi, un ar sliktākiem parametriem, + vaidzēs bremzes, ja izmantos kādai vertikālai iekārtas asij.

----------


## zzz

epis kaarteejo reizi demonstree ka vinsh ir aarkaartiigi viegli pakjerams uz reklaamu un makaronu sabaazshanu ausiis.  ::

----------


## Epis

kādas tur reklāmas es jau vairāk kā 2 gadus uzskatu ka soļu motors ir labāks priekš CNC nekā servo, tas ir tikai pierādījums tam ka citi arī tā domā, un arī pierādījums tai manai sākotnēji trakajai idejai ka PID algoritmam jākoriģē katra soļa motora solis, bet līdz šim neviens nav uzskatījis pa vajadzīgu to pid aprēķinu veikt ātrāk kā 1-4Khz tam protams ir savs pamatojums jo servo motori vienkārši ātrāk nespēj reaģēt uz tām izmaiņām, tas apmēram ir tas pats kā vadīt SMD lodēamo cepeškrāsni ar 1Hz PID frekvenci, un rezultāta nebūs nekāda jo cepeškrāsns reaģē uz izmaiņām tikai pēc kādām 15-25sekundēm, līdz ar to nav jēga vadīt servomotoru ar tādu PID frekvenci ja viņš nevar uz tām izmaiņām tik ātri reaģēt, bet ar soļu motoru ir savādāk viņš var reaģēt tādos ātrumos un līdz ar to paverās jauna iespēja vēl precīzākai kontrollei, 
+ tiri tehniskie parametri ir daudz labāki nekā servo priekš CNC iekārtām.

----------


## GuntisK

Par kādām ātrumkārbām priekš servo Tu te muldi? Ar to gribi pateikt, ka servo nav jaudīgi? Tad Tu dziļi maldies. Domā viņiem nav momenta uz ass?   ::   Tai CNCZONE visi kas sākuši būvēt cnc ar steperiem, galu galā nonāk līdz servo. 



> bet ar soļu motoru ir savādāk viņš var reaģēt tādos ātrumos un līdz ar to paverās jauna iespēja vēl precīzākai kontrollei, + tiri tehniskie parametri ir daudz labāki nekā servo priekš CNC iekārtām.


 Ātrums un precizitāte ir grūti savietojamas lietas, ja vieт es Tevi pareizi sapratu... Un kādi tad ir tie "tīri tehniskie parametri"? 
Manuprāt stepperiem ir vieta tikai hobby cnc iekārtām, visam pārējam servo būtu labāks.

----------


## Vikings

> 2. nav jātūnē PID gain vērtības,


 Visiem PID ir jāregulē gain vērtības pilnīgi viesiem, ja vien viņiem nav automātiskā regulēšana. Visiem.




> 4.precīzs ar gludu kustību.


 Nestāsti brīnumus. Soļu motors tāpēc arī ir soļu motors, jo iet pa soļiem. Servo pie konstanta sprieguma un konstanta momenta iet lineāri.




> nav vajadzīgi nekādi zobrati un ātrumkārbas, skrūvē pataisno klāt pie Vītņstieņa


 Da labi. Pietiekami esmu CNC redzējis, kuruiem servo ir pa taisno (nu labi, caur zobsiksnu or smthng) pievienots pie skrūves. Es redzējis tikai vienu CNC ar reduktoru pie motora. Un to pašu ar soļu motoriem.   ::  




> 9. Efektivitāte, jo ar šādu draiveri motors padod strāvu lai bīdītu smagumu līdz ar to motors patērē tik enerģiju cik vaig lai veiktu darbu, un tas nozīmē ka motors nekarst, un ir energoefektīvs


 A ko? Servo tas taču ir defaultā.

Ko mums Tev vēl jāpierāda, gan sāksi kaut ko praktiski darīt tad redzēsi kas ir kas.

Epi vēlreiz atkārtojos - aizej pastrādā kaut kur, kur katru dienu vari redzēt CNC mašīnas. Tad vismaz būs PRAKTISKA pieredze nevis netā sagrābstīta draza.

----------


## Epis

reku pašreizējā PCB bilde tur varedzēt detaļas un to izkārtojumu un kā visi signāli tiks vilkti, nēsu vēl uz plates uzlicis USB konektoru un izdomājis kur stāvēs 5V regulātors.

nupat atcerējos ka jāuzliek uz plates JTAG kontakts. 

jaunums uz plates ir tas ka es uzliku ferrite bead 0805 čipu lai atdalītu GNDA, no Digitālā Ground un arī VCCA no parastā VCC, un tas pats ar VCCD (PLL no VCCINT) tās detaļas atrodās uz plates labajā augšējā fpga stūrī (nēsu viņas vēl izkārtojis), un vēl noņēmu nost 3 kapacitātorus (0.1uF) lai katrā FPGA pusē būtu tikai 1 kapacitātoru 4x matrica un izvietoti ir tā lai būtu tuvāk tai vietai kur ir vairāk izejošie IO pini (tie arī patērēs viss vairāk enerģijas). 

man liekās ka tagat es esu tehniski ievērojis visus FPGA PCB taisīsānas noteikumus lai čips varētu normāli stabili strādāt  ::

----------


## Vikings

> Izdomāju līdz galam kā slēgšu klāt AVR čipu pie SPI, un fpga šeit shemas bilde:
> OCA0 pins vaidzīgs lai varētu padot Clock signālu kad SPI flash atmiņa būs ielikta Datu sūtīšanas režimā tad es slegšu ārā AVR SPI interfeisu un palaidīšu taimeri kas ģenerēs Clock signālu uz OCA0 pina un konfigurēs FPGA   un brīvajā laikā varēs skatītes kas notiek ar citiem konfigurāciju piniem 
> [attachment=0:2jqi9cys]AVR_SPI_fpga_shema-C.JPG[/attachment:2jqi9cys]


 Epi, izstāsti kā strādā tie viens otram pretī slēgtie buferi?   ::

----------


## Epis

> Epi, izstāsti kā strādā tie viens otram pretī slēgtie buferi?


 Domā par to vietu shēmā kur N_Statusa vadam ir pieslēgta viena bufera izeja un otra bufera ieja ? 
palasīju vēlreiz fpga konfigurācijas shēmu PS un ņemšu nost to 5uz 2.6 buferi jo izrādās ka nekādiem signāliem iekš fpga no AVR nav jāienāk, tos signālus ir jāredz AVR čipam un tad vaig tikai vienu 2.6 uz 5V buferi. 
un tehniski patiešām tie 2vi buferi nekādi nestrādātu, es bīju iedomājies ka pieliekot buferu galā kādu 1k rezistoru tā shēma varētu darboties, bet tad atkal nedarbotos tas 10K pull-uprezistors, un tehniski sanāktu kad tā shēma ar to rezistoru strādāt nevarētu.

----------


## Epis

Papētīju par to Spline un vai vispār G-kodā ir tāda spline instrukcija un izrādās ka nevella nav, ir kautkādas programmas, kas itkā izmanto G6.2 instrukciju priekš Spline, bet es tā arī īsti neatradu normālu programma kas no DXF konverētu Spline uz G-kodu, faktiski visas hoby progas to DXF failus kuros ir Spline to spline pārvērš par daudz mazām līnijām, gudrākās G-kodu programmas mēģina pārvērst par vairākiem Apļu segmentiem, tad itkā sanāk mazāk G-koda nekā polilīniju gadījumā, bet vienalga tas ir daudz.
Tā rakājoties par google un Spline Tēmu atradu FANUC rakstu izrādās ka viņi lieto spline ( spline netā arī sauc par NURBS(Non-Uniform Rational B-Splines)) un var atrast Fanuc rakstus uz šādiem atslēgvārdiem "fanuc G code nurbs"
un pēc viņa rakstiem tad izmantojot spline līnijas kodu apjomu var samazināt 1/10-1/100 + palielinās precizitāte un arī apstrādes ātrums ar kādu iekārta var strādāt, tākā tehniski bonusi no Spline iekārtas vadībā ir, bet ir problēmas ar to g-kodu, un programmām kas to kodu uztaisa.
vārdsakot ir tā ka ja grib Spline tad pašam jātaisa DXF-to G-code pārveidotājs jo nav nevienas progas kas to darītu, cik skatos tad tām lielajām iekārtām ir savi G-kodu standarti un speciālās instrukcijas priekš tā Spline, vārdsakot nekādu tādu kopējo standartu atrast nevar, līdz ar to sanāk ka jātaisa gandrīz vai pašam.

tehniski ja pielieku klāt apļa interpolāciju tad ir viss parasto hobby progu G-koda atbalsts  ::  
ja taisu kodu ar interpolāciju tad reāli nav vajadzības pēc 8Gb flash atmiņas, var izmantot kādu lētāku 64-32Mb seriālo flash, sūdīgi ka šitai savai ciklon3 platei ar BGA čipu stāv tikai 16Mb flash, man tas tomēr liekās bišķi pa maz, atradu digikeyā par 7.3$ 64Mb un 32 maksā uz pusi lētāk, bet tagat nupat atradu to ka tā micron 8Gb flash atmiņa nokritusies cenā veco 16$ vietā tagat iet pa 10.5$  :: , tas nu gan ir lēti, bet es nupat izdomāju ka nomainīšu savu esošo 8Mb flash atminu uz AT45DB161D-SU-2.5-ND 16Mb flash (2.3$) tāpēc ka šitā ir domāta priekš 2.5V barošanas un domāju nelikt to 8Gb flash jo viņai normāls darba režims ir 3V, un 2.7V ir minimums tākā manā 2.5V sistēmā šī atmiņa neies, tajā vietā uzlikšu otru 16Mb SPI flash atmiņu lai kopā būtu 32Mb flasha, man liekās ka šitā būs viss labāk, jo to NAND flash atmiņu iedarbināt ar visiem CRC eror check ir pagrūti un ja es tā vai šā izmanto tos savus saspiestos G-kodus tad kāda jēga man tur mocīties, ar SPI viss ir vienkārši man tur pat nekādu kodu nav jāraksta paņemu pie Nios II proča pielieku 2vas SPI perifērijas un gatavs, varu rakstīt un lasīt flashā+ var pielikt DMA meneģeri lai pumpē datus bez proča darbības un vēl man paliks brīvi vairāki Fpga pini, kurus var kautkur pieslēgt  ::  
kas attiecās uz to ideju ierakstīt CNC progu no LTP porta tad ar 32Mb to varēs darīt tikai būs tie signāli jāsaspiež, un jāraksta vidējais signāls ar frekvenci kads 1khz, tādējādi varēs ierakstīt flashā tās pašas 10-20minūtes, tākā var iztikt bez Gb flasha, kas tomēr ir pārāk sarežģits un dārgs čips.

----------


## zzz

Aijaijai, miikstojies atkal epi. Gigaflopu dsp nochakareeji, megasamplju adc nochakareeji, tagad atminja arii galiigi niikuliiga buus, taa tu taivaanieshus nepaarsitiisi ar shitik shvaku plati cnc robotam.

Un, Viking, nevajadzeeja gan epja domas lidojumus dazhaadu liimenju salaagoshanaa kritizeet. Tagad pasaulei ir gaajis zudumaa viens no epja grandiozajiem izgudrojumiem.

----------


## Epis

> Aijaijai, miikstojies atkal epi. Gigaflopu dsp nochakareeji, megasamplju adc nochakareeji, tagad atminja arii galiigi niikuliiga buus, taa tu taivaanieshus nepaarsitiisi ar shitik shvaku plati cnc robotam.


 pats redzi ZZZ ka spline neatbalsa neviena hobby CNC proga līdz ar to vajadzība pēc Gflopa proča pazūd, ja kas es atradu vienu rakstu par Hermite Curve Interpolation (priekš SPLINE aprēķiniem) un tur bīja salīdzināts kā to var aprēķināt uz parsta 32bit proča (apmēram kāds ARM7) un tās pašas formulas iekš FPGA loģikas un rezultati bīj ka 32bit procim vajadzēja ap 1300 clock ciklus(jeb instrukcijas), bet FPGA hardware tikai 46clock ciklus, līdz ar to fpga saliek proci par 28,2X uz SPline matemātikas. 

faktiski uzliekot 2vas SPI flashatmiņas es reāli varēsu pielodēt klāt sākumā tikai vienu Flash atmiņu redzēs ja būs vajadzība pēc otras tad lodēs otru  ::  

tā plates taisīšana bišķi ir ievilkusies ar to soļu motora un dzinēja topikiem.bet nu drīz turpināšu un to plati pabeigšu.

----------


## GuntisK

> tā plates taisīšana bišķi ir ievilkusies ar to soļu motora un dzinēja topikiem.bet nu drīz turpināšu un to plati pabeigšu.


 Tev tas jau cik reizes aizrādīts-beidz nodarboties ar hu**jām, un ķeries klāt darbam. Bet tomēr liekas, ka tev tukša muldēšana vairāk iet pie sirds.   ::

----------


## a_masiks

*GuntisK* ... ko nevar celt, to nevar nest.
Gan godīgi jāatdzīst, ka arī man ir daži tādi iecerēti darbiņi, kuriem es zinu, ka mana spēciņa ir par maz... -> velku gumiju...   ::

----------


## Epis

Ispējams ka šī būs pēdēja fpga plate vismaz šoga, jo man jau apnika tās plates projektēt, tādēļ arī ir tik svarītgi uztaisīt tādu lai vairāk nebūtu nekas jātaisa un es labāk ilgāk padomāju kā ko taisīt, nekā uztaisu un tad izrādās ka jāpārtaisa, 

Pagājšreiz man tā bīj ka pasūtīju no digikey septembrī detaļas un tad pēc cepešķrāsns uztaisīšanas sāku taisīt plat un tad jau vairs neko izdarīt nevar jātaisa no tādām detaļām kādas sapirktas, un protams ka taisot plati idejas mainījās, bet vispār ja tā padomā tad šitā plate patiešām varētu būt pēdējā, jo pedējās 3 plates bīj tādi kā mācīšanās eksperimenti, it sevišķi pirmās divas.
Ar ciklon2 es gribēju redzēt vai vispār kautkas var sanākt un var salodēt to TQFP iepakojumu.
AR ciklon3 BGA gribēju redzēt vai varu viņu salodēt ar SMD krāsni. 
ar pēdējo ciklon3 gribēju redzēt cik daudz IO var maximāli izvilkt no 2līmeņu plates un vai tādu plati vispār var Almiko uztaisīt.

ar šīm 3 platēm es esu izmēģinājis visu ko vien ir iespējams uztaisīt un lodēt, tākā man tagat ir liela pieredze un vairs nav iekšā eksperimentēšanas trakums, tātad varu mierīgi domāt un taisīt tādu plati kādu patiešām vaig un neko vairāk.

----------


## Epis

Atrisināju USB čipa komunikāciju ar FPGA un SPI flash  tā lai nebūtu jālieto līmeņa pārveidotāja bufferi no 5V uz 2,5V, Vārdsakot es AT90USB čipu darbināšu ar 3,3V, un tos 3,3V ņemšu no iekšējā DC-regulātora kas pēc būtības domāts ir priekš 3,3V USB signālu daļas, bet viņš ir pietiekami jaudīgs lai darbinātu pašu AVRproci un vēl var padot līdz 50ma darbināt kādu citu citu ierīci, (varētu apskatītes moš ir lētāki SPI flash čipi kas iet uz 3,3V), un labums ir tas ka FPGA 2,5VTTL signāls var saņemt ienākošo signālu 3,3VTTL līdz ar to nav vajadzīgi nekādi buferi, un AT90USB 2,5VTTL arī var saņemt bez buferiem, tas nozīmē ka es tagat novākšu visus buferus kas bīj starp FPGA,FLASH, un AT90USB.

Pēc dokumenta AT90USB strādā no 2,7V un tākā es īsti nav garanstījas ka čips strādās normāli uz 2,5V tad labāk viņu darbināt uz 3,3V.

----------


## Epis

Traka ideja pamēģināt uzlikt uz plates to DDR SDRAM atmiņu, pirmstam es bīju nopircis 3,3V SDRAM un šitā atmiņa nebīj neko lēta 5,4$ tad tagat tākā visa mana plate strādās uz 2,5V tad man vaig kādu 2,5V SDRAM atmiņu un te nekā cita nav izņemot DDR SDRAM .
Un uz jautājumu: kādēļ tad es vispār izdomāju likt kādu ram atmiņu? 
atbilde vienkārša, jo iekšējā fpga atmiņa tomēr ir pamaza, un Nios II processoram vaig samērā daudz tās atmiņas it sevišķi ja  kodē ar C valodu, un tad jādomā no kurienes lai ņem to atmiņu, no kuras pa taisno varētu strādāt procis, un ja procis iet ar 50Mhz tad viņam vaig atmiņu kas var datus pārraidīt ar 200Mbytes/s ātrumu, un uzreiz redzams ka Flash atmiņa atkrīt (NAND flasham bīja tikai 20Mbytes/s) SPI bīj ap 5MBytes/s, 8bitu SDRAM kas iet ar 100Mhz tie ir 100MB/s un tad vienīgā atmiņa kas iet ar 8 bitu datu līniju un var to ātrumu nodrošināt ir DDR SDRAM tai ar 100Mhz ir 200MB/s.
8bit datu līnija tādēļ ka man IO pinu skaits tagat ar 144TQFP paku ir ierobežots, tākā jo mazāk jo labāk bīju arī domājis par 4bit DDR, bet tad pārdomāju likt labāk 8bitu.

Un ja skatās uz cenām tad DDR ir tomēr baigi lēta atmiņa un tādejādi viņa saliek visas citas atmiņas pēc ātruma,tilpuma un cenas, vairāk kā 2x, tākā šai atmiņai nav reālu konkurentu, līdz ar to ir ļoti svarīgi iemācītes izmantot šo augsto tehnoloģiju, kas ir labākā, lētākā RAM atmiņa, un faktiski tādēļ arī es ņemu fpga, lai varētu iegūt visus labumus kādi vien ir, un ja apskatās tad tam 1GFLOP TI procim nav DDR SDRAm atbalsa tur ir tikai SDRAM atmiņas atbalts. un citiem pročiem cenā līdz 20$ arī diez vai varēs atrast DDR atbalstu, labi ja būs SDRAM

DDR SDRAM atmiņa varētu būt micron MT46V32M8TG-5B:G TR  (6,5$), palasīju litratūru par tās atmiņas likšanu kādas ir To rezistoru likšanas shēmas, un uztaisīju nelielu simulāciju iekš hyperlinx ar SSTL2-Clas II signāliem kura stiprums ir 16ma un režims slow, un pēc dokumenta Altera liek 56omu rezistorus es ieliku 60omu, bet reāli var arī likt līdz 100omus tā starpība tur nav nekāda lielā, protams te netiek modelēts crostalk starp līnijām.
Lai pieslēgtu DDR atmiņu domāju dalīt atmiņas Adrešu IO pinus ar citiem IO, tie būs kāda iejas Buffera IO pini, jo buferim var izejas uzlikt uz Tristate stāvokli tādejādi viņu izslēdzot, un tad par līnijām varēs sazināties ar DDR atmiņu, un vadot pašu DDR atmiņu nav nepieciešams visu laiku likt adreses līnijās informāciju ar 100Mhz clock to var darīt Max ik pēc 4 vai vairāk clock cikliem, līdz ar to līnija ir reāli noslogota tikai uz kādiem 25% MAximāli, tākā te problēmām nevaidzētu būt. 

No programmas puses tad quartusā itkā ir DDR SDRAM draivera megafunkcija, kas uztaisa visu Loģiku ar Avalon buss interfeisu priekš Nios II proča, vēl nezinu vai tas draiveris ir par brīvu, vai kopā ar Nios II porča licenzi, vai arī atsevišķi licenzējams, bet cik apskatījos tad tur ir tā mana Micron DDR atmiņa un tikai jāsaliek visi atmiņas parametri un tad vaidzētu iet. 

jebkurā gadījumā es šito DDR atmiņu jau sen gribu iemēģināt, un man uz sava ciklon II Dev.kita tādas DDR atmiņas nav tākā jātaisa sava plate lai varētu iemēģināt, ja kautkas neies tad kļūdu atrast kāpēc neiet ir prakstiski neiespējami jo tādu Mērinstrumentu ar ko mērīt signālus man nav.

----------


## Epis

Pamodelēju DDR signālus ar īsto micron MT46V32M16 DDR atmiņas IBIS modeli, pirmstam bīju skatījies kas notiek ar diviem FPGA SSTL2 standarta piniem ja sūta signālu no vienas fpga IO uz citu un salīdzinot ar fpga tai atmiņai ir bišķi spēcīgāki SSTL2 signāli  to labi var redzēt šajā attēlā kur sarkanais ir DDR atmiņas izejošais signāls, bet zilais ir Ciklon3 pina izejošais (te es uzliku švakāko 8ma drivera spēku kāds vien bīja piejams šim standartam, bet pat ja uzliek stiprāko 16ma tad atšķirība ir mazāka bet vienalga atmiņai ir bišķi spēcīgāki IO. 
un es tur shēmā iezīmēju divus rezistorus Pull-up pie 1,25V reference strāvas ar vērtību 100omi, pēc visiem standartiem tiem rezistoriem vaidzēja būt ap 56-60omi lieliem, bet es te atkal izdomāju ka likšu bišķi vairāk, lai būtu mazāks energo patēriņš un varētu izmantot švakākos draiverus, jo man tā DDR atmiņa ies uz 100Mhz (nevis 166 kas ir MAx, bet es Max varētu laist viņu uz 133Mhz ar zemākā ātruma ciklon3 mikreni, bet reāli tie būs ap 80-100Mhz atkarībā no to signālu kvalitātes cik varēšu tik ātri arī darbināšu).
par rezistoriem izmantošu 0603x4 iepakojuma rezistorus kopā tur vaidzēs 6gabalus.
būs jāsāk taisīt shēma  ::  
Par DDR atmiņas kontrollieriem (ar visu avalon interfeisu), es noskaidroju to ka tie gatavie nav par brīvu un viņiem licenzi var pirkt atsevišķi vai arī dabūt automātiski pērkot Quartus 7.2 subscription licenzi tad nāk līdzi Mega wizard IP kodu pakete kurā iekšā ir arī DDR,DDRII,DDRIII atmiņu kontrollieri, un tākā Tā Quartus licenze maksā 2500$ tas nozīmē ka ja es gribēšu to atmiņu izmantot kādā ierīcē tad kontrollieris būs jātaisa pašam, bet sākumā lai pārbaudītu ka atmiņa vispār strādā es izmantošu gatavos Evaluation IP kodus(tāpat kā Nios II proci, kuram licenze maksāja ap 500$), galvenais uzdevums ir dabūt to DDR atmiņu pie dzīvības, jo ar visiem gatavajiem IP kontrollieriem tas nebūs viegli.
[attachment=0:3vg5gru6]DDR_oscils_īstais.JPG[/attachment:3vg5gru6]

----------


## Epis

IR tā ka esu nonācis pie tāda Secinājuma ka nevaru to savu PCB uztaisīt kamēr nēsu nopircis (pasūtījis) detaļas, jo tad kad būs pasūtītas detaļas es arī būšu izlēmis, kas kā īsti būs. Un tagat es taisu to sarakstu ko sūtīt, un JAUNUMS ir tas ka es tomēr izmantošu Latice FPGA ECP2 6000Loģikas mikreni 144 pin TQFP pakā (11$)
priekš PCI būs tie Līmeņu pārveidotāji,
Vēl klāt STM32 procis. 
Priekš komunikācijas ar Enkoderiem, motoru draiveriem (5V TTL) man būs CPLD  LC4032V-75Tn48C (1.65$) čips īstanībā tādi būs 2vi viens priekš LTP 26pin D-SUB kontakta (tur būs 24 IO) un otrs priekš tiem RJ45 (enkodera kontaktiem)arī 24 IO  un interfeis starp CPLD un fpga bus 4bit datu līnija ar clk,Read,Wright +vēl viens vads un Clk frekvence būs ap 100Mhz, un no CPLD IO pinus varēs slēgt, nolasīt ar ~16Mhz frekvecni, un šai CPLD IO ir 5V tolerant un ar Hot swap, ESD aizsardzību vārdsakot tīri izturīgas IO līnijas. 
Un lattice CPLD vaidzēja ņemt jo Mouser.com alteras čipus netirgo (max3000 ir bisķi lētākas nekā ispMACH 4000V) es parēķināju tad šādi ar CPLD iznāk lētāk dabūt tos 5V tolerant IO nekā ar diskrētajiem 74Hcxxx bufferiem, kur mīnus ir tāds ka sanāk tikai vienvirziena komunikācija, bet ar CPLD es varēšu uzstādīt pats kādos virzienos katra IO līnija strādās  ::  

un vēl tākā man čipam būs tikai 90 IO pini tad ar CPLD es daļēji atrisinu arī šo IO trūkumu + 5V signālu problēmu.
Vēl ar Lattice čipu atrisinu arī Konfigurācijas problēmu, jo tā mikrene konfigurēsies pate no 2$ SPI Flash atmiņas, tākā nevaidzēs čakarēties ar konfigurāciju, 
+ uz plates nebūs neviena BGA čipa.
+ varēs izmantot bezmaksas Open sorece LAtticeMicro32;8 pročus, un visas opencores.org perifērijas ar WISBONE datu interfeisu (to ir ļoti daudz, un visu laiku nāk klāt jaunas + tur ir PCI kods  :: 

un Vēl izmaiņas tādas ka DC-DC switch regulātoru vietā likšu Texas LDO fiksētos (lētos) regulātorus, tākā beigās šitai platei vaidzēt būt letai. un PCB sākšu vilkt ka būšu pasūtījis tās detaļas

----------


## Epis

Pasūtiju savu detaļu kalnu no Mouser.com un attiecīgi tagat varēšu sākt vilkt PCB. 

Man tur detaļu kalnā ir iesviesti arī pāris Spiedienasensori 150 PSI, 3D acelerometri, lētā gala MSP430F2012 čipi (šitos es ņēmu speciāli priekš Šiem Fotopārtraucēja sensoriem: EE-SX1131  Dual 0.8mm pitch photo-interrupter, vārdsakot no viena tāda sensora var dabūt ārā 2 SIN viļņus un izšķirtspēja ir tīri laba, jo uztvērējam ir 0.3mm logs, tas ir viņš varēs detektēt normāli 0.3-0.25mm līnijas izprintētas uz kādas caurspīdīgās kodaskopa Plēves un + paša sensora izmēri ir arī super miniatūri 4x5mm SMD un galvenais ka tas ir baigi lēts 0.99$ + MSP430 pa 1.8$ sanāk SIN Lineārais enkoders pa 2.8$ x nodokļi  ::  

Vienīgais ko nenopirku, un ko itkā viadzēja pirkt, ir Lattice LTP porta programmeris(JTAG), es forumā atradu vietu kur viens teica ka tas programmeris ir tāds pats kā ALteras, Xilinx LTP programmeri tikai vadi pie LTP porta slēdzās klāt bišķi savādāk, un tur itkā bīja vadu secība, bet jebkurā gadījumā es PCB uztaisīšu tā lai es varētu ar STM32 ieprogrammēt to SPI flash atmiņu, un tad pate FPGA iekonfigurēsies no SPI flash atmiņas. 
Tagat kādu gadu, nevaidzēs neko no tiem ārzemju veikaliem sūtīt  ::

----------


## Epis

Drīz dabūšu detaļas no Mouser.com (itkā esot jau muitā) un apmēram tāda pēc izskatīsies tā mana plate : jāsaka tā ka es atkal šo to izmainīju un tas jaunums ir 3 LVDS pinu pāri 840Mb/s katrs viens būs CLK, kas aiziet uz RJ45 kontaktu un tas domāts tā tīri eksperimentam un ja strādās tad ar šiem 3 LVDS signāiem varēs saslēgt kopā 2vas manas PCI plates ar CAT5,CAT6 standart interneta Vadu (īsākais bīj 1 metru garš), un datu apmaiņas ātrums būs tāds pats kā starp PCI slotu (reāli vēl lielāks ap 210 MB PCI-express bīja ap 500MB, un tākā es to PCI-express neuztaisīju tad man vaidzēja kādu no tiem Super ātrajiem signāliem iemēģināt un nekā ātrāka par LVDS uz parastām Fpga nav.
Nēsu vēl izdomājis ko lai dara ar tiem 12 STM32 ADC iejas kanāliem itkā uz plates vietas ir papillo tur kautko intresantu varētu izveidot

----------


## Epis

Esu ar to sūtīšanu no Mouser.com Riktīgi iekritis, jo sūtīju ar Fedex international priority un man tur ir 19 dažādas detaļas, un problēma ir ar to atmuitošanu tur Deklarants teica ka vaig taisīt 5 deklarācijas jo tur ir ap 10 dažādu tipu preces(fpga,MCU,rezistori,kapacitātori,optosensori uttt.) un 1 deklarācijā itkā ieiet 2 preču grupas un tāda 1 deklarācija izmaksā 10Ls līdz ar to lai šo sūtīju atmuitotu sanāk jāmaksā 50Ls par kautkadām Sūda deklarācijām, varbūt izdosies pielauzt to deklarantu lai saliek preces 2 vai 3 deklarācijās, jo man tur dažas preces kā sīkie EMI filtri + pāris rezistori maksā smieklīgi maz naudas attiecīg 1.6$ un un 1.5$ līdz ar to taisīt šīm precēm 1 deklarāciju kas izmaksās 10Ls būtu vienkārši Super stūlbi, līdz ar to es viņiem teikšu lai vienkārši MET ĀRĀ. 
Stūlbākais Kādēļ vispār es iekritu ar to FEDEX ir tas ka nupat skatījos un uzmanīgi pētīju MOUSER shiping metodes un tur apakšā stūrī ar maziem burtiem bīj rakstīts ka viņi arī sūta preces ar USPS priority mail, bet pakas tikai līdz 300$  ::  un kas ir vieglākas par kādiem 4lbs, bet mans sūtījums bīja 318$   ::   un kad vadīju datus tad pie Shipping metodēm man neparādījās tā USPS Opcija, un bīj reāli tikai 2vas izvēles vai Fedex, vai USP (abi vienādi-jāmuito pašam un par deklarācijām jāmaksā). 
Stūlbākais ir tas ka es par to Fedex SŪDA pastu jau esu samaksājis Astronomisku summu 168$ (75Ls)   ::  bīju domājis ka to paku saņemšu caur Latvijas pastu tāpat kā sūtot no USPS, bet nekā,  vēl būs par tām deklarācijām Jāpiķo 50Ls + PVN (25ls)  vārdsakot lai atvestu savu 143Ls vērto elektroniku būšu iztērējis virs 150LS    ::  
Līdz ar to šī te mana PCI Plate kurai vaidzēja būt lētākajam risinājumam un attiecīgi viss lētākajām detaļām tagat iznāks tieši pretēju Viss dārgākā, neizdevīgākais elektronikas gabals kādu jebkad būšu uztaisījis  ::  
Savas neuzmanības, nezināšanas dēļ esu baigi smagi iekritis ar šo sūtījumu, un šī ir pirmā un pēdējā reize ka kautko sūtu ar Fedex, pirmstam bīju vienreiz sūtījis ar DHL tur ir tieši tas pats tādļ vairs neko ar DHL nesūtu, bīju domājis ka Fedex ir svādāk, bet re ka izrādās tas pats kas DHL.

----------


## Vikings

A ko visu nevar pabāzt zem sadaļas "radiodetaļas"?

----------


## Epis

Šodien uztaisīja man 3 deklarācijas pa 25ls sarunāju atlaidi(5Ls) + samazinājām skaitu no 11 preču grupām līdz 7 viss vairāk izdevās sabāzt zem mikrokntrollieru klases, tur sabāza MSP430,cortex-M3,ECP2,ispMACH4000, abus Dev.kitus, Presure sensoru, 3D acelerometru, 10bit bus switch, vārdsakot visas mikroshēmas kurās ir kāds procesors,loģika un pārējās integrētās shēmas, kas neiederās citās kategorijās. 
, problēma bīj ar tiem rezistoriem, kondensātoriem,fotopārtraucējs, EMI ferite bead, RJ45 konektoru, flashatmiņa, tur katra detaļa iet savā kategorijā (savs preces kods) un tā bāzt zem kautkādas vienas nevar, viņiem tur ir stingri notektas kategorijas
Vienīgais ievedmuitas nodoklis (ap 3%) ir jāmaksā par Mazajiem EMI filtriem 1.6$, pārējām precēm nodokļa nav (izņemot PVN).

Es tur vēl parunājos ar to deklarantu tad viņš teica ka itkā UPS ievedot preces laiž viņas caur Latvijas pastu un viņu muitu tāpat kā USPS (lētais), tākā ja nākošreiz būs kautkas jāsūta un nevarēs izmantot USPS tad es izvēlēšos UPS, bet Fedex,DHL es vairs nemūžam neizmantošu.
Pirmdien jāiet jāatmuito un tad dabūšu savu čipu kravu  ::

----------


## Vikings

Kas viņi vispār afigeļi? Viņiem nav vienalga, ka tās visas ir radiodetaļas un nevar sabāzt zem viena nosaukuma?  Viņi taču paši neko nejēdz, vai tad viņiem nevar sastāstīt, ka tas principā ir viss viens un tas pats un ka visam jāiet zem viena nosaukuma? Kā viņi zin, ka tieši EMI filtriem jāliek kaut kāds *** nodoklis?

----------


## Epis

> Kas viņi vispār afigeļi? Viņiem nav vienalga, ka tās visas ir radiodetaļas un nevar sabāzt zem viena nosaukuma?  Viņi taču paši neko nejēdz, vai tad viņiem nevar sastāstīt, ka tas principā ir viss viens un tas pats un ka visam jāiet zem viena nosaukuma? Kā viņi zin, ka tieši EMI filtriem jāliek kaut kāds *** nodoklis?


 vienīgais kam ir vienalga kas ir tajā pakā ir Latvijas pasta muita, viņi paliek visu paku zem elektronikas, uzliek tev simbolisku 2% muitas nodokli un esi brīvs  :: , ar īsto muitu tās lietas ir nopietnas.  ::

----------


## valmet

Ar to muitu ir traki - es no Ķīnas pasūtīju Lāzer galviņas priekš Sony Playstation (veda DHL) un man nācās ne tikai braukt no Liepājas uz Rīgu atmuitot, bet arī sūtīt faksu uz Aizsardzības ministriju, lai viņi dod atzinumu, ka šie laser units nav stratēģiska prece  ::  Tagad pasūtu turpat , bet piegādā ar pastu un no problems.

----------


## GuntisK

Interesanti ,kas tad te LV par tādu stratēģiski svarīgo punktu atskaitot tirdzniecībai izdevīgu vietu? Mikroshēmas neļauj ievest,  tur katru aizdomās par sīku SMD katu6ku. Labāk beigtu tā muļķa valsts ar saviem padotajiem ar huiņām nodarboties un darītu ko tiešām noderīgu tautai.    ::

----------


## Epis

Katik man nepiekasītos, man deklarants kautko arī ieminējās ka mikroshēmas varētu būt kautkādas militāri stratēģiskās preces, tipa no viņām Robotu tač var uztaisīt, vai kādu talvadības ierīci   ::  

njā Lāzers jau izklausās tā "Draudīgāk" tādēļ stūlbie muitnieki arī piekasījās.

----------


## GuntisK

Da joptvai-kas Latvijā robotus-terminatorus būvēs ar iznīcinoša spēka lāzeriem? Mani brīžam pārteidz cik stulbi var ļaudis būt.   ::  Vnk nedomā loģiski un viss...

----------


## korium

Par tiem robotiem-terminatorie: Robotika 2008 forumā bija viens džeks no zemessardzes/armijas vai kaukā tamlīdzīga, ta nu viņš stāstīja par to kā šamēji tepat Latvijā būvē militāros teritorijas apsekošanas lidaparātus. Pagaidām vel terminatorus netaisam, bet varbūt kādreiz..   ::

----------


## GuntisK

Tas, kas bija šāgada Robotikā nav uzskatāms par kko nopietnu. Ar pulti vien vadāms tas robots. Par apsekošanas lidaparātiem gan pirmā dzirdēšana. Apsveicami jau ir, ka notiek vismaz kāds progress tehniskajā jomā, taču līdz Terminatoriem to4 ir tālu. Da i kāda jēga no tādiem? Ok-liekas nobraucām no tēmas...

----------


## valmet

Korium - tu esi izpaudis valsts noslēpumu, gaidi ciemiņus  ::

----------


## Epis

Dabūju savu Detaļu paku, muitnieki nekur nepiekasījās  ::  
vēlāk ielikšu bildi.
Tagat ka visas detaļas ir atnākušas būs jāpabeidz tā sava PCB plate  ::  un kamēr plate taisīsies jāiemācās tas STM32,MSP430 normāli kodēt ar C  :: 

pagaidām imēģināju STM32 primer Kitu, pāris spēlītes paspēju un Raisonance RIDE7 progu ieinstalēju, tur ir arī vesela OS uz kuras tās demo spēles, un interfeis taisīts, vārdsakot būs ko papētīt un pamācīties (varēšu tā īsti C valodā mikrenes kodēt iemācītes, līdz šim ar to C mikreņu kodēšanu bīj kā bīj jo nebīj īsti ko kodēt (avr C instrumenti negāja, un ar to Nios II proci neko daudz darboties nesanāca (tur variāk asmā kodēju nekā C) bet ar to Cortex-M3 ir tā ka Asmā viņu kodēt ir nereāli, jo viņa tā arhitektūra ir baigi smagā (daudz instrukciju un sarežģits procis), labāk iekšā nelīst, apmēram tas pats kas Fpga kodēt ar blokshēmām nevis VHDL, vēl MSP430 USB stick kitu nēsu iemēģinājis tur arī būs ar C jākodē, lai gan šito var arī Asmā kodēt jo tur ir maz ASM instrukciju (vienkārš procis kā AVR tikai 16b)

----------


## Epis

Šeit ir mikreņu foto kuras es nopirku, un lejā ir tā īpašā Fotopārtraucēja foto ar diviem uztvērējiem 0.3mm logu un 0.8mm atstarpi vārdsakot īstais sensors optiskajam SIN enkoderim, tādus sensorus ir baigi grūti atrast, digikeyā tādi netirgojās, es jau vispār domāju ka nekad neatradīšu tādu dubulto fotopārtraucēju ar kautcik labu izšķirtspēju, bet re ka vienu atradu  :: 
un enkoderis būs tas sensors + MSP430 PCB priekš viņiem es arī uztaisīšu (kopā ar PCI plati)
[attachment=1:3gzbllze]Mikrenes-mouserCom.JPG[/attachment:3gzbllze]
[attachment=0:3gzbllze]PhotoInterupter-Dual.JPG[/attachment:3gzbllze]

----------


## GuntisK

Enkoderi cik noprotu pats taisīsi? Rodas jautājums par to kā izgatavosi precīzu enkodera disku.

----------


## Epis

Ar lazer printeri domāju ka precizitāte būs +- normāla, ja labi grib tad var izdomāt kādu kalibrēšanas metodi un tā enkodera neprecizitātes digitāli izlabot ierakstot kļūdas vietas un kļūdu novirzi kas ir attiecīgajā diska līnijā un tad tās kļūdas ierakstīt mikrenes Flash atmiņā, un man diskā nebūs vairāk par 50 līnijām, un tos kļūdas % es varētu atrast izmantojot savus USdigital enkoderi kam ir 300CPR, vai arī kādu citu metodi izdomāt, par lineāriem enkoderiem tad ja gadījumā nesanāk normāli izprintēt tās līnijas tad var nopirkt to speciālo caurspīdīgo lentu no USdigital tur izšķirtspēja mazākā ir 100CPI.

būs laikam viens sensors jāsalodē un jāiemēgina ar oscilu savādāk nevar izdomāt kādu rezistoru vaidzēs likt, jo ja būs liels rezistors virs 2komiem tad pilnīgi iespējam ka vaidzēs izmantot kādu opampu signāla spēka pastiprināšanai, jo MSP430 ADC kanāla iejas pretestība ir 2Komi tākā ja fototranzistora signāls būs pārāk švaks tad rezultāts var sanākt neprecīzs,bet vispār man liekās ka to SIN signālu vaidzētu jeb kurāg adījumā laist iekšā Opampā jo opampa iejai ir ļoti liela pretestība līdz ar to signāls netiks ietekmēts no ADC. 
fototranzistoram Ic ir 20ma 
un tur ir šādi tādi tādi grafiki, bet izzīlēt kādu vaidzēs rezistoru pēc tiem es nevaru, ja kāds grib papētīt tad meklējat EE-SX1131 dokumentu  ::

----------


## Vikings

Lauziens vērt vaļā pdfu un skatīties grafikus, bet pareizi vien domā, ka opampā jālaiž. Tas jādara viennozīmīgi, jo nevar jau zināt ko opampa ieejas izdarīs ar vāju signālu. Man ir bijuši brīnumi vāju signālu laižot iekšā PICa ADC.

----------


## Epis

Reku mans sensora tests  ::  sākumā esu ielicis 1kom rezistoru izskatās ka pa lielu jo virs 1.2V ārā dabūt nevar  ::  
te ir arī mana MSP430 USB Stick platīte izmantoju viņu kā 3.6V avotu  :: 
varētu mēģināt ar 2.2K ja būs pa švaku tad 2.8 (pie 3K), bet nu pats galvenais ir tas ka tie rezistori būs virs 2Komiem līdz ar to būs Obligāti jāliek Opamp Buferis. 
[attachment=0:3o2rpuhu]Enkoder-Tests1-oscil-1Kohm.JPG[/attachment:3o2rpuhu]
[attachment=1:3o2rpuhu]MSP430-kits+enkoderSens.JPG[/attachment:3o2rpuhu]

----------


## Vikings

Epi, pat ja rezistori būtu 680 Omi tad tāpat būtu jāliek OPamps. Vienkārši tur tāpat sanāk sprieguma dalītājs starp pullupu un ADC ieejas pretestību, kas rada kļūdu.
Iesaku pamācīties ko kurš grafiks nozīmē, tad pats varētu izvēlēties R vērtību vismaz pietuvināti reālajai, savādāk divas dienas vari eksperimentēt.

----------


## Epis

īstais rezistors ir 2.66 Komi (man cita nebīj) un voltu līmenis mainās pēc šādas attiecības pret rezistoru vērtību  R(Komi)*1.2=maxVolti un attiecīgi 2.66k dod 3.2V tāds arī bīja tas līmenis tākā būs jādomā par Opampu jo signāls ir pārāk švaks priekš ADC iejas. būs jāņem kāds dubūltais LM358D opamps SO8 pakā  ::  vienīgi man liekās ka lai no tā opampa izvililktu ārā tos 3.2V viņam vaidzēs 5Voltu barošanas strāvu a MSP430 iet uz max 3.6V tad laikam jāpadomā par kādu papildus mazo LDO regulātoru uz 3.3V jo par to rj45 vadu es 2vus strāvas vadus vilkt netaisos.

----------


## Epis

Lieta ir tāda ka MSP430 ir ADC ar ārēji uzstādāmu REf+ Ref- līmeņiem tas ir tā ka ADC pārveidos signālu kas būs starp tiem līmeņiem, un ar to sensoru ir tā ka viņš ārā sāk to SIN vilni dot no kādiem 0.15mv un pašās beigāsar to 2.66Komu rezistoru iet 3.2 (3.6vietā) un tad ja es ADC Vref+laižu iekšā pa taisno 3.6v un Ref- GND tad sanāk ka es īsti nevaru izmantot to visu sava ADC 10bit izšķirtspēju, un lai izmantotu visu potenciālu man būtu tie Vref jāpielāgo tiem signāla MAx,Min vērtībām, un nevaru izdomāt vai to pielāgošanu taisīt uz kautkāda rezistoru dalītāja + opamps(signāla pastiprināšnai) vai arī uztaisīt elektroniski regulējamu Reference līmeni ar parasto MSP430 IO kāju kura taisīs PWM tad laidīs to caur + RC filtru un tad caur opampu iekš Reference iejas un man uz MSP 420 sanāktu 2vi šādi DAC (pašam čipam ir 1taimeris ar 2compare reģistriem) ieguvums no šadas digitāli regulējamas ADC konvertiera Vref domāju ka būtu vismaz, kalibrācijā un uzstādīšanā tas noderētu.
Es tagat nevaru izdomāt likt to DAC vai nelikt ?

----------


## Vikings

Manuprāt, tā darot būs salīdzinoši lielas pulsācijas Vrefos. Tad labāk lai ir pastāvīgi uzstādīts vai ja tiešām gribas izvirtības tad liec elektronisko poci, kas regulē vajadzīgos spriegumus.

----------


## Epis

Nupat savilku savu Enkodera PCB šeit attēli (ar shēmu, nu tā shēma tāda vispārīga, dažas detaļas tur neatbilst shematiskam zīmējumam, (vaidzēja vienkārši lodlaukumu, un tādēļ vienā vietā (R4) ir ielikts, pamanīju ka jāpieliek pāris kapacitātori, savādāk man tur neviena nav uz plates. 
Plates izmēri būs 15x20mm  ::

----------


## Epis

Bišķi visa plates taisīšana ievilkās(kā parasti  :: , domāju ka šonedēļ jāķerās klāt un jānobeidz.

ievilkās tādēļ ka vaidzēja uzrasēt vienu detaļu bet tas autocad 2006 izrādijās ir baigais s**s, proti tiko jāuztaisa kautkas tāds riktīgi ģeometriski sarežgīts, tā tur vairs īsti neko izdarīt nevar, moš 2008 versija jau ir labāka,(tur vismaz vītni jau var uzrasēt ģeometriski pareizu), bet es atradu jaunu programmu Rhinoceros 4.0 un kamēr novilku,apguvu tikmēr pagāja 10dienas, paveicās ka tur ir kruta interaktīva Help pamācība.
Reku mana ģeometriski sareģītā forma (tās rievas uz cilindra)  :: 
[attachment=0:3icti7zi]Rucka_BMX.JPG[/attachment:3icti7zi]

----------


## a_masiks

Nu i priekš kam tās rievas vajadzīgas? Ko tās dod DIY fpga motoru kontrolierim?

----------


## Vikings

Nu nu nestāsti brīnumus, tas, ka nemāki ar ACAD rīkoties nenozīmē, ka tas nekam neder.

----------


## GuntisK

Tu mozh tās ru4kas taisies uz virpas taisīt?   ::

----------


## a_masiks

Nu, ja sekojam riteņa konstrukcijai - konsekventi būtu virpot spieķus pēc rumbas izgatavošanas. Domājams ka virpoti un rūdīti spieķi varētu būt izturīgāki un vieglāki par parastajiem.

----------


## Epis

Enkoder PCB mazā shēma gatava reku bilde, un lielajai savilku POWER Līnijas (0.8 mm platas) vēl nēsu izdomājis ko darīt ar to STM32 ADC iejām likt tur Opampus vai tomēr nelikt, vietas uz plates ir itkā daudz. 
[attachment=0:35pcy1zt]Enkoders-gatavs1.JPG[/attachment:35pcy1zt]

Es zinu to ka tikai ar 2007;2008 un 9 autocadu var normāli uzgriezt vītni ar iepriekšējiem to izdarīt nevar, tur ir baigi jāmocās lai kautko vispār līdzīgu vītnei uztaisītu (jāizmanto papildus LISP kodi un tādā garā). Tākā man nav laika tur čamāties ar tādu programmu uz kuras neko izdarīt nevar, es paņemu citu kas to var izdarīt ar pāris klikšķiem  ::  un miers.
Tā ir tāda kā pirmā skice priekš brāļa firmas ( parbmx.com) viņi tur izdomāja ka jāpamēģina te pat tajā gumīju fabrikā pārsimts(vai tūkstos) ruckas uztaisīt  :: 

Uztaisīju priekš Vītnes jaunu Topiku Programmas/software kas zin kā iegriezt vītni atbildat tur.

----------


## Epis

Nu tā beidzot laikam plates PCB ir gatavs  ::  āeit bildē noņēmu tos GND laukus lai var normāliredzēt kā savilkts.
šodien pievilku 3  fpga konfigurācij monitoringa vadus STM32 procim un tad sanāca vilkt tos vadus tā īpatnēji nevis pa taisno, bet gar vienu CPLD tā lai pēc iespējas mazāk maisītu pārējiem "ātrgaitas vadiem" to cik labi man tur tie vadi savilkti un kāda būs tā signālu kvalitāte es protams ka neuzināšu  ::  (tad man vaidzētu taisīt plati tam 60MSPS ADC konvertierim, esu jau piemirsism ko kā tur vaidzēja taisīt un cik tas bīj sareģīti,idejas man bīj baigās  :: , fiksi apskatīšos ja varēs atri uzvilkt to plati tad uzvilkšu, savādāk mētājās man tas čips bez pielietojuma  ::

----------


## Epis

Beidzot uztaisīju pirmos Gerber failus, atkodu kā īsti viņi jātaisa jo pamācībā bīj tā pavirši aprakstīts un protams ka nekas nesanāca līdz brīdim kad atradu vienu nianci tādu kas nebīj nekur minēta, attiecīgi tur ir tāds lodziņš kur ir itkā jānorāda output fails vaig ierakstīt to faila nosaukumu PCIkarte.grb a defaultā tur stāvēja kautkāds pavisam cits faila tips (art001.pho) līdz ar to man PADS2005 netaisīja nekādus gerber failus, es bīju domājis ka proga tos failus taisīt kā P-CAD, bet nekā, bīju mēģinājis tos savus PADS failus kautkā atvērt caur DXF,ASC bet nekas nesanāca dxf bīj kautkādi gļuki un itkā P-cadā var arī ieimportēt PADS failu, bet tur arī neko nerādīja tākā tas variants cauri negāja. 
Pagaidām vēl nezinu ko Almiko teiks rīt laikam jāsūta faili lai viņi sāk taisīt 2vai vai 4ras plates  ::

----------


## Epis

Lieta tāda ka pār mani nāca kārtējā ATKLĀSME  ::  un es sapratu ka man tomēr to PCI slotu nevaig, jo nu skaidrs ir tas ka es to uztaisīt varu, un tad kad es visu bīju uzīmējis sāku domāt: " a ko es ar to iesākšu? itkā fpga iemocīt kādu paraug kodu varēšu bet lielākais jautājums ir par to kā es to sasvu kompi ieprogrammēšu ? un atbilde nekādies  :: . Bišķi paraku netā par piekļūšanu pie PCI slota un informācijas ir ļoti maz, tādu gatavu risinājumu, kodu priekš Visual C# īsti nav 9tur jātaisa kautkādi Draiveri utt..), tākā rezultātā es būšu uztaisījis PCI karti un tā arī tā karte man stāvēs kompī iesprausta, bet komunicēt ar savu elektroniku es varētu tikai caur USB, sanāk tā pastūlbi vai ne ?
+ ja pat kautkādus test kompja kodus palaidīšu tad atkal rodās vecais jautājums par tām CNC progām, nebūs jau nevienas progas kas to manu karti atbalstīs, līdz ar to būs pašam jātaisa un tas ievilksies uz kādiem 3gadiem, tākā pieturēšos pie vecā varianta USB priekš manas Visual C# progas komunikācijas ar Fpga karti un otra varianta standart LTPporta kur vienkārši piespraudīšu klāt kompi savai kartei.

Vispār jau tā PCI, un PCI-Express X1 padarīšana bīj tāda kā vēlēšanās šitās lietas labāk iepazīt un izpētīt vai kautko var uztaisīt vai tomēr esu pa dumju un nevaru, un protams ka var PCI-express X1 var taisīt ja ir 4līmeņu PCB (es hiperlinkā uzmodelēju ar 4 līmeņiem var dabūt ideālos parametrus attiecīgi 100omu diferenciālo un 60 omus atsevišķi līnijai, neko tādu dabūt uz 2 līmeņiem īsti nevar, jo es šodien uzmodelēju Labāko ko vien var dabūt uz 2 līmeņu PCB (biezums 1.5mm) 1oz copper un tad var dabūt 100 omu diferenciālo bet pašām līnijām impecence būs tikai 78.5 omi vairāk dabūt nevar, un lai tā dabūtu celiņam ir jābūt Stripline konfigurācijā ceļu platums 9mil, atstarpes starp ceļiem 6mil (0,15mm) un pa malām GND leyeri. Pēc šitiem jaunajiem parametriem es tagat jau pārtaisu LVDS pinus un Pētot LVDS izrādījās vēlviena nianse tāda ka manai ECP2 fpga nav īsto LVDS draiveru īstais ir tikai recieveris, un tad draiveri jātaisa liekot kopā divus LVCMOS25 IO (+ ::  un papildus jāliek 3 rezistori (man visi būs 100 omi) tad sanāk LVDS draiveris, jāsaka tā ka ciklonam III bīja īstie LVDS, bet tikai puse no LVDS piniem otrai pusei ir jāliek šie rezistori, laikam vienīgā no FPGA kur ir viss ar šiem LVDS kā pienākās ir xilinx Spartan 3x(kāds modelis aizmirsu) tur viņiem bīja arī integrēts recievera 100omu rezistors (šitas nav pat Ciklonam III), 
Parasti es šādas situācijās varu teikt ka atkal esu kautko greizi nolaidis pērkot, pasūtot detaļas, un tā, protams, ka sanāca ar tiem Lvds draiveru rezistoriem, bet nav tik slikti jo es bīju pasūtījis minī 100omu rezistor lauku X8 0603 un tie derēs  :: 
Es ņemu tagat nost PCI daļu un no atbrīvotajiem FPGA piniem un varēs uztaisīt pilnvērtīgu LVDS komunikāciju ar 2viem RJ45 kontaktiem:
1 Master : 2vi Draiveri(CLK; TX) 1 recievers(RX)
2 SLave: 2vi recieveri (CLK;TX) + draiveris (RX)
kopā būs 6 LVDS kanāli divos kontaktos un varēs reāli izeksperimentēt un apskatītes cik ātri tad iet šie kanāli ar parasto Cat5,CAT3 RJ45 vadu, abus galus iespraužot Platē tādejādi savoenojot Slave ar MASTER un dati tiks sūtīti no M uz S un atpakaļ, faktiski sanāk SPI tikai ātrumi citi ceru dabūt kādus 400Mb/s no 1 kanāla, protams šādi varēs saslēgt 2vas vai vairākas plates.
Atlikušos IO izlikšu uz parasta Header kontakta lai beidzot varētu pieslēgt savu Video sensoru.

Varbūt kādreiz tālā nākotnē kad būšu labāk apguvis kompja programmēšanu dziļākā līmenī (draiveru kodēšana) un ievaidzēsies man sūtīt datus no kompja uz kādu elektroniku ar tiem 132-500MB/s tad man būs jau gatavs rīcības plāns ko kā darīt, un taisīt, lai fiksi var uztaisīt, bet pagaidām es varu iztikt ar USB.

----------


## GuntisK

Nu tu jokupēters riktīgais!   ::  Atgiezies pie iesākumiem...

----------


## sharps

slabo uzraut kodu prieksh PCI pasham? taksh jau zinaaju ka apalauziisi ragjeljus pie PCI. zinu paaris dzhekus kas pie shaada tipa dzelzhu programmeeshanaam jau njemaas gadus un vienalga ir daudz kas ko apguut. ir vesels standarta priekshraksts kaa biibele uz 1500 lapaam uz kuras dzheki tur roku kaa dodot zveerestu.

----------


## Epis

> slabo uzraut kodu prieksh PCI pasham? taksh jau zinaaju ka apalauziisi ragjeljus pie PCI. zinu paaris dzhekus kas pie shaada tipa dzelzhu programmeeshanaam jau njemaas gadus un vienalga ir daudz kas ko apguut. ir vesels standarta priekshraksts kaa biibele uz 1500 lapaam uz kuras dzheki tur roku kaa dodot zveerestu.


 Kurā posmā tad viņi uzkārās? tā bīj kompja programmu puse vai tieši paštaisītā PCB problēma ?? ja PCB tad kādus čipus viņi izmantoja?

Man arī ir tās PCI,PCIe SIG  standarta specifikācijas, proti fpga kodu atrast un iemēģināt jau varētu, bet problēma jau ir tajā kā tad es to Plati pārbaudīšu ? nekādu Super Digitālo signālu analizātoru man nav un tur ir kādi 49 signāli   ::  ja kāds slikti strādā, vai slikti pielodējies tad nekas neies. 
1. problēma: man nav instrumentu ar kuriem pārbaudīt tādu signālu kvalitāti,trokšņus un tā tālāk.

un ir jau vēl tā pamatu pamatu problēma ar to pašu PCI standartu ka tas ko es gribēju taisīt laižot signālus caur FET switch nebūtu atbilstoš PCI signālu standartiem, līdz ar to atkal nav īsti garantījas vai viss strādās, bet 3.3V PCI sloti kompjos nav.
Ir izeja lodēt uz plates kādu speciālo PLX PCI controller čipu kurš parūpējās par PCi interfeisa daļu un ārā nāk vienkāršota paralēlā datu maģistrāle no kuras var nolasīt un ierakstīt.

Vēlviens variants bīj taisīt PCIe-x1 karti un tur lai viss būtu pēc standartiem un kautcik saprātīgi lēti likt XIO2000a čipu kas ir PCIe-PCI bridge un tur tad galā būtu 3.3V PCI interfeis kuru jau var savienot ar FPGA pa taisno + ja to dara uz 1nas PCB plates tad problēma ar signāliem nebūs, vienīgi šeit tad vaig 4 līmeņu plati priekš tā PCIe interfeisa un tākā PCIe lai pieslēgtu vaig novilkt tikai 3 ātrgaitas diferenciālos pinu pārus tad kļūdīties un kautko nolaizt grizi domāju ka nav iespējams tākā 95% ka ar pirmo reizi viss varētu strādāt, vienīgi ej un to 4 līmeņu plati uztaisi kādā PCB cehā tas prieks izmaksās padārgi  ::  uz 2 līmeņiem tādu plati var izmocīt bet nebūs nekādas garantijas ka kautkas strādās, un tad bez kādiem super Ghz Osciloskopiem neiztikt lai saprastu kur problēma kādēļ kautkas neiet. 

2. Man personīgi viss smagākā problēma liekās tieši tā paša kompja programešana, jo ja PCB pusē var atrast kompromisu un izeju no situācijas ar augstākas integritātes čipiem tad kompja pusē ar tiem draiveriem, sofitem ir galīgi di**ā, nemaz nerunājot par kādu Linux lai kautko jēdzīgu tur izstrādātu un uzkodētu ir jābūt baigam specam  windows OS progu veidošanā tā ir vesela kodēšanas nozare to draiveru rakstīšana un VisuelC# ir tikai mazs atzars(ka atrodās pašā augšā un izmanto visus sakodētos labumus no apakšas), un es pagaidām esu tikai caur Com portu esu sazinājies ar savu SMD krāsni, caur LTP portu arī var bez problēmām, un USB, Ethernet ir arī reāli jo paši ražotāji jau tos Draiverus ir sarakstījuši + paraug kodus pa brīvu ielikuši atliek tikai novilkt pareizi iestatīt un lieta darīta  ::  

Viena izeja kā kautko iemācītes kodēt tās PCI,PCIe kartes ir paņemt kādu gatavu FPGA Dev.kitu kuram nāktu līdzi visas test kodu paketes,draiveri lai var reāli izmēģināt, bet parasti tie kodi ir Evaluation, kas nozīmē ka ja gribi likt iekš sava čipa tad ej un maksā, vai taisi pats, un ar tiem windows draiveriem tur arī varētu būt problēma jo jāskatās ar kādām programmām tos var kodēt, mainīt pielāgot, tas ir baigais, baigais čakars.

man personīgi gribējās bišķi dziļāk parakt,uzināt par šīm te PCI,PCIe lietām un esu daudzko sapratis, un lai ķertos un patiešām uztaisītu kādu PCI karti man tagat trūkst MOtivācijas, jo nu tas neabšaubāmi ir sarežģiti(no programmēšanas puses) un tādēļ man priekš sava Fpga motion kontrolliera tas liekās pārāk grūts, un arī nelietderīgs ceļš, ieguvums no tā man nebūs nekāds lielais, un nav vērts dēļ šāda Hoby projekta tā mocīties.
Var teikt ka savu Zinkāri es esu apmierinājis, tagat zinu kas tie ir pa Zvēriem bet tālāk rīkošos pēc veselā saprāta un tas vieglākais ceļš (USB) un starp platēm LVDS kautko līdzīgu SPI interfeisam tikai ar citu ātrumu  ::

----------


## sharps

> slabo uzraut kodu prieksh PCI pasham? taksh jau zinaaju ka apalauziisi ragjeljus pie PCI. zinu paaris dzhekus kas pie shaada tipa dzelzhu programmeeshanaam jau njemaas gadus un vienalga ir daudz kas ko apguut. ir vesels standarta priekshraksts kaa biibele uz 1500 lapaam uz kuras dzheki tur roku kaa dodot zveerestu.
> 
> 
>  Kurā posmā tad viņi uzkārās? tā bīj kompja programmu puse vai tieši paštaisītā PCB problēma ?? ja PCB tad kādus čipus viņi izmantoja?


 probleemas faktiski ir visos posmos, gan PCB, gan programmaturas rakstiishanaa. taapeec jau tas ir komandas darbs. vienam cilveekam to visu nepavilkt. kaa saciit jaasaka divas galvas ir gudraakas par vienu. PCI PCB projekteeshanaa vairs nestraadaa tie principipi kas pie vienkaarshu mikrokontrolieru PCB plashu projekteeshanas. arii softwari uzrakstit nav tik vienkaarshi nenjemot veeraa signaalu izplatiishanos buutiibu.
tika izmantoti dazhaadi wireless paredzeeti chipi.
ok pietiek liet uudenjus, ja tieshaam ir interese uz PCI ko taisiit tad labaak savaakt kopaa attieciigus interesentus un nospraust meerkji ko vajag. no nulles kautko taisiit taa ir vesela epopeja. ja to dara tad vajag tieshaam logjisku pamatojumu kam tas vajadziigs. varbut pat biznesa plaanu ir veerts sastaadiit.

----------


## jeecha

Es varbuut kautko esmu palaidis garaam - bet prieksh kam vispaar tas nenormaalais interfeisa aatrums ir vajadziigs ja tu taisies savaa dzelzii taisiit visas interpolaacijas un araa dot solju vai servo vadiibas signaalus?
Protams iespeeja piemaukt kautko pie PC ar PCI/PCIe shinas aatrumu ir skaisti un interesanti - kaut vai aatrus DAC/ADC likt klaat un rakstiit/gjenereet signaalus... bet nu prieksh CNC vadiibas tas nav drusku taakaa "overkill"?
Par tiem draiveru softiem - patiesiibaa tas nav nemaz TIK briesmiigi (varbuut man gruuti objektiivi spriest, es tomeer 10+ gadus straadaaju programmatuuras izstraadee). Sen sen atpakalj naacaas nedaudz piepatchot vienu linux kernelja draiveri kaareiz PCI kartinjai, tad nu sanaaca nedaudz papeetiit kaada konkreeti linuxam taa PCI draiveru arhitektuura ir - katraa zinjaa uzrakstiit triviaalu draiveri kursh stumda datus turpu shurpu starp kerneli un pci karti ir paveicams darbs cilveekam kursh maak programmeet (nejaukt ar "zin programmeeshanas valodu"). Cita lieta ka to visu apgruutinaatu apstaaklis ka ar pashdarinaatu PCI kartinju tu nekad nevari skaidri zinaat kas nestraadaa pareizi - tavs draiveris vai tavs dzelzis, liidz ar to visu parikti atdebugot vareetu buut jautrs pasaakums.
Probleema ar daudzajiem PCI/PCIe fpga "development kit" ir taada ka tie ir diezko daargi (kaa jau lielaakaa dalja dazhaadu mikrenju eksperimentu kitiem).

----------


## Epis

Viena no idejām bīj to visu interpolāciju taisīt komī, piemēram kautvai paņemt to pašu EMC2 linux softu tur varētu klāt piespraust to PCI karti un tad grūst viņā iekšā Step/dir signāla ātruma vērtības un no kartes saņemt Quadratūro enkoderu jau dekodētas vērtības, tātad fpga tad darītu šo te melno darbu gēnerētu un dekodētu signālus ar tādu ātrumu un precizitāti(kvalitāti) kādu kompis nevar pavilkt + signālus skaits varētu būt daudz daudz lielāks tas pats arī uz enkoderiem, tādēl arī lai to visu tiešo informāciju novadītu vaig tādu ātrgaitas pieslēgumu (132MB/s), jo šo rupjo datu apjomi ir lieli.
piemēram GuntaK ideja bīj piespraust kompim klāt papildus parasto PCI-LTP porta karti un tādejādies dabūt papildus IO līnijas, un piespraust pie tiem IO klāt tik ierīces cik vien vaig, bet tad kompim tos visus signālus vaidzēs, ģenerēt un dekodēt, un tas nav mazs darbs, bet es te nerunāju par IO līniju skaita palielināšanu, bet gan par kompjūtera atslogošanu veicot šo te melo signālu ģenerēšanas,dekodēšanas darbu, kas ir ideāli piemērots priekš fpga čipiem.

un šeit pārējie varianti
1. taisīt visu interpolāciju fpga čipā uz čipa nosūtot tikai komandas kautko līdzīgu G-kodam tikai smalkāk un detalizētāk priekš šādām komandām datu pāraides apjoms būs mazs, līdz ar to vaidzīgais ātrums arī būs mazs (ar USB pilnīgi pietiektad faktiski fpga plate varētu strādāt autonomi, ņemt datus no Flash atmiņas un izpildīt (kompi nevaig, vai arī tikai kā monitoringa vizualizācijas ierīci)

Viss lētākā elektronika kas ir nopērkama un kautcik sakarīga priekš mana pielietojuma ir Mesanet.com 5I20 PCI IO karte tur pat ir Motion controller kodiņš, tur priekš PCI interfeisa tiek izmantot PLX čips, kas to visu komunikāciju nokārto, mīnus tāds ka tas čips ir samērā padārgs PCI9030-AA60PI-F mouser.com iet pa 32$   ::    salīdzinot mana fpga maksā 11$, priekš PCI varētu paņemt ciklon III pa 12$ (tam ir vairāk PCI 3.3V compliant IO pinu) tad piespraust klāt 15$ XIO2000 čipu un būtu PCIe-X1 plate  ::  kas detaļās sanāktu lētāk nekā tas 1ns PLX čips. 

Faktiski tā situācija ir tāda pasūdīga ar tām PCI kartēm un viņu standartiem, fpga čipi var atbalstīt 100% PCI 3.3V elektroisko signālu prasības, bet neviens maita (paspruka) netaisa tādas kompju mātesplates   ::   un es piemēram skatos uz savu kompja PCI 10/100 standart Internet karti, kur ir viens mazais Realteck čips un man reāli liekās ta tā PCB plate ir tikai 2 līmeņu un tad es iedomājos ka mierīgi tač var uztaisīt PCI 3.3V karti pieliekot FPGA čipu tik tuvu ka IO celiņu garums būtu mazāks par 10mm līdz PCI slota kontaktam es neticu ka šajos 10 cm varētu tie signāli tā degradēties ka nekas nestrādātu ! 
bet tikai dēļ šīs nejēdzības ar tiem kompju 5v PCI slotiem es šādu karti taisīt nevaru, jo nav, netirgojās neviena mātesplate ar šiem 3.3V PCI slotiem (tikai kautkādas serveru dārgās mātesplates kurās ir tie jaunie PCI-X 64bit sloti un tās plates ir padārgas.
Šausmīgākais ir tas ka tiek taisītas Kompju mātesplates kur chipsets atbalsta jauno PCI v2.3 standartu kas pasaka ka 5V signālus vairs nelietojam, bet tie maitas chipsetu taisītāji uztaisījuši ka viņu čipiem ir 5V IO Tolerance līdz ar to mātesplatēs atkal stāv 5V PCI sloti un var spraust vecās 5v kartes  ::  faktiski neviens pasaulē neievēro šo te PCI SIG V2.3 standartu un izskatā ka nemaz netaisās, jo tagat tač ir PCI-Express, bet priekš tā PCI-express bez 4līmeņu PCI un 15$ XIO2000 čipa neko iesākt nevar, tas nav lētais PCI 3.3V  :: 

kad beidzot parādīsies pirmie PCI3.3V sloti  standart 30-40Ls mātespates ????    ::  
pagaidām lētākā mātesplate ar PCI-X slotu kur varētu eispraust šādu PCI 3.3V karti ir Asus M2N32 WS Pro SLI ~ 100Ls  ::

----------


## Epis

Aizmirsu pierakstīt pašu galveno: tagat šai platei es domāju vilkt līnijas ar 0.15mm atstarpi un  katru Fpga IO līniju par kuru ies ātrie LVCMOS signāli līnijas tiks atdalītas ar GND starplīniju kas savienosies ar apakšējo GND layeri tas tādēļ lai samazinātu signālu Impedence no 134 omiem uz kādiem 70 un atdalošā GND līnija kas samazinās crostalk+ EMI izstarošanu un arī EMI uzņemšanu vārdsakot Plate mazāk radīs trokšņus, signāli būs kvalitatīvāki un varēs ātrāk iet  ::  

Tākā es tagat iešu nevis uz fpga izvilkto izmantoto IO kvantitāti, bet gan uz kvalitāti  :: , pagaidām es vēl nēsu uztaisījis nevienu šādu PCB plati ar šādiem pavisam citas kvalitātes signāliem.
0.15mm atsarpi ceru ka Almiko varēs uztaisīt (vismaz viņi saka ka var  ::  ) un cik es hyerlynx skatījos ta samazino atsarpi no 0.2 uz 0.15% tas impedence rādītājs uzlabojās vidēji par 30%+ietaupās vieta.
jaunajai platei vaidzētu būt pavisam jaunā Kvalitātē, un tas ir mēģinājums izspiest no 2 līmeņu PCB visu labāko ko vien var izspiest  ::  
šeit neliels shematiskais attēls par līniju magnētiskajiem laukiem un kā tie atšķirās 70omu signālam(pa kreisi) no 134omu pa labi (faktiski tas pats kas antena).
[attachment=0:11hmcmfb]2layer PCB impedence_comparison.JPG[/attachment:11hmcmfb]

----------


## GuntisK

Bet paklau Epi! Nemaz tik daudz kompja resursus tās PCI--->LPT kartes nenoņems. Pilnībā nokomplektētai un automatizētai virpai pietiktu arī divu LPT I/O pinu. Tas pats Dave Kowalczyk (TCNC autors) savu virpu vispār vada no viena LPT! Un virpo uz nebēdu! Daudzus procesus vispār var uzticēt kādam PLC, ja jau gribas visu tik ļoti sarežģīt. Man liekas, ka tu drausmīgi pārspīlē ar FPGA izmantošanu un tām Motion control kartēm. Principā jau viss sarežģītais sastāv no vienkāršā. Silti iesaku sākumā salikt ko vienkāršāku, paeksperimentēt, tad radīsies priekšstats ko vajadzētu uzlabot un ko nē. Padarbojies ar TCNC- dabū kkur vecu kompi (kādu pirmo Pentiumu), uzstādi uz HDD tīru DOS, Nortonu un ieraksti TCNC. Šī programma tiešām ir prātīgi izveidota. Pamēģini-ir tā vērts!  ::

----------


## Epis

Visu laiku domāju kā es citādāk varu pieslēgt savu fpga plati ar kompi lai dabūtu kautcik sakarīgu ātrumu, un vienkāršu komunikāciju un tad atcerējos par tiem IDE (Integrated Drive Electronics) slotiem uz sava kompja mātesplates kur spraūzās cietais disks sāku skatītes un tā ir samērā vienkārša 16bit datu maģistrāle vienīgi sākumā nevarēja saprast kā tad īsti tas interfeis saucās un tie nosaukumi ir dažādi: parasti IDE, ATA; Ultra ATA, Mana kompja mātesplate atbalsta Ultra DMA 133/100/66/33, un kā redzams tajos nosaukumos ir tāda kā neliela putra, katrs sauc kā grib, un pats standars sākot ar kuru mana mātesplate tad atbalsta ir ATA/ATAPI-4 (ir arī vecie ATA-1;ATA-2;ATA-3 standarti (visi lēnāki) šito ceturto vēl sauc par "Ultra ATA/33"; "Ultra DMA/33" un tā tie standarti iet līdz pat ātrākajam ATA-7 Ultra-ATA/133, 133MBytes/sec kas starp citu ir tik pat ātri kā PCI 32bit 33Mhz slotam tur sanāk 132MB/s, man pietiktu ar kādiem 30MB/s (tas būtu ļoti labi)
man mājās stāv Cietais disks 120Gb kas atablsta ATA/133, faktiski visi ši nosaukumi un stadarti ir 40 pin IDE konektos kur ir 16bit divirziena datu maģistrālē un papild IO, faktiski papētot vēsturi šitas ATA radās no ISA slota un ir kautkas tam līdzīgs tikai ātrāks ar modernāku protokolu utt.. 

Novilku ATA-4 specifikācijas un PCB uztaisīt priekš sī nevaidzētu būt nekādām problēmām  ::  jo signāli nav nekādi ātrie, un HEader 40 kontaktu deficīts arī nekāds nav vienīgi būs vaidzīgs 5V signālus samazināt līdz 3.3V apmēram tā pat kā PCI 5V kartei izmatnošu to pašus 10bit data buss switch kurus nopirku  ::  

man liekās ka šitas IDE/ATA interfeis ir īstais, jo ar sito es varu pievienot plati pie kompja, pie cietā diska, pie kāda Flash HDD, un arī savienot ar tām minī izmēra mātesplatēm kā micro ATX; PC104 faktiski visām mātesplatēm ir šie IDE kontakti  ::   tākā tas ir īstais risinājums.
no kompja programmēšanas puses sanāk tā ka mana plate būs kā HDD, un primitvāko komunikāciju uztaisīt nevaidzētu būt grūti, vismaz internetā ir visādi kodi,pamācības kā ko darīt, tākā šis te varētu būt pa spēkam  ::  
jāpalasa vēl bišķi tie elektriski perametri un tad jātaisa PCB  ::

----------


## Epis

Ja runā par Procesoriem un to jaudu tad pēc vakardienas man mainījās uzskats ka fpga ir labākais paralēlās procesēšanas paraugs, proti joprojām ir bet tikai zemā loģikas līmenī tur kur iet jau runa par 32,64bit FPU operācijām un matemātiku jeb to HPC (high performance computing) un tad es atklāju tās GPU, es zināju ka tām ir šausmīga procesējošā jauda bet par to ka viņas var pats ieprogrammēt izmantojot C un kādus bez maksas softus nezināju un tad izlasīju vienā vietā par jauno NVIDIA Tesla T10 Čipu kam būsg andrīz Tetra FLPS jauda un tur parādījās tā CUDA programmējamā vide un izrādās ka ar to CUDA var programmēt visas NVIDIA GPU kartes sākot ar  GeForce 8400 sēriju (šitās kartes maksā kādi 25-30Ls   :: ) bet normāli jāņem kāda GeFOrce 8800 serijas tur jau ir 112 stream procesori un tāda jauda ka pietiks 10 CNC virpām  ::  un kompja procesoru šīs kartes saliek kā mazu bērnu, šitā visa fiča ir samēra jauna tā CUDA iznāca 2007 gadā tākā viss tas atīstās tikai pāris gadus. 
Nez vai ir tāda CNC proga kas izmanto šīs grafiskās kartes kā hardware accelerātorus?

Galvenais kas mani iesaista ir tā cena piemēram pa kādiem 75ls var nopirkt lētāko no Geforce 8800 serijas kartēm un tev jau ir 112 procesori kurus ar bišķi uzlabotu C++ valodu un Visual Sudio progu var saprogrammēt.

Man pēkšņi radās MOTIVĀCIJA pamācītes kodēt to kompi (it sevišķi tās mega jaudīgās GPU kartes) 
tagat mana ideāla CNC sitēma izskatītos tā: kāda Lēta kompja Mātesplate ar PCI2 x16 slotu (procim īsti nav nozīmes) + Geforce 8600GT (45ls) + ULtra DMA 33 Fpga zemo līmeņu signālu apstrādātājs (ģenerātors, dekoderis, voltu līmeņu salāgotājs utt..) 
un kāda CNC proga uz Linux, vai windows kur visa smagā matemātika notiktu uz GPU un tad centrālais procis vienkārši būtu kā datu sūtītājs, un centrālo processu vadītājs vizualizētājs apmēram tā  ::

----------


## Vikings

Šitā diskusija sāk raut jumtu.  :: 
Gunti, man liekas Tu runā ar sienu.  ::  Es jau esmu teicis n reizes to pašu. Bet nu tagad vnk ir interesanti ar ko tas viss beigsies. Ja beigsies.
Epi, bet priekš kam Tev vajag tādu jaudu kura var kontrolēt 10 virpas, ja taisies kontrolēt tikai vienu virpu un virpot rumbas?

----------


## Epis

Nuvar jau var tā uz fikso ar kompi visu vadīt un priecāties kā viss iet, bet man gribās to kvalitāti redzēt, apmēram kā Fanuc un citām industriālām, un tur ir tā Spline interpolācija visas atgriezeniskās saites, asu savstarpējā kordinācija, un tas viss smuki maksā un tās sistēmas tur nav nekādas mazjaudīgās ar LTP portiem.
Kā jūs domājat vai ar tādu Geforce 8600GT  CUDA uzkodētu CNC softu un kādu Fpga IO karti nevarētu dabūt tādu pašu rezultātu ??  vai pat pārspēt tos Fanuc un citus industriālos CNC.
Man liekās ka var un apskataties cik tas izmaksā   ::  
fpga tāda plate kādi 30ls, GPU 8600gt karte 45ls un kāds vecs šrota kompis kur iespraust GPU pa 20-25Ls var tādu hlamu dabūt (man pašam mājas stāv viens vecais kompis ar athlon64 2000 proci un PCIe-x16 grafiskās kartes slotu un pirms kāda pus gada es vienam savu pašu pirmo kompi notirgoju pa 10-15Ls tur bīj kāds celeron procis (tam laikam ka nebīj PCIe slota)  tākā šitas viss kopā varētu vilkt uz 100ls   ::  + pats saprogrammē un rezultāts tāds pats kā 1000$ Fanuc kontollierim   ::  tākā ir par ko padomāt !! maksā 1000$ vai saķīlē pats. 
Protams tas nav viegli un lai kautko tādu izdarītu ir jāmācās, un jātērē savs laiks, bet no otras puses tas ir intresanti, izglītojoši,ir ko darīt brīvajā laikā, un rezultātā ir samērā vērtīga manta  ::  

par izstrādes platformu var ņemt to linux moš sākumā to EMC2 (jo tas ir pa velti), un pamēģināt to CUDA uz linuxu un kautkā kopā ar to EMC2 sabīdīt, sākt protams var ar pliku EMC2, bet pirms tur kautko sākt vaig to plati uztaisīt un fpga ielikt to ATA/33 kontrollieri un tad jau redzēs kas tur sanāks.

----------


## zzz

Fantaazijas ir veertiiga manta tikai straadaajot par rakstnieku, tehnikaa vajadzees radiit kaadu krietni taustaamaaku rezultaatu. Abet taads no epja gaisa pilju buuvnieciibas nav sagaidaams un nekad nebuus.

----------


## jeecha

Tas viss ir ljoti relatiivi - manai Sherline CNC freezei man pilniigi pietiek ar stepperiem bez atgriezeniskaas saites kurus vada Mach3 un EMC2 (atkariibaa no garastaavoklja lietoju vienu vai otru) uz P4 1.7Ghz kastes (Mach3 impulsu gjenerators man staav uz 60000 ticki/sekundee, 75000 shitais PC jau vairs nevelk). Es pilniigi apzinos ka reizeem kaadu soli man tas viss pasaakums pazaudee (man ir 200 solji/apgriezienaa stepperi ar 1/8 mikrosolju draiveriem, kopaa 1600 mikrosolji/apgriezienaa, skruuves ir metriskaas 1mm/apgriezienaa - 0.000625mm izshkjirtspeeja, tiesa backslash ir lielaaks, bet ne par to runa). Peedeejo reizi kad testeeju atkaartojamiibu (stundu dzenaaju katru asi shurpu turpu ik pa laikam ar mikrometru pameerot kaada nobiide radusies deelj skipotiem soljiem) secinaaju ka bez slodzes kljuuda ir tik maza ka izmeeriit to nav iespeejams (backslash robezhaas). Zem slodzes varbuut kaads solis vairaak tiek izlaists, bet taapat praksee tam nekaada noziime, vismaz pie PCB urbshanas/routeeshanas, mazu plastmasas detalju freezeeshanas no orgstikla un pvh utml.

Tad nu mana paarlieciiba ir ka labi - servo vai stepperi ar atgriezenisko saiti protams ir labi un pareizi, bet praksee pie lietaam kaadaam es to daiktu izmantoju tam nav nekaadas noziimes, un shaubos vai ritenja rumbu virposhanai arii buutu...

Par to DIY pieeju - tomeer vaig domaat nedaudz plashaak - tas ka detaljas maksaa kapeikas saliidzinot ar kaadu gatavu produktu, ne vienmeer noziimee ka DIY sanaaks leetaak - savs laiks tomeer arii nav par velti. Ja ir veelme vadiit savu superiekaartu, ljoti apshaubu idejas par pashtaisiitu "FPGA kontrolieris no 0 ar PCIe vai IDE interfeisu utml prichendaaljiem" lietderiibu - varu sadereet ka shajaa projektaa tu esi ieguldiijis jau pietiekami daudz laika lai taa vietaa vienkaarshi nopirktu gatavu komerciaalu kontrolieri. Ok, varbuut kautko jaunu arii uzzinaaji tajaa procesaa, bet pareekjini cik laika tu veel ieguldiisi tajaa visaa ja njem veeraa ka patreiz neesi realizeejis pat ne 5% no projekta...
Otra lieta - CNC iekaartai elektronika - tas ir pilniigaakaas pupu mizas, lai arii ne paaraak sarezhgjiita - praksee smagaaka droshvien tomeer ir mehaanika, ja es gribeetu kaadreiz taisiit CNC routeri no 0, es toch saaktu ar mehaaniku nevis kautkaadu vadiibas plati.

Cita lieta ja savu superkontrolieri tu veelies komercializeet - tad varbuut ir jeega teereet laiku un nervus izveidojot produktu kas ir labaaks vai leetaaks par konkurentu razhojumiem, bet tad arii vaig ljoti konkreetu biznesa plaanu nevis "metodom nauchnogo tika" kautko bakstiities.

----------


## zzz

Ja epis savu uuber kontroleri komercializeetu - sajuusminaatie klienti tak vinju pakaartu tuvaakajaa kokaa. Laimiigaa kaartaa nekaada komercializaacija tur nedraud vismaz tuvaakos 10 gadus.

----------


## a_masiks

> varu sadereet ka shajaa projektaa tu esi ieguldiijis jau pietiekami daudz laika lai taa vietaa vienkaarshi nopirktu gatavu komerciaalu kontrolieri.


 Pirms gandrīz gada mūsu varonis atzinās ka projektā "CNC supervirpa divriteņu rumbām" kopā ir iztērējis aptuveni 1000Ls. Naudā. Te der pieskaitīt arī krāsni un pēdējos detaļu pasūtījumus, kas liekas, mērāmi vairākos simtos $.
Ja pieskaita viena cilvēka darbstundu samaksu kaut vai minimālās algas apmērā - summa būs dramatiska, bet mēs tā nedarīsim.
Mēs izlasīsim vienu pērli šai kontekstā un padomāsim mazliet par dzīves jēgu....




> pats saprogrammē un rezultāts tāds pats kā 1000$ Fanuc kontollierim  tākā ir par ko padomāt !! maksā 1000$ vai saķīlē pats.

----------


## GuntisK

Epi-tu tabļetkas nekādas nelieto?   ::

----------


## Epis

iet runa šajā topikā Kā uztaisīt Motoru kotnrollieri, nevis kā strādāt ar kādu parasto hobby CNC softu kas tikai gēnerē step/dir signālus.
Un tākā neviens šeit vismaz līdz šim, nav pats kautko tādu taisījis tad skaidri var teikt ka neviens īsti nezin kā tas jātaisa un kāds ir labākais, lētākais vairants (neiet runa par motion controller pirksānu bet taisīšanu).

Runājot par tām LTP portiem tad labs jautājums man ir cik tad ātri LInux var reaģēt uz ienākošo LTP portā signālu? 
1;10;100us vai 1ms cik attiecīgi ja būtu jādekodē Quadratūrais enkoderis kāda būtu dekodēšanas precizitāte ?? (mazākais laika intervāls, ar kādu var izšķirt ātrumu)
ja šis parametrs nav kā minimums 1us tad LTP ports manā skatījumā enkodera dekodēšanai nav derīgs.
uz manas fpga plates no CPLD es šo signālu ķeršu ar 5-10Mhz frekvenci (taimeri skries ar tādu ātrumu, ja LTP ports un kompis var veikt šo funkciju tad es esu gatavs sekot GuntaK piemēram un spraust kompī kautvai 5LTP porta adapter kartes  ::  jo tad sanāk ka nav jēga lietot nekādu fpga! un to pašu var arī atiecināt uz signālu ģenerēšanu (laigan šeit vaig bišķi augtāku frekvenci kādi 20-40Mhz priekš precizitātes, ar to tikt galā var mierīgi 8bit atmega, vai PIC bet vai LTP ports varēs to izdarīt ??  man liekās ka nē!

neliels oftops par mācīšanās jēgu ko dažš labs nesaprot!
Nu tu a_masik atkal izcēlies ar savu gudrību, pēc tava teiktā konteksta sanāk tā ka cilvēkam faktiski vispār nevaig mācītes, jo tas ir financiāli neizdevīgi, labāk nopirkt visu gatavu jo tā sanāk lētāk.
piemēram kā kautko var iemācītes ja neko netaisa?  te jau ir latvijā lielākais vairākums kas domā ka neko nav jātaisa, jo vieglāk visu nopirkt gatavu, protams ir lietas kur patiešām nav un nevaidzētu izgudrot no jauna kā divrieni, bet mācību nolūkos būtu vēlam tomēr mēģināt izgudrot uztaisīt to divriteni no 0, jo kā ta savādāk saprastīs un iemācīsies kautko taisīt un domāt kā to uztaisīt.

----------


## GuntisK

Varu piekrist tevis teiktajam, ka neko neiemācīsies, ja neko nedara. Runājot par LPT kartēm. Kam tev TIK liels reaģēšanas ātrums?   ::

----------


## a_masiks

Nu, ko. Ja prakse ir iemācīto zināšanu atspoguļojums - ko tad esi uztaisījis?
Strādājošu, pabeigtu projektu!
Ievēro atšķirību : tas ka tu tikai domā, ka nu jau māki - tās ir tikai tavas domas un nav salauzta santīma vērtas.
Iet runa tikai par vienīgi dzelzī realizētiem, pilnvērtīgi strādājošiem projektiem.
Cik tādu ir?
Un tad - kāda jēga no tādas "mācīšanās"?

Mans konteksts ir - katram darbam ir savs mērķis. Ja mērķis bija izgatavot riteņa rumbas - tā arī bija jādara, nevis jāsāk kasīties gar elektroniku un programmēšanu. Ja mērķis bija paniekoties ar elektroniku, programmēšanu - ko tad maldies pa projektiem pa tukšo? Sēdi uz viena projekta, līdz tas sāk normāli strādāt. Kontekstā izskatās ka vēlies tikai visādi gudri izrunāties lai apmierinātu savu ego pēc uzmanības apliecinājumiem. Tev tad jādodas uz http://www.calis.lv vai http://www.sap.lv - varēsi iegūt kāroto  uvagu un pačotu. Resp. - tas ko un kā dari, nekādi neatbilst tava paša uzstādītajiem uzdevumiem. Kota mums brīnīties, ja nevari sasniegt mērķi?....

----------


## Vikings

OK, Epi Tu esi rēķinājis vispār cik vajag reālu ātrumu enkodera detektēšanai? Nu paņemsism tādu vienkāršu un, manuprāt, pilnīgi iespējamu piemēru.
Vītnes solis - 5mm.
Māx. ātrums - 10cm/sek.
Izšķirtspēja - 2um.
Lai pārvietotu asi ar 10cm/sek ātrumu, skrūvei jāgriežas ar 20 apgriezieniem sekundē.
No skrūves soļa un izšķirtspējas izrēķinam, ka enkoderim ir 2500 iedaļas. Tas nozīmē - max.enkodera frekvence dotajai iekārtai ir 50kHz, tas ir 20us periods. Par maz?
Nu liec kaut 10x ātrumu, bet tā pat tas būs tikai pusMHz. Pēc kā Tu tiecies - pēc darboteis spējīgas mašīnas vai pēc "man ir par 2.8% lielāks ātrums nekā 88. gada Fanuc iekārtai un vietējo džeku vidū man krāns gar zemi velkas"? Nolaidies taču reiz uz zemes...

----------


## sharps

lai jau cilveeks muld. es vismaz sen taados tekstos neklausos. taadi kadri zinaami. runaa par to ko nav sajeegas.
epja tekstus ar nevaru normaali palasiit. uudenji. par lektoru taadu... nee labaak nee samaaciis jaunajiem visaadas muljkjiibas.

----------


## Epis

Šeit vikings tavs piemērs parēķinot tālāk.
Piemērma cik enkoderu impulsus vaidzēs lai varētu detektēt motora ātrumu ar 0.1RPM izšķirtspēju ?? tavā piemērā bīj 1200RPM tātad detektējam 1199,9RPM  (papildus arī 1199,8;1199,7 )
Skaties kas notiek: 
ja pie 1200RPM enkodera frekvence bīja 50 000 Hz (kas ir 20 us) pieņemam ka tas ir laika intervāls ar kādu LTP ports var uzķert signālus un šitās 20us mēs izmantosim reķinā cik vaidzēs soļus lai noteiktu to 0.1RPM 

1. Pie 1199,9 RPM Enkodera frekvence = 49'995.75 Hz 
2. starp posmā pie 1199,8 = 49'991,5
3. pie 1199,7 rpm = 49'988,75 Hz 

tagat skatamies kādu vaig laida vienības izšķirtspēju lai varētu detektēt šādus te intervālus  1000/50=20(us)
Sākums 20 us)
1. 20,0017 (us)
2. 20,0034 (us)
3. 20,0045 (us) 
Tālāk salīdzinam pa cik tad nobīdās laika intervāls atņemot iepriekšējo (jeb Delta Laiks)
1. 0.0017us (588Mhz)
2. 0,0017us 
3.0,0011us  (909Mhz)
un iekavās ir redzama šī laika intervāla Frekvences atēls tātad kas parāda kādai vaidzētu būt Taimera ejošajai frekvencei lai varētu ar pirmo piegājienu noķert un izmērīt viena enkodera impulsa ātrumu. 

Un tagat varam aprēķināt cik daudz enkodera impulsus mums vaidzēs lai mēs varētu detektēt starpību starp 1200RPM un 1199.9RPM lūk aprēķins
20(us)/0.0017(us)=11764 cilklus   ::  
Sliktākajā variantā ar 0.0011 sanāk 18181   ::  

Nu un zinkārīgajiem realitātē 11764 cikli uz CNC iekārtas izskatītos kā 11764*0.002(mm uz 1 ciklu)=23.52 mm (2.3cm   ::  
Kā jums patiktu zināt kāds ir iekārtas ātrums ar kautcik pieņemamu precizitāti tikai pēc 2.3cm ! 
Laika intervālos 20us*11764=235280us= 4,25 Hz   ::   man baigi patīk ar šādu te ātrumu var ļoti labi nokontrollēt CNC notiekošos procesus un 4.25Hz PID arī būs baigi efektīvs (no coment)

Tākā pārdomājiet vēlreiz šo jautājumu vai vaig Mhz taimera frekvenci Enkodera signālu dekodēšanai vai nevaig ? 
pats enkodera signāls var neiet ātrāk par tiem 50Khz bet taimerim ir jāiet pēc iespējas ātrāk (10-20Mhz tik cik mikrokontrollieri velk ir normāls ātrums  :: 
man liekās ka esu visu pareizi aprēķinājis, ja kāds atrod kļūdu tad palabojat.

----------


## Epis

manā izpratnē ar 1-5Mhz signālu uztveršanas ātrumu varētu normāli detektēt enkodera ātrumu priekš PID 1-2Khz frekvencē ar samērā labu, pieņemamu (0.1RPM) izšķirtspēju. tākā šeit neiet runa par kādām ekskluzīvām īpašibām bet gan par nepieciešamību nodrošināt sakarīgu precizitāti.
AR SIn enkoderi man būs tā pašvakāk jo tur ADC iet uz 200Khz tad katram kanālam būs tikai 100Khz un tad būs tāda precizitāte kā Vikinga piemērā, bet es ceru to ADC overclockot lai ietu uz 400Kz,  un pilnīgi iespējams ka ja enkodera ātrums palielināsies tad atslēgt ADC režimu un izmantot IO Capture režimu, kas piesaistīts MSP430 16Mhz Taimerim, tad tā izšķirtspēja uz lieliem ātrumiem būs pavisam cita  ::  tātad uz maziem ātrumiem ADC 200Ksps uz lieliem 16Mhz Taimeris, proti kurā meomentā pārslēgties to vaidzēs skatīties.

----------


## Vikings

Ja godīgi es neizpratu daļu Tavu aprēķinu, bet radās viens tāds elementārs jautājums - NAH* VISPĀR KAUT KO DETEKTĒT STARP ENKODERA IMPULSIEM? Izmērīt ātrumu starp diviem enkodera impulsiem nav iespējams, jo vispār nav nekāda atbalsta punkta pēc kura mērīt. Un nu nezinu īsti kādēļ Tava virpa sapratīs, ka iebraukusi auzās pēc 2cm noiešanas, bet manā gadījumā tiktu mērīts katrs enkodera impulss un pārbaudīts uz atbilstību un attiecīgi pieņemts lēmums kā labot neprecizitātes.
Žēl, ka praktiski vairs nav brīvā laika, es tiešām pieķertos līdzīgai lietai un parādītu, ka tur ne 500MHz taimeri vajag, ne GPU ar 112 procesoriem. Varu tik vēlreiz atgādināt - esmu redzējis FANUC iekārtu kuru kontrolē 80x286 procesors un daži izpildošie procesori un viss notiek. Un nerunāsim par kādām Padomju laika CNC iekārtām, kas vēl šodien lasa no perfolentām programmas un griež ka nemetās.

----------


## a_masiks

> Piemērma cik enkoderu impulsus vaidzēs lai varētu detektēt motora ātrumu ar 0.1RPM izšķirtspēju ?? tavā piemērā bīj 1200RPM


 Rēķinām.
1200rpm /0,1spr [step per round] = 12000 spm [step per minute]
izsakām soļus sekundē
12000spm/60sek [sekundes minūtē] = 200.
Tātad lai nodrošinātu prasīto precizitāti, pietiek ar nedaudz lielāku kā  200Hz enkodera signālu.
ņemam kaut vai 5 reizes lielāku enkodera soļu skaitu.
5x200Hz=1000Hz, vai 1kHz.
Pārveidojam signāla impulsa perioda garumā-
1kHz = 1msek. Pieņemam, ka signāls aizņem pusi no perioda.
Tad enkodera signāla garums būs 0,5ms.
Kur te tiek dabūtas mikrosekundes un 909Mhz signāls - man absolūti neskaidra matemātika.

----------


## Epis

Nu tu masik neko nēsi sapratis, un savā piemērā esi paņēmis citus enkodera parametrus.
Te iet runa par izšķirtspēju nevis par enkodera signāla uzķeršanas ātrumu, atiecīgi piemēram ja tavs enkoderis ģenerē 1Khz signālu pie X ātruma un tev tavas signāla nolasīšanas ierīces izšķirtspēja ir 2Khz jeb 0.5ms tad tu vari noteikt šādus ātrumus:
0.5ms;1;1.5;2;2.5 utt
pārveidoju frekvencē tas izskatās šādi: 2Khz;1;0.666;0.5;0.4Khz un tā tālāk.. 
un tagat paskaidro man kā tu detektēsi enkodera ātrumu ja viņš ies ar 999Hz frekvenci ??? ja tu vari detektēt tādus ātrumus kādus es esu uzrakstījis augšā ?? 




> NAH* VISPĀR KAUT KO DETEKTĒT STARP ENKODERA IMPULSIEM? Izmērīt ātrumu starp diviem enkodera impulsiem nav iespējams, jo vispār nav nekāda atbalsta punkta pēc kura mērīt. Un nu nezinu īsti kādēļ Tava virpa sapratīs, ka iebraukusi auzās pēc 2cm noiešanas, bet manā gadījumā tiktu mērīts katrs enkodera impulss un pārbaudīts uz atbilstību un attiecīgi pieņemts lēmums kā labot neprecizitātes.


 Kā nav atbalsta punkta starp kuriem mērīt ja ir 2vi enkodera impulsi viens ilga 145us un otrs 130us tad mēs varam noteikt vidējo ātrumu kāds ir bījis un tas ir (145+130)/2=137.5us vienam impulsam, lūk mēs zinam tagat kāds ir vidējais ātrums un šo Vidējo ātrumu arī izmantojam PID aprēķinā attiecīgi ja PID cikls ir 2Khz tad priekš PID aprēķina mums vaig 2Khz vidējo ātrumu jeb kopējo enkodera noieto ātrumu summu un arī noieto soļu skaitu pa šo laiku mēs vadām iekšā PID algoritmā, nevis katra enkodera ātrumu, proti šāda iespēja pastāv kad vaidzēs arī vadīt 1na enkodera soļa ātrumu, bet tas ir tad ja enkoderis griežās lēnāk nekā PID pamat frekvence un tad būs protams arī jāsamazina PID frekvence, jo PID bez datiem nevar strādāt, ja nav datu tad nav arī aprēķina, bet ja datu ir vairāk nekā PID frekvence tad ņemam visu to datu summu. 

Varbūt te kāds uzskata savādāk ?? 

Faktiski visa šī diskusīja iet par tiem ātrummiem un izskatās ka viss veltīgi  :: 
Radās ideja:
GuntimK es varu ieteikt iespraust labāk savā kompī nevis LTP adapter karti bet gan daudzkanālu COM porta kartes, tad viņš varētu uztaisīt Enkoder dekoderi uz kādas Atmegas,attiny,PIC kuram taimeris skrien ar 16Mhz un tajā čipā veikt visus signalu dekodēšanu + vidējos aprēķinus un tad caur COm portu nosūtīt kompim rezultātu ar 112Kb/s priekš 1Khz PID ar šo ātrumu vaidētu pietikt jo varēs aizstūtīt kādu 14KB/s un tad būs jāsūta kopējais ātrums (24biti)+ noietais soļu skaits(16biti), un tad veicot EMC2 izmaiņas datu savākšanā varētu atslogot kompi jo man liekās ka COm ports to seriālo interfeisu pats hardwareiski dekodē un tā datu nolasīšanas frekvence ir pietiekami zema 14khz lai kompis nepalaistu garām kautkādu informāciju. 
ja gribi būt modernāks izmanto USB čipu bet nu tad vaidzēs ar draiveriem čakarēties.

----------


## jeecha

Par taam frekvenceem - lai no dekodera nolasiitu poziiciju pilniigi pietiek ar 1/(signaala periods/2), taatad praksee tie ir dazhi desmiti kHz. Ja gribas ar nenormaalaako precizitaati dabuut aatrumu - protams signaalu lasiishanas frekvencei jaabuut krietni lielaakai. Bet prieksh kam tev tas aatrums ir vajadziigs ja PID ieejas dati ir poziicija un laiks... Atkal naakotnes paredzeeshanai?  :: 

Runaajot par projektu izstraadi (man ir pieredze lielos programmatuuras projektos, bet noteikti citaas jomaas ir liidziigi, taadeelj taisot kaadu elektroniku es arii censhos vadiities peec taada pasha principa) - projekta saakuma stadijaa parasti tiek noveerteeti iespeejamie projekta riski, un attieciigi lielaakie projekta riski tiek noveersti peec iespeejas aatraak, lai mazinaatu kopeejo projekta izgaashanaas iespeeju. Respektiivi kad uz salvetes ir radusies bilde par to kaada aptuveni buus arhitektuura - skatamies par kuraam no taas daljaam iisti nav skaidrs kaa to uztaisiit un vai to vispaar var taa uztaisiit, un tad pirms zinaamaas daljas saakt taisiit izpeetam shiis riskantaas daljas liidz stadijai kad ir paarlieciiba par to kaa taas taisiit, bet neiedziljinoties pilniigaas detaljaas. Un tikai tad, kad par visaam daljaam ir pilniigi skaidrs apmeeram kaa taas taisiit un ir paarlieciiba ka dotajaa veidaa taas var uztaisiit, kjeramies klaat pie kautkaadas konkreetas realizaacijas.

Shai gadiijumaa ir sanaakusi totaala iedziljinaashanaas vienaa konkreetaa projekta sadaljaa pilniigi aizmirstot par paareejiem riskiem, kas iespeejams ir daudz nopietnaaki - piemeeram pashtaisiita CNC mehaanika vai iespeeja visu sho elektroniku vadiit caur kaadu gatavu softu. Vai tieshaam ir jeega ziimeet PCIe un PCI kartes celinjus ja nav nekaadas nojausmas kaa to visu vadiit kaut vai no EMC2?

P.S. Kaa jau rakstiiju vienaa no saviem pirmajiem postiem sheit - man arii patiik paspamot, it iipashi seezhot darbaa un malkojot kafiju un paraleeli risinot eksistenciaalas probleemas kaa apstraadaat miljoniem finansu transakciju dienaa utml. Taakaa jau ieprieksh atvainojos par shiis bezjeedziigaas diskusijas "uzkurinaashanu"  ::

----------


## Vikings

> Varbūt te kāds uzskata savādāk ??


 Jā, es un ne tikai.
Nu piemēram, kā es organizēju savu servo projektu. Ja nesapratīsi tad vakarā varu iemest arī bildi no Quartusa kur smuki viss redzams.
1. Ir ieeju bloks, kas apstrādā enkodera un Step/Dir signālus. No tiem viņš izrēķina pašreizējo pozīcijas kļūdu.
2. Ir PID matemātikas bloks. Info tas saņem no ieejas bloka, izrēķina izejas vērtību un dod to uz PWM bloku. PID darbojas PWM frekvencē. Mīnuss tāds, ka gadījumā, ja jāmaina PWM frekvence tad arī jāpārkoriģē PID koeficienti pie tādas pašas mehānikas.
3. Saņemto PWM vērtību PWM bloks atstrādā vadot pilno H tiltu.
4. Ir vēl viens bloks, kas atbild par komunikāciju ar vadības AVR proci - sūta regulēšanas vērtības uz kompi, ieraksta matemātikas blokā koeficientus.

Un tas norealizēts uz C II mikrenes. C II tādēļ, ka tas nesatilpa MAX II CPLD. Patiesībā jau to vajadzētu varēt sabāzt arī AVRā, CPLD uzticot tikai PWM vadību, bet nu tik tālu es vēl netiku...

----------


## GuntisK

> Radās ideja:
> GuntimK es varu ieteikt iespraust labāk savā kompī nevis LTP adapter karti bet gan daudzkanālu COM porta kartes, tad viņš varētu uztaisīt Enkoder dekoderi uz kādas Atmegas,attiny,PIC kuram taimeris skrien ar 16Mhz un tajā čipā veikt visus signalu dekodēšanu + vidējos aprēķinus un tad caur COm portu nosūtīt kompim rezultātu ar 112Kb/s priekš 1Khz PID ar šo ātrumu vaidētu pietikt jo varēs aizstūtīt kādu 14KB/s un tad būs jāsūta kopējais ātrums (24biti)+ noietais soļu skaits(16biti), un tad veicot EMC2 izmaiņas datu savākšanā varētu atslogot kompi jo man liekās ka COm ports to seriālo interfeisu pats hardwareiski dekodē un tā datu nolasīšanas frekvence ir pietiekami zema 14khz lai kompis nepalaistu garām kautkādu informāciju. 
> ja gribi būt modernāks izmanto USB čipu bet nu tad vaidzēs ar draiveriem čakarēties.


 Paldies par ieteikumu, bet...   ::  Nav man vajadzīgs tāds enkodera-dekoders. Serviķiem man būs step/dir vadāms draivers (iet runa tieši par virpu). Un tici man- pašlaik mani nekas cits (programmatūra, kompja ātrums u.t.t.) tā nebaida, kā jaudas daļas (resp. izejas tranzistori, to vadība) pareiza izveide. Bāzēts draiveris uz ATTINY2313 (kautgan tagad vairāk skatos uz ATMEGA8,16 pusi... ). Vot lai tas MK arī skatās to enkoderi-ko viņš dod laukā un tml. Kompis viņam padod STEP impulsus un lai tā plate arī nodrošina iziešanu pozīcijā. Usje! 
Jāsaka viens- būtu NESALĪDZINĀMI labāk, ja tu Epi censtos izveidot plati kompim, kura ar DAC palīdzību izdod laukā +/-0...10v signālu un saņem enkoderu signālus no motora, un vada elektroautomātiku. Tas tā- savietojamībai ar industriālo standartu.

----------


## Epis

Par projektiem tad tos varētu iedalīt 2 kategorijās: 
1 tie projekti kurus taisa savā sfērā kuru labi pārzini un vari ātri visus novērtēt,izvērtēt un kādu sakarīgu,reāli izpildāmu darbības plānu uztaisīt.
2 tie kur zināšanas ir pilnīgi 0 tad nav iespējams neko izvērtēt, un kādus laika limitus nospraust un šeti viss totiek processa gaitā, faktiski šāda veida projekti ir tie kur ir kautkas jauns jāizgudro, jāatklāj. 
Es gribētu redzēt kādu izgudrotāju kurš tā pēc pasūtījuma varētu nedēļas laikā kādu nopietnu izgudrojumus uztaisīt, ar to es gribu teikt ka šādus processus nevar paredzēt, varbūt super idejas radīsies pēc pāris dienām, a varbut pēc pāris gadiem, tākā šeit veiksmes % ir ļoti zems, salīdzinot ar 1. variantu kur faktiski 90% ir veiksme un tie 10% ir visādi sīkumi kas būs papildus jārisina.

un mans gadījums ir 2. nejaušibas rezultātā ievaidzējās cnc uztaisīt un kā zināms tad tādā jomā kur neko nezini nevar nekādus riskus un ko citu novērtēt kamēr kautko neuzināsi, un lai kautko uzinātu ir jārokās pa to visu lietu, varbūt es bišķi pa dziļi roku un pārāk bieži noeju no galvenā ceļa pētot tādas eksotikas kā PCIe (gribās jau zināt kā strādā modernākās tehnoloģijas ! ) un bišķi aizrāvos ar BGA lodēšanu (tas bīj kā izaicinājums -> sanāks vai nesanāks, tad vēl Video sensori, DDR atmiņas un citas augstākās tehnoloģijas, faktiski tā ir zinātkāre par to no kā tad sastāv visa elektronika un kā tā darbojās, tādēļ pētot visu nozari kopumā laiks iet un iet  ::  
bet nu esu jau gandrīz visu izpētījis un tādēļ apstājos pie ULTRA DMA 33/66/100/133(modāju ka šito varētu arī pavilkt) 
jo tas ir Lēts komunikācij veids viss ko vaig ir Header kontaktiņi(pārdesmit santīmi)
-Nav striktas prasības pēc daudzslāņu PCB un visādiem impedence parametriem (ar 2 līmeņiem pilnīgi pietiek)
- IO skaits ir daudz mazāks nekā PCI slotam.
-Un kā redzat ir dažādas ātruma pakāpes sākot no kādiem 33MB/s līdz 133MB/s(PCI ātrums) un domāju ka mātesplate arī atbalsta galīgi vecos ATA standarus tie ir vēl lēnāki 8;16MB/s tākā cik vaig ātrumu tik arī būs  ::  
-Šeit nav nekādas Laika aiztures(pauzes) kādas ir USB,Ethernet interfeisiem(ir speciālais industriālais internets Sercos III)
-IDE kontakti ir visās Mātesplatēs.
-Var pie viena vada pieslēgt 2vas IDE kartes(cietņus) viena master otra slave  ::  godīgi sakot es tagat sāku domāt vai man tur uz plates vispār to LVDS kontaktu vaig? jo nu ar šo IDE vadu var savienot 3 kartes kopā  ::  un pie kompja piespraust 2vas + kompim parasti ir 2vi IDE sloti citiem pat 4ri tākā spraud klāt cik gribi  ::  + ir arī SATA-> IDE pārveidotāji (cietajiem diskiem), tos arī var izmantot lai dabūtu papildus IDE slotus  ::  tākā vai man vispār to LVDS vaig ?  laikam jau ka nē. tai vietā labāk ielikšu papildus RJ45 kontaktus priekš enkoderiem, varētu arī ielikt kādu DAC vai arī nelikt neko.

Tagat beidzot nolēmu kompī ieinstalēt Linuxu Ubunt 8.04 tad man vienā cietnī būs 2vas OS, windows un linux  ::  un tad pamēģinās padarboties ar to EMC2 un aptīties kā ko tur programmē, es tā jūtu ka būs jāmācās tas linux programmēt lai tos draiverus uztaisītu un kautko tajā EMC2 progā pielabotu pēc savām velmēm, un ja ar kompi būs pa švaku tad GPU accelerātoru varētu pakodēt  :: .

----------


## Epis

Nu tā es izdomāju ka vaig tomēr uz Plates uzlikt SDRAM 128mb  (133Mhz) čipu  :: , un tākā man ir fpga tikai ar 90 IO līnijām tad nācās meklēt kompromissu par to kur lai dabūn 28IO priekš SDRAM čipa, un tākā IDE,SPI flash daļām neko nogriezt nevar tad nācās samazināt CPLD IO pieslēgumu skaitu no 15uz 13 un STM32 proča pieslēgumu IO skaitu no 13 līdz 6(divas SPI līnijas katra ar 18Mb/s ātrumu)

Par SDRAM es tagat tā pamatīgāk izpētīju kā tas čips tur strādā, kas īsti ir ar tiem Refresh, precharge režīmiem, un kā vispār ar viņu komunicē un esu visu pamatos sapratis, galvenais taisot PCB ir tas ka nevaidzēs likt nevienu Terminācijas rezistoru (tādu man uz plates nebūs).

Slikti ir tas ka man ir tikai 1 tāds čips  ::  un te Lv tādu atmiņu nopirkt nevar, labi ir tas ka ir digikeyā (micron) un mouserā( ISIS) un itkā 2vas dažādas firmas bet SDRAM čipu IO pini ir vienādi (tur ir SDRAM standartiņš tākā ja strādās šitā SRAM atmiņa tad nākošreiz ka sūtīšu paņemšu vēl  ::

----------


## Epis

Būšu bišķi kļūdījies IDE IO skaita aprēķinos un taisot IDE shēmu PCB progai izrādās ka tur vaig 31IO (agrāk saskaitīju 37IO), pāri paliek kādi 6 IO un tad no tiem es varētu uztaisīt LVPECL 3.3V diferenciālo standartu ar šito te var sūtīt signālus kautvai pa 100metru garu vadu  ::  apmēram kā Ethernet 100, protams jo garāks vads jo mazāks ātrums, un to cik ātri iet tas LVPECL es īsti nezinu, bet vaidzētu būt ātri (līdzīgi kā LVDS) kādi 400Mb/s  domāju ka būtu reāli par kādu 1metru vadu  :: .
ja kas LVPECL plus ir tāds ka viņš iet uz 3.3V līmeni līdz ar to nav vaidzīgs papildus DC regulātors .

Es tā tagat domāju vai man vispār pietiks ar 3.3V 1A  (3.3W jaudu) jo mans LDO vairāk izspiest nevarēs !  ::  
SDRAm atmiņa noēdīs stabili kādas 0.5A un vai visam pārējam pietiks ar 0,5A ?

----------


## Velko

Kas tā par OMFG atmiņu, kas veselus 500mA ēd? Man liekas neticami, neesi kautko sarēķinājis šķērsām?

----------


## jeecha

Joprojaam apshaubu visa shitaa pasaakuma praktisko jeegu un neticu ka tas kaadreiz tiks realizeets liidz galam.

Bet par SDRAMiem runaajot - vai tad tev atvilknee nemeetaajas kaads vecs DIMM modulis vai grafikas karte vai skanju karte? Uz tiem tak parasti meetaajaas kaadi SDRAM chipi un interfeisi vinjiem ir diezgan standartizeeti (atshkjiras tikai busa platums kas uz DIMM moduljiem parasti ir 8 biti un timingi). Datasheetus googlee gan jau atrast var un uz veciem DIMM moduljiem parasti ir 8 chipi (8chipi * 8biti katram = 64biti kopaa, vai arii 9 chipi uz ECC moduljiem, jo tiem ir 72biti kopaa), taakaa vienu vecu atminjas moduli ar karstu gaisu (vai tavaa gadiijumaa ar cepeshkraasni arii) var paarstraadaat par jauniem astonjiem atminjas chipinjiem  ::

----------


## Epis

> Kas tā par OMFG atmiņu, kas veselus 500mA ēd? Man liekas neticami, neesi kautko sarēķinājis šķērsām?


 reku no Micron Sdram datasheeta: 
Auto refresh current: CKE = HIGH; CS# = HIGH; tRFC = tRFC (MIN) IDD5    manam čipam ir  310 mA   ::  
+ vēl tač ir jāskaita klāt IO patērētā jauda kas SDRAm itkā būs 4ma tātad 29IO x 4ma =116ma, no fpga puses to IO jaudu var regulēt attiecīgi uzlikt kautvai 8ma tad tas cipars dubūltojās. tākā 500ma priekš strādājoša SDRAM ir normāli.
Priekš SDRAm atsevišķi parasti iesaka 1A DC regulātoru a man tas regulātors būs vissam.

kopā saskaitīju un sanāk ka vaidētu ap 1.5A (sliktākajā gadījumā ka viss strādā) un tas nozīmē ka normāli vaidzētu 2A DC barošanas bloku  ::  
Būs jāuzliek papildus TLV1117-3.3 regulātors 0.8A priekš SDRAM un kāda CPLD.

Par jēgām runājot tad tas jau visiem ir skaidrs ka pašam taisīt kautko nav nekādas jēgas, ja var nopirkt visu gatavu, 
man jau pašam dažreiz liekās ka es šo plati taisu taišanas pēc  ::  proti pats taisīšanas process ir svarīgāks par rezultātu tādēļ laikam tik ilgi man šī lieta velkās jo man šis PCB taisīšanas process ir iepaticies, to varētu nosaukt par PCB taisīšanas māniju  ::  un tādēļ es arī skatos ko? cik daudz? es uz tās savas plates varu sabāzt, tā lai tas strādātu, jo nav jēga uztaisīt nestrādājošu PCIe plati tikai dēļ tā lai būtu kur uzlodēt kādu Kruto PCIe bridge čipu (man tāda ddoma bīj bet es pārdomāju jo iespējamība ka tas strādās uz 2 līmeņiem ir ļoti zema  ::

----------


## Vikings

> + vēl tač ir jāskaita klāt IO patērētā jauda kas SDRAm itkā būs 4ma tātad 29IO x 4ma =116ma, no fpga puses to IO jaudu var regulēt attiecīgi uzlikt kautvai 8ma tad tas cipars dubūltojās. tākā 500ma priekš strādājoša SDRAM ir normāli.


 Nestāsti brīnumus, kaut ko toč neesi sapratis, katrā ziņā neticu, ka KATRA RAMa kāja ēd 4mA. Tas taču būtu totāls nonsenss...

----------


## Epis

Tā jau protams ka nav ka visu laiku tā Ram kāja ēd 4ma tā ēšana notiek tikai tajā momentā kamēr loģiskais signāls nav nostabilizējies, jo otrā galā iejošie Buferi nēed neko, bet tā ēšana notiek uz tās PCB celiņu un paša čipa kājas Kapaciātātes, induktivitātes rēķina jo tur tas lādiņš uzkrājās pie loģiskā 1 un izlādējās pie 0 un tā tad ir tā patērētā jauda, es vismaz to tā loģiski spriežot izprotu, LVcmos tas ēšanas perjos ir kāda ~1ns , tādeļ arī ir tā ka jo Augstāka signala frekvence jo lielāks energo patērīņš  dēļ tā ka visu laiku jālādē, jāizlādē tā datu līnija (apmēram tas pats kas lādēt izlādēt kapacitātoru, vai induktoru).
šeit arī ir tas termins Simultanous Switching Noise (SSN) tas ir tad kad vairums Izeju slēdzās vienā perjodā tad uz to ~1ns tā patērējamā jauda ir Šausmīgi liela (tāda kādu es tur izrēķināju)   ::  
pozitīvi ir tas ka fpga var tos efektus samazināt uztaisot laika aiztures daļai no IO pinu piemēram slēgt tās IO kas ir īsākas bišķi vēlāk (kādu 1ns) tad šis SSN efekts izlīdzināsies un netiks vilkts no barošanas bloka nenormāls, momentāns, strāvas daudzums kā rezultātā kritīsies spriegums un izejošie signāli būs nekvalitatīvi.
Tākā Fpga var Visus šitos SSN, (tai skaitā arī EMI) tīri labi var regulēt, ar nevienu citu mikreni neko tādu izdarīt nevar!), protams es neko sākumā regulēt netaisos, bet būtu intresanti papētīt šitās lietas   ::  vienīgi man tādas arpatūras nav ar ko pētīt tos nano sekunžu signālus. 

Atklāju tomēr ka šai ECP2 fpga ir tomēr pilnie LVDS draiveri, bet tikai pāris IO piniem labajā, Kreisajā  bankā, tieši tas pats ir arī ar Ciklon III par spartan3 nezinu moš tur visi diferenciālie ir pilnie LVDS, bet reāli jau nav vaidzība visiem IO būt diferenciāliem, galvenais ka šai Fpga iejošie diferenciāliem IO ir pilnie LVDS,LVPECL reciveri(+ārējais rezistors jāliek pašam), salīdzinoši ciklonam III LVPECL standarts ir tikai uz Clock IO tākā Ecp2 var pat teikt ir labāka fpga par CIII  :: 

Vakar savilku, pārliku STM32 IO pinus un CPLD+SPI flash un SDRAM(daļēji savilkts) šodien jāturpina, ir tā ka ir jāmeklē kompromissi tajā vilkšanā jo viss ir ļoti blīvi (100% IO ir izmantoti) tā kā nav viegli vilkt šito izmēros palielo PCB.
labi ka man ir TQFP iepakojums, ja būtu BGA tad par signālu kvalitāti varētu vispār aizmirst (tur bez 4 līmeņiem uz BGA čipu var pat neskatītes (tad ja grib vilkt kādu 50-70omu ceļiņus ar zemu crostallk4).

----------


## Velko

> Tā jau protams ka nav ka visu laiku tā Ram kāja ēd 4ma tā ēšana notiek tikai tajā momentā kamēr loģiskais signāls nav nostabilizējies


 Un kā tu domā, priekš kam tad mikreņu barošanā liek decoupling kondensatorus?

----------


## Epis

Kautkur bīj Alteras dokumentos formulas kur var aprēķināt cik daudz tie IO ēdīs pie tādas un tādas frekvences.
man to decoupling kapacitātoru būs papillo (man ir dubultie SMD  0.1uf) 
jaunais aprēķins:
pie tādiem SDRAM atūmiem (100-133Mhz) būs tā ka kopējais laiks ir 7.5ns un tad ja pieņem ka 2ns signāls kāpj 3 krīt tad stabili bez izmaiņām viņš tāv tikai kādas 2.5-3ns līdz ar to 2/3 daļas visa laika tiek slēgta IO līnija un tad dalam šo ciparu uz 2vi jo tikai vienā reizē tiek IO līnija uzlādēta lidz 3.3V tātad Energo patēriņš ir 1/3 no IO Spēka(4ma) un tas sanāk 1.33ma (nav nemaz tik daudz  ::  bet sasumējot tos 29signālus sanāk 38.5ma itkā nav daudz, sliktāka situācija būs ar to IDE jo tur tas paralēlais 40pin vads būs ar lielāku kapacitāti un tie augšanas un dilšanas ātrumi ievērojami lēnāki (kā kuram standartam) tajos ATA 4 specifikācijas dokumentos bij minēts tas energopatēriņš īsto ciparu esu aizmirsis bet bīj kautkur virs 100 ma .

uzlikšu uz PCB vietu Otram LDO regulātoram TL1117 un tad redzēs vai vaidzēs lodēt vai nevaidzēs, ja kas būs rezerve.

----------


## Epis

Nu ko šeit bilde Kā es esu knapi knapi savilcis SDRAM atmiņas IO   ::  
atstarpe starp līnijām 0.15mm signāla līnijas 0.25mm un stdalošās GND 0.2mm starp visiem signāliem ir GND līnija tādejādi sanāk Signāla līnijas impedence 70 omi. ir tā ka zemākas pretestības celiņus dabūt pie tik blīviem signāliem ir neiespējami un tas ko es izdarīju protams ir uz Robežas redzēs vai Almiko varēs tādu PCB vispār uztaisīt.
Jāķerās klāt IDE vilkšanai. un tad LVPECL un Power līnijas.

----------


## Vikings

Tev neliekas, ka pa apakšējo slāni ejošais masas savienojošais celiņš ir galīgi garām? Atbildi pamato.  ::

----------


## Epis

> Tev neliekas, ka pa apakšējo slāni ejošais masas savienojošais celiņš ir galīgi garām? Atbildi pamato.


 Viss kārtībā tas zilais ir GND leyeris kas tiks aizpildīts pašas beigās un tur lejā pagaidām izņemot GND citu vadu nav  vēlāk jāpieliek kautkur zem pašām čipa kājām 3.3V barošanas vadi un tad lieta darīta.

Vispār izskatās tie celiņi savilkti samērā šausmīgi, bet nu neko darīt negribās maksāt 3-4x lielāku cenu par 4 līmeņu PCB un tās ir tikai lētākās 4līmeņu PCB cenas, ja taisītu ar tādiem VIA un ceļu izmēriem kā es te tad tā plate maksātu pat 5-7X dārgāk nek tagadējās, tākā nekas cits neatliek kā mocīties ar tiem 2 līmeņiem  ::  un izgudrot visādas Viltības lai tiktu pie tiem "krutajiem" parametriem celiņu parametriem. 
par 4 līmeņiem var domāt tad ja tiek izstrādāts kāds komerciāls produkts tad tas ir pat ekonomiski izdevīgāk nekā 2 līmeņi jo sanāk miniatūrāka plate, un mazāk laika aiziet vilkšanā.

APstījos Lattice mājaslapā ir parādījušās cenas jaunajai XP2 fpga un lētākā 144pin pakā ies pa 12.5$ man liekās ka tas ir baigi lēti, nopirkt vēl pagaidām nevar bet gan jau kautkad varēs.

----------


## jeecha

Par 4 slaanju PCB runaajot - TIK briesmiigas taas cenas nav - ja labi pameklee var atrast kantorus kas prototipus taisa arii leetaak par 100$ par vienu eurocard izmeera plati ja pasuuta tikai vienu (kjiinieshi parasti par shipping necenshas nopleest 9 aadas, vinji saprot ka 100$ veertu plati nav jeega suutiit ar 200$ Fedex).

Par SDRAM routeeshanu - es no taa neko nesaprotu, bet esmu maniijis ne vienu vien 2 slaanju plati kur 100Mhz SDRAMa signaali ir norouteeti vienaa liimenii un otraa nav pat "ground plane", piekam celinji nav ne garumaa matchoti un nemaz tik iisi nav. Katraa zinjaa parokot kaadas tikai pasaulee cilveeki plates neizmanto saviem SBC uz ARM7/9 tad visaadus briinumus atrast var un kautkaa vinjiem tas viss tomeer straadaa.

Un atgriezhoties pie SingleBoardComputer - ja iedomaatu plashu routeeshana un ciinja ar veejdzirnavaam nav dziives nepiecieshamiiba - varbuut vienkaarshi panjem kaadu SBC ar kautkaadu ARM7 vai ARM9 vai ARM11 procesoru kuram blakus jau ir SDRAM, flash, FPGA, kaa arii chupa RS232, USB, ethernet, SD/MMC, chupu GPIO iznestiem uz pin headeriem un veel visaada perifeerija? Taadus pa kaadiem paarsimts zaljajiem var dabuut ar jau ieshuutiem bootloaderiem kas pa seriaalo vai tftp maak rakstiit flashaa... un nebuus jaachakareejas ar plates routeeshanu.

----------


## Epis

> Par 4 slaanju PCB runaajot - TIK briesmiigas taas cenas nav - ja labi pameklee var atrast kantorus kas prototipus taisa arii leetaak par 100$ par vienu eurocard izmeera plati ja pasuuta tikai vienu (kjiinieshi parasti par shipping necenshas nopleest 9 aadas, vinji saprot ka 100$ veertu plati nav jeega suutiit ar 200$ Fedex).


 Nu nez kur tu tik lētu cenu 4 līmeņiem esi atradis ? 
 es par 100$ neko atrast nevaru lētākis ir kādi ~150$ par 2vām 3x3inch platēm (tas ir pamaz man vaig lielākas)
apmēram tādas ir lētākās cenas tajos onlain shopos, varbūt esi sajaucis jo dažviet itkā reklamē ka ir baigi lēti, bet apakšā ar maziem burtiem uzrakstīts ka vēl jāpiemaksā tooling cost kādi 110$  ::  tākā ne viss kas izskatās lēti ir patiešām lēti. 
+ visi pasta izdevumi un atmuitošana beigās sanāk ka jāliek klāt vēl kādi 50-60% pie summas un tad ir virs 100Ls  ::  
+ dažviet ir uzrakstīts ka divi vidējie līmeņi ir POWER leyeri pie kuriem itkā var pievienot tikai VIA un tad faktiski sanāk 2 līmeņi tikai priekš Vilkšanas, bet šitas variants tomēr ir labāks par plikiem 2 līmeņiem jo tad lai dabūtu normālu līniju impedence nevaidzētu vilkt tos starpceliņu.

Paņemam vienu piemēru šeit links: http://www.expresspcb.com/ExpressPCBHtm ... andard.htm
tur ir tas Fiksētais vidējais GND,POWER leyeri (kuros neko vilkt nevar tikai ar VIA savienot un ar to faktiski man pietiktu lai normāli varētu savilkt IO līnjas SDRAM ar 70 ohm impedence bez starp GND līnijām jo atstarpe starp top un iekšējo GND ir 12mil kas padara 10mil microstrip pliku celiņu par 70 ohmu impedence celiņu (standart 2 līmeņu platei tas cipars ir 134omi)
tākā ar šādu 4 līmeņu PCB pilnīgi pietiktu un kvalitāte būtu super  ::   (tur specifikācijās viņiem mazākais ceļš atstarpe ir 6mil un caurums 8mil ar šādiem parametriem varētu pat normāli uztaisīt  PCB priekš BGA čipa  ::  jo es te izrēķināju ka ar 6mil ceļu varētu izvilkt pirmajās 3 rindas (divus celiņus starp lodēm (lodes lodētos pie 0.25mm kantaina četrstūra (es jau tā esu darījis un lodējis) 
pricing formula is: $130 + ($0.87 * NumberOfBoards * BoardAreaInSquareInches) + ($1.25 * NumberOfBoards) + Shipping.

----------


## Epis

Es tā domāju domāju par tiem SDRAM celiņiem un pārējiem celiņiem kur es uzliku to atdalošo GND līniju un reāli izdomāju ka tas ir galīgi garām jo celiņa garums ir ļoti mazs un nekāds briesmīgais crostalk un EMI tur neveidosies un šorīt pārbaudīju uz Hyperlynx un tā sanāk ka ja ceļa garums ir 1inch (0,25mm ceļš atstarpe, 3.0Lvcmos 4ma spēks) tad tas crostalk ir jau tāds paliels pie 600mv, bet tas ir normas robežās un nespēs kaitēt, jeb radīt gļukus, + DRAM gadījumā šeit bildē var redzēt ka lielākā daļa ceļiņu ir īsāki par 1inch (25.4mm) faktiski tur ir tikai 3 celiņi (garākie) kuri sasniedz tādu garumu visi pārējie ir zem 25mm vidēji 10-20mm tākā sdramam vaidzētu iet uz max (133Mhz). + kā redzams es SSDRAM čipu novietoju Maximāli tuvu fpga un IO izkārtojums tāds lai celiņi būtu Maximāli īsi, jeb īsākais iespējamais variants  ::  
Var arī redzēt kā izskatīsies IDE Kontakts un Izvilktie IO (šito kontaktu bīj grūti vilkt jo tur ir tas 5V buss switch ierobežotājs + rezistoru čupa (visiem (31) IO ir šie te rezistori lai būtu mazāk jālodē saliku 4x rezistoru matricas (tur kur varēja).
Vēl jādavelk STM32 cīps, jāizvelk 3 LVPECL līnijas un Power pini jāpievelk tur kur viņu nav. tad PCB būs gatavs. 

[attachment=1:v357r36u]PCB_UltraDMA100_sdram.JPG[/attachment:v357r36u]

Es vakar, aizvakar tā bišķi pasapņoju par 4 līmeņu PCB un to PCIe plati kādu es varētu uztaisīt ar to XIO2000 čipu un sapņošana izpaudās tā ka uztaisīju PADS progā PCIe čipa fotprint,shēmas simblolu un Ecp2 BGA256 čipa shēmu un PCB bildi un tad fiksi uzmetu aptuveno shēmu kā varētu slēgties pamat abi čipi ar PCI interfeisu un tā vizuāli Routerī savilku daļu.
un vilku es ar mazāko  ceļu, atstarpi 6mil un no BGA 256 čipa ar sādiem parametriem var izvilkt pirmās 3 rindas  ::  un tie čipi velkās tīri labi faktiski var viņus likt blakus vienu otram ļoti tuvu.
es izrēķināju ka tai fpga BGA iepakojumā es varētu pieslēgt klāt pilnīgi visu ko līdz šim bīju iedomājies,iegribējies  :: 
SDRAM,NAND flash,CPLD,IDE,PCI32,STM32, SPIflash un pāris fiferenciālo LVpecl (lvds).
varbūt kautkad nākotnē kad būšu uztaisījis šito plati un kautko jau uzkodējis tad varētu uzzīmēt tādu vienu (visu vienā) PCB arī ar to super PCIe interfeisu.  atklāju ka ar daudzslāņu platēm var veidot arī tos integrētos capacitātorus ( ~10pf) no iekšējiem GND,POWER slāņiem faktiski šādas viltības būtu jāizmanto ja tiktu taisīta kāda PCIe plate.
[attachment=0:v357r36u]PCIe_xio2000-example.JPG[/attachment:v357r36u]

----------


## Epis

Paintresējo par tām 4 līmeņu platēm un no igaunījas atnāca tāda dīvaina cena par 100x160mm PCB 295.272 EUR + TAX un ta cena ir vienāda 2 un 4 platēm. īsti nav skaidrs vai tās ir plates ar visiem "Navarotiem" kā silkscreen, Maska utt +visi super minī celiņi (2mil) un caurumi 4mil un kas zin moš arī Blind VIA   ::   ie iet cenā, tākā par igauniju var teikt ka tas ir labi ka viņi vispār kautko taisa, bet no kā veidojās cena īsti vēl nav zināms. ? 

Ir vēl 2vi varianti kur varētu kautko lētu uztaisīt, 1. batchpcb.com  (nēsu vēl iereģistrējies un pamēģinājis iziet viņu DRC-Bot PCB pārbaudi vai viņi vispār var uztaisīt to ko man vaig, pārsvarā lielākā problēma ir ar tiem VIA prametriem kuri ir tākā Miglā tīti apmēram tā ka pasaka ka min caurums ir 13mil, bet nekur nav rakstīts kas ir ar to Anual ring, jeb Kopējo VIA izmēru citur tie parametri ir vēl lielākā putrā, nav normāli uzīmēta mazākā iespējamā VIA ko viņi var uztaisīt. 

Aizsūtīju failus uz FreeDFM.com (DRC Bots ) lai pārbauda kļūdas un iespējamo uztaisīšanu + cenu 4pcb.com shopā  tādu parastu Test failus.

REku maza bildīte kur tas XIO2000 PCI interfeis jau ir pilnībā savilkts ar fpga + pull up rezistori savās vietās (izkārtojumu protams var uzlabot, bet tas ir tikai pirmais uzmetums, lai pārbaudītu vai vispār ir vērs kautko tādu taisīt un cik tas maksā, jo ja maksās dārgi tad nav jēga taisīt un kautko tālāk darīt.
[attachment=0:2etr4w7d]PCIe_xio2000-example2.JPG[/attachment:2etr4w7d]

----------


## Epis

Ir problēma ar Drill failu kautkāda iemesla pēc tas Pirmkārt nedod ārā normālu NC drill formātu (trūkst daudzas lietas) šito problēmu es itkā atrisināju Manuāli ar roku pārkopējot un ierakstot pats tos trūkstošos ciparus (par paraugu ņēmu P-Cad drill failu.
Lielākā problēma ir ka tās Drill Faila korinātes nesakrīt ar Gerber failu caurumu kordinātēm, esu izmēģinājis visādus variantus arī offset, problēma ir tā ka katram failam ir kautkāds savs mērogs un tad sanāk ka gerber ir mazs, bet Drill fails daudz lielāks līdz ar to pat ja ar offsetu piedabūn kādu 1nu VIA tad pārējie nesakrīt  ::  

Karoči nezinu ko lai dara.  ::   pēc tām stūlbajām pamācībām itkā viss notiek vienkārši tikai pēctam kad skatās viewmate progā tos failus tad nekas nav kā vaig  ::

----------


## Vikings

Epi, vai gadījumā failu atšķirība nav 25,4 reizes? Nu tad vnk viens ir mm otrs collu mērsistēmās un gala rezultātam jābūt vienādam.

----------


## Epis

Beidzot kautkas sanāca. uztaisīju parastu test progu ar 2x5 Header kontaktu kur apakšējais caurums ir tieši 0,0 kordinātē.
un tad skatījos ko kompis dod ārā un šeit bildē šķībā ir tas ko standartā ar default parametriem PADS izdeva (gerber un drill kopā nesader, un gerber ir vispār kautkur baigi tālu aizbīdījies prom (ofsets x,y bīj 1000) 
otrā bildē uzliku ofset 2000 un tagat jau bīj labāk ar gerber novietojumu, tas atradās jau Viewmate progas centrā bet caurumi atālinājās un tad es sāku skatītes kas ir ar tām kordinātēm un atradu to ka Caurumiem visi cipari ir ar 1nu nulli lielāki līdz ar to tas ir 10X lielāks izmērs nekā gerber zīmējums un tad es ar rokām izlaboju noņēmu no beigām 1nu nulli (sākumā mēģnāju likt klāt 1nu nulli sākumā, bet tas neko nedeva vaig ņemt nost to nulli. 
[attachment=0:1v8bc315]Gerber-Drill defekts.JPG[/attachment:1v8bc315]
un pate ptroblēma ar NC drill failu kas nāk ārā joprojām paliek, un šeit fragments no faila ko dod ārā PADS2005:


```
%
T1F197S550
X05080000Y05080000
X05334000Y05080000
X05080000Y05334000
X05334000Y05334000
X05080000Y05588000
X05334000Y05588000
X05080000Y05842000
X05334000Y05842000
X05080000Y06096000
X05334000Y06096000

M30
```

 Un šitas variants protams neiet cauri, un ir bišķi jāpamaina, jāpieliek klāt sākums un tā T1F197S550 daļa jāizlabo un īstais fails kas ir īstais NC drill standarts pēc pārtaises izskatās šādi:


```
M48
METRIC,TZ,000.00
T01C0.33

%
T01
X0508000Y0508000
X0533400Y0508000
X0508000Y0533400
X0533400Y0533400
X0508000Y0558800
X0533400Y0558800
X0508000Y0584200
X0533400Y0584200
X0508000Y0609600
X0533400Y0609600

M30
```

 un te es esu arī modificējis un noņēmis X;Y kordinātēm to 1nu nulli  ::  

vispār lieta ir tāda ka ja neizdodās noregulēt to PADS2005 drill failu tā lai tas izdod ārā vismaz normālas kordinātes (pārējo var ar roku momainīt) tad gandrīz vai sanāk tā ka ir jātaisa Visual C# 2005 programma kas tās nulles klāt pieliks un pieliks,nomainīs parējo informāciju   ::  
šādos brīžos iemaņas programmēšanā sāk patiesi noderēt jo nu ej un kādiem 200-300 caurumiem maini tos ciparus! 

Vispār jau Baigi šausmīgi ka tik kruta proramma kas vispār ir labākā ar kuru esu PCB vilcis ir tāds stūlbs defekts, vai arī defekta nav un es nezinu kur ir tie uzstādījumi kuri šo problēmu labo.

----------


## Epis

NUpat atcerējos ka tajā NC drill faila sākumā METRIC,TZ,000.00 rinda nozīmē metrisko sistēmu a man tur ir amerikāņu moš tad to nulli vaidzēja likt klāt dēļ tās metriskās sistēmas ? 
būs jāpartaisa gerber fails un drill fails uz metrisko moš tad sakritīs kordinātes  ::

----------


## Epis

Beidzot atradu to īsto režīmu, problēma bīj ar to parametru "Zero Suppress" tur ir 3 opcijas: None;Leading;trailing 
un NC drill failā leading ir LZ, Trailing ir TZ  un man visu laiku stāvēja PADā uz None, bet NC failā bīj TZ tādejādi visi cipari bīj pa 1nu nulli lielāki un es uzliku TZ opciju PADā un situācija bīj vēl sliktāka (vis bīj vēl miniatūrāks) tad uzliku uz LZ un beidzot Sakrita, tākā esu beidzot "Atkodis" visus PADS2005 knifus  ::  
Tagat beidzot viss ir skaidrs, bet joprojām PADS netaisa īsto failu un tas protams būs pašam manuāli jāpieliek ar Notepadu.

----------


## Epis

Tātad nolēmu darīt tā ka papildus šitai 2 līmeņu PCB ko es te visu laiku taisu un pārtaisu, uztaisīšu arī 2līmeņu PCIe-X1 PCI karti ar to Xio2000 čipu, un jā jā !!   ::   tā būs 2 līmeņu Plate (nevis 4 kā vaidzētu) ar BGA 0.8mm Pitch   xio2000 un pa to ies PCIe 2.5Ghz signāli  proti paši šo signālu celiņi būs ļoti īsi ( ap 10mm) tākā domāju ka pa tik īsies ceļiem signāliem vaidzētu tomēr normāli sasniegt čipu. bet nu Galvenā Cīņa taisot šādu PCB ir tā xio2000 čipa celiņu vilkšana jo kā zināms tad PCI interfeisam ir ļoti daudz signālu (50) un tie visi ir jādabūn ārā no tāda miniatūra čipa un izskatās ka man tas ir veiksmīgi izdevies reku bilde apakšā. atliek pilikt,pievilkt barošanas vadus un visus Analogos barošanas filtrus,kapacitātorus un tad viss būs gatavs  :: 

Vēl jaunums ir tāds ka ir izmaiņas tajā parastajā tur es ņemu nost IDE/ATA interfeisu, un lieku klāt 2vus LVDS Rj45 kontaktus katrā pa 3 Lvds pāriem un lai varētu mana PCIe fpga karte sazināties ar prasto Fpga karti vai ar citu tādu pašu karti.
[attachment=0:2bmj3hnk]PCIe_2L_papusei.JPG[/attachment:2bmj3hnk]

----------


## Vikings

Pietrūkst vēl SATA, FireWire un VGA. Piemet taču tos arī pilnam komplektam.

----------


## Epis

> Pietrūkst vēl SATA, FireWire un VGA. Piemet taču tos arī pilnam komplektam.


 Sata, Firewire un HDMI, DVI arī esu pētījis, bet nu tur ir tā pašvaki ar tiem čipiem jo tādu interfeisu pašam taisīt ar kautkādu pliku PHY ir neprāts.

Faktiski tā PCIe plate no programmēšanas puses ir parasta PCI32 (33vai 66Mhz) plate un priekš PCI 32 Opencores ir kādi 4 kodoli, un Lattice ir arī savējie Master,Targer IP demo kodoli (kā alterai,xilinx) tākā kodēt neko īpaši daudz nevaidzēs vismaz sākumā lai iztestētu plati. 

skatoties reāli uz to IDE/ATA tad tas bīj tāds pasūdīgs variants jo ir tikai 1ns kodu paraugs (tāds apšaubāms) + tā lieta tur ir sarežģita, un pats standarts ļoti vecs (>20gadi), un nebūs ilgi jāgaida ka kompju mātesplatēs šie te IDE kontakti sāks pazust, ar laiku arī PCI kontakti pazudīs un taivietā būs PCIe kontakti, tākā faktiski, reāli nav nemaz no kā izvēlēties, ja skatās uz jaunajiem standartiem tad ir tā vai nu PCIe,vai arī SATAI,II 
Pārējos tādus kā USB,Ethernet un citus neapskatu jo tie nav īstā laika, un pārāk smagi savos protokolos,standartos, jāsaka ka SATA arī ir pasmags protokols, tāpat kā PCIe (iekš fpga aizņem 10 000Loģikas) bet manā gadījumā man par to nebūs jādomā jo to visu darīs Xio2000 kuru uzstādīs un sagatavos kompja BIOS draiveri, un domāju ka varēs redzēt kompī to vai tas čips vispār strādā vai nestrādā arī bez Fpga kodēšanas (komī vaidzētu parādītes CIe to PCI bridge (tiltam) automātiski ja tas čips vispār strādās bez nekādiem papildus draiveriem, un kodiem.) 

Un protams viss vienkāršākais un primitīvākais komunikāciju veids ir PCI 32bit 33Mhz tam ir vienkārša komunikācija (fpga Target no 600 Loģikām) kas prasa maz resursu, bez lielām laika aizturēm tātad "īstā laika" vienīgā problēma un pamat NELAIME ar to PCI, kā jau te esu rakstījis, ir ši te neveiksmīgā pāreja no 5V uz 3.3V Slotiem un faktiski šī pāreja ir tik neveiksmīga dēļ tā ka neviens īsti tai vairs neredz jēgu jo PCIe kartes tagat ir tik pat lētas kā PCI (tie Gb čipi ir palikuši lēti tādēļ cenas krīt un Pec manām domām neviens kompju mātesplatēs neliks varis tos jaunos PCI 3.3V slotus, ticamāk ka nākotnē pamazām no mātesplatēm pazudīs PCI sloti jo viņi aizņem parāk daudz vietas (salīdzinot ar PCIe-x1) tākā PCI nav nekādas nākotnes  :: .

----------


## sharps

saki PCI 32bitu ir vienkaarshaakais komunikaacijas veids? heh sasmeejos. varbuut labaak pakaapies soliiti uz atpakalju un uztaisi ko reaali straadaajoshu un pashu pashu pashu vienkaarshaako komunikaacijas veidu - RS232 un/vai LPT.

PS
Veej jau var piemest Gigabit ethernet  :: . tikai tie switchi daargi. tos ar veel vajadzees projekteet. beigaas jau tas projekts taa kaa maaja. jeega tam visam?

----------


## Velko

> tākā PCI nav nekādas nākotnes .


 Da kāda starpība, kaut vai uz ISA slota. Taisies savam CNC (ja vispār kādreiz pabeigsi) nemitīgi mātenes apgreidot, vai tomēr darbināt un savas rumbas virpot? RS232 arī nav nākotnes un sāk pazust no mātenēm. Vai tas traucē elektroniķus jamo lietot? 

Jāsaka, ka nu jau galīgi vairs nesaprotu, ko centies uztaisīt. Izskatās pēc plašu zīmēšanas, zīmēšanas pēc. Būtu labāk braucis kādus dabasskatus pagleznot, ja jau tik ļoti patīk zīmēt.

----------


## dmd

drīz svinēsim epja virpas projekta divus gadus. varbūt pa godu šim notikumam kāds grib uz sevis taisītas CNC uzvirpot kādu rumbu un pasniegt kā dāvanu?  ::

----------


## sharps

> drīz svinēsim epja virpas projekta divus gadus. varbūt pa godu šim notikumam kāds grib uz sevis taisītas CNC uzvirpot kādu rumbu un pasniegt kā dāvanu?


 
vai veel labaak veikalaa pirktu... un leetaaku.

----------


## Epis

Domāju ka tie kas kautko ir mēginājuši izgudrot labi zin ka neko jaunu izdomāt nevar kamēr nav dziļi izpētīts,izanalizētrs viss kas jau pastāv līdz šim, un tad kad tas viss ir izdarits arī var domāt kautko jaunu, savējo risinājumu. 
Un mans uzdevums te nav kautko nokopēt,paņemt gatavu, bet gan izdomāt savējo variantu kas manuprāt būtu labākais ko es varu uztaisīt, un tad es arī skatos kādas ir manas iespējas, ko es varu, nevaru, ko dara citi, ko viņi izmanto, kā ko taisa un rezultātā var redzēt visu ainu kopskatā katra risinājuma + un - un arī pieņemt kādu lēmumu pa kādu ceļu iet, un tagat es skatos vai ir iespējams iet par PCIe-X1 ceļu un kad būšu pabeidzis savilcis pilnīgi visu Xio2000 čipu Tikai tad es redzēšu un varēšu izdomāt Cik tas ir reāli ? vai tas vispār var strādāt? Te vēl jāpiebilst ka vienreiz jau es skatījos to iespēju izmantot PCIe-X1, bet toreiz tā situācija bīj savādāka, un es daudzas lietas nepamanīju, palaidu garām kā šo te Xio2000 čipu, es tur pētīju XIO1100 kas ir pārāk sarežģits un var teikt ka Nereāls, bet Xio2000 tāds nav un tā ir pavisam cita lieta.

Ir tā ka domājot, taisot visas sīs te plates visu laiku nāk klāt jauna informācija, izpratne, sapratne kā kas strādā tādēl arī ir tā ka itkā pabeidzot vilkt vienu PCB versiju domas mainās un jātaisa jauna PCB jo pa to laiku nāca klāt jauna informacija kas maina domas par to visu lietu, protams, es tagat domāju ka PCIe-X1 variants ir pēdējais, bet nu to vai savelkot šo te plati manas domas būs joprojām tādas es nevaru garantēt, ja es dabūšu kādu jaunu informāciju kas ir pret PCIex1 tad gribi vai negribi būs domas jāmaina un jātaisa jauna plate, tādēļ ir tā ka kamēr tu visu nezinu, un nodarbojies ar izzināšanu tikmēr nevar pieņemt nekādus galējus lēmumus, jo jebkurā brīdī var nākt kāda jauna informācija, sapratne,apskaidrība kas to visu kopējo bildi maina un ja mainās domas tad Rīcība parasti seko domām, tākā tagat es domāju tā , bet kā es domāšu pēc nedēļas, mēneša es nezinu, stabili domāju ir ar to Pirmo Plati uz kuras būs visi pamat elementi MCU,USB,FPGA,LTP, SDRAM tākā tās ir tādas Stabilās vērtības kurām ir jābūt, šaubīgais ir LVDS vai LVPECL (IDE es no saraksta izslēdzu) un kādi papildus IO ar ar 5V tolerant iejām.

----------


## Epis

Varbūt kāds te domā ka tas tā viss baigi dīvaini notiek ka tās domas tik bieži mainās, bet man tas liekās normāli, jo es lasu arī citos forumos kā CNCzone kur arī ir tādi kā es kas taisa elektroniku un viņi arī muļājās gadu, divus izstrādā kādas 3-4 PCB versijas līdz nonāk pie kāda slēdziena, jeb galējā varianta. 
Pat tādi Profesionāļi kā tas Māris freimansi (Geckodrive) jau pus gadu to savu Cheep drive taisa itkā viss sākās baigi ātri pāris nedēļās pirmais variants bīj gatavs bet pēc tam sākās visādas pārdomas, kas? ko? kā labāk uztaisīt, radās jaunas idejas, tad protatipi, citas lietas un tagat jau pus gads pagājis bet kā nav palaista tā PCB pārdošanā tā vēl nav visu laiku to datumu atliek jo kautkas jāpietaisa, jāpielabo. citiem čaļiem kas nav tādi profi iet grūtāk tur ir viens tāds kas soļu motoram draiveri taisa, un viņš sāka kautkur tad kad es un jau ir pagā'juši 1.5gadi un neko notirgojis viņš vēl nav bet uztaisījis vairākas plates gan viņš ir. salīdzinājumā es pirms tiem 2 gadiem sāku vispār no 0, bet tie visi bīj jau profi, tākā mans progress nav nemaz tik slikts  ::  

Būtu intresanti pasekot līdzi kādai Latvijas firmai, vai induviduālistam kas kautko izstrādā no 0 (kādu jaunu produktu)  un diez vai te kāds spētu kautko tādu krutu uztaisīt kādos pāris mēnešos, pus gads aizietu kā minimums līdz pēdējai stabilajai versijai !!

----------


## sharps

> Būtu intresanti pasekot līdzi kādai Latvijas firmai, vai induviduālistam kas kautko izstrādā no 0 (kādu jaunu produktu) un diez vai te kāds spētu kautko tādu krutu uztaisīt kādos pāris mēnešos, pus gads aizietu kā minimums līdz pēdējai stabilajai versijai !!


 protams ja viens pats straadaa pie liela projekta, tad taa arii ir. nav taadu cilveeku kas zinaatu visus smalkumus pilniibaa. dazhiem padodaas programmeeshana, citam hardware, veel citam juridiskaa puse, veel citam maarketings un reklaama. tikai tad jau var domaat par kaut kaadu produktu izstraadi. arii laika tam nepietiktu ka chetru cilveeku komanda tev jau pogas izgriezusi.
un tu domaa ka nopietnu produktu izstraadaataaji forumaa te bljaustiisies "es da es". zini kaa projekteeshanas kompaanijas savus prototipu dzelzhus reklamee? uz visiem prochiem un atminjaam uzliimiites liek. interesanti kaadeelj tas taa.

----------


## dmd

well, ņem vērā to, ka kamēr tie džeki pieslīpe un tā, tev vēl pat prototips īsti nav gatavs  :: 

starpcitu tev varētu šķist interesants apstāklis, ka dzelzs gabalam, ko uzšāva uz manrsu (phoenix lander) ir rad6000 dēlis (33mhz 128M rama)
hablam vecais, labais 80486
ISS 80386
space shuttle 80386

neliek biki aizdomāties? tu te projektē kautkādu monstru, bet tikmēr fēniksa landeris mierīgi bubina ar saviem 25-33 mhz

----------


## sharps

par shuttle biju dzirdeejis ka inzhenieri pa baraholkaam raakaajoties lai atrastu vecaas detaljas shuttle kompiishiem. pashi vinji par taadu diivainiibu izsakaas taa ka paarbaudiitas veertibas ir taas stabilaakaas. es teiktu shitaa ka jo aatraaks procis jo aatraak uzkaraas.


PS Ja gribi tieshaam to CNC uztaisiit, tad saac ar vienkaarshaakiem un pieejamaakiem dzelzhiem. kaa arii atrodi domu biedrus. no shitiem sadrukaatiem palagiem man miegs naak.

----------


## jeecha

Nu es sho diskusiju (ja to par taadu vispaar var nosaukt, jo vairaak gan tas izskataas peec "trakaa zinaatnieka monologa") uztveru kaa uzjautrinoshu lasaamvielu pirms guleetieshanas.

Epis, tu tieshaam labaak negribi nopirkt kaadu leetu ARM vai tamliidziigu SingleBoardComputer ar kaadu no tevis iemiiljotajaam FPGAaam jau blakus procesoram? Tas saanaaks kudish leetaak un aatraak un ljaus fokuseeties uz pashu logjikas un procesora programmeeshanu kas droshvien arii prasiitu lielaako dalju laika shaadam projektam. Taapat viss ko tu liidz shim esi te aprakstiijis nav iipashi vairaak kaa chipu appnotees ziimeetaas sheemas utml, nekaada "izgudrojuma" piegarsha te pagaidaam nav juutama.

----------


## sharps

jeecha tur nu tev pilniiga taisniiba. no pieredzes zinu ka programmeeshana aiznjem vairaak kaa pusi laika. sheemas top aatri. dazhreiz programmeeshanas laikaa izpeld sheemas nepilniibas.
ber runaajot par tiem domu biedriem, tad man ir kaads projektinjs kuraa es labpraat kaadu iesaistiitu. jo tajaa visaa ir diezgan daudz ieriichu paredzeets. taa kaa vareetu drusku padaliit darbus un es vareetu uzticeet kaadu devices dalju uztaisiit kaadam. tad nu arii beigaas salikt kopaa visu ieriici un peetiit kas no taa visa sanaak. ja kaadam ir interese tad var privaati atpuust zinju.

----------


## Epis

Pēc pēdējo pāris gadu pieredzes es uzskatu ka vis grūtāk ir tieši iemācīteis uztaisīt pašu Hardware. Programmas, softus iemācītes cept ir daudz vieglāk nekā iemācītes uztaisīt strādājošu PCB kādam krutam modernam čipam kādēļ ? 
Tādēļ ka ir liela atšķirība programmēšanai no PCB taisīšanas un būtiskākā ir pārbaudes mehānismos, ja programmu var pārbaudīt momentāni uz kļūdām, un to darbību (ar simulātoriem vai uz kāda Dev.kita ar debugeri) tad PCB pārbaudīšanas process ir ļoti lēns un izgstoš + prasa milzīgus finansu līdzekļus (reāla protatipa uztaisīšana + salodēšana, bet visvairāk naudu prasītu īstu kvalitatīvu mērinstrumentu iegāde (pāris 1000 $), tādēļ arī nevar iemācītes vilkt un taisīt PCB 3 mēnešos, bet paiet gads un vairāk tieši dēļ tiem protatipiem un arī Testēšanas instrumentiem, man nekādu kruto test instrumentu nav tākā es šeit vispār reāli nevarēšu neko nodiagnosticēt savā protatipā tākā sanāk padomāt par visu to 2kārši pirms kautko izlemt par taisīšanu, vai netaisīšanu, un izmantot visu piejamos instrumentus, lai vismaz kautcik varētu prognozēt, paredzēt rezultātu signālu līmenī.
Tākā tā arī ir sava veida pārbaude, eksperiments par to kādas tad ir uz šodienu tās reālās iespējas uztaisīt kādu protatipu.
Kā jau jūs redzat at Tiem PCB ražotājiem un cenām ir tā ļoti  grūti, jo šīs augstās tehnologījas ir BGA čipos (MicroStar BGA 0.8mm un pat chipscale BGA 0.5mm) tākā tā ir ļoti ļoti liela problēma.
Tādēļ nākās meklēt unikālus risinājumus tam lai vispār varētu izvilkt to PCB, jo ir lielas problēmas atrast PCB ražotāju kas pa lētu naudu taisītu tik smalku PCB un šī iemesla dēļ es tagat savu PCIe plati pārtaisīju uz lielāku celiņu izmēru tagat ceļš,atstarpe ir 0.18mm/7mil (sākumā bīj 0.15mm/6mil), es atceros ka bīj viena PCB 4 līmeņu firma kurai tas limits bīj 7mil un 6 mil jau maksāja dārgi, tākā ir tieša sakarība starp ceļu izmēru un cenu, bet lielākā problēma ir urbšanas caurumi, to parametrus ir grūti saprast un izprast ražotāju Maximālās iespējas, tādēļ ir jātaisa PCB konkrēti kādai PCB ražotāj firmai pēc viņu iespējām.

Xio2000 čips jau ir pa 90% savilkts vēl atliek pāris VCCA filtrus uzlikt un tad itkā viss gatavs. kopā zem čipa būs kādi 28 0.1uF kapacitātori x2 pakā kas reālo čipu skaitu samazina līdz 14, vēlāk kad būšu pabeidzis ielikšu bildi.

----------


## Epis

> jeecha tur nu tev pilniiga taisniiba. no pieredzes zinu ka programmeeshana aiznjem vairaak kaa pusi laika. sheemas top aatri. dazhreiz programmeeshanas laikaa izpeld sheemas nepilniibas.


 Viss atkargīgs no sarežgītības, var būt tā ka PCB būs ar BGA čipiem, bet pats softs tāds primitīvs vai gluži otrādies kāds lētais mikrokontrollieries ar milzīgu programmu.
Un ātri top tikai tas ko tu jau kādreiz esi taisījis (ir gatavi kodi, shēmu praugi utt..), viss jaunais top ļoti,ļoti lēnu.

----------


## sharps

> jeecha tur nu tev pilniiga taisniiba. no pieredzes zinu ka programmeeshana aiznjem vairaak kaa pusi laika. sheemas top aatri. dazhreiz programmeeshanas laikaa izpeld sheemas nepilniibas.
> 
> 
>  Viss atkargīgs no sarežgītības, var būt tā ka PCB būs ar BGA čipiem, bet pats softs tāds primitīvs vai gluži otrādies kāds lētais mikrokontrollieries ar milzīgu programmu.
> Un ātri top tikai tas ko tu jau kādreiz esi taisījis (ir gatavi kodi, shēmu praugi utt..), viss jaunais top ļoti,ļoti lēnu.


 galiigi aplami tu domaa. kaada jeega dzenaat ljoti vienkaarshu programmu uz uuberkruta procha, lai vienkaarshi iesleegtu/izsleegtu releju. vienkaarshaa MCU nedabuusi OSu virsuu un nemaz nevajag. taas jau ir divas galeejibas vai nu skopums vai izshkjeerdiiba.
protams ja ir taadi gatavi kodi. reference design kodiem parasti ir tikai informatiiva noziime.

----------


## Epis

Gribat redzēt ārkārtīgi augstu sarežģitības līmeni tad skataties kā es savilku šito XIO2000 čipu tikai 2 līmeņos  :: 
Zem čipa ir 14 x2 0.1uF kapacitātor lauku čipi SMD 0504 (zaļie apļi) tātad kopā tur ir 28 sīkie 0.1uF kapacitātori + vēl 6 1000pF 0402 un 
Sarežgīti to barošanu bīj vilkt jo tur ir 4 barošanas daļas 2 digitālie, un 2 analogie līmeņi + analogais GND tākā baigi sarežģiti var pat teikt knapi knapi savilku.
Barošanas vadus vilku cik platus vien varēju vidēji 0.4-0.6mm.

Vispār būs baigi grūti šito brīnumu lodēt.

Xio čips kā tāds ir savilkts un tur vairs neko nemainīšu tagat jāsaliek pārējās detaļas  :: . 
 



> galiigi aplami tu domaa. kaada jeega dzenaat ljoti vienkaarshu programmu uz uuberkruta procha, lai vienkaarshi iesleegtu/izsleegtu releju. vienkaarshaa MCU nedabuusi OSu virsuu un nemaz nevajag. taas jau ir divas galeejibas vai nu skopums vai izshkjeerdiiba.


 Šitas XIO2000 čips neprasa nekādu programmēšanu un pamatā ir domāts priekš PCI aizstāšanas ar PCIe-x1 piemēram gribi uztaisīt kādu PCIe- USB,ethernet,LVDS vai cita interfeisa karti būs vien jāliek virsū šāds monstrīgs BGA čips, ja ne tieši šis tad kādas citas firmas čips kurš arī būs tajā pašā BGA pakā un ar līdzīgām Prasībām, parametriem sarežģitības, tākā nevisas augstākās tehnolģijas ir procesori, faktiski lielākais variākums ir visādi šādi čipi kas veic kādu specifisku darbu, te neiet runa par Releju slēgšanu, releju slēdzim elektroniku var uzlodēt pat bez PCB (kā es savai SMD krāsnij (sākumā uzlodēju releju slēdzamu variantu pēc tam tik uz Triac pārgāju)

----------


## Vikings

> Gribat redzēt ārkārtīgi augstu sarežģitības līmeni tad skataties kā es savilku šito XIO2000 čipu tikai 2 līmeņos


 Pat neredzot bildi es nezkādēļ sasmējos par šito tekstu vien.  ::

----------


## Epis

njā, es tā skatos uz to bildi un domāju cik tas ir reāli ? vai tur kautkas vispār var strādāt ?  un mani protams māc šaubas un tagat kad tā plate ir uzīmēta var reāli objektīvi novērtēt un izlemt vai vispār ir vērts taisīt tādu Plati ?? 

ja tā paskaita detaļu skaitu un to šausmīgo minī kapacitātoru daudzumu un tuvumu ar kādu viņi ir novietoti tad nebribās pat domāt par to kā es to visu tur lodēšu, čakars ar lodēšanu būs baigi liels. 

un tagat itkā var salīdzināt kā izskatījās parasta PCI 32 karte un šitā PCIe-X1 nu sarežģītības ziņā tā PCI karte bīj daudz vienkāršaka + viņu savilkt bīj daudz vieglāk. 
Un ja tā padomā kāda ir iespējamība palaist PCI karti un šo te PCIe karti tad šai te PCIe es varētu dot tikai kādus 10% (tas faktiski nozīmē ka nekas nestrādās  ::  ), bet tai PCI kartei ap 70% jo te vismaz signāli ir sakarīgā ātrumā un ja nestrādās tad var uztaisīt test programmas attiecīgi vismaz kautko var darīt, a ar PCIe ja neaizies ar pirmo tad nekā viss pa velti. (+0.8mm BGA faktoru arī nevar izslēgt un tas var radīt problēmas 1mm BGA ir normāli bet 0.8 jau pa traku).

Man nupat ienāca prāta Laba ideja, agrāk es te mēģināju taisīt PCI karti ar visiem navarotiem, kontaktiem un problēma bīj tur ka tā PCI karte pātērēja pārāk daudz IO resursus un visam vienkārši nepietika, tagat taisot šo te PCIe izdomāju ka uz tās plates ir jābūt LVDS izvadiem komunikācijai ar pamat karti, un tagat ienāca prātā tāda doma  ka kādēļ lai neuztaisīt PCI karti tādu pašu kādu bīju domājis taisīt šo te PCIe, tikai bez PCIe čipa un ar visiem PCI komponentiem. 

Tātad tagat fiksi savilkšu jaunu PCI karti ar 12 LVDS kanāliem un viss. vismaz šito karti es varēšu 100% iedarbināt un man nevaidzēs sūtīt nekādas papildus detaļas no mouser, jo viss nepieciešmais man jau ir nopirkts  ::  

Par to PCI izmiršanu kompju māteslatēs domas nēsu mainījis pamazām PCI pazudīs, bet pozitīvi ir tas ka jebkurā gadījumā varēs nopirkt šādus te PCIe- PCI adapter kartes priekš vecajām PCI kartēm  :: .

UN es te tā vēl arī apskatījos kas bīj ar to DDR SDRAM un tā arī ir tāda padārga tehnoloģija salīdzinot ar parasto SDRAM, itkā  DDR patērē mazāk enerģijas, bet tur vaig tos terminācijas rezistorus + atsevišķu VTT 1.25V barošanas bloku un kopā tas visu baigi baigi sarežģī.

par to XIO2000 tad tur patiešām vaig normālu 4 līmeņu plati lai vismaz samazinātu detaļu skaitu (liekot 2x vietā 4X kapacitātoru lauku čipus, vai pat 8x lai nav jāčakarējās ar lodēšanu, šo te PCB dizainu es saglabāšu, kas zin moš nāktonē ja zidomāšu tomēr kautko taisī tad ar 4 līmeņiem varētu. 

Tātad mans gala slēdziens:  ::  
PCIe-x1 tomēr parāk dārgs prieks un Mega sarežģits salīdzinot ar PCI tādēļ būs laikam jāņem PCI32.
no atmiņām manprāt nav nekā vienkāršaka un lētāka par SDRAM.
komunikācijā vinnē LVDS tas saliek visus standartus vienīgais mīnus tāds ka parstajiem mikrokontrollieriem nav to LVDS kanālu  ::  vienīgiem kautcik gudrajiem čipiem kuriem ir šie te LVDS ir fpga tākā LVDS ir lētākais starp 2vām fpga komunikācij veids uz lielākiem attālumiem (-10m) (ar LVPECL var vilkt pat līdz 100m (tā es lasīju)

----------


## Epis

NU tā šeit jaunā Plates versija kuru šodien fiksi savilku tātad tur ir PCI 32 interfeis un 12 LVDS kanāli 2viem RJ45 kontaktiem var uzstādīt tos LVDS kanālus gan kā TX, gan kā RX noņemot to 100 omu rezistoru sanāk TX, uzliekot RX, laigan domāju ka vaidzētu arī strādāt ar visu rezistoru (tip divvirzienu komunikācija). 

3 stundas pagāja taisot PCI, un otras 3h LVDS (dēļ to līniju garumu salāgošanas) šitā būs PCB plate pa 1 dienu  ::  
tākā nav ko te mūldēt ka es PCB plati zīmēju pus gadu, es domāju ko kā zimēt pus gadu.  
Noslēpums kādēl tik ātri tā PCB savilkās ir tāds ka man visām detaļām ir jau biblotekas faili un blociņā jau atzimēti visi sgināli + es jau agrāk to PCI bīju vilcis tādēl arī iet tik ātri. UN tādēļ ir tā ka tiko tev jādara tas ko jau kādreiz esi darījis tā tu, Naudas valodā runājot, esi PRODUKTĪVS, bet tiko jādara kautkas tāds ko nekad nēsi darījis tu nēsi, un nevari būt produktīvs, un tad ir stūlbi skaitīt patērētās stundas cik esi ielicis lai dabūtu kautko gatavu, takā apgalvojums ka pelnīt var tikai ar to ko māki darīt šajā gadījumā ir patiess, kamēr mācies tikmēr par pelīšanu var aizmirst, tākā nav jēga salīdzināt mani, iesācēju, ar kautkādiem profesionāļiem kas ikdienā to vien dara kā atstrādā savas zināšanas un strādā gandrīz vai kā konvejiers (visu laiku vien un to pašu dara no rīta līdz vakaram).
[attachment=0:19yxk82g]PCI_LVDS_plate1.JPG[/attachment:19yxk82g]

----------


## Epis

Itkā likās ka visu jau esu izdomājis līdz galm, bet kad uztaisīju lielajai platei no atlikušajiem IO izvadus (tādus ar kādiem var pieslēgt savu Kodak video sensoru pa taisno, tad apskatījos ka tas kodak sensors nolasāš ļoti vienkārši, un sāku domāt kā tad es zināšu vai tā tas sensors patiešām kautko filmē, un vienīgais veids kā to zināt ir slēgt klāt Monitoru un ar monitora pieslēgšanu tad arī sākās problēmas, man tagat ir tikai 1na elektronika pie kuras var pieslēgt savu kompa monitou (cyclone II dev.kits) un slikti tas ka ar to dev.kita komunikāciju ir tā ļoti pašvaki (tur nav LVDS) un tad domāju domāju un izdomāju ka jāuztaisa man no PCI32 kartes atlikušajiem IO (tur ir kādi 12-14) VGA monitora interfeiss (3x4bit DAC+V,H sync) un tad domāju par konektoriem un negribājs likt to parasto COM porta konektoru, izdomāju ka jāliek DVI kontakts un papildus analogajiem signaliek jāpieslēdz arī 4ri LVDS diferenciāli tad es itkā teorētiski varētu pieslēgties arī pie digitālā DVI-D monitora, vai DVI-I(ar analogajiem signaļiem) un VGA ar DVI-VGA adapteri(man tāds stāv mājās nāca līdzi Videokartei) tākā viss universālākais kontakts ir DVI (pilnais) + ir arī DVI-HDMI adapteri un teorētiski es arī varētu HDMI monitoru vadīt (ar 4 LVDS) bet nu es tur tā lasīju lasīju, un ar tiem digitālajiem Video standartiem ir tāda dīvaina lieta kā HDCP protokols, jeb tas Drošibas standarts pret datu kopēšanu un tā tālāk un to standartu es taisīt netaisos, tākā nav īsti zināms kā ir ar tiem monitoriem skaidrs ka tiem kuriem tā HDCP atbalsta nav ņems pretī parastos T.M.D.S signālus un to interfeisu kas rakstīts DVI specifikācijās, bet vai tie ar to drošības fiču HDCP monitori varēs komunicēt bez tās drošibas fičas.

Kā ir vai tas HDCP tiem monitoriem kuriem viņš ir automātiski ieslēdzās defaultā, vai tā ir kā papildus opcija, un defaultā monitors komunicē ar DVI specifikācijās minēto interfeisu ??? 

Skaidri zinu to ka tiem monitoriem kuri atbalsta DVI-I (jeb papildus digitālajam arī analogo) nav nekādu HDCP un ar tiem es varēšu komunicēt, bet ar HDMI monitoriem (kur nav analogā atbalsta vairs vispār) varētu būt tas HDCP drošības sūds.

Tātad jaunās izmaiņas (priekš Video kameras) ir tādaska es no PCI plates noņemu nost 2vus RJ45 kontaktus (6LVDS kanāli) un tai vietā uzlieku DVI kontaktu (4LVDS+ analogie RGB+H;V sync) analogais būs tikai 4 biti (DAC būs no rezustoriem R2R shēma tākā manam ciklon Dev.kitam.) un līdz ar to krāsu izšķirtspēja būs tikai 12 biti ( ap 4000 krāsas) un tādēļ ja vaidzēs vairāk krāsu, moš lai redzētu labāk ko tad filmē mana kamera varētu izmantot DVI digitālo monitoru tad būs 24biti krāsas. 

Beigās es varēšu uztaisīt Standa alone CNC agregātu ar video kameru + 1600x1200 LCD-DVI monitoru un varētu pieslēgt klāt vēl kādu keybord, USB peli (caur STM32 proci) un faktiski sanāk gandrīz vai pilns dators ar visiem navarotiem  :: 

Tagat laikam ka ir viss ko es vispār varu pieslēgt, uztaisīt, uzlodēt, kopā man tur sanāks vairāk navaroti nekā uz sava Ciklon II dev.kita  ::

----------


## Epis

Ir tā ka PCI karte ir Pabeigta (viss gatavs) un pie otras plates vēl bišķi jāpastrādā to varētu nosaukt par Finālu  ::  šonedēļ obligāti pasūtīšu tās plates lai taisa. 
Ir tā ka es tagat esu apmierīnāts ar rezultātu visām fičām kas uz plates būs.

Šitās 2 līmeņu plates kuras es taisu reāli der tikai tādam testam, protatipam, jo ražot tādas plates īsti izdevīgi nebūtu, jo pirmkārt detaļas būs jālodē no abām pusēm, (piemēram nanam ciklon II lētajam dev.kitam visas detaļas lodējās no 1 puses) kas ievērojami padardzina lodēšanu, un lai uztaisītu tādu plati kur visas detaļas ir no 1 puses vaig tomēr izmantot 4 līmeņu PCB, ja doma pats lodēt kādu mazu partīju tad lodēt tos TQFP,PGFP iepakojumus domāju ka nav ekonomiski izdevīgi jo solis ir pārāk mazs 0.5-0.65mm, bet BGA ir pavisam cita lieta tur solis ir 1mm un krāsnī tas čips smuki salodējās, un kļūdas defektu % ir daudz, daudz zemāks nekā TQFP + nevaru iedomāties kā tādai TQFP vispār var uztaisīt uzprintēt to lodalvas pastu  0.25mm platu līniju, un ja uztaisa tad liekot čipu virsū (ar roku) tur viss tāpat izsmērēsies,bet BGA čipam vispār nevaig nekādu  lodalvas pastu likai to parasto lodalvas, lai veicinātu lodēšanos  ::  un +- pieļaujamā novirze BGA ir ļoti liela +-0.2mm un čips krāsnī pats nocentrējās tākā tas ir ātrāk, ērtāk un lētāk  ::  vaig tikai krāsni.
Un ja pat pats uztaisa kādu CNC lodalvas printētāju tad man vienalga māc šaubas par to TQFP lodēšanu, domāju ka to pastu tur nevar normāli uzspiest un sadozēt kā to var izdarīt ar to STENCILu, bet tādiem iepakojumiem ar 0.8 un lielāku soli problēmām nevaidzētu būt.

Vispār ja šitas viss ko tagat uztaisīšu strādās un kautko normālu varēs uztaisīt tad kas zin varbūt pēc kāda pus gada, gada uztaisīšu kādu komerciālo versiju  ::

----------


## Neatkarīgais

vaaaks    ::  
pirms gaaga kad saakas runas par CNC man ar bij doma ka mosk tadu varetu uzmiestarot bet labi vien ir ka neko nesaaku
tas tak ir vaaks taisiit sitaadus murgus, nu kada vella peec? cik tur laika, nervu un naudas aiziet?
nedomaaju ka musdienaas ir verts ko taadu dariit. un tomeer cnc majas apstakjiem var iepirkt par 2-3k ls un miers viss drosi, parbaudiits, stradaa un galvenais bez cakara un galvassapem.
labi taas tikai manas domas- bet tiem kas taisa- lai jums veicas, neesmu jau pret.  ::

----------


## zzz

Neatkariigais, biedriisha epja abstraktos maakslas darbus plashu ziimeeshanaa nekaadaa gadiijumaa nevajag uzskatiit par jelkaadaa zinjaa saistiitiem ar CNC darbagalda buuvnieciibu, tas ir vienkaarshi balets pats par sevi, bez jeegas, rezultaata vai pielietojuma, vienkaarshi taapeec ka epim taa patiik. 

Ja gribi redzeet kaa patieshaam uzbuuvee CNC darbagaldu, aizej apskaties uz Jetija uztaisiito.

----------


## Epis

Šodien dabūju, jeb apguvu jaunu ļoti ļoti svarīgu informāciju dēļ kā iespējams ka būs kārtējo reizi jāpamaina PCB dizains, proti, tas ir saistīts ar tiem Decoupling kapacitātoriem, es veicu tādu dziļāku rakšanu šajā tēmā un beidzot sapratu kas tur īsti ir par lietu un cik tad daudz vaig tos kapacitātorus, agrāk es mēģināju saprast šito visu lietu bet nekādīgies nevarēju iebraukt un šorīt kļūva viss skaidrs, skaidrs kļuva nevis tādēļ ka es beidzot atradu tādu litratūru kuru izlasot es visu sapratu, vismaz sāku saprast. 
šeit pāris informācijas avoti: 
Choosing and Using Bypass Capacitors (Part 1 of 3)
+http://www.planetanalog.com/showArti...leID=199905522
Šeit iet runa par jaunajiem Krutajiem X2Y kapacitātoriem ļoti labs raksts, salīdzinājumi, tieši ar Fpga čipu, baigi daudz labas informācijas.
+www.x2y.com/publications/decoupling/jul24-06.pdf

Šeit ir īs apraksts par Viss viss Krutākajiem AVX kapacitoriem:
Low Inductance Capacitors
+http://download.siliconexpert.com/pd...nts/w2lw3l.pdf

UN lieta tāda ka piemēram viens 0508 IDC kapacitātors var reāli aizstāt 7 0402 parastos jo šitam "Inter-Digitated Capacitors "(IDCs) kapacitoram ir 50pH induktivitāte salīdzinot ar 0402 kuram tā ir ap 600pH un cik es tur lasīju tad jo zemāka induktivitāte jo ātrāk kapacitātors var uzladēties, izlādēties, filtrē lielāku frekvenci, tā Self Resonant Frequency ir lielāka un šitiem krutajiem tā ir baigi lielā
[attachment=0:g2oao2im]IDC_resonantFrequencygraph.JPG[/attachment:g2oao2im]
un pēc tā grafika var smuki redzēt ka 10nF 0604 kapacitātors pēc sava ātruma (80Mhz) ir līdzērtīgs 200nF 0508 IDE 80Mhzkapacitoram tātad sanāk tā ka lai uztaisītu kādu 400nF 80Mhz filtru vaidzētu 40 0604 kapacitātorus vai arī 2vus 0508 IDE starpība ir 20X  ::   un tas arī nozīmē to ka lai es savai fpga uztaisītu labu DC barošanas bloku man pietiktu ar 2-3 šādiem super 0508 IDE kapacitātoriem kas aizvietotu kādus 22-24 parastos 0402 SMD MLC kapacitātorus, bet tas būtu iespējams tikai ar BGA pakas čipu, jo 144 TQFP ir pārāk liela pinu induktivitāte + atstarpe no IO pina līdz čipa centram būtu pārāk liela lai zimantotu 1nu 0508 IDE kapacitātoru pieņemsism priekš 3.3V, vai 1.2V barošanas ! 
Tākā tagat vispār ir jāsāk pārdomāt viss pa jaunu.

----------


## dmd

ou, decoupling kondensatori. kāds pārsteigums!!!

----------


## Epis

Un ievērtējiet tajā pamācībā tos Grafikus ar impedence un frequency un tur bīj piemērs kur paņēma 3 nomināla 0805 kapacitātorus 1uF; 0.1uF; 0.01uF un šeit ir grafiks kas attēlo cik tad labi filtrē šāda paralēlā 3 kapacitātora filtru kombinācija:

Faktiski pēc grafika var redzēt ka no 0.1uF un 0.01uF jēgas nav praktiski nekādas tātad nav jēga likt vairāku nominālu vienāda iepakojuma kapacitātorus kā 0805 no tā labāk nepaliks. 
un šeit grafiks kur katram mazākajam nominālam ir jau mazāks iepakojums un kā redzam ir jau pa visam cita lieta  ::  


secinājums ļoti vienkārš ir jāliek pēc iespējas lielākā nomināla kapacitātors pēc iespējas mazākā iepakojumā, un tagat es saprotu kādēl uz mana FPGA ciklon II dev.kita (150$) stāv tikai 1 nomināla 0.1uF kapacitātori visi 0603 iepakojumā, jo nav jēga likt piemēram 0.001uF kapacitātoru jo viņš tāpat nevarēs neko labāk izfiltrēt par to 0.1uF, ja grib ko labāku tad ir jāņem mazāks iepakojums, vai arī modernāks iepakojums kā tie 0508 IDC; x2Y 0603 tādā garā tad filtrēs 200-300Mhz ka maz neliekās  ::  
Slikti ir tas ka es nezinu cik tad tiem manējiem x2 0504 kapacitātoriem ir tā induktivitāte ?  ::   tas manējais laikam ka nav IDC, bet parastais MLCC un vienkārši 2 vienā iepakojumā  ::  tākā nekas labāks par tiem 600-700nH nebūs  :: 

varbūt paņemšu pāris vietās  tos kapacitātorus no apakšas pārlikšu uz augšu lai būtu mazāks ceļa garums un līdz ar to labāki parametri  ::  

Būs vēl jānoskaidro cik tad maksā tie super krutie kapacitātori  ::  pagaidām tie X2Y 0603 cenas bīj padārgas ap 1$ gabalā pa citiem vēl nav nekas zināms, bet lēti jau nekas nebūs un kā jau teicu šādus kapacitātorus var likt tikai FPGA čipiem, jo TQFP vienkārši nav jēga.

----------


## Epis

> ou, decoupling kondensatori. kāds pārsteigums!!!


 pārsteigums tāds ka līdz šim es domāju ka tas kādu frekvencē tas strādā ir atkarīgs no viņa nomināla nevis no iepakojuma. izrādās ka viss pretēji (protams ja iet runa par Mhz,Ghz signāliem)

----------


## dmd

tā jau ir, tā jau ir. </sarcasm>

----------


## Epis

Nu lūk parakājos Mouser, digikey katalogos apskatījos citu firmu krutos kapacitātorus un izrādās ka viņi nav neko dārgi  ::  
Viss izdevīgākais un lētākais ir murrata LLA219C70G475ME01L 100nH 8pin 4.7uF tikai 0.28$ faktiski ar 1nu šādu čipu piektiktu veselai BGA256 pakai priekš standart LVCMOS signāliem, un vēl vienu kodolam, bet šitas nav viss viss ātrākais capacitātors kāds tur tirgojās un ātrākais ir šitas LLM215R70J224MA11L 0.22uFar 10 piniem un 45nH induktivitāti un maksā arī lēti 0.29$ vienīgi tā kapacitāte ir tāda pašvaka  ::  ir tur protams arī 1uF un 2.2uF modeļi bet tie viņiem ir non-stock,varbūt nākotnē būs  :: 

apstījos kāda ir induktivitāte Fpga čipu pakām un ciklon II čipam ir šādi parametri:

Inductance (nH)		
Typ	Min	Max
144TQFP     8.15       7.70	 10.72
256BGA     4.54	        3.20	   6.79

nu BGA ir 2x zemāka, bet galvenais jau ir tas attālums kas būtu starp pakas centru un kāju un 1444TQFP tas ir 11mm bet BGA no 1-9mm kā kura lode, piemēram VCC kodolam tas būs 1mm jo lodes ir visas pašā centrā, bet VCCIO pārsvarā ir 3 rindā  no ārpuses tad tie būs kādi 5-6mm  tākā BGA čipam var šāds 1 capacitātora likšanas variants nostrādāt, bet 144TQFP vaidzēs vairākus katrā sānā savu. 

Tagat BGA čipa plate sanāk ar mazāku detaļu skaitu nekā TQFP, un tas nozīmē arī lētāka ražošanā  :: .

----------


## Vikings

Epi, bet padomā, ja katra barošanas kāja ir savā malā, tad jau attālums ir dažāds! Tā kā pie katras kājas tomēr vajag savu kondensatoru pēc iespējas tuvāk tai.

----------


## Epis

NO Visas šitās jaunās high tech Super kapacitātoru informācijas man atkal sāk nākts Jaunas trakas idejs par 2 līmeņu BGA plati ar 3 super kapacitātoriem zem čipa katram voltu līmenim savējo  ::  un ja ALmiko var uztaisīt 0.15mm celiņus,atstarpi, ja nevarēs tad igauņi toč varēs, tad es no sava BGA var izvilkt pirmās 3 rindas caur virsējo slāni  ::  un tas nozīmē apmēram 100 IO pinus proti šajā 144pin TQFP ir tikai 90IO, bet no BGA ar 0.15mm ceļu es jau dabūnu 100 IO   ::  bet vispār tajā BGA256 ir 190IO pinu, domāju ka varētu izvilkt vēl kādus 30 bez īpašām problēmām un kvalitātes zudumiem.
un tākā man būtu tik šausmīgi daudz IO es varētu uztaisīt PCB kur būtu viss,patiešām viss par ko vien var iedomāties: 
PCI,
DVI,
LVDS,
SDRAM(16biti),
CPLD,
STM32
SPI Flash.
net nu pirms taisīt tādu monstru man jāuztaisa šis te protaipa plates un jānoskaidro vai vispār es to FGPA varu piešķilt, savādāk būs kā ar ciklon III uztaisu BGA plati un izrādās ka nevar pielaist, jāurbj caurumi cem čipa un jāčakarējās, + ja taisīšu to BGA plati tad tā lai var uzspraust ne tikai ECP2 čipu bet arī jauno XP2 fpga ar Flash atmiņu  :: , Power pini ir  identiski, un tas arī pats galvenai, jo atšķirīgos JTAG, konfigurācijas pinus var izvlikt, vienīgi priekš LVDS jāskatās vai tie IO pāri sakrīt galvenais var nesakrist terminālu zīmes (+,-) jo tas nav neko svarīgi, galvenais lai kāju pāri būtu vienādi.
jo ir tā ka XP2 būs ar savādāku loģikas tilpumu nekā ir ECP2, attiecīgi tur bū 5000, 8000, 17000, bet ECP2 ir 6000, 12000,21000 un sliktais tajā ECP2 ir tas ka 12000 čips maksā baigi dārgi 30$  ::  bet 8000 XP maksā tikai 18.8$ tākā ja man ar 6000 ir par maz un vaig bišķi viarāk es varu paņemt 8000, vai arī ja varu sabāzt visu 5000 tad ņemu 5000 loģiku čipu, jo XP2 nevaig konfiugrācijas Flash atmiņu  ::  tākā tas ir baigi superīgi ka vari paņemt tādu čipu kādu ievaigās.




> Epi, bet padomā, ja katra barošanas kāja ir savā malā, tad jau attālums ir dažāds! Tā kā pie katras kājas tomēr vajag savu kondensatoru pēc iespējas tuvāk tai.


 ar to attālumu bīj kā ka kādi 4-5mm varēja būt mierīgi,galvenais bīj normāli celiņi virs 0.5mm līdz kājai,lodei un galvenā jau ir tā induktivitāte kas samazina to kondiķa darbības  ātrumu, kas šādam celiņam varētu būt pāris,pārdesmit nH, bet tākā pašam kondensātoram būs super zema 100nH induktivitāte+ čipa iepakojuma 5-10nH+VIA (laikam 3-5nh) tad pat varētu teikt ka var vēl mierīgi pielikt pāris mm pie celiņa garuma jo vienalga tā kopējā induktivitāte būs zemāka par tiem 600nH kas ir 0402 kondiķim un rezultāts būs ļoti labs. tākā viss ir iekš tās induktivitātes, jo zemāk jo labāk.
Tākā ar šādiem kapacitātoriem varētu patiešām uztaisīt Labu 2 līmeņu PCB priekš BGA čipa, jo ar parastajiem kapacitātoriem tas īsti nav iespējams.

----------


## dmd

jā, tā tak nav nekāda raķešzinātne!
nē, paga, mļin, nav jau pienācis tas brīdis, kad raķešzinātne ar saviem 80386, 80486 un līdzīgajiem jau ir stipri vienkāršāka?

----------


## sharps

> Neatkariigais, biedriisha epja abstraktos maakslas darbus plashu ziimeeshanaa nekaadaa gadiijumaa nevajag uzskatiit par jelkaadaa zinjaa saistiitiem ar CNC darbagalda buuvnieciibu, tas ir vienkaarshi balets pats par sevi, bez jeegas, rezultaata vai pielietojuma, vienkaarshi taapeec ka epim taa patiik.


 tas ir neviss vienkaarshi balets, bet balets uz ledus. iipashi ja nemaak slidot.

----------


## dmd

ar granti.

----------


## Epis

A ko jūs "Gudrie prāti" ieteiktu šajā decoupling kapacitātoru lietā ? kādus kapacitātorus likt un cik daudz ? 
ECP2 144TQFP pakā ir 10 VCC; 4 VCCAUX; 8 VCCIO, 12 GND.
Darbināmās ierīces LVDS- 200-400Mhz; SDRAM-133Mhz, STM32-dubūltais SPI 18Mhz, 2CPLD 7pini kādi 20-40Mhz. un vēl video sensora interfeis, bet protams viss vienlaicīgi nestrādās, bet nu tās frekvences ir tādas paaugstas, it sevišķi ja darbina LVDS, vai SDRAM (šito toč darbinās).

Uztaisīju tam dullajam kapacitātoram 0508 PCB zīmējumu un pamēģināju uzlikt viņu zem BGA čipa un kautkā baigi sūdīgi liekās, nekas prātīgs tur nesanāk, jāmēģina ņemt lielāks iepakojums 0612, ja tas neies ta jāņem bišķi švakāki 200pH tie Reverse Geometry (murata LLL sērijas)

Es ta slidot vēl nemāku,bet mācos, bet jūs runājat tā itkā baigi labi mācētu slidot, man katkā neticās !
jā kāds te kautko baigi zin, tad padalaties šajos noslēpumos, piemēram tādā kā šitie pavisam cita līmeņa kapacitātori, ja kāds būtu kautko ieminējies ka tādi eksistē pirms kādiem pāris mēnešiem tad varbūt jau viss būtu gatavs, jo padomājiet ir tač starpība starp 3-4 kapacitātoriem kas jāuzliek,jāsavelk,pēctam jāuzlodē, un kādiem 22-28 sīkajiem 0603 vai vēl trakāk 0402.

pateikšu ko nevaig man virs ieteikt:
Alteras appnoti, par barošanu.
Xilinx apnots xapp623.pdf te ir čotka viss aprakstīts, iedotas vērtības, % daudzums. tādā garā.
un vēl nevaig atkārtot tos linkus kurus jau es pats esu ielicis. 
ja ir vēl kautkas ko es nēsu atradis tad liekat linkus.

----------


## Epis

> Neatkariigais, biedriisha epja abstraktos maakslas darbus plashu ziimeeshanaa nekaadaa gadiijumaa nevajag uzskatiit par jelkaadaa zinjaa saistiitiem ar CNC darbagalda buuvnieciibu, tas ir vienkaarshi balets pats par sevi, bez jeegas, rezultaata vai pielietojuma, vienkaarshi taapeec ka epim taa patiik.


 Redz Topiks saucās DIY fpga motoru kontrollieris kas pirmām kārtām nozīmē uztaisīt FPGA plati un pēc tam uz tās plates uztaisīt to motion kontrollieri, un tagat kā redzi ir tikai vēl sākuma posms plates taisīšana (jau pēc skaita šitas kuru taisīšu būs 4 protatips.)
1.  bīj Ciklon II plate. mērķis pārbaudīt vai vispār kautkas strādā un apskatīties vai vispār var salodēt TQFP paku.
2.   ciklon III BGA (ar defektiem)- mērķis: pārbaudīt SMD lodējamo krāsni un BGA lodēšanu, un protams vai vispār kautkas strādā + video sensora PCB.
3 uzlabotā ciklon III BGA: mērķis izlabot iepriekšējās PCB kļūdas  un bišķi uzlabot,un šitās visas 3 Plates nebīj nekas vairāk kā protatipi lai pārbaudītu vai vispār kautko var uztaisīt, uzlodēt, un uz tām pltēm izņemo Fpga Flash atmiņas nekā cita praktiski arī nebīj, tur visi IO tika vienkārši izvilkti lai būtu viņiem pieja.

4. tagadējā -jauna mikrene ECP2: un mēŗķis uztaisīt reālu funkcionējošu plati ar visiem vajadzīgajiem konektoriem, interfeisiem,pieslēgumiem + tā lai var spraust klāt kompim, un spraust klāt citām ierīcēm pa taisno, bez nekādām tur papild platēm, + tai jābūt reālai izstrādes platformai kur nav jāpērk nekādas programmu, intelektuālā īpašuma licenzes, tādēļ arī izvēlējos lattice fpga jo viņu procesori, pamat IP kodoli ir pa velti, bet Alterai,Xilinx nekas nav pa velti par visu ir jāmaksā. + fpga konfigurējās no parastās SPI flash, ciklonam tā bīj speciālā flash atmiņa kas pamatīgi maksāja.

----------


## a_masiks

> Es ta slidot vēl nemāku,bet mācos, bet jūs runājat tā itkā baigi labi mācētu slidot, man katkā neticās !
> jā kāds te kautko baigi zin, tad padalaties šajos noslēpumos, piemēram tādā kā šitie pavisam cita līmeņa kapacitātori, ja kāds būtu kautko ieminējies


 "es skatos -  te jūs BMW un audi tjūnējat. Nu ja esat tādi spečuki pasakt man - kāds tangāžas leņkis jāliek reaktīvajai sprauslai manam mersim? Es gribu izspiest max ātrumu savam mersim ar SUPER motoru no Eurojeta. Apnotēs rakstīc par tangāžas leņķi, bet tas ir ļotakam uz 3 riteņiem, bet man būs SUPERSTABILS verķis uz 4 riteņiem un ar EJ200 Jauno Superdzinēju. Man vienkārši vajadzēja tikt uz Liepājas bīč party,  bet es parēķināju ka pa ceļu būs jāvelkas 2 stundas. Es te vienā forumā izlasīju ka ar Jauno SuperDzinēju to var izdarīt 10 minūtēs. Nu es nolēmu ka nav ko čakarēties, man vajag uztaisīt tā, lai braucamais  ir pac Superīgākais. Dzinēju jau pasūtīju, nevaru izdomāt stiprinājuma kronšteinu - sanāk baigi smagais, un te es izlasīju ka svarīgs ir tas Tangāžas leņķis! Ja jau esat tādi spečuki mašīnu delžos - tad jau varat man pateikt - kādā lenķī likt - 9,5° vai 11,3°? Var būt kāds ir mēģinājis uzlikt 15°?  
Es te pagājušo gadu uzliku iepriekšējo Supermotora versiju, tā nebija tik jaudīga, mersis apmetās ar kājām gaisā, bet SUPERMOTORS tā ārī neiedarbojās...  man teica ka tas esot tangāžas leņķa dēļ. Man tagad būs pac jaunākais SUPERMOTORS, ja uzlikšu pareizo lenķi /pārējies var teikt ka iet, jo tur nekādu problēmu nevar būt/ - man būs krutākais braucamais, salikšu visus bemnerus un lamburgus kā mazos....

----------


## a_masiks

PS -  atgādinu veco piedāvājumu - par 5ls/gab atjaunoju tavu izčakarēto BGA mikreņu kājas vai iepērku pa 1 colas pudeli visus tevis neveiksmīgi pielodētos cilkonus. Uz pusēm nesalauztus un citādi nebojātus, protams.

----------


## Vikings

Hā hā labs stāsts. +1.  ::

----------


## Epis

Barošana PCB (pamat platei) ir gatava vēl tik paliek savilkt neizmantotos STM32 Io pinus uz to Header kontaktu un LVDS pinus pārvilkt (ar vietu priekš rezistoriem).
UN Barošana man tagat izskatās tā ka es 3.3V taisa L5973D 2.5A (efektivitāte 70-80%) agrāk man tur stāvēja LDO ar jaudu 1A un ar tiem LDO ir tā ka viņi gaigi karst, un negribās savu PCB taisīt par sildītāju, jo ir jau pietiekami daudz detaļu kas karsīs taķā switch regulātors priekš lielām jaudām  ir labākā Opcija. un 1.2V 200ma taisa LDO, 2.5V arī LDO un tas arī viss, es no sākuma bīju domājis taisīt to 3.3V barošanu ar 1A LDO regulātoru, bet tam vidzēja Vin ne lielāku par 5V, un tādēl arī uzliku tomēr to L5973D lai var slēgt pie pēc iespējas lielākas strāvas (max 35V).
Rīt laikam ta būs fināls "pus gada" darbam  ::  3 uzprojektētas plates, lai varētu reāli kautko beidzot uztaisīt. par to ka plates stādās esu 100% pārliecināts jo nav BGA paku un visas kļūdas defektus varēs izlabot takā iedarbināt es tur visu varēšu.

----------


## Epis

Es tā baigi aizdomājos sakarā ar to topiku par Frekvences counteri un to cik lielu frekvenci varētu FPGA LVDS pini uzķert un arī ģenerēt un ja ECP2 ir 700Mbps LVDS kanāls tad ar 3 PLL var 4X frekvenci sadalīt un uzķert 0.3ns intervālu tas ir ~ 2.5 Ghz   :: , bet kā tad ir ar signālu ģenerēšanu, ja ar PLL to pamat frekvenci nobīda un sadala tik pat smalkos gabalos tad vai būtu reāli uzģenerēt tādu 2.5Ghz LVDS signālu (piemēram priekš PCIe-X1 interfeisa ?? proti fpga IO izejošie pina Bufferi vadās ar D-Type/LATCH reģistru, un Lach režimā kad CLK=1 tad iejas signāls pa taisno parādās izejā, un tad jautājums varētu būt tikai par to vai izejošais LVDMOS bufferis spēc ģenerēt tik ātru signālu, un vai tam pietiks spēks, itkā jau tie bufferi strādā ļoti ātri, varbūt ka ir tādi parallel to serial Ghz konvertieri,transciveri, kas varētu 4rus LVDS kanālus 700Mbitus pārtaisīt par 1nu 2.5Ghz LVDS signālu ?

būd bišķi jāpaintresējās, un jāapskatās kā tas izskatītos ar Loģik

----------


## valmet

::   ::   ::

----------


## Epis

Domāju paņemšu ātri uzģenerēšu Gerber failus un aizsūtīšu, un kārtējais abloms ar to NC drill failu, skatos viewmatā viss galīgi ačgārni, un mēģini kā gribi kruķīt tos Leading,trailing zero parametrus neko labu dabūt nesanāk, un pēc 2h čakara pieleca kā tad īsti jātaisa, proti tākā es iepriekšējo reizi iepriekšējai test platei uztaisīju ta šoreiz man nekas nesanāca, bīj jāmeklē cita kombinācija un iemesls tam bīj tas ka man šitā plate pēc izmēriem ir lielāka līdz ar to NC drill faila Leading zero uzstādījums vairs negāja cauri jo kompis ņēma pretī tikai ciparus līdz 10.0000 un ja ir pāri 10 kordināte 11 tad caurums stāveja gandrīz vai pie 0, un šo kļūdu izlaboju pārliekot drill failu uz Treiling zerro 4:2 (reāli man Padā bīj 2:4  tad pozitīvie cipari ir itkā  4 un aiz komata 2vi, bet PADS es liku lai aiz komata ir 4 cipari un veselos tad var liekt 2vus vai vairāk, tākā baigi dīvaini, iespējams ka problēma ir mērvienības  varbūt Pads dod ārā metrus, bet viewmate attēlo cm vai mm tākā es vēljoprojām nesaprotu kā tur kas īsti ir. bet labi ka tagat beidzot caurumi ir īstajā vietā  :: 
Vēl nācās nočakarēties ar SOlder MASK jo proga ģenerēja to atvērumu lielāku nekā detaļas kājas laukums, bet es gribēju bišķi samazināt un tad atkal kamēr atradu vietu kur to parametru var nomainīt pagāja pāris stundas, jo nav viegli atrast šitos parametrus.

tāds čakars !!

----------


## Vikings

Es nesaprotu ko tu tur p!sies, paņem taču saglabā kā PCAD2002 failu (protams, ja ir tāda iespēja) un sūti uz Almiko. Es nekad neesmu taisijis Gerberfailus, es nezinu visus parametrus kādus viņiem vajag, aizsūtu plati kādu viņu vajag man  un tālāk lia tad ņemas viņi paši.

----------


## Epis

Tur jau tā lieta ka tie PADS2005 Eksportētie faili neiet uz PCADa, pcads never vaļā nevienu failu pat ne gerber kurus ir taisījis PADS, tākā nav citas izejas kā taisīt tos failus uz PADS.

tā ir ar tām programmām, vissu gribēt nevar, vienai labāks routeris citai atkal Failu ģenerātors, Padam vienīgais defekts ir tie drill faili tos es ar roku pārtaisu (copy paste kordinātes + jāuztaisa urbju nummuri)

----------


## jeecha

Nu ja nemaaki no CAM procesora dabuut aaraa NC drill failus kurus saprot konkreetais plashu razhotaajs (patiesiibaa man nedaudz liidziiga probleema ir ar Altium Designer - vinja CAMTasticaa opciju ir TIK daudz ka taa uz sitiena gruuti saprast kaadas opcijas tad jaaliek) - uzraksti kaadu nelielu scriptinju kas vinju pielabo un piegjeneree klaat to kas pietruukst. Tie faili tak dikti vienkaarshi ir, athskjiraas koordinaashu formateejums un lietotie G/Mwordi, cik tur taa darba vinjus paarkonverteet ar kautkaadu Python vai kaada nu kuram tuvaakaa scripteeshanas valoda. Shaadaa veidaa es gjenereeju no NC failiem failjukus ko barot iekshaa Mach3/EMC2 plashu urbshanai un routeeshanai, jo meegjinaajumi dabuut no Eagle vai Altium NC ko pa taisno vareetu iebarot Mach3 iipashi veiksmiigi nebija.

----------


## Epis

Man tagat ir jauna problēma gļuko Gerber failu ģenerātors,proti, nerāda Top leyerī STM32 proča 48PQFP iepakojuma kājas, pagaidām iemeslu nezinu, bet varbūt esu kautko Pads layout pamat parametros  grizi uzstādījis, jo mēģinot uztaisīt to Soldermask es tos parametrus tur tā nepajokam mainīju (pamatā ķeksīšus opcijās) un būšu kautkādu opciju uzlicis ka tas iepakojums neparādās gerber failā  ::  agrāk parādījās, man liekās ka tur bīj kautkāda opcija nodzēst elementu ja nav izmantoti visi Pini, vai arī ir kādi DRC pārkāpumi tādejādi automātiski izlabojot kļūdu, apmēram tādā stillā.

To opciju tur patiešām ir ļoti daudz, un no vienas puses tas ir baigi labi, jo fiču arī ir daudz, bet tas ir ļoti sarežģiti, un slikti tas ka pamacībā šie visi sīkumi ir ļoti slikti aprakstīti, it sevišķi tā failu ģenerēšana, tur viarāk par Loga zīmējumu nav vispār nekas piemintēts, apmēram tādā stilā: 
šeit ir logs kur ir visādi uzstādījumi, un tālāk tev pašam jāzin kas ir kas.

man jau bīj doma sākumā uzrakstīt mazu VIsual C# progu kas to PADS NC tupo failu pārtaisītu par normālu, bet pētot to Pads NC failu nevar atrast Urbja izmēru, proti tur ir kautkads ciparu virknējums kas itkā norāda ka tas ir kautkāds mistisks caurums, bet no tiem cipariem nevar noteikt to izmēru, līdz ar to arī nevar uzrakstīt tādu automātisku failu konvertieri,pielabotāju, itkā tos urbja izmērus un caurumu skaitu es varu dabūt no Drill drawing gerber tipa faila, bet tas ir tīrs gerber zīmējumu fails un tajā atrast kautkādus urbja izmērus ir nereāli (caur to failu Preview var redzēt caurumu diametru,skaitu,simbolu ar kādu viņš ir atzīmēts bet pašā failā atrast tos datus ir grūti (es nēsu atradis) un iespējams ka kordinātes no turienes arī varētu paņemti, bet kā jau teicu tur viss ir baigi samudžināts, man pagidām vieglāk ir ar roku pārtaisīt to NC drill failu jo ir tikai 4 urbja izmēri.
Uz pirmās plates man caurumu skaits būs apmēram 428:
200gab  0.3mm maziem
208gab  0.9mm priekš kontaktiem 
un tālāk vēl kādi 20 lielie dažādos izmēros arī priekš konektoriem.
Ja nākotnē būtu jātaisa kāda Plate ar kādiem pāris 1000 caurumiem + kādiem 10-20 urbja izmēriem tad noteikti ka vaidzētu kādu programmu kas pārtaisa tos Drill failus uz normāliem.

----------


## jeecha

Pag pag, NC failos iekshaa gan vajadzeeja buut arii instrumentu izmeeriem, kautkur saakumaa, izskataas apmeeram:


```
T01C0.3
T02C0.5
T03C0.7
```

 Shie T-wordi definee urbja diametru (no augstaakmineetaa piemeeram - T01C0.3 = toolim 01 diametrs ir 0.3 vieniibas).

Peec tam starp X#Y# urbshanas komandaam kur mainaas cauruma diametrs ir atkal T-wordi kuri pasaka kursh instruments jaalieto taalaak, piemeeram:


```
X00100Y00100
T02
X00020Y00200
```

----------


## Epis

Atradu problemu kā'dēļ nerādās 48pi LQFP paka izrādās ka tā programma viwmate nez kādēļ nerāda to iepakojumu ja viņš atrodās 45grādu un citos lenņos kas nav 90;180;275;360 visi citi lenķi nerādās, bet PADS gerber failu preview logā to iepakojumu var redzēt tad lau laikam Almiko arī varēs redzēt to paku, jo agrāk esu taisījis plati ar 45 grādu leņķa pakām  :: .

To es zinu, bet šeit ir NC drill faila fragments kādu ārā dod mas PADS2005 un problēma ir tā T1F95S300 rinda es tur neredzu Urbja izmēra lielumu   ::  


```
%
T1F95S300
X283650Y112050
X421500Y139500
X431500Y147500
X507000Y149500
X1087000Y119000
X1087000Y127500
X1088000Y155500
```

 šeit ir mans pārtaisītais fails uz pareizo NC formātu


```
M48
METRIC,TZ,0000.00
T01C0.3
T02C0.9
T03C3.2
T04C1.6
T05C2.2
%
T01

X283650Y112050
X421500Y139500
X431500Y147500
X507000Y149500
X1087000Y119000
X1087000Y127500
```

----------


## Epis

Beidzot aizsūtīju failus lai taisa plates  ::

----------


## Epis

Nupat lasīju vienu CNC lapu un uzgāju tādu lietu kā ETHERNET Powerlink, vienīgais Hard-Real time internet protokols, kas izmanto parasto internet infrastruktūru, proti nekādi specifiski čipi, nav vaidzīgi (kās piemēram sercos standarta gadījumā) itkā tas esot Open sorce un kodu var novilkt priekš Linuxa.
http://www.ethernet-powerlink.org

CIk izlasīju tad tur ir tā laika sinhronizācija un garantētais piekļuves laiks, lai varētu sūtit kautkādus kritiskos datus zem 0.1ms (vai ātrāk piemēram 1us). 
būs japapēta, jānovelk un kas zin moš ir vērts kautko uz šitā uztaisīt proti ātrums tur ir labs, iet zem linuxa, un ja iet zem linuxa tad noteikti ka tie draiveri ir sataisīti tā lai patiešām būtu tā REal time reaģēšana, un savu fpga karti es pie interneta slēgt klāt varu mierīgi (diferenciālos signālus uzķert es varu, un arī nosūtīt, vienīgais kas nav ir tie magnēti,transformātori, bet domāju ka var iztikt arī bez tiem, slēgt pa taisno un Loģikas kodi internetā ir piejami viss visādie.

itkā šito standartu bīju jau agrāk redzējis, bet toreiz kautkā likās ka tas nav nekas nopietns, bet laiks iet un šitas ir kļuvis populārāks + tā Open sorce ideoloģija man pašam arī ir kļuvusi nozīmīgāka.

----------


## jeecha

Nolodee no kaadas vecas tiikla kartes konektoru ar visiem transformatoriem, kondensatoriem un gaismas diodeem. Vai arii naakamreiz kautko suutot no Digikey pakjer kaadu (zem 5$). Vispaar komiski - kautkaada pavisam leeta 100Mbit tiiklene maksaa leetaak nekaa Elfaa tas konektors  ::

----------


## Epis

Vispār stūlbi kā es tā baigi pus gadu domāju, domāju par tiem interfeisiem ar kompi un beigās izrādās ka tāpt esu greizi nošāvis, vispār bīj man tāda iekšējā bals ka vaig pasūtīt arī to Ethernet PHY čipiņu no mouser, bet nepasūtīju  ::  latvijā jau nopirkt protams ka neko nevar!  un ar kapacitātoriem arī esu nošāvis grizi, nu neko darīt mūžu dzīvo mūžu mācies. 

Intresanti tas ka lielākā daļa hardware tiem ethernet Powerlink ir bāzēti vai nu uz fpga vai ASIC parastie proči ir reta parādība  :: .


ievērojet tai PCI kartei pie PCI slota ir 5ci čipiņi varu derēt ka tie ir tie BUss SWITCH kurus es arī uzliku savai PCI kartei  ::

----------


## jeecha

Kautkad naakamnedeelj suutiishu no Digikey, varu pie reizes tev kautko arii pakjert ja tu Riigaa kautkur dziivo.

----------


## Epis

Būtu baigi labi, es dzīvoju Rīgā-purvciemā. 
 es rīt uztaisīšu to detaļu sarakstu daudz detaļu nebūs pāris tie PHY čipi (3.5$) Pāris krutie kapacitātori un pāris lētos SDRAM čipus (man pašam ir tikai 1ns tas čips, bet tākā man būs vairākas plates un jauno noteikti ka arī taisīs ar SDRAm čipu tad vaidzēs vēl jo kā nekā tā ir Lētākā RAm atmiņa  :: 

ja kas tajā MOuser katalogā ir pašvaki ar PHY čipiem (tur ir tikai 1ns sliktā 64TQFP pakā un dārgs 5$, turpretī digikeyā izvēle liela (pārsvarā Micrel čipi) un lētākais iet par 2.2$ vienīgi iepakojums viņam tāds pasūdīgs, tākā būs jāskatās kādu paku labāk ņemt (prioritē tādai kuru vieglāk lodēt.

----------


## okars

Paarstaaj kropljot valodu!
Latviski ir kondensators, vai veel ir pieljaujams teikt kapacitāte, bet ne to pornograafiju ko Tu lieto - taada vaarda NAV!

----------


## Vikings

Jeecha, man arī šo to vajag. Var piemesties?

----------


## Epis

Es tagat pameklēju internetā MCU ar integrēto ethernet PHY/MAC un atradu Stellaris sērijas čipus,Lielākai daļai(vairākumam) 32bit ARM čipu nav integrētā PHY, viņiem ir internet perifērija kas strādā ar ārējo PHY čipu, un šiā bīj lētākā MCU kas digikeyā tirgojās ar integrēto PHY, un čips kā tāds ir ļoti labs, man normāls liekās LM3S6537- 13.6$, tur principā ir viss ko vien var vēlēties proti: 10/100 ethernet, 4 32bit taimeri (8-16bit) uz šiem taimeriem ir 3*2 PWM bloki, 6 imput capture kanāli,counteri (aizņem 3 taimerus) vārdsakot 3 soļu motoru draiveru vadīšanai ar enkoderiem pilnīgi pietiek. 

Un nekur jau nav teikts ka man jātaisa viss Powerlink interfeis, man liekās ka pietu paņemt pamat darbības principus un uztaisīt tādu fisko variantu, proti galvenais lai 0.1ms laikā varētu sūtīt un saņemt datus no kontrolliera, un tālāk to sinhronizāciju tad varētu veikt pats kompis. 

Tur ir arī Loģikas kodi priekš FPGA, bet es tā reāli domāju, ja es domāju izmantot un taisīt to visu uz šitā Powerlink kas pēc būtības ir modulārs dizains, proti gandrīz vai katram motoram var savu bloku taisīt, un tad ja tam modulim ir jāvada tikai max 3 motori, tad fpga sanāk pārāk dargs risinājums kādas 2x, + kodēt grūtāk, un izdevīgi bīja tikai tajā variantā kad bīj viss vienā proti viens čips vada kādas 4-5 asis, nolasa 12 enkoderus tādā garā, bet ja to visu sadala uz 3-4 Poewrlink blokiem tad vairs īsti nev vajadzība pēc fpga, un šajā gadījumā pietiek ar vienu Labi integrētu,(perifērijām bagātu MCU kā šitas stelaris (tas pats Cortex-M3 kodols kā STM32 vienīgi stm32 nav interneta perifērijas (tā es būtu ņēmis to) tākā šitie ir tie jaunie krutie MCU, pēc cenas maksā tik pat cik 8-16bit čipi.

un tad man sanāk sūtīt pāris šitos čipus + Ethernet Dev.kitu 69$ (tur ir visi debuggeri,programmeri paraug kodi, lai ātri varētu iemācītes kodēt to internet perifēriju). + magnētus+kapacitātor
līdz vakaram uztaisīšu sarakstu  ::

----------


## Epis

Vispār šitā apskaidrība man nāca  lasot šito rakstu "Keeping Control" 
http://www.motioncontrolonline.org/i4a/ ... ageID=3677
un tur ir apskatīti visi industriālie kontrolles veidi, un kāds kuram labums, un tad no šitā raksta es biški vēl pameklēju un arī atradu to Ethernet Powerlink.

Man būs Centralizēti kontrollētā arhitektūra proti ases virsējā līmenī tiks sinhronizētas,kordinētas,pielabotas no kompja, un tad kompis sūtīs komandas, kuras draiveris ar Path planning fiču dekodēs un ģenerēs step/dir, proti tās komandas kas tik sūtītas uz Stelaris čipa daraiveri būs jau bišķi apstrādātas, pēc sākotnējās idejas  G-koda dekoder softa un tālāko komandu ģenerēšanu veiks pate MCU.

Var arī mēģināt to sinhronizāciju veikt draivera līmenī, bet tad redzēs, ja čips varēs to pavilkt tad kādēļ gan ne.

----------


## Epis

šeit lejā detaļu saraksts: 
LLL185C70G105ME01L   0.34$   20gab
 EKC-LM3S6965       69$     1gab
KSZ8721BT          3.6$    2gab
SI-46001-F         4.6$    2gab 
MT48LC16M8A2TG-75:G TR     5.44$  1gab.
PTH08000WAS        8.56$      1gab.
Kopā    106.2$

Ja sūtīsi tās detaļas tad pirms sūti atraksti (šeit vai pm)  cik apmēram man būs Ls jāmaksā.

Bīj domā sūtīt vispār tikai to Dev.kitu, bet tad padomāju ka drošības pēc jāpaņem arī tie PHY čipi, jo ja nu gadījumā kautko uz tā Kita tur kautko nevarēs tad fiksi uzceps Vēlvienu FPGA-2x Eternet karti ar vsiem super navarotiem un lieta darīta  :: 
Ja kas tām Ethernet Powerlink kartēm ir 2vi Ethernet Porti, vienā ieiet otrā iziet un tad var saslēgt aplī visas ierīces, un šādi saslēdzot ir augstāka drošibas pakāpe, jo ja kautkur pa visu pārtrūkst vads, tad viss turpina darboties, bet ar Stelaris MCU var uztaisīt tikai 1nu Ethernet pieslēgumu, līdz ar to šitas variants cauri vairs neiet. Skatīsies no sākuma ko var izdarīt ar stelaris Kitu un tad redzēs vai ir vērts taisīt fpga-dual Ethernet karti vai nav (detaļas man jau būs  :: 

Šeit bilde tam internet Evaluation kitam:

----------


## Epis

Veicu dziļāku izpēti par Powerlinks un tā komponentēm, sastāvdaļām, kā veidot tīklu un kā vispār internets strādā(šito es daļēji zināju, bet tikai virspusējā līmenī apmēram kā 1/100 iedzīvotājiem, proti dziļākā līmenī, Kā es tagat, labi ja zin 1/10 000   ::  

Ir tā ka lai saslēgtu tīklā vairākas ierīces Powerlinkam kā jebkuram citam internetam ir vajadzīgi tie switch,Hub proti no vienas iejas dabūnam ārā 2vas vai 3, var arī tikai 1nu(ja ir 2vi ethernet kontakti tad 1 ieja otrs izeja, tipa Repiteris

Lūk šeit ir attēlota EPL(ethernet PowerLink) modulārā shēma kur ir saslēgtas 3 mašinas un katram mašinas blokam ir savi EPL moduļi, dzeltenā krāsa ir tie Ethernet HUB, kā redzam tad tie HUB nav tikai atsevišķi kā slēdži bet arī viņi ir integrēti iekšā tajos EPL moduļos, bet tur pašā lejā(labā mala) ir viens EPL modulis bez HUB un tam klāt slēdzās tikai 1ns ethernet vads, lūk šādu bloku,moduli var uztaisīt ar šito Stellaris MCU(lēti ātri vienkārši  :: ), bet tādu īsto EPL bloku ar integrēto HUB uz tāda augsti integrētā MCU vairs nav ekonomiski izdevīgi taisīt jo ir 2vi internet pieslēgumi un iekšējai programmai jānodrošina HUB funkcionalitāte, proti tie signāli kas domāti pašam blokam jānolasa un visi pārējie kas uz viņa neatiecās fiksi jāsūta tālāk, pēc specifikācijām šādam HUB delay ir jābūt līdz 500ns (tas ir apmēram tā nolasam pirmos 4rus MAC adreses baitus un ja tā paka nav domāta mums sūtam visu signālu tālāk (proti tur vaig FIFO bufferi, jo tālāk jāsūta tas pats signāls, kas ienāca tākā visu signālu vaidzēs aizkavēt par 4 baitiem. tākā bez FPGA iztikt kā redzat nevar, bet principā tādai nelielai CNC mašinai vaidzētu kādus 2-4 šādus blokus, kur katrs vadītu kontrollētu kādus 2 motorus+visādus slēdžus, un tad ir 2vi varianti:
1. paņemt kādu PC plati ar 2-4 ethernet Portiem (tādas atrast var) un kodēt līdz nelabummam to kompi, lai dabūtu īstu Real time performance, (līst iekšā kernelos, vai arī vispār taisīt visu uz kādas Hard -RTOS ),+šim būtuvēl jānodrošina vizuālais interfeis (monitors,grafiki, vārdsakot smuka vizuālā vide kur var visu redzēt (man tā vaig).
2. Kompis + FPGA 2-4 Portu ethernet HUB un motion kontrollieris (kur ir iekšā visas iepriekšējā varianta Hard-RTOS funkcionalitāte). 
Šajā gadījumā visu darbu dara FPGA un kompis ir kā Opcija, jeb Vizualizēšanas insturments + šim modelim ir tāds ka kompi var programmēt izmantojot kautvai Visual C# (es atradu VC# kodu kur var pat iešo nolasīt visu kas nāk no internet porta un ierakstīt nosūtīt jebkāda veida informačiju pa internet portu (proti tas ir windows Layer2 (parasti standartā var piekļūt tikai pie layer3 info, bet šeit viens ar to windows DDK uztaisīja NDIS driveri tā lai to var izdarīt, tākā pašam draiveri nav jātaisa un var cept kādu viengribi interfeisu (protms nebūs Real time performance, bet vizualizācijai un parametru uzstādīšanai tādu nemaz nevaig.
Ja kas manā variantā ja labi grib var pat Wireless komunikāciju uztaisīt starp FPGA un kompi, jo real time performance nevaig tākā iespējas šādā variantā ir visplašākās.
Ja es kautko taisīšu šādu tad man būs pašam savs ethernet standarts jo tas viņu CanOPEN ir pa traku, man vaig ko vienkāršāku (pats izdomāšu savu CanOPEN, bet pamat komunikācijas ideja protams ka paliks tā tur ir tīri laba.
http://www.codeproject.com/KB/IP/sendrawpacket.aspx

[attachment=1:3plonsc5]EPL-sistēma1.JPG[/attachment:3plonsc5]
šeit tāds viens piemērs kā ar šo standartu slēdz tīklā visādas ierīces, mans variants būs principā līdzīgs tikai tie draiveri tiks pa taisno saslēgti ar FPGA kontrollieri (zvaigznes pieslēgums)
[attachment=0:3plonsc5]EPL-sistēma2.JPG[/attachment:3plonsc5]

----------


## GuntisK

> Veicu dziļāku izpēti par Powerlinks un tā komponentēm, sastāvdaļām, kā veidot tīklu un kā vispār internets strādā(šito es daļēji zināju, bet tikai virspusējā līmenī apmēram kā 1/100 iedzīvotājiem, proti dziļākā līmenī, Kā es tagat, labi ja zin 1/10 000


  Neliekas, ka Tu sevi par augstu vērtē?   ::

----------


## Epis

> Neliekas, ka Tu sevi par augstu vērtē?


 Es to izsecinu pēc apmēram šādas formulas, ja apmēram 1/1000 īsti zin kas ir Oma likums (volti,amperas,pretestība) šie cilvēki varētu būt tie kas mācījušies par elektroniķiem, tad 1/10 no tiem kas kautko zin par elektroniku varētu zināt kas ir internets(signālu līmenī), un tādejādi sanāk 1/10 000. tie ir tikai tādi aptuvenie cipari, un tik slikti viņi ir tādēļ ka 90% jauniešu mācās humanitāros priekšmetus, un tikai tie 10% kas paliek eksaktajos var kautko zināt + 1% tie kas induviduāli kautko paši internetā uzrok kā es.

Ja tu domā savādāk tad pasaki cik tavprāt cilvēki varētu uztaisīt paši kādu ethernet 10/100 Plati ?? (izmantojot jau gatavus PHY čipus, jo bez PHY, uz diskrētajiem, vai citiem čipiem tas ir vēl grūtāk.)

piemēram cik cilvēki latvijā varētu uztaisīt Ethernet 100base-TX bez PHY uz lētās FPGA, vai CPLD ???  es šodien izpētīju un konstatēju ka tas ir reāli iespējams (vismaz es tā domāju pa nopietnam, un es domāju ka tas patiešām varētu reāli strādāt.
Un vēl pēc šiem pašiem manis izdomātajiem principiem (shēmu līmenī, nevis loģikas) varētu arī uztaisīt 1000base_T ethernet reciveri, draiveri vēl nēsu domājis, bet tur ir tikai bišķi jāpadomā kā tos rezistorus likt  ::  lai dabūtu 1v;0.5v;0v;-0.5v;-1v līmeņus. 

Tātad cik ir tādu kas vismaz shēmu līmenī varētu uzcept 100/1000base-T ethernet, bez PHY ?? (izņemot fpga uz citiem čipiem tādus brīnumus uztaisīt nevar)  laikam pagaidām es esu vienīgais  ::

----------


## dmd

http://www.elfa.lv/cgi-bin/index.cgi?artnr=73-867-43

nepilni seši lati, un gandrīz nekāda nočakara (vismaz man tā šķiet)

kā grasies cīnīties ar kolīzijām?

----------


## Epis

> kā grasies cīnīties ar kolīzijām?


 Full duplex variantā tādu kolīziju nav, tās ir Half duplex versijā, ka TX,RX iet pa 1nu vadu pāri, a šeit katram savs vadu pāris, tākā man liekās ka tā nav problēma, bet vispār tajā Loģikas primitīvājā līmenī(PHY) izņemot to bitu kodēšanas formātus es dziļāk vēl nēsu skatījies, bet nekam pārāk sarežģitam tur nevaidētu būt, es šeit tagat runāju par pašu hardware(signālu līmeni), un to ka esu izdomājis kā uz fpga var dabūt tos ethernet signālus, bez ārējā PHY, vienīgi pagaidām tā ir tikai ideja, uz jaunās fpga plates vaidzēs iemēģināt. bet šeit jāpiebilst ka tas ir iespējams uz zemajiem voltu līmeņiem proti - 100/1000 base-T, bet 10base-T nevar (pārāk rijīgs tas standarts tik daudz fpga IO izpsiest nevar), bet šitiem 100/1000 ir 2vi vadīšanas režimi "curent mode line driver"un "voltage mode line driver" pirmais cauri neiet jo atkal ir pārāk rijīgs (40ma), bet otrais gan sanāk, jo te patērējamā jauda ir 10 ma(kas ir reāli priekš fpga IO), un 1000base-T clock ir tik pat ātrs kā 100, vienīgi nāk klāt vēl 2vi voltu līmeņi + advancētāka bitu kodēšana.

priekš tiem kas nazin par ko runāju šeit raksts: 
http://www.eetimes.com/showArticle.jhtm ... D=51200238

----------


## ptr

> Veicu dziļāku izpēti par Powerlinks un tā komponentēm, sastāvdaļām, kā veidot tīklu un kā vispār internets strādā(šito es daļēji zināju, bet tikai virspusējā līmenī apmēram kā 1/100 iedzīvotājiem, proti dziļākā līmenī, Kā es tagat, labi ja zin 1/10 000


 nu, nu, ko tad īsti esi apguvis  -  etherneta vai  interneta fizisko līmeni ?  
Ka nesanāk kā Paganelam kas mācījās spāņu bet iemācījās portugāļu valodu  :: 




> Tātad cik ir tādu kas vismaz shēmu līmenī varētu uzcept 100/1000base-T ethernet, bez PHY ?? (izņemot fpga uz citiem čipiem tādus brīnumus uztaisīt nevar) laikam pagaidām es esu vienīgais


 Iespējams, ka Tev taisnība  :: . Pārējos būs ļoti grūti motivēt  vēlreiz izgudrot velosipēdu ar 0.75 riteņiem, ja par pāris naudiņām dabūjams gatavs, strādājošs čips  ::

----------


## Epis

Šeit ir pāris bildes kas parāda pēc būtības kā var uzbūvēt 100base_TX reciveri ar comparātriem un 1000base-T transmiteri ar 4riem  IO, vai 2 diferenciāliem draiveriem, un lai noķertu 1000base_T signālu vaigpielikt klāt vēl papildus 2vus comparātorus.
[attachment=1:1eqllsrb]LVDS-100base-TX_reciver_1000B-Transmiter_shem.JPG[/attachment:1eqllsrb]
šeit es hiperlinxā uzmodelēju ko dotu ārā fpga 2vi TTL3.0V pretēji signāli pie 100 omu slodzes ar mazāko 4ma spēku, un lielāko 16ma spēku un kā redzam ir atšķirība tīri liela, faktiski rezultātā no 4 IO iegūstam 1000base-T signālu ar 4. voltu līmeņiem  ::  vispār šajā gadījumā pat nav vaidzīgs neviens ārējais rezistors  :: , modelēju es Ciklon III IO TTL3.0 standartu.
[attachment=0:1eqllsrb]TTL3,0v-4ma_16ma-signāls.JPG[/attachment:1eqllsrb]

protams ka var nopirkt gatavu PHY čipu un tad lieta darīta, bet es to izpēti veicu tā apstīties vai kautko var arī uz fpga uztaisīt bez PHY, un kautko sanāk ka tomēr ir iespēja (bez eksperimentiem neko apgalvot nevar), cik tas ir ekonomiski izdevīgi es nezinu, bet gan jau ka ir  :: , bet vispār šitā 100base_t internet kodēšanas tehnika man liekās ka ir ļoti laba, un iespējams ka pēc tiem principiem varētu uztaisīt daudz labāku,un ātrāku komunikāciju uz lieliem attālumiem tieši starp fpga ar standart cat5 vadu. esošie standarti kā LVDS iet līdz 20metriem un ātrums tur kādi 400mbiti/s, jo garāks vads jo lēnāk iet, un nav zināms cik varētu ātri iet šitas variants ar tiem MLT-3 signāliem, kas sakodēti pēc visiem standartiem, varbūt ka attālumu varētu dubūltot nesamazinot ātrummu ! bet to var tikai eksperimentāli noskaidrot.

----------


## Epis

Ārprāc ko es nupat izdomāju, proti kā uz FPGA uztaisīt 1.6-2.6Gbit/s   ::   komunikāciju izmantojot parasto Cat5 vadu un parastos PAM-5 kodēšanas signālus(vai PAM-4), bet ar FPGA IO + mana kodēšanas tehniskā FIČA, darba frekvece pa visiem 4 vadu pāriem ir 40-66Mhz salīdzinājumā parastam 1000base_T tā ir 62.5 Mhz tākā signāli ies pa Lēto (pat vēl lēnāk nekā parastam ethernetam vienīgi viņu pārraidītais datu apjoms būs 1.6-2.6X lielāks.
Proti pa 1nu vadu pāri tiek pārraidīti 400-665 Mb/s (1000base-T ir 250Mb/s) 
ja neizmanto to PAM-5 un raida ar parasto Diferenciālo (2 voltu līmeņi) tad pa 1 vadu ar iepriekšējo frekvenci iet 240-399Mb/s 

 uzminiet nu kā es to idejiski dabūju gatavu ?? 
varat uzreiz uzdot sev jautājumu kā iespējams pārraidīt vairāk bitus par clock tikšķiem ??? (man tur ir 3x vairāk bitu nekā tikšķu, par tiem gļukiem un stabilitāti es protams neko nezinu, kautko tādu varētu tikai eksperimentāli noskaidrot)

Man tagat šito obligāti vaidzēs ietestēt,iemēģināt uz Fpga  :: .

----------


## vecteevs

> Ārprāc ko es nupat izdomāju, proti kā uz FPGA uztaisīt 1.6-2.6Gbit/s   
> Man tagat šito obligāti vaidzēs ietestēt,iemēģināt uz Fpga .
> man tur ir 3x vairāk bitu nekā tikšķu, par tiem gļukiem un stabilitāti es protams neko nezinu, kautko tādu varētu tikai eksperimentāli noskaidrot


 Aizej labāk eksperimentāli ieskriet  sienā !!

----------


## dmd

epi, oma likumu ātri noskaiti. tas būtu nummur viens.
palasi par crosstalku, tas būtu nummur divi

----------


## Epis

kautkā baigi ilgi man tās PCB taisās, būs laikam rīt jāzvanās, savādāk apnika gaidīt. 
bet nu vispār jau ar jauno ethernet Powerlink, un vispār ethernet komunikāciju ir tā bišķi jāpārdomā kā ko taisīt, tākā no otras puses būtu labi ja viņi neko nebūtu vēl uztaisījuši, tad varētu ievest ātri šādas tādas korekcijas (uzlikt LVDS vietā 2vus 100Mb Ethernet interfeisus proti 1nu bez PHY un 1nu ar PHY + uztaisītu FPGA ADC 6bit 20Msps, konvertiera shēmu (kādus 4 kanālus  ::  ) 
par ADC es atradu baigo informāciju, kur viens uztaisīja tādu FPGA plati un 6bit 22Msps ADC imantojot 3 rezistorus +kapacitātoru šeit no powrpoint prezentācijas attēli kā tas Zvērs darbojās, itkā teikts ka strādā tīri labi, nu ja strādā tad man arī vaig! (agrāk es jau tiku taisījis bet es izmatoju rezistor dalītāju, lai reference voltage comparātoram pievadītu priekš SAR tipa ADC, bet tur izmanto pavisam citu tehniku, proti lēde kapacitātoru un skaita laiku kāds paiet kamēr tas ir uzlādējies tik tālu ka komparātors nofiksē ADC vērtību un tad aprēķina to uzlādes laiku pēc kura arī nosaka ADV vērtību  ::  itkā ļoti vienkārši, tur tas čalis uztaisīja 10-12bit 2Msps ADC šādi, precizitāte man liekās ka ir pārspīlēti liela ! es domāju ka ar 5-6bit būtu OK.

Ja kas šitajā bildē ir attēltos frekvences 4x dalītājs un no tās shēmas var uztaisīt solīdu frekvences Counteri  ar augstu izšķirtspēju (~700ns)
[attachment=1:1c9zwy41]FPGA-6bit-ADC1.JPG[/attachment:1c9zwy41]
[attachment=0:1c9zwy41]FPGA-6bit-ADC2.JPG[/attachment:1c9zwy41]

----------


## Epis

Beidzot dabūju savas PCB no almiko  ::  viņi tur uztaisīja katru pa 3 gabaliem (kopā 6PCB pa 32Ls), izskatās jau baigi labi.
un visu dienu lodēju, un esu pielodējis 1 platei visus čipus,barošanas blokus, un vēl atliek salodēt sīkos kapacitātorus,reiztorus.
lielākā problēma bīj ar Barošanas bloku, proti es to ņēmu no Vecās nosvilinātās ciklon II plates un protams to es lodēju pirmo un kamēr nolodēju, pielodēju (pa vidu nekas kā parasti negāja, izrādijās ka 10uf tantalium kapacitātors bīj beigts un gāja uz īso kamēr man pieleca pagāja daudz laika.
šajā reizē PCB bīj taisīta pēc savādākiem Soldermask uzstādījumiem un man liekās ka šitie ir daudz labāki, jo abus divus TQFP 0.25mm kājas čipus salodēju samērā ātri, kājas kopā nelipa, un šoreiz es to Lodalvas pastu smērēju ļoti maz un bīj mazāk situāciju ka lodējot lipa vadi.
pagaidām atradu 3 defektus: 1 pie 1.2V LDO regulātora nepareizi vadi savilkti.
2 nopietnāks, proti, 16Mb flash atmiņai Fotprints ir pārāk mazs, tik mazs ka kājas nevar salodēt, tā dīvaini sanāca jo izrādijās ka šitā flaš ātmiņa ir izmēros platāka nekā otra 4mb ST atmiņa.
3. barošanas bloka kapacitātora GND pina poligons izrādījās bīj izolēts (nebīj kontakta ar īsto GND poligonu, nācās novilkt vadu. 

Vispār jau tā lodēšana ir baigais čakars it sevišķi ar lodāmuru viss grūtāk lodēt tos TQFP čipus, un to L5973 barošanas bloku jo tur ir daudz detaļu, kas vispirms ir jātrod, tad precīzi pēc polaritātes jānoliek un tas viss prasa laiku. 
ir protams kārtējā mācība "kā nevaig taisīt platei"  protams kā parasti nākošā plate būtu 2x labāka ar 2x mazāk detaļām un bez TQFP (ar BGA) un ar lielāka izmēra detaļām, jo tās sīkās detaļas pēc pieredzes ir vienas vienīgas galvassāpes.

Bildi ielikšu vēlēk.

----------


## Vikings

Epi, kāds Tev lodāmurs? Ja lodāmuram ir sakarīgs uzgalis, temperatūras regulācija un pieejams vis maz kaut kāds mikroskops vai normāla lupa tad arī 0,5mm pitch pročus lodēt ir kaifs.

----------


## jeecha

Ir naacies lodeet TSSOP un TQFP ar 0.5mm pitch, triviaali tas nav, bet izdaraams ar temperatuuras reguleetu lodaamuru/lodstaciju un smalku uzgali, palielinaamo stiklu un "solder wick" issavienojumu nonjemshanai tas ir un sagaadaa sava veida "mazohistisku" kaifu kaa jau Vikings mineeja  ::

----------


## Epis

Esu visas acis izmežģījis skatoties vai tās 0.25mm kājas ir pielodējušās un salipušas, lodāmurs man arī vecais pa 1.5Ls ar maināmiem galiem (bīj doma nopirkt šodien jaunu uzgali bet ritenim pazuda pretaizdzīsanas trose, tādēļ argusā nesanāca iebraukt un plati salodēt arī līdz galam nevaru jo trūkst to konektoru (USB,LTP port) 
ja man būtu tas profesionālais lielais,stacionārais palielināmais stikls ar apgaismojumu tad protams ka būtu kaifs lodēt a tā jo mazāk BGA lodēšana man labāk patīk (fiksi uzsmērē uz plates lodpastu, uzmet virsū čipu un liec iekšā krāsnī  :: ) pēc 10 minūtēm viss gatavs, pagaidām krāsnī man nav sanācis salodēt tos TQFP čipus, jo nav stancila un ar lodējamo pastu kuru izmantoju tagat vadi kopā līp un jēga likt krāsnī nav nekāda, varbūt ar kvalitatīvāku lodalvas pastu kautkas varētu sanākt, bet šitā kas man nav tik laba. 

ja kas vispār ir jādomā kā taisīt elektroniku, un PCB lai būtu pēc iespējas mazāk jālodē, savādāk var sanākt tā kā vienam tajā CNC zonas forumā, tas kurš 1.5gadus stepper draiveri projektē un jau pus gadu nevar uzražot, nesen viņš iepostēja ka ir nopircis lietotu PIck and Place mašinu    ::    kas sver kādus 800lbs  un kuriozs tajā ka nevar ievilkt viņu savā mājā (jāsit ārā sienas   ::   (un jūs te domājat ka es tāds patraks, paskataties ko citi gatavi darīt lai tik kautko uztaisītu  :: 

Es tā čaļa vietā būtu, tai vietā, lai pirktu veselu PickPlace mašinu, būtu pārprojektējis to draiveri, un mēģinājis samazināt detaļu skaitu cik vien var, kautvai ar kādām dārgajām viss vienā Actel Flash- Fusion FPGA (BGA pakā), proti 1 šāda mikrene aizvietotu visas viņa mikrenes (tos Attiny + CPLD) + ja viņam tur ir switch DC regulātori tad ņemtu gatavos POL (pa dārgo) lai mazāk jālodē, un domāju ka ja viņš to izdarītu tad varētu arī pats tos savus draiverus salodēt, _un jau sen tirgotu_ !! a tā kamēr viņš to mašinu uzstādīs, noregulēs paies vēl 3 mēneši. 
Dažreiz dzenoties pēc Lētuma mēs aizmirstam ka tas viss arī būs pašam jālodē !! tākā vai vairāk lētāku detaļu ir to vērtas ??.

----------


## GuntisK

Tu vienkārši esi slinks Epis! Poh kādas detaļas un kā tu to plati esi izprojektējis- jālodē būs tāpat!

----------


## Epis

Pāris šādas plates priekš sevis eksperimentiem salodēt es varu, bet lodēt kādu mazu partīju priekš pārdošanas vienkārši nav izdevīgi pārāk daudz laika aiziet un arī kādos cehos kautko tādu lodēt mazā partījā man liekās ka būtu dārgi, neizdevīgi.
tas no CNC zonas arī gribēja cehā lodēt bet viņi nosauca cenu kādus 45$ par plati un tādēļ viņš sāka pats lodēt, bet ka salodēja pirmās 5vai 10 plates redzēja ka tā lieta iet ļoti lēnu (1h salika detaļas 1 platei, bet pēc 2-3 platēm rokas piekūst un produktivitāte krītās tākā 1d kādas 3-4 tikai sanāk bet darbs visai dienai) un iedomājies ja uz plates būtu 4x mazāk detaļu tad varētu salikt detaļas 4x vairāk platēm un salodēt krāsnī 4x variāk pavisam cita lieta un produktivitāte. 

Tākā ražošana tā ir nopietna lieta tur visu rēķina naudā, nevis slinkumā. un es zinu ka šitā protatipa plate priekš ražošanas neder un vispār jau kautko optimizēt var tikai tad kad ir strādājoš protatips (man tāda vēl nav) ar visiem kodiem un tā tālāk, bet ir arī iespējams savlaicīgi jau protatipa stadījā domāt par to un izvēlēties tādas detaļas kurām ir lielāka optimizācijas iespēja, universalitāte, integrietāte.

----------


## Vikings

Ir ir Latvijā firmas, kas lodē detaļas uz plates un nebūs tur nekādi 45$ par plati. Vnk jāiet un jāinteresējas. Un to kā vispār iespējams, ka stundu jāliek detaļas uz motora draiva plates es galīgi nesaprotu.

----------


## Epis

Nu šeit ir bildes no tās viņa stepper driver plates (tie kas nav regustrējušies CNCzone fotkas redzēt nevar tādēļ izgriezu un samazināju izmērus lai varētu redzēt visi), 
http://www.cnczone.com/forums/showthrea ... 56&page=36
proti 1 ir pēdējā versija, otra bilde ir vecā versija, kā redzams
tadtur ir pamatplate ar 4 Attiny2313-20SU katram motoram savs un atsevišķi Power stage plate uz kuras izņemot diskrētos elementus stāv CPLDs (XC9536). 
šeit viņa paša apraksta frakgnemts: 



> The four AVRs (Attiny2313-20SU) on the PC interface board are the real brain behind the micro-stepping modes, torque compensation vs rotational speed, and reference voltage morphing features.
> 
> The CPLDs (XC9536) on the power boards provide the average current control, decay control, torque loss monitoring, as well as the safety features.


 tā CPLD ir barošanas bloka otrā pusē un tur vēl ir čupa ar diskrētajām SMD detaļām, kopā tur ir baigi daudz detaļu.
nebrīnītos ja arī barošanas blotki čipiem uz katras plates būtu savējie. 
Ekonomiska kombinācija būtu bījusi tāda 1na MCU(50-70Mips)  priekš 4 asīm + 1 liela BGA CPLD priekš draivera, vai ideālākajā gadījumā 1na FPGA priekš vissa  :: . un tad būtu reāls price/performance. pirmajā variantā varētu arī plates dalīt 2 daļās proti Interfeisa,smadzeņu daļa un 4asu Jaudas  daļa ar CPLD. domāju ka tas būtu daudz lētāk nekā šādā konfigurācijā.  + kārtīgām smadzenēm arī varētu ieprogrammēt advacētākus kontrolles algoritmus, kā tā asu sinhronizācija un tādā garā...
[attachment=2:9uheimbj]K-4-Size_comparison1.JPG[/attachment:9uheimbj]
[attachment=1:9uheimbj]K-4-Size_comparison2.JPG[/attachment:9uheimbj]
Power plates otra puse.
[attachment=0:9uheimbj]K-4-Rev3.02SMD_POWER2.jpg[/attachment:9uheimbj]

----------


## Epis

Un vēl ja tā paanalizē vispār hobby LTP porta plates uzbīvi tad parasti LTP porta signāli uz tās draivera plates tiek Opto izolēti un tas nav nekāds lētais prieks tā opto izolācija + ja draiveri sadala 2 un vairāk daļās tad atkal tur ir viss jāizolē, lai būtu plug & play, proti, darbības laikā iespraud, izspraud, un tad LTP ports beigu beigās izrādās tāds samērā padārgs, var pat teikt viss dārgākais variants, jo piemēram USB neko tādu īpašu tur nevaig, bet Ethernet ir vēl labāks variants tur ar transformātoriem viss ir izolēts (īstanībā šitas ir viss labākais variants) un 100Mb ethernetam ātrums pietiktu lai tos Step/dir pārraidītu.

Tākā principā lai uztaisītu Lētu hobby hardware ir no LTP porta jāpāriet uz ethernet un ja daraiveris ir dalītais tad starp smadzenēm un Jaudas daļu arī vaig ko līdzīgu ethernet, vai kādu lētāku, ātrāku alternatīvu kā LVDS,LVPECL kas domāts mazākām distancēm 5-20metri un ātrumi tur ir daudz lielāki 200-400Mb/s tākā varēs pārraidīt viss Datu apjomu no, uz smadzenēm, par motoriem un visu čotka kontrollēt. 

Es nesen lasīju par to cik LVDS, ir lētāks par parallelām datu maģistrālēm takā tas ir virs 2-5 pat 10X price/performance. + energo patēriņš! ir CPLD čipi ar LVDS IO ! 

Tā būtu tāda mana kritika un analīz par to kā vaidzētu taisīt šādu draiveri lai tas patiešām būtu ekonomiski izdevīgi, visos līmeņos (ražošanā salikšanā,energo patēriņā utt..)

----------


## jeecha

Tavam projektam arii tuliit buus gads... bet pagaidaam nav pat straadaajosha prototipa, kur nu veel razhoshana  ::

----------


## Epis

tas čalis profesionāls elektroniķis ar stāžu, es iesācējs, bet es kā iesācējs vismaz pa šo laiku esu sapratis kādu ceļu jāiet, bet tas profs gāja pa to ceļu pa kādu viņam bīj vieglāk (programmēja,lodēja to ko mācēja). un tāds ir rezultāts.
Vispār par to LTP portu tad tagat notiek tāda kā pāreja no LTP uz USB  dažādu iemeslu dēļ populārākais ka laptopiem vienkārši LTP porta nav, bet USB protams nav tas labākais, bet salīdzinot ar Ethernet ir krietni lētāks vismaz mikrenes ar integrēto USB ir lētākas par normālu ethernet mikreni (kā manējā STM32), un ir daži motoru draiveri kuri iet tieši ar USB, bet nopietnākām lietām tomēr ethernet.
 Ir 2 varianti vai USB, vai ethernet, ar USB jātaisa tāds vairāk Standa alone variants(datus sūta sakodētus), ar ethernet var taisīt kautko līdzīgu LTP portam kur datus,komandas sūta īstajā laika. man uz šitās plates kuru uztaisīju būs USB variants, proti varēšu uzglabāt SDRAM atmiņā lielu datu apjomu 128Mb +16meg flash tākā sanāk Stand alone variatns.  ::  
kad šito plati salodēšu tad mēģinšu cept kautkādus kodus tad redzēs kā kas, pagaidām visu saldēt nevaru jo nav nopirktas visas detaļas + jāuzlodē tas programātors.! 

mēģināju nofočēt plati, bet pēc pirmā kadra bačas izbeidzās, paspēju ielādēt komī.
bilde sanāca baigi sūdīgā jo focēju ar veco aparātu, laikam roka nokratījās tādēļ viss miglā, būs kautkā jāmēģina darīt ar tām baterijām, nevaru atrast lādētāju.

reku pagaidu bilde.
[attachment=0 :: avtlbg9]ECP2_LielāPlate1.JPG[/attachment :: avtlbg9]

----------


## Epis

Tā salodēju beidzot gandrīz visu plati (Ltp kontaktu nēsu vēl pielodējism jo argusā nebīj, rīt būs  :: ) + salodēju arī 5cus savus Super krutos, minī SIN Quadratūros Enkoderus (2vi SIN viļņi) ar mazo 16bit  MSP430F2012 MCU priekš digitalizēšanas priekš Kilo/CPR izšķirtspējas  :: 
Rīt būs jāsāk testēt un skatītes vai viss strādā kā nākās. viss lielākās bažas man ir par to fpga programmeri kuru uzlodēju no kautkāda 74HC4316   4kanālu MUX elementa, jo citu HC serijas kautkādu buferu nebīj ja šitas strādās tad tas vēl negarantē ka fpga ies, jo programmera shēma ir neoficiāla, proti atradu forumā, kur viens ielika tākā nav nekādu garantīju ka tā shēma ir īstā LTP porta ispProgrammera kopīja, maita ražotājs nepublisko to shēmu un 50$ maksāt negribās par programmeri.

ar bildēm ir tā ka man nav ejošu bateriju, bet vispār pie tāda kārtīga aparāta tikt varēšu nākošnedēļ ka bračka nopirks jaunu fočiku nikon D300 tad ar to varēs kvalitatīvi tuvplānā iefoķēt.
Vēl man negāja nopirktie RJ45 kontakti, kautkādus netādus man tur argusā iesmērēja, tur bīj laikam 2 varianti un es paņēmu neīstos  ::  bet nu tie RJ45 ir kā opcija, jo lielā 4xRJ45 kontaktu paka kā redzams bildē ir sen pielodēta.

----------


## Epis

kautkas man nav kārtībā ar plates barošanas blokiem jo ir tā ka 3.3V saiet uz īso ar 2.5V bloku.
Sākās visa skāde tad kad nolēmu pieslēgt plati pie barošanas tad man visā sistēmā rādīja 0.9V spriegumu, tad sāku skatīties kas par lietu un izrādījās ka 2vus dubūltos kapacitātorus bīju salodējis nepareizi (salodēju abaus galus kopā, bet vaidzēja atsevišķi jo tie ir 2vi kapacitātori 1nā pakā un līdz ar to sanāca ka salaidu 2.5V uz īso ar 1.2V, šito es izlaboju nolodējot nost tos 2vus vainīgos kapacitātorus, un neslēdzot atkārtoti pie barošanas vada pārbaudīju vai joprojām ir īsais starp 2.5V un 3.3V un izrādās ka ir, tad pārbaudījis visas vietas neko neatradu un nolēmu ka jānolodē 2.5V TL317 regulātoru, kad to izdarīju tāpat īsais starp 2.5V un 3.3v bet starp 3.3 un 1.2 īsā nav. un ap šo momentu man baterija multimetram nosēdās  ::  un neko vairs nevaru izmērīt. 
jāgaida rītdiena ka aizbraukšu uz argusu un bačas nopirkšu + LTP štekeri. 
man ir tāda sajūta ka tas īsais starp 2.5V un 3.3 ir nevis no PCB defekta bet gan iekš fpga čipa, jo cita varianta vienkārši nav, tur bīj kautkāds tāds specifisks barošanas bloka IO pins kā VCCAUX un tas ir pielikts pie 2.5V VCCIO3 (3 banka), pārējie 3 VCCAUX ir pie 3.3V (atrodās citās čipa pusēs).
Skatos specifikācijā un laikam ka tā arī ir ka visi tie VCCAUX ir iekšā savienoti un tas ir priekš iekšējās fpga struktūras, laikam būsū taisot PCB sajaucis jo vienā vietā bīj itkā rakstīts šitā:



> Auxiliary power supply pin. This dedicated pin powers all the differential and
> referenced input buffers


  un tad laikam ka es nodomāju ka jāliek viņš uz 2.5v priekš LVds un te laikam arī ir tā problēma.
Galvenais man lai nebūt sačakarēta pate FPGA jo 1.2V bīj uz īso ar 2.5Vun tākā tas bīj īsajā ar 3.3V caur VCCAUX tad paši saprotat viss fpga 1.2V kodols varēja iesvilt, bet dīvainā kārtā spriegums bīj 0.9V visā sistēmā tākā teorētiski ir cerība ka fpga tomēr būs palikusi vesela ! 

Vispār baigi daudz kļūdu, un šitā problēmas pamat cēlonis bīj šitie super mazie 0504 dubūltajie kapacitātori es tos sūdus lodēju kopā jo viņi ir vienkārši tik mazi ka ļoti grūti salodēt atru atsevišķi. ielikšu bildi bišķi vēlāk (nopirku bačas fotoaparātam) 

sanāk tā ka jālodē tagat otra plate un pirms lodēt jau PCB līmenī jāizlabo tā kļūda ar VCCAUX pinu, jo savādāk ja nestrādās 'pirmā plate tad es nezināšu kur problēma, proti, programmeris neiet, vai fpga sasvilusi tākā viens ir vainīgs.

Vispār es kārtējo reizi lodējot Plati nepareizi viņu lodēju, proti salodēju 3.3v regulātoru pēctam fpga un citus čipus, tad pašās beigās capactiātorus un mazos DC regulātorus un rezultātā īssavienojums, preizi būtu lodēt no sākuma visus kapacita'torus + barošanas blokun un pārbaudīt vai viss strādā, īso nav un tikai tad fpga un citus, bet es jau nevarēju nociesties, man vaidzēja to fpga pielodēt pēc iespējas ātrāk  ::

----------


## Epis

Reku bildes pāris vietās aizkrāsoju GND poligonu zaļās maskas tekstūru ar zaļo krāsnu, lai samazinātu bildes faila apjomu  zem 100kb jo nu man savā inbox albūmā kautkā vairs nesanāk ielikt bildes  ::   un nācās arī sagriezt bildi 2 daļas.
[attachment=1:ztxjx1ug]ECP2-PCB2.JPG[/attachment:ztxjx1ug]
[attachment=2:ztxjx1ug]ECP2-PCB1.JPG[/attachment:ztxjx1ug]

un šeit vainīgās vietas, kur bīj lodēšanas kļūda, ievērtējat cik tie kapacitātori miniatūri un tādus ir baigi grūti lodēt, it sevišķi ja katra kāja ir savam voltu līmeni, ja jālodē abas kopā tad vēl normāli.
[attachment=0:ztxjx1ug]ECP2-Back1.JPG[/attachment:ztxjx1ug]

----------


## Epis

Tā beidzot barošanas regulātori strādā, nācās mest ārā tos vecos L5973D un aizvietoju ar Tps76833 Lineāro un tad viss sāka strādāt un esu sadedzinājis arī vienu TSP79301. 
Rezultātā būšu nočakarējies 3-4 dienas ar tiem L5973D regulātoriem, ja būtu lodējis pilnīgi svaigus regulātorus tad varbūt ka viss būtu kārtībā, bet tākā tie bīj nolodēti no vecās plates tad nekas nesanāca.
Tagat jāsalodē līdz galam programmeris un jāskatās vai fpga strādās vai nestrādāsm ja nestrādās tad jāsalodē otra plate līdz galam un vēlreiz jāmeģina, ja arī tad nestrādās tad ar oscilu jāskatās programmera signāli, ja tur neko nerādīs tad skaidrs ka programmera shēma nekam neder un jāsūta no mouser īstais programmers.

----------


## Epis

NU tā beidzot izdevās ISP kabelis strādā, proti pagaidām tikai varu CPLD ieprogrammēt (jo salodēju vadus pa taisno ar LTP portu) lai varētu arī fpga domāju ka jāmēģina apvienot Alteras programmeris ar šito Lattice ISP.  ::  
Jāsāk pārlodēt Alteras programmeri lai programmē arī lattice čipus  :: 

šeit bilde no pagaidu programmera  ::  

un vēl atradu internetā kādu veco Lattice PDF kur ir tā kabeļa shēma uzzīmēta  ::  jaunajos PDF tās shēmas vairs nav bet šitā ir īstā jo man strādā (tikai bez tā bufera, ar buferi noteikti ka ar ies.)
 [attachment=0:3ht8t1hf]ISP programmer shema.JPG[/attachment:3ht8t1hf]

----------


## Epis

Tā, nupat konstatēju ka esu tomēr nosvilinājis vienu jauno 11$ ECP2 fpga čipu pašā sākumā kļūdaini salodējot kopā pāris dubūlto smd kapacitātoru kājas, kur vienai bīj 1.2V otrai 3.3V un ar to es sadedzināju čipa kodolu  ::  par to es esu pārliecināts jo beidzot uzlodēju strādājošu JTAG programmeri un abas divas CPLD strādā (tiek atpazītas, inicializētas), bet fpga dod ārā tukšu bildi (neko) tākā būs jāņem rokā nazis un jāgriež nost visas fpga čipa kājas un tad jānolodē un jālodē virsū rezerves čips (pasūtīju es 3 čipus proti 1 rezervei, šādas situācijās atmaksājās rezerves pasūtīšana  :: .
šitas ir 2 fpga čips kuru esu jau ar nepareizu voltu līmeni nosvilinājis, iepriekšējā bīj vainīgs barošanas bloks, nepareizi rezistoru uzstādījumi un ielaidu 5V iekš VCCIO tagat cieta kodols dēļ kļūdas lodēšana, nākošreiz es vairs tādus dubūltos kapacitātorus neizmantošu, un ja izmantošu tad abus divus 1 voltu līmenim, nevis katram savu.
Stm32 procis noteikti ka strādā.

----------


## Epis

URĀĀ beidzot fpga strādā  ::   un kad pārlodēju fpga čipu tad uzreiz nekas negāja un kā parasti atradu kārtējās kļūdas lodēšana (nebīj pielodēts 10k pull-down Xres pins dēļ kā vispār nekas neiet, un VCCJ (jtag power pins), tākā man tagat īsti nav skaidrs vai tas vecais fpga čips tomēr strādāja vai bīj beigts   ::   bet to tā arī nekad neuzināšu jo es viņu no plates nevis nolodēju bet gan nogriezu šeit bilde, es kautkur izlasīju ka tā ir viss labāk ņemt nost tos nestrādājošos TQFP čipus, jo lodējot ar lodāmuru sanāk plēst un tad var noplēst nost arī PCB celiņus bet šitā viss notiek ātri un kvalitatīvi.
[attachment=0:2fzzirhl]ECP2-nogriezta.JPG[/attachment:2fzzirhl]

Tagat jāmēģina iekonfigurēt un ierakstīt konfigurācijas datus SPI flash atmiņā lai čips varētu pats sevi iestartēt, šitas man vēl nav izdevies uz nevienas ieprieksējās fpga plates, parasti tur kautkas negāja un ciklon III es pat mēģinājis vēl nēsu ar paralēlo flash konfigurēt. un pēc tam sākšu beidzot kodēt  ::  varētu mēģināt SDRAM atmiņu iedarbināt un STM32 proci caur STM32 kita Jtag.

----------


## Epis

ieprogrammēju Led mirgošanas progu un Leds mirgo, tad mēģināju ierakstīt progu SPI flashā bet,kā parasti, nekas nesanāca,  Rāda ka flash atmiņas "CHECK ID" verifikācija nenostrādāja, būs jāskatās kas pa lietu ar to flash atmiņu.

----------


## Epis

UrāĀ   ::   beidzot tomēr viss strādā, izdevās ielādēt SPI flashā programmu un pēc tam noņemt programmeri,atvienot USB un pieslēdzot atkal pie USB (bez programmera) SPI iekonfigurēja FPGA un mana led TEst programma strādāja  ::  tas nozīmē ka tagat pirmo reizi mūžā man fpga konfigurējās. 
Atradu vēlvienu kļūdu uz PCB, proti nebīj pielikts CS(Chip Select) pins, uz fpga tas ir DI/CSSPION 86. pins, tai vietā tas bīj pielikts pie GND (itkā pareizi, bet kad dziļāk apskatījos kā strādā tā SPI flash tad pie rakstīšanas operācijas to CS pinu vaig perjodiski ieslēgt uz 1, un to dara fpga, šito es protams ka nezināju projektējot plati.

----------


## Epis

iemēģināju uzbūvēt laticeMicro32 proča sistēmu (čipā nelādēju), un apskatījos demo C kodiņus un kāda parasta Led diodes spīdināšana aizņem vairāk atmiņas nekā man tur ir iekš Fpga čipa, (man tur ir tikai 3 Ram bloki) tākā es pagaidām domāju to lielo procesoru tomēr neizmantot (man tur viņš ar šādām perifērijām SDRAM,GPIO8pin,UART,1onchipRAM aizņēma ~3300Lut +1 DSP 32x32bloks un procesoram nebīj uzlikta L1,L2 cach atmiņa ja to uzliek tad vaig papildus 8 RAM blokus tākā šito proci var reāli likt iekšā iekš 2x lielākas fpga, bet man tur ir pa maz to resursu, līdz ar to plāns tagat tāds apskatīt un iemēģināt mazo Micro8 8bit proci (tas ir ļoti mazs 200-400 Lut + 1Ram bloks kodiem) un šitas kodējās ASMĀ, un vēl jāpamācās ar C kodēt tā Stm32 proča perifērijas,un jāuztaisa tā USB komunikācija  ar kompi. tad domās kā tos motorus tur sinhronizēt, un izpildīt tos kodus. 

Un es tur kārtējo reizi nevaru saprast kā viņi ar C kodu piekļūst klāt tām periferijām (GPIO,UART utt..) caur tiem Draiveriem un sūdīgi tas ka tur tie draiveri kodējās ar C++, un tur lielākā problema ir tie stūlbie pointeri un galvenasi ka tā stūlbi salikt ka nevar saprast ko viņi ar to vispār domā? šeit viens piemērs kā tiek ar GPIO (Ledos) ierakstīta vērtība


```
//šādi viņi izskatās ka paņem LED perifērijas atrašanās adresi kas ir 0x80000080;
MicoGPIOCtx_t *leds = (MicoGPIOCtx_t *)MicoGetDevice(LED_GPIO_INSTANCE);
//iet visādi kodi un šitā vieta man ir viss neskaidrākā

while(1){
		*((volatile unsigned int *)(leds->base)) = ~iValue;
```

 vot kā lai saprot to *(( int *) (a)) = C  nevaru sarast kā var šādi rakstīt (int *) ko tas vels parāvis nozīmē ??? meklēju google un tādus brīnumus atrast nevaru.
ir rezes ka man tā C valoda baigi tracina ar šādiem visādiem brīnumiem.


lai saprastu no kurienes es izraku tos koda gabalus tad šeit pilns mazais kods


```
#include "DDStructs.h"
#include "LookupServices.h"
#include "stdio.h"
#include "MicoUtils.h"

const char *LED_GPIO_INSTANCE = "LED";
const unsigned int uiBlink = 1;

int main(void)
{
	unsigned int iValue = 0x1;
	unsigned int iShiftLeft = 1;

    /* Fetch GPIO instance named "LED" */
	MicoGPIOCtx_t *leds = (MicoGPIOCtx_t *)MicoGetDevice(LED_GPIO_INSTANCE);
    if(leds == 0){
        printf("failed to find GPIO instance named LED\r\n");
        return(0);
    }
    printf("found GPIO instance named LED\r\n");


    /* if we're not to blink, return immediately */
    if(uiBlink == 0)
        return(0);

    /* scroll the LEDs, every 100 msecs forever */
	while(1){
		*((volatile unsigned int *)(leds->base)) = ~iValue;
		MicoSleepMilliSecs(100);
		if(iShiftLeft == 1){
			iValue = iValue << 1;
			if(iValue == 0x100){
				iValue = 0x40;
				iShiftLeft = 0;
			}
		}else{
			iValue = iValue >> 1;
			if(iValue == 0){
				iValue = 0x02;
				iShiftLeft = 1;
			}
		}
	}


    /* all done */
	return(0);
}
```

----------


## Velko

> vot kā lai saprot to *(( int *) (a)) = C  nevaru sarast kā var šādi rakstīt (int *) ko tas vels parāvis nozīmē ???


 C valodas pamati...

Pointeris būtībā ir mainīgais, kas satur kādu atmiņas adresi, pēc kuras ir kautkas atrodams. Pointerim ir tips, kas parāda, kam tajā adresē būtu jāatrodas.

MicoGPIOCtx_t *leds - pointeris uz adresi, kurā atrodas MicoGPIOCtx_t tipa vērtība, izvietota pa baitiem, kas atrodas sākot no šīs adreses.

leds->base - acīmredzot tas MicoGPIOCtx_t ir struct vai class, kurā ir lauks "base". Ar -> ņemam to base vērtību.

(volatile unsigned int *)(leds->base) - acīmredzot "base" satur kautkāda tipa pointeri, vai vienkārši skaitli. Nezinu kāda tipa pointeri, bet acīmredzot - ne tāda, kāds mums vajadzīgs. Mums tas nepatīk - gribam lai tas būtu pointeris uz "volatile unsigned int". "volatile" - var mainīties neatkarīgi no programmas (var mainīt dzelži). "unsigned" - bez zīmes. "int" vesels skaitlis. Atkarībā no kompilatora/arhitektūras var aizņemt 1, 2, 4 vai 8 baitus.

Ārējais *() - gribam tikt pie vērtības, kas atrodama pēc šīs adreses, šajā gadījumā tajā ierakstīt. Visa 
"*((volatile unsigned int *)(leds->base))" konstrukcija atbilst "volatile unsigned int" tipa mainīgajam. Neliels piemērs:


```
#define my_leds *((volatile unsigned int *)(leds->base)) /* my_leds tiks aizvietots ar šo "briesmīgo" konstrukciju */
//volatile unsigned int my_leds; /* semantiski tas pats, bet neatradīsies pareizajā adresē, aizkomentēts */

/* un visbeidzot */
while (1) {
    my_leds = ~iValue;
}
```

 Varbūt sākumā liekas ārprāts, tomēr šī manipulēšana ar pointeriem praksē ir ļoti noderīga.

Neliels mājas uzdevums: kā savādāk varētu pierakstīt "leds->base"? Ir vismaz 2 (drusku garāki) veidi, kā varētu to uzrakstīt.

----------


## okars

> Un es tur kārtējo reizi nevaru saprast kā viņi ar C kodu piekļūst klāt tām periferijām (GPIO,UART utt..) caur tiem Draiveriem un sūdīgi tas ka tur tie draiveri kodējās ar C++, un tur lielākā problema ir tie stūlbie pointeri un galvenasi ka tā stūlbi salikt ka nevar saprast ko viņi ar to vispār domā?
> 
> 
> ```
> //iet visādi kodi un šitā vieta man ir viss neskaidrākā
> while(1){
> 		*((volatile unsigned int *)(leds->base)) = ~iValue;
> ```
> 
> ...


 Aaaaaaaaaaaaaaaaaaaaa, kaa es reecu!  ::  Lielie inzhenieri atduras pret pointeriem!  ::  Tad redz kur sleepjas CPLDisma buutiiba - cilveecinjsh vienkaarshi nesaprot kaa darbojas procesors. Nu ko, varbuut, apguvis pointerus un citas programmeeshanas iespeejas, driiz inzhenieris prieksh sevis atkal atklaas ko fantastisku un galvenais neredzeeti jaunu - procesoru.  :: 




> tur lielākā problema ir tie stūlbie pointeri


 Pointeri nevar buut stulbi, bet programmeetaajs, kuram pointeri ir probleema, gan viennoziimiigi ir stulbs un par programmeetaaju saukties nav pelniijis.




> meklēju google un tādus brīnumus atrast nevaru.


 Tad jau inzhenieris pat google lietot nemaak. Kaut vai te:
http://msdn.microsoft.com/en-us/library/caaw7h5s.aspx
http://msdn.microsoft.com/en-us/library/d9f2bsy2.aspx

Bet vispaar es domaaju, ka te mums vislabaak vareetu liidzeet programmeeshanas eksperts *tvdx*! Ekspert, ko teiksi? Stulbie pointeri, ne?   ::

----------


## jeecha

Haha, Epis atkal uzjautrina... Neliels precizeejums - "tie stuulbie pointeri" (taapat kaa viss paareejais koda gabals ko tu tur iemeti) nav C++ bet gan C.
Ar ko C++ ashkjiraas no C? Origjinaali ar to ka C++ ir klases jeedziens, muusdienaas veel klaat operatoru paarlaadeeshana, templeiti, virtuaalas funkcijas utt utjp.

Anyway, kaa tu taisies vispaar ieksh C kautko rakstiit ja nesaproti pointerus? Iesaku graamatniicaa nopirkt kaadu C graamateli "dla chainikov" un paniekoties ar GCC kautvai kautkaadas "hello world" programminjas parakstiit, jo nesaprotot kaa un kam lieto pointerus un pointerus uz pointeriem iipashi taalu netiksi.

----------


## Epis

apsties SMD krāsns visualC# kodu man tur nevienā vietā nebīj jāliek nekādi *un &, un iepriekšējam nios II procis es arī varēju kautko vienkāršu uzkodēt bez pārāk smagām darbībām piemēram to pašu kvadrātsaknes kodu es tur palaidu  :: , un tur es varēju Asamblerī arī kodēt (apmēr kā AVR studijā asmblerī kodēt), un ielādēt kodu čipa lai paspīdināt ar proci Ledus, a šeit nav nekādas atsevišķas asamlbera progas kur ieliec vienu .S failu un lādē iekšā, caur tiem IDE  ar C es tos .S failus palaist nemāku un ar asm arī šādas mainīgās platformas nav īspāsi prāta darbs kodēt, jo tās perifēriju adreses var mainīties tādēļ ir jāiemācā šitā automātiskā adrešu ņemšana kas ir caur tiem perifērij draiveriem.

C pamatus es zinu, bet tajās visās pamācībās nav visas variācijas kā tiek tie pointeri tur izmantoti un šitas vairants ka (a*) tur nav!! man joprojām nav skaidrs jo es nevaru atrast nevienu pamācību kur tā pēc kāda mainīgā liktu to *zīmi un tad vēl iekavas ? bet izskatās ka šajā IDE tiek tāds stils izmantots, parasti rakta tā  *a (pirms bet tur ir pēc un man tas nav skaidrs !

Pagaidām es vēl nēsu palaidis debageri, ir tur instrucion set simulātors(ISS), bet tas karās augšā un neiet, laikam ka vienīgias kā to kodu debagot ir laist viņu uz fpga un tad jāskatās no kurienes kā programma tās vērtības tur ņem.

šeit viens piemērs no tā GPIO draivera (pamat fails  DDStruct.h 

```
#define MicoGPIOCtx_t_DEFINED (1)
typedef struct st_MicoGPIOCtx_t {
    const char*   name;
    unsigned int   base;
    unsigned int   intrLevel;
    unsigned int   output_only;
    unsigned int   input_only;
    unsigned int   in_and_out;
    unsigned int   tristate;
    unsigned int   data_width;
    unsigned int   input_width;
    unsigned int   output_width;
    unsigned int   intr_enable;
    DeviceReg_t   lookupReg;
    void *   prev;
    void *   next;
} MicoGPIOCtx_t;


/* gpio instance gpio*/
extern struct st_MicoGPIOCtx_t gpio_gpio;

/* declare gpio instance of gpio */
extern void MicoGPIOInit(struct st_MicoGPIOCtx_t*);
```

 Kas tas par pierakstu:   (struct st_MicoGPIOCtx_t*)   kkādēļ to * neliek pirms st_MicoGPIOCtx_t ? 
un tās GPIO adreses sanāk ka tiek ņemtas no DDStructs.c 


```
/* gpio instance gpio*/
struct st_MicoGPIOCtx_t gpio_gpio = {
    "gpio",
    0x80000080,
    255,
    1,
    0,
    0,
    0,
    8,
    1,
    1,
    0};
```

 Un es nevaru saprats kā viņi to *leds pointeri tad uzstāda šeit tā kodu rinda kas to dara:
 /* Fetch GPIO instance named "LED" */
	MicoGPIOCtx_t *leds = (MicoGPIOCtx_t *)MicoGetDevice(LED_GPIO_INSTANCE);

un tālāk cik varu saprast tad caur to leds arī tad var piekļūt visām  struktūras  st_MicoGPIOCtx_t vērtībām (kuras tiek automātiski ieliktas kad uzģenerē to visu sistēmu.)

*((volatile unsigned int *)(leds->base)) = ~iValue;

man vaig kautkādu taisno ceļu kā to uzkodēt bez tā MicoGetDevice, kas laikam ir "LookupServices.h" faila funkcija,koda gabals..

Vai kāds var atrast pamācību kur būtu šitas pointera piemērs ( kautkādaVērtība *)  ???? es atrast nevaru, esu izskatījis vairākas C pamacības grāmatas nekur nav  ::

----------


## Epis

Es apskatījos kā ir ar ARM proča kodu paraugiem no IAR kicktart progas un tur arī vienā vietā demo kodā bīj kautkas līdzīgs, bet tur šitas pointers bīja tika tajās 2 rindās viss pārējais kods izskatās kā parasti normālam kodam jāizskatās, bez pointeriem un visādiem citādiem sūdiem, perifērijas arī definējās ļoti primitīvi vienkāršā stillā :
ja man šitam procim viss notiktu tādā pašā stillā tad es te neprasītu neko par tiem (sarežģitajiem) pointeriem, jo bez viņiem var iztikt, un pārsvarā izmanto parastos pinterus, nevis šādi sačakarētos kur nevar sapras uz ko tad viņš īsti tur normāda, un ko vispār dara !!    ::  


```
T0PWMCON_bit.PWM3ENA =   1;                  // Match register 1 is source of toggle
  T0MR3 = PCLKFREQ/350;                        // 350Hz square wave
  T0MR1 = PCLKFREQ/500;                        // 30% duty cycle
```

 

```
#include "RTC_Interrupt.h"
#include <math.h>

void main (void)
{
 
  /* šeit ir kroplīgais Pinteris (unsigned int*) ko tas vells parāvis nozīmē ???  kādēļ nevar rakstīt bez iekavām normālā stillā?
  unsigned int *ptr2VectCtrlBase = (unsigned int *)0xFFFFF200;
  unsigned int *ptr2VectAddrBase = (unsigned int *)0xFFFFF100;
```

----------


## jeecha

Ak dies Epis, nu luudzu luudzu tomeer izlasi kaadu graamatinju par C... tie iekavaas ir typecasti...

Respektiivi ko tad noziimee 

```
unsigned int *ptr2VectCtrlBase = (unsigned int *)0xFFFFF200;
```

 Stekaa tiek uztaisiits mainiigais (pointeris uz unsigned int) kuram tiek pieshkjirta veertiiba 0xFFFFF200 (respektiivi pointeris raada uz adresi 0xFFFFF200).

Tagad pa daljaam:
unsigned int *ptr2VectCtrlBase ---- tiek deklareets mainiigais kura tips ir pointeris uz unsigned int
(unsigned int*)0xFFFFF200 ---- konstante 0xF... tiek nocastota uz tipu pointeris uz unsigned int, respektiivi rezultaataa mees ieguustam pointeri kursh raada uz adresi 0xFF...

P.S. C un C# vai Java ir LJOTI maz kopiigaa... vispaariigi njemot - liidziiga sintakse, tas arii viss.
P.P.S. Nu luudzu luudzu tomeer iemaacies kas ir pointeris, kas ir typecast, kas ir referenceeshana un dereferenceeshana (sorry es tieshaam nezinu kaa muusdienaas shos sauc latviski) - nu vismaz centies izlasiit un saprast kaut vai http://pweb.netcom.com/~tjensen/ptr/pointers.htm

----------


## Epis

Galvenā problēma ir tajā koda izmērā, man tagat tā Demo LED test proga aizņem ~33Kbytes koda   ::  
tas tač ir pilnīgs sviests, es asmā nios II procim tos Ledus spīdināju ar kādām 5-10 asm rindiņām koda izmērs bīja labi ja 0.1kB, a te 33kB.
Vot kā lai uzkodē ar C minimāla izmēra kodu ?? 

tagat mēģinu būvēt sistēmu ar SPI flash atmiņu, ir tā ka man ir 2vas SPI flash atmiņas 1na konfig. otra papildus brīvā.
Uztaisīju vienu proča sistēmu tādu kuru varētu ielādēt iekš fpga, bet problēma jau ir tur ka es tajā savā čipa nevaru ielādēt to Led test progu kas aizņem 33KB  :: , vaig kautkā uzrakstīt programmu kas aizņems nevis 33K bet max 2KB.

----------


## zzz

Mjaaa, epja kodeeshanas prasmju eliitisms aplauzaas uz nepietiekama izmeera fpga.  :: 

Jaja, ir taada paveida "programmeetaaji".

Nu ko, epi, njem ka praksee Meerfija likumus un konkreeti:

Neteeree veltiigi speekus, panjem lielaaku aamuru, ops, fpga dotajaa gadiijumaa.  :: 

Nu vai arii kaa iistens uuberhacka drikjee visu naakotnes supercnc zoftu asembleraa. C ir prieksh vaarguljiem un veel visaadi stulbi pointeri iekshaa, kam vinjus nafig vajag!!!  ::

----------


## Velko

> Galvenā problēma ir tajā koda izmērā, man tagat tā Demo LED test proga aizņem ~33Kbytes koda


 Ko tu tur ellē ratā linko klāt? Pašai programmai (tā kurai puslīdz pilnu kodu iedevi) iekš 1KB vajadzētu mierīgi salīst.

Izmet ārā _printf_, tā ir ļoti smaga funkcija. Tas _MicoGetDevice_ arī izskatās tā, ka tur baigi liela un universāla draiveru bibliotēka klāt linkojas. Bet tev jau nekas vairāk kā tā "base" vērtība nav vajadzīga - izmanto porta adresi pa tiešo.

----------


## jeecha

Klau, a kaadeelj vispaar shitaa bakstiishanaas ar to fpga procesora IP, vai tad tev uz plates nebija kautkaads procesors blakaam?

----------


## Epis

tagat es domāju vai vispār ir vērts likt šito lielo 32bit proci iekš fpga, vai arī mazo 8bit (micro ::  tas kodējās ASMā, bet kautkādu proci man tur iekšā vaig, lai 1. savienotu savu perifēriju kaudzi, 2. bīdītu datus un veiktu kādas primitīvas datu manipulācijas īstajā laikā kā PID, un tas stm32 pris ir domāts priekš USB komunicēšanas, bet nu tad jau redzēs kas kā..
tagat man ir jāiedarbina, jāizpēta tas iekšējais procis lai redzētu kā tur tās lietas notiek, un tad skatīsies vai tas ir to vērts vai tomēr jāliek vairāki 8bit proči (katrai asij savu 8bit proci  ::  ).  

kautko esu sen atpakaļ lasījis par kautkādiem linkeriem, make failiem un visādiem C brīnumiem, bet parasti ir tā ka ja to pats neiemēģini,un tam cauri neizrocies tad viss ātri ātri aizmirstās, un laikam ka ir pienācis laiks rakties, un tā kur tad slēpjās tas fails kurā ir sagrūstas visas tās bibloteku kaudzes, kas neko nedara ??? 

bet vispār jau stūlbi, man VHDL kods kompilējās bez nekādiem tur linkeriem, un es tur vienkārši pats pievienoj failus no kādiem tad tā loģika sabūvēta ar lodziņu interfeisu, nekādi tur kodi nav jākodē, pārsvarā ja faili atrodās vienā mapē tad viņi paši savienojās, un proga visu izdara manā vietā, kādēļ tad C nav tāda automātiska failu atrašanas ielikšanas proga ? kas no tiem biblotekas failiem paņem to ko reāli kodā izmanto un pārējo met ārā, bet te izskatās ka visu drazu paņem un tad sanāk 33K atmiņa.

----------


## Velko

> kādēļ tad C nav tāda automātiska failu atrašanas ielikšanas proga ?


 Ir tāda proga. Saucas linkeris  ::  Un tas pievieno *tikai* to, kas nepieciešams - nekāda "lieka draza" netiek pievienota. Cita lieta, ka funkcijām, kuras tu izmanto ir nepieciešams ļoti daudz koda, lai tās spētu pilnvērtīgi darboties. 

Piemēram _printf_ - universāla izvades/teksta formēšanas funkcija. To, kāds teksts jāizvada nosaka format strings (pirmais arguments), pēc tam var sekot visu iespējamo tipu argumenti, kurus tas galu galā pārveido par tekstu. Turklāt nekad nevar iepriekš paredzēt, kāds format strings tiks padots - tas ir tikai mainīgais, līdz ar to - tiek linkots klāt viss, kas varētu būt nepieciešams. Tas pat var nozīmēt, ka linkojas klāt floating-point bibliotēka - kautkā tak jāvar floatu uz tekstu pārveidot, ja nu gadījumā iekš format stringa & argumentos tāds parādās. Un vispār - kāda vella pēc tur printf? Printf uz kurieni? UART? LCD? HVZ?

Tas pats ar to _MicoGetDevice_ - lookupo iekārtu pēc teksta. Izskatās, ka šī funkcija spējīga sameklēt jebkuru dzelzisku ieŗīci, kas tajā procī pieejama. Lai tā to varētu izdarīt (nekad nevar zināt, ko tieši gribēsi sameklēt) - atkal linkojas klāt visi iespējamie draiveri.

Tā ka "stūlbi" ir tikai tas, ka tu nepapēti kodā izmantotās funkcijas sīkāk, bet žēlojies par build sistēmas nepilnībām.

----------


## Epis

uztaisīju jaunu C projektu ieliku 1nu C failu ar parastu darbību:
int main(void)
{
int a=5;
int b=6;
int C=a+b;
}
uzspiedu Build Project pogu un atkal uzģenerēja veselu kaudzi kodu tagat elf fails aizņem 25,6Kbaiti nu itkā ir mazāk nekā 33Kb bet joprojām neadekvāti daudz, mēģināju kautko izmaninīt tajos make file, un galvenajā makefile izkomentēju vienu rindiņu:
#declare C sources needed for archive
C_SRCS += 		DDInit.c	\
		DDStructs.c	\
	#	MicoStdStreams.c	\  šito izkomentēju ārā lai nebūvē to MicoSTDStreams.C

bet kad nospiedu atkal build prjektu tad kompis uzģenerēja visu no jauna un tās izmaiņas  kuras ieliku pazuda un vis kā no jauna.
Kā lai šito auto ģenerācijas sūdu atslēdz ??? esu gatavs kautvai ar roku tās bāzes adreses inicializēt, lai tik netaisa tos Kb koda !

----------


## zzz

Par izmantojamo izstraades tuulju probleeminjaam konsulteejies ka pie sho tuulju piegaadaataajiem, taa luuk beerninj epi, "nekādu problēmu.  :: "

----------


## vecteevs

jebitiit ar visaaaadaaam  raimondroshaam fignjaam   kompileet  kodu prieksh 1 usd procha ir tiirais nepraats. 
Jebal Epi es tev ticeeju par

----------


## Epis

Šodien mēģināju palaist hardware debuggeri, un utaisīju proča loģikas failu,ielādēju iekš fpga un tad caur to IDE piedu debug un nesūda neiet  :: , 
procis man bīj uztaisīts tāds: GPIO(8līnijas), SPI16Mb flash čips, un EBR (on chip memory 2kB) un pate programma protams ka aizņēma tos 26KB tādēļ domāju ja ielādēšu flashā visu to kaudzi tad kautkam vaidzētu strādāt, bet nekā  ::  
pēc tam pieleca ka reāli ka parasti programma strādā tā ka nolasa instrukcijas un ja instrukcijā ir kādi dati jāsaglabā tad saglabā, a kur manā gadījumā tas procis tos datus sglabās ??? (ar 2kB kas ir uz fpga nekam nepietiek, un Flash atmiņai lai kautko saglabātu vaig dzēst ārā veselu lapu 512bytes un tad lai kautkur noglabātu ir vispirms jāsaglabā esošie dati, tad jāizdzēš un jānomaina tā informācija esošajos datos un tad jāraksta viss iekšā flashkā acīm redzot šito compileris nemāk darīt. un pats process ir tik šausmīgi bremzīgs ka jēgas nav nekādas, un rezultātā pat Debugeris neiet !! 
Vienīgā izeja laikam ka ir iedzīvināt to 128Mb SDRAM atmiņu (itkā wisbone SDRAM perifērija ir piejama, bet tā ir ar 32bit datu līniju un parametri uzstādīti arī kautkādi citādāki, tākā pārtaisīt to Verlog kodu priekš savējās SDRAM būs pagrūti, bet laikam ka citas izejas nav jo šitā SDRAM tad būs gan instrukcijām, gan datiem un tad cerams ka tas debuggeris beidzot iedarbosies.
man jau nāk tāda doma ka moš mans LPT programmers pa švaku, un vaig kādu drutāku USB JTAG, bet domājot loģiski vaina ir mazajā RAM atmiņā dēļ kuras procis vienkārši neiet, jo cik palasīju tad debuggeris arī pieliek savu kodu papild porciju pie pamat koda.

ierakstīju savu bēdu stāstu arī Lattice forumā, redzēs moš kāds kautko pamācīs  ::  šeit jau neviens tāpat neko nerubī par tik specifiskām lietām.

----------


## dmd

ZOMG!   ::   ::   ::

----------


## jeecha

Jaa, ko lai saka, drusku abloms tavam konceptam uz leetajaam FPGA likt procesoru IP. RAM ta nepietiek lai instrukcijas un datus keshotu. Starp citu aareejais SDRAM tev diez vai paliidzees jo man ir sajuuta ka procesora keshiem parasti lieto atminjas kuras var lasiit/rakstiit vienaa ciklaa (piemeeram aatrus SRAM turpat blakus uz kristaala vai aareejus). Tas gan protams atkariigs no taa kaadu tad procesoru tu tur baazi - von Neumann vai Harvard arhitektuuras.

Un veel - nav taada Verlog, luudzu iemaacies beidzot nosaukums pareizi rakstiit  ::

----------


## Velko

Pirms neliela laika kāds forumā rakstīja:



> sen jau tie laiki ir pagājuši ka uz fpga kodēja pliku loģiku, mūsdienās vispār vari vairs loģiku nekodēt, paņem uztaisi procesoru sistēmu no gataviem kodiem(IP core), 10 minūšu laikā un tad kodē procesoru


 Nu, ko - tad tik uz priekšu...

----------


## Epis

Tā ir zināms progress noticis :=>  man beidzot nāca apskaidrība lasot Software devolper User's Guide nonācu nejauši līdz pēdējai sadaļai meklējot pavisam citu informāciju par verilog un tā sadaļa saucās Software Development
Utilities, kur tad pēc kārtas ir aprakstīti visi tie ZVĒRa GCC instrumenti kā: lm32-elf-as (assemblers); lm32-elf-gcc(compilers);
lm32-elf-ld (linkers), un lm32-elf-objcopy kas uztaisa no elf bin failu kuru itkā tad var lādēt kādā flash atmiņā.

un tā nebūtu nekāda apskaidrība ja es nebūtu atradis kādu piemēru kā es Asm kodiņu varētu pārvērst par programmējamo flashā failu, vai arī iekšējā proča ram failā. un šeit tad ir tas mazais paragrāfs kuru izlasot man nāca apskaidrība,apgaismība, ar kuru es tagat kāpšu ārā no kārtējās bedres kurā kā parasti iekritu  :: 


```
The following two commands are used to compile the boot copier code into an executable image: 

lm32-elf-gcc -c BinCopier.S 
lm32-elf-ld BinCopier.o --section-start .text=".$BootAddress" -
 o BinCopier.elf 

In Figure 144, .$BootAddress represents the flash memory address that will contain the merged boot copier and the application binary. It is also the address location that the microprocessor’s EBA register must contain so that the microprocessor starts fetching instructions starting from this address on reset. The effect of providing the section-start parameter to the linker is that it creates an .elf file that entirely resides in the flash. This executable is then converted into raw binary format for programming to the flash device. The command used for doing this is as follows: 

lm32-elf-objcopy -O binary BinCopier.elf flashprog.bin 

The output is a raw binary format file, flashprog.bin, which can now be programmed to flash memory, using a flash programmer. This file contains the boot copier executable, as well as the application’s binary image stored as data, which can be copied by the boot copier to target memories from the non-volatile flash memory storage. 
lm32-elf-objcopy -O binary BinCopier.elf flashprog.bin
```

 


> sen jau tie laiki ir pagājuši ka uz fpga kodēja pliku loģiku, mūsdienās vispār vari vairs loģiku nekodēt, paņem uztaisi procesoru sistēmu no gataviem kodiem(IP core), 10 minūšu laikā un tad kodē procesoru


 Tieši tā arī ir paņem no gataviem IP blokiem saliec (es jau pa šo laiku kādas 10 versijas esu paspējis salikt) un tad atliek tikai kodēt, bet problēma jau ir tur ka piemēram tas SDRAM kods bīj tādam čipam, bet man ir savādāks čips atšķirības nav lielas bet tākā tā ir cita valoda tad tas nebūs viegli.

----------


## Velko

Nu, iemācies gan ar GCC apieties. Principi paliek tie paši gan x86, gan AVR, gan citām GCC supportētām arhitektūrām (ieskaitot to lm32). Nebūs "jāmācās viss no jauna", kad vajadzēs kādu citu proci programmēt.

----------


## Epis

nu tā programma CYGwin shell ir vienkārši sausmīga proga, visu dienu nočakarējos lai vienu asm failu (paņemu uz dullo) asamblētu un dabūtu Objekt .o failu un pēc tam mēģināju elf uztaisīt bet parādīja čupu ar defektiem.
un čakars bīj tur ka tā proga man sākumā rādija;
[/] $  
un tad tur itkā tajā logā ir kautkas jāraksta un es ierakstu kā pec parauga
[/] $  LM32-elf-as crt0ram.s 
un nekas neotiek met ārā ka nevar atrast failu, vai mapi, un tad skatos savā pdf manuālā tur bilde ar attēlu kā izskatās tas logs un tur [/] $ vietā ir [/cygdrive/c/.un tā tālāk adrese..] $ 
un tad es sapratu ka vaig kautkā iedabūt iekšā to adresi bet kā ??? izmēģināju viskautko un uzraku netā komandu cd [path] 
un sāku mēģināt visādus variantsu un vis laik erori, kamēr kautkas sāka sanākt, un parādijās pirmā adres
[/cygdrive/e/fails] $   
bet man tā adrese ir baigi garā un rakstot lielāku gabalu nekas atkal neiet, beigās izrādās ka lai dabūtu tālāk ir jāraksta katra mapīte atsevišķi  ::  
[/cygdrive/e/fails] $  cd \LM32\ 
[/cygdrive/e/fails/LM32] $ cd \LedTest\   .. un tā tālāk līdz aizrokos līdz tai mapei kur stāv Asm fails un tad ieliekot to Lm32-elf-asm crt0ram.s  kautkas uztaisījās. 
čakars ar to batch ir baigais. un slikti tas ka nav nromālu pamacību, tās kas ir ir baigi sūdīgās. 
vaig pamēģināt nokompilēt parastu C failu redzēs kas notiks.

----------


## jeecha

Jaa, nu tam kursh neko citu muuzhaa kaa GUI nav lietojis ar CLI protams zinaamas probleemas vareetu buut...
Tas "shausmiigais" shells ir Bash, un iipashi par vinja tizlumu neviens nesuudzaas. Varbuut man ir gruuti objektiivi spriest jo es ikdienaa rakstu C/C++ kodu un Makefiles bez nekaadas IDE uz Linux, AIX, SunOS un HP-UX. Man piemeeram daudz eertaak un saprotamaak shkjiet ar rokaam sarakstiit kaadus shell vai Python scriptus, Makefile utml, nekaa kautkaadaa IDE bakstiities ar peliiti.

Un vispaar Epis, tu pirms tam apgalvoji ka tev patiik maaciities jaunas lietas, bet peedeejaa laikaa C pointeri redz ir stuulbi un Bash shells ir shausmiigs...

----------


## Epis

dēl tiem make failiem un vispār visa GCC es ari AVR kodēju asmā pa taisno ar AVRstudiju, tādēļ es arī uzskatu ka iemācītes asambleri kodēt un uzrakstīt kodu uz tādas programmas kur vari to .s failu ielikt ar kādu pogu nokompilēt un ielādēt ir daudz vieglāk nekā ar to GCC un C valodu, pate C valoda ir viegla bet tā visa kombinācija ir pašausmīga, un galvenais šausmu cēlonis kā parsti ir sliktās pamācibas kur neko nevar saprast.
es tagat lasu mekleju visādas pamācības par to make failu (es teikšu kā ir es vēl nēsu saprastis kur kā to make tad aktivizē caur to bash logu vai, itkā bīj pamācībā tāda vienkārša instrukcija make all kas laikam ņem to make un tad tas kas tur iekšā to visu sakompilē.

pamatos tas make fails izskatās vienkārš bet kad apskatos kādus make failus ģenerē mana IDE tad es tur neko nesaprotu itkā pamācībā rakstīts ka var tos IDE auto make failus izmantot kā paraugu, bet kā lai izmanto ja nevar vispār saprast kas tur notiek (es tur neredzu nevienu normālu make rindiņu tādus simblolus variacījas es tutoriālos atrast nevaru) 
šei galvenā makefile saturs. 


```
################################################################################
# Automatically-generated file. Do not edit!
################################################################################

#************************************************************************
# Version=3.0
#************************************************************************
#************************************************************************
# PROJECT SETTINGS
#************************************************************************
PROJECT_NAME=Led11k1
BUILD_CONFIGURATION=Debug
PROJECT_DIRECTORY=..

PLATFORM_DIRECTORY= $(PROJECT_DIRECTORY)/Led11
PLATFORM_NAME=Led11
PLATFORM_FILE=Led11.msb
PLATFORM_FILE_PATH=../../Led1/Led11/soc
PROJECT_USER_PREF=$(PROJECT_DIRECTORY)/user.pref


PLATFORM_PERL_FILE_PATH = C:/ispTOOLS7_1_STRT/micosystem/utilities/perlscript/lm32/
#************************************************************************
# Installation path for peripherals
#************************************************************************
MDK_PERIPHERAL_DRIVERS_DIR_PATH=$(PLATFORM_FILE_PATH)/../components
PERL_BUILD_SCRIPTS_PATH=../$(PLATFORM_FILE_PATH)/../components/lm32_top/gnu/
APP_BUILD_PERIPHERALS_PATH=../$(MDK_PERIPHERAL_DRIVERS_DIR_PATH)



#************************************************************************
# Identify project-sources: MANAGED BY ECLIPSE!!
#************************************************************************
OUTPUT_DIR = $(BUILD_CONFIGURATION)
ROOT = ..
SUBDIRS := \
. \


-include $(SUBDIRS:%=%/subdir.mk)
ifneq ($(strip $(DEPS)),)
-include $(DEPS)
endif

CC = lm32-elf-gcc
SYSCFLAGS += -ffunction-sections -O0 -g2 -w -D_USE_LSCC_PRINTF_
LDFLAGS +=-Wl,--gc-sections
INCLUDE_PATH+=
PLATFORM_LIBRARY=./$(BUILD_CONFIGURATION)/lib$(PLATFORM_NAME).a
PROJECT_LIBRARY+=
PROJECT_LIBRARY+=$(PLATFORM_LIBRARY)
ARCHIVE_OBJS+=

#************************************************************************
# obtain root for compiler toolchain
#************************************************************************
CC_PATH = $(dir $(shell which $(CC)))

#************************************************************************
# Identify USE_STANDALONE_SMALL_PRINTF
#************************************************************************
USE_STANDALONE_SMALL_PRINTF = TRUE

#************************************************************************
# COMPONENTS/PLATFORM MAKEFILES
#************************************************************************
include $(PERL_BUILD_SCRIPTS_PATH)/build_processor.mk
include $(PERL_BUILD_SCRIPTS_PATH)/build_drivers.mk
include $(PERL_BUILD_SCRIPTS_PATH)/gnu_rules.mk

LD = lm32-elf-gcc
CFLAGS += -ffunction-sections -O0 -g2 -w -D_USE_LSCC_PRINTF_
VPATH += ./../$(PLATFORM_NAME)
C_SRCS+= $(APP_C_SRCS)
ASM_SRCS+= $(APP_ASM_SRCS)
CXX_SRCS += $(APP_CXX_SRCS)
ARCHIVE_OBJS+= $(APP_ARCHIVE_OBJS)
INCLUDE_PATH+=./../$(PLATFORM_NAME)

#************************************************************************
# Identify executable-name for this application
#************************************************************************
PROJECT_EXE=$(PROJECT_NAME).elf

#************************************************************************
# IDENTIFY C LIBRARY
#************************************************************************
# USE_SMALL_LIBC is populated by managed-build process
USE_SMALL_LIBC = FALSE
# special processing when using small-libc
ifeq "$(strip $(USE_SMALL_LIBC))" "TRUE"
C_LIB = -lsmallc
else
C_LIB = -lc
endif
#

#************************************************************************
# FUNCTIONS
#************************************************************************
define fn_remove_file
	rm -f $1
	@echo
endef

.PHONY: all $(DIST_LIB_MAKE) dummy

#************************************************************************
# Default rule: build everything
#************************************************************************
all: dummy $(DIST_LIB_MAKE) force_clean_archive_objs $(PROJECT_EXE)



#************************************************************************
# Rule to build dependent libraries
#************************************************************************
$(DIST_LIB_MAKE):
	@$(MAKE) --directory=$@

#************************************************************************
# Dummy rule to create output directory as well as
# run make on the "synchronous" makefiles
#************************************************************************
dummy:
	@mkdir -p $(OUTPUT_DIR)
	@echo $(INCLUDE_PATHS)

#************************************************************************
# Rule to build the project (application)
#************************************************************************
$(PROJECT_EXE) : $(ARCHIVE_OBJS) $(PROJECT_LIBRARY) 
	@echo building application...
	$(LD) $(CPU_CONFIG) $(PROJECT_LINKER_SCRIPT) -o$@ $(ARCHIVE_OBJS) $(PROJECT_LIBRARY) -lm $(C_LIB) -lgcc $(PROJECT_LIBRARY) -lnosys $(LDFLAGS)
	lm32-elf-size $(PROJECT_EXE)

#************************************************************************
# clean archive objects due to changes from Eclipse
#************************************************************************
force_clean_archive_objs: $(PROJECT_USER_PREF) ../$(PLATFORM_FILE_PATH)/$(PLATFORM_FILE)
	@echo detected change in user.pref or platform...
	@echo force-cleaning archive objects...
	$(foreach object,$(ARCHIVE_OBJS),$(call fn_remove_file,$(object)))
	touch force_clean_archive_objs
	@echo

#************************************************************************
# Rule to clean everything
#************************************************************************
clean:
	@echo cleaning project objects..
	$(foreach object,$(ARCHIVE_OBJS),$(call fn_remove_file,$(object)))
	rm -f -r $(OUTPUT_DIR)
	rm -f *.o
	rm -f *.elf
```

 Es pagaidām saprotu tikai šāda tipa make failus: (kā pēc tutoriala) 


```

    project.exe : main.obj io.obj
    	tlink c0s main.obj io.obj, project.exe,, cs /Lf:\bc\lib 

    main.obj : main.c
    	bcc –ms –c main.c 

    io.obj : io.c
    	bcc –ms –c io.c
```

----------


## Velko

Nu, es makefailus rakstu ar roku. Ģenerētajos arī man šķiet pagrūti iebraukt. Apmēram tādi izskatās mani makefile priekš AVR:


```
PROGRAMMER=usbasp
TARGET=motor
OBJS=main.o uart.o motor.o

CC=/usr/bin/avr-gcc
CFLAGS=-g -Os -Wall -mcall-prologues -mmcu=atmega8
OBJ2HEX=/usr/bin/avr-objcopy
DUDE=/usr/bin/avrdude

all: $(TARGET).hex

program : $(TARGET).hex
        $(DUDE) -p m8 -c $(PROGRAMMER) -y -U flash:w:$(TARGET).hex

%.elf : $(OBJS)
        $(CC) $(CFLAGS) $(OBJS) -o $@

%.o : %.c
        $(CC) -c $(CFLAGS) $< -o $@

%.hex : %.elf
        $(OBJ2HEX) -R .eeprom -O ihex $< $@

clean :
        rm -f *.hex *.elf *.o
```

 Atceries, ka tur, kur ir atkāpes obligāti jābūt TAB simbolam (atstarpes nederēs).
Palaižās jamais vienkārši, lai nokompilētu:


```
make all
```

 Un lai ieflashotu atmelī:


```
make program
```

 Pamatprincips ļoti vienkāršs - palaižot make 'kautkas', tiek meklēts vai ir nepieciešams kompilēt dependences (tās kas pie 'kautkas' aiz : ) un tā rekursīvi uz priekšu. Kad visas dependences ir up-to-date, tad palaižas komanda(s), kas rakstītas ar atkāpi zem 'kautkas'.

----------


## jeecha

Epis, tas ka tu nesaproti uzreiz nenoziimee ka tas viss ir shausmiigi un pamaaciibas ir sliktas. Miljoniem cilveeku nesagaadaa nekaadas gruutiibas shell scripti un GNU make Makefiles. Atrodi googlee pirmo "makefile tutorial" un uz priekshu, saakumaa protams iesaku iepaziities ar kaut vai bash pamatiem.
Un jaa - IDEs protams gjeneree diezgan "piepuustus" Makefile, bet iisteniibaa nekaa ljoti sarezhgjiita vinjos nav - vienkaarshi iemaacies pamatus (kas Makefile ir "rules", "variables" un "dependencies").

P.S. Esmu tevii diezgan viilies - ja liidz shim man likaas ka tev patiik peetiit jaunas lietas, vieniigi shii energjija parasti tiek novirziita ne gluzhi pareizaa virzienaa, tad peec peedeejiem postiem kuros tu vienkaarshi "noliec" lietas kuras nesaproti... nu nez nez.

----------


## Epis

Velko piemērs jau kautcik saprotams, protams ne pilnībā bet tur vismaz jau var redzēt līdzīgu kodu.
plāns tagat tāds uztaisīt mazu C kodu un kā include ielikt tikai DDStructs.h failu un tad caur main C failu piekļūt tām perifērijām ar parasto pointeri (es atradu kautkādu piemēru).  un kad dabūšu tos elf tad vaig mēģnāšu vēlreiz debaggeri palaist uz fpga, ja tas neies tad būs jāuztaisa kāds Led spīdināšanas kods un jāielādē iekš fpga kopā ar konfigurāciju visu proča kodu un jāskatās spīd Leds vai nē.
asmā protams ledus spīdināt ir vieglāk nekā ar C, vienīgi tad tās adreses ar roku jāraksta.

----------


## Epis

> P.S. Esmu tevii diezgan viilies - ja liidz shim man likaas ka tev patiik peetiit jaunas lietas, vieniigi shii energjija parasti tiek novirziita ne gluzhi pareizaa virzienaa, tad peec peedeejiem postiem kuros tu vienkaarshi "noliec" lietas kuras nesaproti... nu nez nez.


 viss atkarīgs no pētāmā objekta simpātijām,patikšanas, motivācijas proti lasīt visādus tehnologiskus žurnālus,kodēt iekš Visual C# ir patīkami, bet mācītes kodēt kādu veco,vizuāli prastu DOS stila logu,softu nav neko patīkami, es tādas nepatīkamās lietas daru tikai galējās nepieciešamības gadījumā, ja savādāk nevar, un ir pienācis brīdis ka patiešām savādāk nevar, ja tāds brīdis nebūtu pienācis (varēja reāli nepienākt, ja viņiem tajā IDE būtu super maza izmēra C bibloteka kāda ir Nios II procim kur patiešām var uzrakstīt mazu kodu  un ielādēt iekš pāris KB iekšējā ram un smuki debagot. un dēļ lattice koderu slinkuma man tagat jāmocās  :: .
salīdzinājumam man arī nepatīk verilog valoda, jo tur tie signāli kodējās tā pārāk vieglā, bezatbildīgā stillā, nepavelti tika izdomāta VHDL kur ir stingrāka kodēšanas disciplīna, tur viss ir kārtīgi,smuki salikts pa plauktiņiemm salīdzinājumam verilog valda pamatīgs bardaks, bet VHDL tīrība un kārtība.

----------


## Epis

Nupat skatoties CNC zone ieraudzīju tādu baigi aktīvo topiku un izrādās ka tur apspriež nesen parādījušos CNC motion kontrollieri  "CNCbrain" galvenais ka tas ir lēts 500$ un tam ir 6 asis un dubūltā closed loop kontrolle tas ir tieši tas ko man vaig proti ja 1 ass sāk bremzēt,atpalikt tad visas pārējās arī piebremzē, tālāk tā cncbrain kaste pie kompja slēdzās caur USB un strādā neatkarīgi no PC (tāda bīj arī mana ideja par neatkarīgu ierīci) un tas kompja softs viņiem tur ir taisīts uz VB. (visual studijas 2005 ) un visu sorce kodu viņi tur ir ielikuši līdz ar to var to softu pats pielabot,pietaisīt priekš savas CNC iekārtas, vārdsakot tā ir industriālas kvalitātes kontrolle, bet cena kā hobby elektronikai līdz ar to piejama jebkurai kabatai  :: .

http://www.safeguardrobotics.com/defaul ... b=cncbrain
http://www.cnczone.com/forums/showthrea ... =CNCBrains

Teikšu kā ir man tieši tādu verķi visu laiku vaidzēja, viens ir skaidris to viņu CNC visual studijas softu es toč izmantošu un piekodēšu savai ierīcei  :: . 
nav īsti skaidrs kādu proci tad izmanto tas CNCbrain kontrollieris raksta ka viņam ir paralēla daba, un vēl visādi multitreading brīnumi, ka tik tur iekšā nav kāda fpga.
savu hardware es protams turpināšu taisīt neskatoties uz to ka ir parādījusies reāla alternatīva.

----------


## Velko

> kodēt iekš Visual C# ir patīkami, bet mācītes kodēt kādu veco,vizuāli prastu DOS stila logu,softu nav neko patīkami


 Pēc maniem novērojumiem - grafiskā interfeisa programmu rakstīšana ir visķēpīgais no visiem programmēšanas darbiem. Labi, tādu "pečkas progu" ar vienu logu, grafiku un pāris pogām uztaisīt nav grūti. Bet kad jātaisa kas lielāks - brr. Nekad nevar paredzēt, kādā secībā useris pa tām kontrolēm klikšķināsies, bet jānodrošina, lai jebkurā gadījumā viss strādātu pareizi.

Konsoles programmas šajā ziņā ir daudz vienkāršākas. Ir ievaddati, ir algoritms un ir izvaddati, nekādu "pārsteigumu" pa vidu.

CLI sākumā liekas grūti, taču kad iemācās - daudz ko var paveikt ātrāk un efektīvāk, nekā spaidot podziņas un ķeksīšus. Kā man darbā sysadmins teica:



> Q: Kāpēc operētājsistēmai vajadzīga grafiskā vide?
> A: Lai varētu vairākus termināļus vienā ekrānā palaist.

----------


## jeecha

Nu protams, ir starpiiba pechkas viens lodzinsh vai nopietna GUI aplikaacija. Bet tas ir taapat kaa saliidzinaat kautkaadu vienkaarshu consoles aplikaaciju (kas ievadaa sanjem datus, kautko pagremo un atdod atvasinaatos datus) ar nopietnu distributeetu sisteemu kura mezhoniigaa aatrumaa starp chupu dazhaadiem datu avotiem visu translee, reekjina, saglabaa datubaazee un atdod rezultaatus. Shaadai sarezhgjiitaakai sisteemai biezhi vien "aareejo kairinaataaju" ir ne mazaak kaa lielai GUI aplikaacijai... un kad sisteemai saak paraadiities prasiibas atbildeet ne veelaak kaa noteiktaa laikaa, apstraadaat tuukstoshiem "transakciju" sekundee, nodroshinaat 99.999% "uptime" utt utjp, tad taa vairs nav nekaada "sviestmaize ar sieru" un jaapieliek ljoti liela atjautiiba un izdoma lai to norealizeetu  ::  Bet tas jau ir pilniigi cits staasts un ne par teemu.

Man piemeeram arii PIC kodu eertaak un pierastaak shkjiet rakstiit nevis MPLAB IDEe bet savaa pierastajaa teksta redaktoraa ar "syntax highlighting" (manaa gadiijumaa tas ir NEdit prieksh X, bet pa cik man uz WinXP taapat staav Cygwin+XFree86 deelj taa ka darbaa visa izstraade notiek prieksh Unix, tad nav nekaadu probleemu lietot NEdit arii zem Cygwin, zinu tas ir perversi, bet kautkaa esmu ljoti pieradis pie taa redaktora ::  un kompileet uzrakstot vienkaarshu Makefile. Dazhi koleegji savukaart visu kodu raksta ieksh VIM (VI-iMproved) pa taisno ssh shellos, bet nu tas manupraat ir drusku pa skarbu... bet nu tas jau ir kaa kuram eertaak un pierastaak. Viens no lielaakajiem plusiem shaadai uz Makefile (patiesiibaa make nav vieniigaa iespeeja, ir arii ant un citi toolji shaadiem meerkjiem, bet tas principu nemaina) baazeetai pieejai ir iespeeja taisiit "Single-command-build" - respektiivi ar vienu komandu iespeejams uzbuuveet visu sisteemu, neatkariigi no taa kaadaas tehnologjijaas ir taisiitas taas sastaavdaljas. Mazam projektam tas varbuut neshkjiet svariigi, bet kad sisteema sastaav no chupas dazhaadu sastaavdalju tad tas jau paliek ljoti kritiski.

Naakamaa lieta ir "izejas koda versiju kontrole" - iesaku kautko taadu lietot arii maziem hobija projektiem (pieraduma peec arii maajaas lietoju Subversion). Kaadreiz var ljoti nodereet informaacija par to kas un kaadeelj piemeeram kodaa tika pamainiits pirms pus gada... vai piemeeram "atrulleet" kodu atpakalj uz staavokli kaadaa tas bija pirms nedeeljas kad tika uzsaakts dzerstinsh kura rezultaataa viss kods tika salauzts.

Labi, sorry par spamu, nenaak miegs un neko nopietnu iisti negribas dariit, tiem kas straadaa programmatuuras izstraadee viss augstaakmineetais droshvien taapat bija pashsaprotams.

----------


## Epis

Mēģinu visādos variantos to make failu uztaisīt bet nekas nesanāk  ::  


```
LD=lm32-elf-ld  #/ispTOOLS7_1_STRT/micosystem/gtools/bin/
CC=/ispTOOLS7_1_STRT/micosystem/gtools/bin/lm32-elf-gcc

LED : DDInit.o 
	$(LD)  -o LED DDinit.o
	
DDInit.o : DDInit.c 
	$(CC) -c DDInit.c 

crt0ram.o : crt0ram.s 
	lm32-elf-as -o crt0ram.s

#/user/bin/ld: cannot find -luser32 
# erors: make: *** No rule to make target ĻED'.  Stop.
```

 shellā rakstu:  make LED  un tad man izmet ārā erroru;
make: *** No rule to make target ĻED'.  Stop.

Itkā daru vissu pēc pamācības bet nekas nesanāk kas pa vainu ? 
sanāca tajā shell atsevišķi uztaisīt to Objekt failu un pēctam Elf failu, bet tas apjoms ir ap 5KB parastai A+B=C funkcijai, un pamēģināju arī vienu inicializēšanas ASM failu un tāpat elf apjoms turās pie 4-5KB vai tas ir normāli ? 
un kā vispār uztaisīt un nokompilēt C failu kurš izsauc ASM inicializācijas failu ?

----------


## Velko

> shellā rakstu:  make LED  un tad man izmet ārā erroru;
> make: *** No rule to make target ĻED'.  Stop.


 Neraksti vis make LED.  Tu raksti make *Ļ*ED   :: 

Nu, labi - varbūt nē (ja pārrakstīji to kļūdas paziņojumu).

Atceries, ka UNIX sistēmās (kuru emulē arī CygWin) tiek ņemts vērā burtu "lielums" - DDInit.o un DDinit.o ir 2 dažādi failu nosaukumi.

Vēl vienā vietā esi piemirsis -o atslēgu.

Ar ASM inicializācijas failiem ir tā, ka koda izpilde sākas ASMā, kur tiek uzstādīts steks un citas kritiskas lietas, bet pēc tam no turienes tiek izsaukts main() C kodā.

Par faila izmēru - apskaties ar _objdump_ tam .elf failam - kas tad tur īsti sanācis. Noderīgas atslēgas šai programmai: -s (parāda saturu pa sekcijām), -d (disassemblēts kods) un -h (parāda kopsavilkumu) Visdrīzāk -s un -d rezultātus vajadzēs failā saglabāt. Piemēram:
_objdump -d LED.elf > kautkadsfails.txt_

----------


## Epis

Tā es tagat izdomāju ka lai iemācītos ar tiem make failiem strādāt un tos C kodus kompilēt (kopā ar ASM) izmantot to WinAVR  progu (kurā kompilē AVR kodus) un tagat ir tā ka atradu labu apjomīgu pēc izmēriem GNU make pamācību 
http://www.gnu.org/software/make/manual/make.html#Goals

es to Velko failu bišķi pārtaisīju jo tā pa taisno man viņš tur negāja un pagaidām nevaig to programmēšanas funkciju, galvenais ir nokompilēt un tikt līdz elf failam kas pagaidām neizdodās. 

slikti tas kad tajā Programmers Notepad progā tos Warningus un erorus nevar nokopēt tādēļ nākās fotku likt.

šeit mans kake kods:


```
#all: hello.o 

#hello.0: hello.c
#	avr-gcc -o hello.o hello.c 
	
#PROGRAMMER=usbasp
TARGET=hellohex
#OBJS=hello.o
LD=C:/WinAVR-20080610/bin/avr-ld
CC=C:/WinAVR-20080610/bin/avr-gcc
CFLAGS=-g -Os -Wall -mmcu=atmega8\
 -mcall-prologues
OBJ2HEX=C:/WinAVR-20080610/bin/avr-objcopy
DUDE=/bin/avrdude

all: $(TARGET).hex

#program : $(TARGET).hex
#	 $(DUDE) -p m8 -c $(PROGRAMMER) -y -U flash:w:$(TARGET).hex

%.elf : hello.o
	 $(LD) $(CFLAGS) hello.o -o hello.elf

hello.o : hello.c
	$(CC) -c $(CFLAGS) hello.c -o hello.o

hellohex.hex : hello.elf
	$(OBJ2HEX) -R .eeprom -O ihex hello.elf hellohex.hex

clean :
	rm -f *.hex *.elf *.o
```

 šeit hello.c kods (šeit ir kāda problēma cik var pēc erroriem noprast, bet kāda es nesaprotu itkā kods kā kods nekā tur tāda nav.)


```
void main()
{
 unsigned INT A=4;
 unsigned INT b=7;
 unsigned INT c = B-A;
 
  return 0;
}
```

 un kā lai to Asm failu tad tur ieliek tajā make failā ? (pagaidām asm failu nēsu uztaisījis, bet tā nav nekāda problēma paņemšu vienu no vecajiem SMD krāsns failiem un līdz stackpointerim  izgriezīšu  :: 

un te vesela čupa ar erroriem
[attachment=0:gi6f2pt7]Error_warning1.JPG[/attachment:gi6f2pt7]

ko tur vaig tam C failam kādas biblotekas ?? ja jā tad kā make failā viņas uzlikt, un vai tad standartā lai nodefinētu INT a vispār vaig kādu bibloteku ?

----------


## jeecha

1) C/C++ viss ir "case sensitive" atshkjiriibaa no paskaala vai beisika vai sazin kaa veel;
2) ja tev funkcija ir deklareeta ka neko neatgriezh, tu nevari taisiit return 0;
3) patiesiibaa main() parasti tiek deklareeta kaa funkcija kas atgriezh int...



```
int main()
{
        unsigned int a= 4;
        unsigned int b= 7;
        unsigned int c= b-a;
        return 0;
}
```

 P.S. Joprojaam silti iesaku palasiit kaadu graamatinju par C/C++ pamatiem...

----------


## Epis

Beidzot sanāca uzģenerēt pirmo HEX failu  ::  priekš ATmegas8 tā C funkcija aizņem 38baitus  ::  

patiešām tagat viss aizgāja, sūdīgi ka nav normālas IDE kur to kodu rakstīt ,tad tādas kļūdas varētu pamanīt, a tā bez IDE nevella nevar pamanīg tās kļūdas.
Ja kas tās IDE progas parasti koderi mīl jo viņās var ātrāk kļūdas atrast + pats galvenais ir tā automātiskā kodu pabeigšanas fiča kā Visual C# kur pietiek uzlikt pirmo burtu un var fiksi,automātiski uzmest veselu funkciju un galvenais ka tas viss būs gramatiski pareizi  ::   un tā automātika reāli kāpina kodēšanas produktivitāti + samazinās kļūdas.

Tagat jau jaunais Hīts ir grafiskās izstrādes vides (laikam cypress MCU ir ir kautkāda tāda izstrādes vide), kur apakšā ir tie auto kodu gēnerātori kautkas līdzīgs visualC# kad veido grafiski tos windows lodziņus un tad pēc auto uzģenerētā koda kautko pats piekodē klāt, tikai tur tā automātika savieno perifērijas un kodē kautkādu funkcionalitāti, protams zem katra bloka apaksā jābūt reālam iepriekš izstrādātam kodam, ja ir tāda liela kodu bibloteka tad šādi tā lieta protams iet ātrāk uz priekšu, tas pats ir arī ar fpga proču sistēmas būvi grafiski sabīdi,izvieto perifērijas un uzģenerē sistēmu vienīgi pēctam jākodē.

Nēsu vēl teicis ka nesen izlasīju ka Ti beidzot ir izlaidis free compileri zem linux saviem C6000 DSP pročiem , tas nozīmē ka var nopirkt pa 11-15$ kādu tms32C6720(vai 2) proci 144Tqfp pakā un reāli iekodēt tur programma tiem pročiem lādējās no ārējās flash atmiņas kā fpga tākā nekādus JTAG nevaig pirkt, pats galvenais jau ir tas ka tā jauda ir zvērīga piemēram 200Mhz procis iet ar 1600Mflops  un energo patēriņš 250Mhz (2GFLOP) kodolam ir ap 0.7W + IO kādi 0.2-3 W 
tas jau praktiski ir vesels galda kompis, ja pieliek klāt flash + SRAM,vai SDRAM. un kādu loģiku jo procim ir pašvaki ar perifērijām tur izņemot seriālo interfeisu un Memory managment vienību nekā cita nav (ne USB,ethernet MAC,UART, karoči pliks procis kam vaig klāt vēl funkcionālo vienību, uz šito es tēmēšu tikai tādā gadijumā vaidzēs tos peldošos punktus un kautko nevarēs izdarīt.

----------


## jeecha

Nez, es jau nez cik gadus rakstu C/C++ kodu bez nekaadas IDEs un par produktivitaati nesuudzos.

Anyway, ja ljoti gribas, lieto Eclipse http://www.eclipse.org un prieksh AVR vari lietot AVR-C plug-inu http://avr-eclipse.sourceforge.net/.

----------


## Epis

Tagat ir jauna problēma ar to asm failu kautkā tas WinAVR neatpazīst to asm sintaksi, met ārā visādus tupus erorus.
ja kas bīj arī problēmas ar to m8def.inc include failu tur arī neko neatpazīst kautkā dīvaini.
šeit starts.S asm kods


```
#include "m8def.inc" 
.org 0x000
	rjmp reset 
.org 0x003 
	rjmp TIMER2_COMP
.org 0x004
	rjmp Timer2_overflow
.org 0x00B
	rjmp UART_RX_compleate
.org 0x00E
	rjmp ADC_complete

.org	 0x01E
	rjmp USART_TX_compleate

.EQU Triac = 5 ; Triac Pins PD5

reset: ; the reset code:
; stack setup; set SPH:SPL to
; RAMEND
	cbr	R16,1<<Triac  ; Triac OFF
	out	PORTD,R16
	clr R0
	clr R1
	clr r2
	clr R3
	clr r4
	clr r5
	clr r6
	clr r7
	clr r8
	clr r9
	clr r10
	clr r11
	clr r12
	clr r13
	clr r14
	clr r15
	clr r16
	clr r17
	clr r18
	clr r19
	clr r20
	clr r21
	clr r22
	clr r23
	clr r24
	clr r25
	clr r26
	clr r27
	clr r28
	clr r29
	clr r30
	clr r31

	ldi r16,low(RAMEND)
	out SPL,r16
	ldi r16,high(RAMEND)
	out SPH,r16
	
	call main
```

 tas "call main" ir pareizā instrukcija ar kuru izsaukt C main() funkciju ?? 
šeit jaunais make fails kuram cik saprotu vaig apstrādāt visus C un .S failus kuri ir mapē ar šim divām rindām:
%.o: %.c
   $(CC) $(CFLAGS) $< -o $@
%.o: %.s
   $(CC) $(CFLAGS) $< -o $@


```
#PROGRAMMER=usbasp
TARGET=hellohex
OBJS=hello.o starts.o
LD=C:/WinAVR-20080610/bin/avr-ld
AS=C:/WinAVR-20080610/bin/avr-as
CC=C:/WinAVR-20080610/bin/avr-gcc
CFLAGS= -g -Os -Wall -mmcu=atmega8 -mcall-prologues
OBJ2HEX=C:/WinAVR-20080610/bin/avr-objcopy
DUDE=/bin/avrdude

all: $(TARGET).hex

#program : $(TARGET).hex
#	 $(DUDE) -p m8 -c $(PROGRAMMER) -y -U flash:w:$(TARGET).hex

hello.elf : $(OBJS)
	 $(LD) $(OBJS) -o hello.elf

#hello.o : hello.c
#	$(CC) -c $(CFLAGS) hello.c -o hello.o

hellohex.hex : hello.elf
	$(OBJ2HEX) -R .eeprom -O ihex hello.elf hellohex.hex

%.o: %.c
	$(CC) $(CFLAGS) $< -o $@

%.o: %.s
	$(CC) $(CFLAGS) $< -o $@

#%.s: %.c
#	$(CC) -S $(CFLAGS) -fverbose-asm $< -o $@



clean :
	rm -f *.hex *.elf *.o
```

 un te warningi beigā pat rakstīts ka neatpazīst to call main asm instrukciju, kautkas acīm redzot nav kārtībā ar to GCC assembleri, vai make fails nav pareizi uzstādīts kas tur ir pa lietu ?? 
[attachment=0:1tma85p5]Error_warning2.JPG[/attachment:1tma85p5]

----------


## Velko

Vai tad nu vienmēr citiem priekšā viss jāsaka? Ehhh...  šitāda versija vismaz kompilējas:


```
#include <avr/io.h>  	/* cits include */
.org 0x000
   rjmp reset
.org 0x002 	;	 lamājās, ka pārklājas, nezinu vai būs pareizi 
   rjmp TIMER2_COMP
.org 0x004
   rjmp Timer2_overflow
.org 0x00B
   rjmp UART_RX_compleate
.org 0x00E
   rjmp ADC_complete
.org 0x01E
   rjmp USART_TX_compleate

.equ Triac, 5 			; nomainīts no = uz ,

reset: 
   cbr R16, 1<<Triac		; Triac OFF
   out PORTD, r16
   clr R0
   clr R1
   clr r2
; ----- snip ---
   clr r30
   clr r31
   /* starp citu - šitais prasītos pirms reģistru tīrīšanas, ja tāda vispār nepieciešama */
   ldi     r28,lo8(RAMEND)
   ldi     r29,hi8(RAMEND)
   out     AVR_STACK_POINTER_LO_ADDR, r28
   out     AVR_STACK_POINTER_HI_ADDR, r29
   rcall main
```

 Vai strādā arī - nezinu un nemaz netaisos pārbaudīt.

AVR gadījumā pašam taisīt un linkot klāt kādu ASM startup failu ir lieki - avr-libc sastāvā esošais ir labu labais. Defaultā linkeris arī to izmanto, tā ka iegūtais .elf ir pilnībā nokomplektēts, gatavs pārtaisīšanai par .hex un flashoshanai. 

Ja nu vienīgi ko tādu darīt "sporta pēc".

Cita lieta varētu būt priekš tā lm32. Ja jau nokompilējot triviālu C failu, pēc linkošanas sanāk "milzīgs" fails - tātad kautkas nav uztaisīts kā nākas. Tur var nākties "pajāties" ar to startupu pašam.

----------


## Epis

Tāpat neiet, Avr studijā viss iet a te nekas neiet, problēma tajā GCC compilerā izskatās ka viņš neatpazīst asm instrukcijas

tagat rāda erroru rindai
OUT  PORTD, r16
errors: Constant value required
tas pats erors arī uz
out     AVR_STACK_POINTER_LO_ADDR, r28
   out     AVR_STACK_POINTER_HI_ADDR, r29

Out instrukcija ir iekrāsojusies zila tajā notpad programmerī. 
iepriekšējā gadījumā errori bīj tai komentāru zīmei ( ::  arī m8def.ini failā

----------


## Velko

Nezinu, man kompilējas. "Maģiskā" komandrinda:
avr-gcc -c -I/usr/lib/avr/include/ -mmcu=atmega8 epis.S -o epis.o

Ar -I atslēgu norāda, kur atrodas includes (man gan nevajadzēja - strādāja tāpat). Nu, un faila paplašinājumam jābūt ar lielo S.

----------


## Epis

Asm fails beidzot aizgāja, nomainīju make failā %.s uz %.S un aizgāja, bet rodās jauna problēma man tagat rāda ka starts.S ir
(.text+0x3 :: : undefined reference to `main' 
un kā lai es tad pareizi savienoju C koda main ar asm main funkciju, moš tajā C kodā vaig kautko speciāli norādīt, vai asm kodā norādīt uz C kodu ?? 

ja es C kodā ielieku //#include "starts.S" tad man uzreiz sāk baigi gļukot tas asm koda compilātrs un atkal brēc ka viņam viss tajā asm kodā nepatīk, kā tad lai īsti izsauc no C koda asm funkcijas un otrādies no asm C funkcijas ???

----------


## Velko

Nja... beidzot pašam kļuva interesanti "izkost" to pasākumu līdz beigām.

Vispirms - linkojot norādi abus .o failus - to kas no ASMa un to kas no C. Tiktāl OK, tikai tagad lamāsies, ka nevar tos interruptu labeļus atrast. Visvienkāršākais - izmet ārā pagaidām.

Tā kā centies linkot klāt pats savu startup kodu, tad nāksies izmantot pašam savu linkera skriptu. Tas varētu izskatīties ~ šādi:


```
OUTPUT_FORMAT("elf32-avr") 
ENTRY(reset) 
cstart = 0x0; 
SECTIONS 
{ 
    .text cstart : AT(cstart) 
    { 
        code_start = .; 
        *(.text) 
        *(.rodata) 
        code_end = .;
    } 

    .data 0 : AT(0) 
    { 
        data_start = .; 
        *(.data) 
        data_end = .;
    } 
}
```

 Linkošana varētu izskatīties šādi:
avr-ld -T link.ld --oformat elf32-avr -o epis.elf epis.o ccode.o

Tagad lamāsies, ka nevar atrast entry simbolu - reset. Pieliekam ASMā klāt:


```
.global reset
```

 Pēc tam vajadzētu kompilēties pareizi.

Jāsaka gan, ka neesmu pārliecināts, vai tur īsti pareizi sanāk ar .data segmentu - līdz šim paštaisītu ld skriptu esmu izmantojis tikai priekš x86, tomēr vismaz flash-am vajadzētu sanākt pareizi.

AVR-iem šādu "izklaidi" ikdienā neizmantoju - vienkārši kompilēju un linkoju C failus un viss notiek   ::

----------


## a_masiks

kaut kāds klusums iestājies. Tad sanāca to LED lampiņu mirkšķināt? Jeb tomēr lētajai FPGA jaudas mazliet pietrūka?
Un kā ar galveno uzdevumu?
Nu, tur - USB konekts ar kompi, motoru sinhronizācija un koda izpilde?.....

----------


## Epis

Klusums iestājaš jo man internets pazuda tajā 7septembra (pirmdienā) paranormāli lietainajā dienā un veselu nedēļu viņi tur remontēja un šonedēļ vēl nācās mainīt manējo internet kabeli jo kā izrādās vads bīj arī pārrauts, tākā 11 dienas esu bez neta nodzīvojis  ::  

Situācija ir tāda ka es pagājšnedēļ padarbojos ar tā sava STm32 cirkle kita C kodēšanu atkodu kā spīdināt Ledu pa taisno ar tiem pointeriem, inicializēt tās perifērijas, un uztaisīju sava ātruma koda 


```
/* Enable the TIM Counter */
    TIM2->CR1 |= CR1_CEN_Set;
 
 // Âtruma formula ar Kvadrâtsakni
   int X1 = 250;
  int Xo = 2;
  int Vo = 1;
  int A = 5;
  
  s32 g= (Vo*Vo) -2 * A * (Xo - X1);
 s32 G2 = sqrtf((g));  
s32 T = (-Vo - G2)/A;  // aizmirsu vai šitas bīj tajā test kodā.

//Apstâdina Timeri un nolasa rezultâtu.
 /* Disable the TIM Counter */
    TIM2->CR1 &= CR1_CEN_Reset;
// Nolasa counteri--
u16 TimeCLK = TIM2->CNT;
```

 pirmstam protams nāk STm32 proča clock un AHB perifērij clock uzstāde,inicializēšana un arī GPIO,Timer2 uzstāde, ar taimeri bīj problēmas jo kautkādies nedefinējās TIM2 un rādija ka neko neatpazīst, bet speciālajam TIM1 kuram ir atsevišķs header fails viss gāja, un tas TIM2 header fails ir visiem 4 taimeriem un es cik pētīju tad tur tā definēšanas struktūra ir sarežģitāka, un biegās pēc ilgas čakarēšanās sanāca kad main() koda sākumā ieliku to TIM2 definīciju tad aizgāja.
 #define TIM2                ((TIM_TypeDef *) TIM2_BASE)

Testa rezultāti (taimera clock 72Mhz ) bīj tādi ka visas darbības ipildīja 246 -5(timer stop) instrukcijās reāli clock ciklos tas bīj 3x vairāk jo izrādās ka laižot programmu no Flash atmiņas  starp katru instrukcijas nolasīšanu ir 2 nop (1 instrukcija 3 clock cikli jo flash ātrāk par 24Mhz nevelk), tākā tagat ir jāpēta kas ir ar tā TUMB2 instrukcijām, kā viņas uzstādīt,aktivizēt un ja tad viss vilksies tad jāmēģina laist prgramma no iekšējās RAM atmiņas tad būs 1clk, 1 instrukcija.

par fpga proci es tur laikam ka neko kodējis nēsu, ar avr nupat apskatījos man tas asm fails kopā ar c laikam ka arī nekompilējās.

Tākā ir tā ka vienīgais kas man strādā, un ko reāi var ar C iekodēt ir tas STm32 ar Ride7 progu un arī debuggeris, simulātors, disasamblers strādā un var redzēt kādu kodu tas C compileris tur ģenerē un vispār asm kods ir tīri normāls, pašam tādu būtu grūti rakstīt tik sarežģitam processoram (tas vairs nav AVR 8bit kur ar pārdesmit asm rindiņām var spīdināt ledus.) 

UN jaunā ideja man bīj tāda ka ir jāuzraksta viss trajektorīj ģenerēšanas kods (pa taisno no G-koda (protams pirmstam to Gkoda tekstu ar visualC# pārtaisīs par cipariem, bez nekādām tur failu sistēmām, un burtiem, lai var ātri,efektīvi dekodēt,katru G instrukciju.)
un sāku pētīt to savējo visualC# lineārās interpolāicjas kodu (es viņu kautkur forumā esu ielicis) un ir tāds pasmags tas kods, bet to idarīt, var un nēsu es neko izdarījis jo uzkāros uz SIN,Cos funkcijām kas nekompilējās (papildus lineārai interpolācijai es gribu arī apļa interpolāciju un tur vaig to SInusa funkciju, jeb sin vērtības lenķim a (ar augstu izšķirtspēju) un tad sāku rakties par visām savām matemātikas grāmatām, sākumā neko sakarīgu nevarēju atrast, to kā izrēķināt bez nekādiem 3stūriem to SIn(a) vertību un nekādu rezultātu, tad meklēju lielo krievu matemātisko Encikopēdiju (interneta man nebīj) un tur atradu kautkādu šausmīgu formulu, apmēram šādu:

casx = 1-(x^2)/2! +(x^4)/4! .... , ~<x<~          (~ bezgalības zīme) 

itkā viss skaidrs izņemot to 2! 
sāku tajā matemātikas encikopēdījā rakst ko tas (!) ķēms nozīmē izrādās ka tas ir kautkāds Faktoriāls   ::  
atradu šādu vienādojumu 
n!= (sqrt(2pi*n* (n^n)*e) - n_e tā tālāk.. 

rezultāts tāds kad nevaru aprēķināt sin,cos vērtības. tagat kad ir nets mēģināšu goglēt un atrast kādu strādājošu ARM Cos,vai SIN bibloteku, vai kādu kodu kā tad aprēķina tās vērtības ar augstu izšķirtspēju (vēlam bez peldošajiem punktiem, jo ar tiem man arī neko labi nekodējās, laikam ka nesu tik gudrs lai saprastu tās GCC math.h biblotekas



```
// SINa() tests
s32 Xkord = X1*sin(45); // neiet
float Alfa= 45;
float simts=100;

float FXkord = sinf _PARAMS((Alfa)); //neiet arī bez tā _PARAMS (šitas bīj math.h funkcijas definējumā ko tas nozīmē //nezinu.)
u32 Ykord = roundf _PARAMS((FXkord)); // arī nekas neiet gan ar, gan bez tā _params varbūt tur kautkas jāliek, bet kas to es nezinu.
```

----------


## zzz

> itkā viss skaidrs izņemot to 2! 
> sāku tajā matemātikas encikopēdījā rakst ko tas (!) ķēms nozīmē izrādās ka tas ir kautkāds Faktoriāls   
> atradu šādu vienādojumu 
> n!= (sqrt(2pi*n* (n^n)*e) - n_e tā tālāk..


 Hehe, ir visai amizanta epja psihozaa reakcija uz dazhaadiem abstraktiem jeedzieniem, kurus shis nespeej uzreiz apjeegt. Stuuulbie pointeriiiii, kjeeeems faktoriaaaals!!!!! uttt.  :: 

To faktoriaala formulu, kuru tu te esi uzkjellejis, tev nahren nevajag - taa ir lieliem n. Maziem izmanto faktoriaala definiiciju n!= 1*2*3*...*n 

Un vispaar toch meklee jau nu gatavu trig biblioteeku - ar tavu hmmm hmmm izgliitiibu matemaatika, personiigaas fantaazijas par teemu pie laba gala nevediis.

----------


## Velko

Tā "šausmīgā" formula saucas Teilora rinda. "Ķēms", protams, ir faktoriāls, kuru visvienkāršāk rēķināt tā, kā zzz rakstīja.

Cits paņēmiens - lookup tabula. Uztaisi masīvu ar iepriekš aprēķinātām vērtībām (teiksim - no 0 līdz 90, pa grādam) un kad vajag - lasi tik nost. Strādās mežonīgi ātri, nevajadzēs arī nekādas bibliotēkas meklēt/programmēt. Iespējams, ka sanāks pat atmiņu ietaupīt - ej nu sazini, cik daudz aizņems normāla sin() funkcijas implementācija.

----------


## Epis

Tātad man tagat tas virziens ir tāds ka gribu redzēt kā tiks ar to kodu interpolāciju un visiem PID algoritmiem galā viens pats STM32 procis, proti cik laiku tas viss aizņem piemēram (katra funkcija atsevišķi + PID katrai asij, un tā savstarpējā sinhronizācija piemēram starp 2,3,4 ) un tad varētu padomāt, pārdomāt kas patērē viss vairāk resursus, un vai ir kautko vērts likt uz hardware accelerātora iekš fpga (ja kādu matemātisko processu var paātrināt virs 5x iekš fpga (ar visu datu pārstūtīšanu, saņemšanu (ja tāda vispār nepieciešama) tad būs tā jādara, + arī apskatīšos cik ir reāli to visu uztaisīt bez fpga, proti, uz viena šitā lētā stm32 proča, teorētiski tas ir iespējams bet cik ātri strādās tā sistēma jeb visi PID, un step,dir signālu ģenerātori !, tākā tie ir tie jautājumi uz kuriem tiks meklēta atbilde, un tad redzēs ko rādīs cipari.

Jā izrādās ka faktoriāls ir pavisam vienkārša lieta, kura ir līdz vājprātam sarežģiti aprakstīta tajā matenes necikopēdijā, labs iemērs kā nepamatoti sarežģit lietas, tā lai sarpastu tikai izredzētie matemātiķi.

Sinusa tabula man nederēs, jo nav tāda fiksēta apļu grāda interpolācijā, proti G kodā varbūt ievilkta riņķa līnija ar rādijusu 1metrs, vai arī ar 4mm un tālāk interpolējot nāk reāli fiziskā, mehāniskā izšķirtspēja ja man piemēram 1 soļu mtora mikro solis fiziski būs kādi 0.001mm tad ja jāvirpo riņķa līnija ar rādijusi kādi 20mm tad 0.001mm solim būs jārēķina sinus ar lenķi kuram aiz komata būs kādi 2,3 cipari tākā šitā izšķirtspēja ir pārāk smalka, to īsto smalkumu es vēl nezinu, bet kad cepsies kods, un likšu reālus dzīves ciparus tad jau redzēs cik būs aiz komata tam lenķim.

----------


## zzz

> Sinusa tabula man nederēs, jo nav tāda fiksēta apļu grāda interpolācijā, proti G kodā varbūt ievilkta riņķa līnija ar rādijusu 1metrs, vai arī ar 4mm


 Aaadnako...  Sheit tiek izgudrota jauna veida sinusa funkcija, atkariiga no raadiusa??? Jaudiigs sasniegums matemaatikaa, jaudiigs. steorna muuzhiigie dzineeji nobaal un nervozi piipee kaktinjaa, saliidzinot ar to.  :: 


Jaaaaaa, bez epja forumaa nebij iisteno humoru.  ::

----------


## Velko

Tur gadījumā nevar iztikt ar Pitagora teorēmu, bez kādiem sīnusiem?

Tas gan uzdevumu neko daudz neatvieglo - vajadzēs funkciju kvadrātsaknes rēķināšanai.

Šķiet, ka "atrast kādu strādājošu ARM Cos,vai SIN bibloteku" nevari atrast tāpēc, ka tā pati kas nāk no math.h/libm.a varētu būt tīri lietojama. Tikai sīnusa aprēķināšanai funkcija saucas nevis _sin_, bet gan _sinf_ (bez kautkādiem tur _PARAMS). 

Un jā - trigonometrijas funkcijām leņķis jāuzdod nevis grādos, bet gan radiānos.

----------


## jeecha

Jaa, look-up tabulas shim pielietojumam nav praktiski, tieshi deelj precizitaates. Visticamaak naaksies izmantot Teilora rindas.
Pluss shai pieejai ir ka var ieguut veertiibu ar nepiecieshamo precizitaati (piemeeram sin(x) gadiijumaa summeejot (-1)^n*x^(2n+1)/(2n+1)! liidz briidim kameer kaarteejais saskaitaamais ir mazaaks par nepiecieshamo precizitaati). 1.gjimnaazijaa sho visu maaca (vismaz pirms gadiem padsmit kad es tur maaciijos) 11.klases informaatikas stundaas...

Par praktisko algoritma realizaaciju - tev nevaig katru saskaitaamo reekjinaat atsevishkji (liidz ar to tev nevaig kaapinaat x^n un reekjinaat faktoriaalus) - katru naakamo saskaitaamo tu vari ieguut reizinot ieprieksheejo...

Piemeeram uz fikso uzpljekaata sin(x) realizaacija vareetu izskatiities apmeeram shaada (nenjemot veeraaa pi neprecizitaati)... un negribaas izmantot standarta biblioteeku kaadu:



```
const double pi=3.14159265358979323846;
double absf(double x)
{
    if (x>0) return(x);
    else return(-x);
}

double sinf(double x,double precision=0.0001)
{
    double res= x;
    double add= x;
    long iter= 2;
    while (x<pi) x+= pi;
    while (x>pi) x-= pi;
    while (1) {
        add*= x*x;
        add/= iter++;
        add/= iter++;
        if (iter%4) res+= add;
        else res-= add;
        if (absf(add)<precision) break;
    }
    return(res);
}
```

----------


## zzz

Kaaaroch ja epim gribaas izklaideeties pasham ciitiigi kodeejot sinusu utml, tad burvju vaardinsh ko ierakstiit googlee, wikijaa uc vietaas ir CORDIC.
Kaa reiz izveersties uz fpga, zaaj@bis konveijeru var taisiit.  ::

----------


## Epis

pagoglēju par apļa interpolāciju un atradu vienu ļoti vienkāršu algoritmu kas var to darbu paveikt ar nepieciešamo izšķirtspēju un tas algoritms nosaka riņķa līnijas punktu kordinātes iespējamo tuvumu pašai rinķa līnijai pēc parastās rinķa līnijas formulas x^2+y^2=r^2 
un protams ka pēc tās formulas tā īsti jau nevar atrast,izrēķināt nezināmo nākošā punkta kordināti, bet viņu var izmantot lai meklētu to punktu un piemēram noteiktu kurš no 2 punktiem ir tuvāk reālajai riņķa līnijai, tas ir apmeŗam tāpat kā strādā SAR ADC konvertieris meklējot ADC signālu ar DAC un ar katru nākošo piegājienu palielina iegūtā rezultāta iespējamo precizitāti, tā arī šeit izvēlās uz dullo 2 punktus un tad liek iekšā Riņķa līnijas formulā  Fxy=x^2+y^2-r^2 un skatās kāds rezultāts, ja tas ir Fxy= 0 tad abas x,y kordina'tes ir precīzas, bet ja rezultāts ir >0 tad šī kordināte atrodās ārpus rinķā līnjas, vai <0 tad iekš riņķa līnijas un tā mainot kordinātes var +- ar katru nākošo soli pietuvoties reālajai rinķa līnijai.

un pēc šīs pašas metodes arī domāju ka būs jāpārtaisa tā lineārā interpolācija, vispār esu jau piemirsis kādas tad kordinātes es tur beigās dabūju ārā, vai tik nebūj kautkas līdzīgs šitam.

Tākā varēs iztikt bez SIN funkcijas  ::  un kas zin moš tad varēs ar visām 4 asīm tikt galā viens pats procis bez fpga palīdzības !

----------


## zzz

> kas zin moš tad varēs ar visām 4 asīm tikt galā viens pats procis bez fpga palīdzības !


 Taa ir totaali nosodaama biedriisha epja grandiozo "fpga foreva" ideju zaimoshana.

----------


## Epis

> Taa ir totaali nosodaama biedriisha epja grandiozo "fpga foreva" ideju zaimoshana.


 viss ir normāli skaties uz fpga kā uz multifunkcionālu bloku kurš var izdarīt jebko ko vien ievaigās un tas piešķir platei funkcionalitāti  protams ka es tagat meģinu iet viss vieglāko kodēšanas ceļu, bet man neticās ka visu varēs uzkodēt uz tā Stm32 un tad pienāks arī fpga kārta, kas aizlāpīs stm32 trūkumus, un trūkumi tur protams ka ir, un vēl līdīs ārā viss vissādi zemūdens akmeņi, un tagt man ir instrumenti ar kuriem tos visus pārvarēt, lai kādi arī tie tur nebūtu. un finālā tad redzēs kas kā, tad varēs novērtēt vai bīj vērts uz plates likt fpga vai varēja iztikt bez.

Tagat var teikt ka iet pēdējais posms un tā ir kodēšana.

----------


## zzz

Whatever, whatever, whatever. 

epi tev nav nepiecieshams tagad izgudrot atmazkas un teoreetisko pamatojumu taam. Taapat tak visi zin, ka shitas tavs pashreizeejais neuzkriitoshais leecieninsh no fpga uz niikuliigu ARMu ir taapeec, ka tev sanaaca neliels jauks aplauziens ar softcores prociiti ieksh fpga, tad nu jaakjimereejas ar to, kas vismaz mazdrusku straadaa.

Iistajam fiilingam palasies savus agraakos slavas rakstus par teemaam, kaa fpga uuber alles un mikroprocesori vairs nav vajadziigi.  ::

----------


## Epis

Nu ir tā ka ja kādu laiku kautko neizdodās izdarīt tad gribot negribot sāc meklēt kādu alternatīvu, vieglāko ceļu, un tas micro32 proča pasūdīgais IDE softs man bišķi piegriezās ar tiem visiem make failiem un citiem struntiem, bet nu tas nenozīmē ka fpga ar integrētu proci nekam neder, piemēram NiosII procis man smuki strādāja un tur IDE bīj normāli sataisīts, + palīdzība arī piejama atsevišķā Nios II proča forummā, bet tas micro32 kā jau jauns procis vēl nav tik plaši lietots, un tur ir papillo visādu zemūdens akmeņu, tākā uz kādu laiku es viņu atlikšu malā, kad dabūšu lielāku pieredzi stm32 kodēšana un tajos make failos tad moš izdosies palaist arī to micro32, vispār jau man baigi patika tas NiosII vienīgi tur jāpērk licenze(vai dev.kitsar licenzi) kādi 500$ tieši tas pats ir arī xilinx microblaze procim tas arī jāpērk vai nu ar dev.kitu 500$ vai atsevišķi licenze(šeit laikam bišķi lētāka nekā nios II) un tie proči ir super kruti, abiem ir vieta Hardware accelerātoru piekabinašanai pa taisno pie proča, FPU hardware atbalsts un tur tās datu līnijas arī ir advancētākas,optimizētākās, proti pa lēto neko labu dabūt nevar, viss labais tomēr kautko arī maksā.  :: , bet es nēsu gatavs investēt tādu naudu licenzēs, ja nu vienīgi kautkad nākotnē ka varēs patiešām redzēt to Labumu price/performance ko var iegūt no tāda proča sistēmas tad var dorši tērēt naudu, bet priekš sava CNC es vēl neko nezinu, kad būs gatavs kāds kods strādājoš tad varēs papētīt, kas labāk,lētāk 1stm32, vai pat 2vi Stm32 proči (savienoti ar 18Mbps SPI) vai fpga+ārējais (stm32) vai Fpga+iekšējais procis(niosII,micro32).

tādas ir tās iespējamās kombinācijas, lētums manā skatījumā nozīmē minimālu detaļu skatiu, un pēc iespējas mazāk lodēšanas (ja ir BGA256 paka tad tā ir priekšrocība nevis trūkums, jo vieglāk lodējās nekā 100,144tqfp + bga labāki pinu kontakti un mazāks atstarpes starp barošanas vadiem, līdz ar to var uzlikt 1nu superCapacitātoru (kā es to iepriekš izpētīju) un miers. 
vispār var jau runāt,fantazēt gari un ilgi, bet jēgas īsti nav nekādas jo tas viss ir varbūtības izteiksmē, reāli kas kā varēs pateikt tikai nākotnē kad kautkas būs gatavs.

----------


## zzz

> vispār var jau runāt,fantazēt gari un ilgi, bet jēgas īsti nav nekādas jo tas viss ir varbūtības izteiksmē, reāli kas kā varēs pateikt tikai nākotnē kad kautkas būs gatavs.


  ::  Aijaijai, kaadi apburoshi viedi vaardi. Seviskju sharmu tiem pieskjir tas, ka tie naak no foruma pljaapaashanas absoluutaa rekordista. Nez, 11 dieninju bezinternets un softcores nodeviigaa nestraadaashana buus moraalaas traumas radiijushi, vai kas par iemeslu?

----------


## Epis

Karoči to lineāro interpolāciju es taisīšu pēc tā Bresenham's line algorithma, man tajā savā visual C# kodā šitā lieta nebīj līdz galam izdomāta tur es ieliku tikai to laika soļa laika aprēķināšanas kodu kurā bīj kvadrātsakne, un tad šito Bresenham algoritmu varētu izmantot priekš kordināšu aprēķināšanas un tad starp kordinātēm rēķinās to asu ātrumu (sūdīgi ka bez kvadrātsaknes iztikt nevar.) 
un tā apļa interpolācija jau arī iet uz tā paša bresenham algoritmu būtības principa. 
http://en.wikipedia.org/wiki/Bresenham% ... _algorithm

principā šitā jaunā kordināšu interpolācija man būs ietaupījusi daudz,daudz laika, + jo vieglāk jo labāk  ::

----------


## Epis

šodien notika neliela pavirzīšanās uz priekšu reālā koda izstrādē un tas ko konceptuāli izdomāju un VisualC# kodā iemetu ir tā trūkstošā soļu ātrummu ģenerēšanas daļa, kas spej tos  datus rēķināt ģenerēt pēc secības, proti, šādus datus teorētiski varētu krāmēt lielā flash atmiņā un tad ar kādu CPLD,fpga ģenerēt tos Step/dir signālus, bez nekādiem processoriem ar pāris Mux jo šajā brīdī tie dati vēl nav saarhivēti, un arī līdz galam izdomāju pārdomāju to arhivēšanas formātu un reāli viņš būs ļoti primitīvs: 
2 veida datu pakas:
1. Ass Soļu laikam, kas atkārtojās vairāk kā 2 soļos (lai nebūtu jāraksta divas 2.tipa pakas)
2. Ass Soļu Laikam, kas neatkārtojās, proti, nākošam solim būs jau cits laiks un sava 2.tipa paka
katram ass laikam protams ir sava datu paka.
un 1.tipa paka sastāvēs no ID=8b+ Laiks=16b+soļuSkaits=16b + GlobālaisLaiks=24bit
2.tipa paka ID=8b + Laiks=16b 

un ID blokā būs pakas identifikātors un ass numurs vairāk tur principā nav ko likt iekšā, varētu vēl nākotnē tajā ID ielikt iekšā kādu 3.tipa paku kādiem Relejiem,slēdziem (priekš dzesēšanas) un citām Spec fičām. 
Vispār 1. paku varētu sadalīt vēl 2 daļā, viena daļa ar to GlobāloLaiku un otra Bez, jo tādās lietās kā paatrinājums,apļa interpolācija būs situācjas, ka kādiem 2-5 soļiem būs vienāds laiks(pēc noapaļošanas) un tad tas 24bit vispārējā laika cipars tur īsti nav vaidzīgs, un tas laika cipars ir vaidzīgs principā tikai Kāda Jauna Cikla uzsākšanai, piemēram ka jēc 2 minūtēm sāk darboties piemeram Zass(visas pārējās jau strādā) tad pašā sākumā vaidzēs tai Z asij nosūtīt lai gaida savu mirkli un tad sāk strādāt, bet tā to Globālolaiku, (reāli taimeri ) parastajās Operācijās nevaig.
Principā ir vēl viena problēma kas konveptuāli nav atrisināta un tā ir tās pašas trajektorijas aprēķināšana priekš piemēram daudz asu iekārtu sistēmām, kur vienā momentā var būt 2vi dažādi FeedRate parametri dažādām asu kombināicjām, proti:
F50 X4 Y6  F90 Z20 A11   // šito es pats nupat uzcepu 
vispār es pats nesaprotu vai ar G kodu var vispār kodēt 2 neatkarīgus FeedRate ?? par salīdzinājumu piemēram varētu būt 2galvu Frēze kur katra galva kustās ar savu padevi, kodu un ja katrai ir 3 asis tad kopā sanāk 6asis, itkā problēmu varētu atrisināt vienkārši, proti, interpretēt to kā 2 atšķirīgus G-kodus.
Par šito es domāju tādēļ jo piemēram ja es izdomāju virpot uzreiz ar 2griežņiem tad var rasties situācija ka katram ir savs padeves ātrums !! un kā lai es to tad G-kodā fiksēju ? un vēlāk interpolēju ?

----------


## Epis

Tā, esu novedis to savu pirmo melnraksta kodu,ideju, līdz strādājošam "bugg free" kodu ģenerējošam rezultātam, principā man tagat ir pilnīgi visa Lienārā interpolāicja un tajā kodā ir jau integrēta pirmā kodu arhivācijas fāze, proti katram ass ātrummam (24biti) ir savs ID 8biti  kodā tos ID var atpazīt pēc šādiem cipariem: X=129, Y=130, Z=131(Zass G-kodā iekšā nav tākā tur redzēt viņu nevar, un tad lai saprastu TextBoxā to ciparu jūru skataties tos ID un pēc tam nākošie 3 baiti ir Ass ātrumma vērtība kuras Bāzes laika intervāls ir 1Mhz proti mazākā vienība ir 1mikrosekunde(vispār šito vērtību vaidzētu pacelt līdz kādiem 10-20Mhz) un cipari tur ir sakārtoti pretēji tam kā lasam, pirmais iet pēdējais cipars un pedējais ir pirmais. 

Teikšu kā ir:  čakars bīj baigias! vaidzēja samērā ilgi to kodu debbagot,pielabot ciparu transformācijas no double uz int32, kamēr uztaisīja to funkcionalitāti tā lai strādā, un pats kods arī nav nekāds mazais, vispār jo vairāk kodēju jo vairāk man māc šaubas ka tas Stm32 varēs tikt galā ar to matemātiku.
[attachment=0:eg3yxkdv]G-decoder_1_stepSpeedGenerator.JPG[/attachment:eg3yxkdv]

----------


## Epis

Vakar uztaisīju jauna tipa Arhivātor kodu, kur tos baitus kas katrai asij atkārtojās vienkārši neraksta (to atkārtojumu atzīmē ID baitā tādejādi vecais Test kods kura bildi jūs redzat iepriekšējā postā ģenerē mazāk datu un tur 1 paātrinājuma fāzē sanāca 123 Soļi (soļu laiki) un jaunais kods uz 1 soļu laiku vidēji patērēja 2.63baitus un vecajā variantā vaidzēja 4 baitus (bez nekādas arhivēšanas) un atšķirība vēl ir tāda ka jaunajā variantā Laika cipars ir 32biti vecajā bīja tikai 24biti tākā jaunajā kodā bez arhivēšanas vaidzētu 5baitus datu, bet ar arhivēšanu tikai ~2.63 (minimums ir 2baiti MAx = 5baiti) lūk tāds ir mana pirmā Paātrinājuma arhivātora performance  ::  
Tagat atliek vēl uztaisīt tām lineārām kustībām to arhivātor kodu kur būs Soļa laiks un SOļu Skaits+Globālais laiks (pa 1dienu uztaisīt varēšu).

Vispār pašā sākumā es domāju ka ir jāpamēģina šitā USBCNC ideja ka kompis sūta tos datus uz stm32caurUSB (īstajā laikā), nākoš nedēļ domāju ka būs gatavs PIRMAIS strādājošais protatips  ::

----------


## Velko

Ja jau tik ļoti gribi ekonomēt - pieliec tam samplim repeat skaitli. Būs tev uz vienu sampli minimums 0 baiti, maksimums - 6 baiti. Jebšu uz 256 sampļiem: minimums - tie paši 6 baiti, maksimums 1536 baiti. Salīdzinājumam, tev šobrīd uz 256 sampļiem sanāk: minimums 512, maksimums 1280.

Vai ir vērts, atkarīgs no tā, cik tie sampļi daudz atkārtojas. Iespējams, ka var pat likt 2-baitīgu repeat - tad varēsi 65536 sampļus iebāzt 7 baitos.

----------


## Epis

Tā daudzkāršā repeat fiča man būs tajā konstantā ātrumma sadaļā kur būs 32bit ātrums+32bit Repeat skaitlis(soļu skaits),  bet šajā daļā kuru es esu tagat uzkodējis ir paātrinājuma aprēķins un šeit katrs soļa Laiks ir citādāks (proti nav repeat).

          Laigan kas to lai zin moš kad ātrumma cipars paliek mazāks un mazāks šadas situācijas ka noapaļošanas rezultātā izdod 2 vienādus ātrummus varētu palikt ar vien reālāk, proti jo tuvāks rezultāts 0 jo lielāka varbūtība ka rezultāti pēc noapaļošanas būs vienādi, un tieši tas pats arī ir ar paātrinājumu, jo tas mazāks jo lielāka varbūtība ka rezultāta ātrumi pēc noapaļošanas būs vienādi kādus pāris soļus. tākā laikam ka vaidzēs pielikt klāt vēlvienu bitu kas ļaus darīt, ierakstīt 1baitu kas pateiks ka šitas cipars ir tādspats kā iepriekšējais  :: .

Un ja ar USB var pārsūtīt labākajā gadījumā 1MB datu un tākā kautkas būs arī jāsūta atpakaļ tad tas ātrums samazinās uz pusi un sanāk 500KB/s, cik daudz sanāk un ar kādiem ātrummiem varētu strādāt asis tā uz dullo paredzēt to nemaz nevar, vispār vienīgais veids kā kautko prognozēt, būtu uztaisīt kompī algoritmu kas pēc G-koda apstrādes pasaka vai tas būs reāli, savādāk var sanāk tā ka laiž kodu un sanāk tāda situācija ka iekārta apstājās jo nav datu!, vai arī ik sekundi raustās.. proti lai šādu sistēmu taisītu vaig kādu nākotnes paredzēšanas metodi, un ar šādu metodi pat varētu vadīt līdz pat 8 asis, protams pirms tam validējot pašu processu.
Tākā vēl viss tā īsti nav skaidrs un ir par ko padomāt.

----------


## Epis

nu tā šodien vēl nācās pielabot to C# paātrinājuma arhivātor kodu, jo izrādījās ka tur tomēr bīj vēl errori uz negatīvu paātrinājumu, un iepakoju to savu jauno paātrinājuma kodu vienā milzīgā Funkcijā:
void Acceleration_Arhivātors (int CPI, double Xpos1, double Ypos1, double Zpos1)

un tagat man 3 kodu vietās stāv šī te funkcija kas izsauc kodu, savos izmēros lielo (pagaidām lielākā funkcija), bitu arhivātoru,datu pakotāju, un rezultātā tagat kad palaižu savu EpiCNC softu nospiežot Decode_text pogu man atverās vēlviens logs ar tiem visiem paātrinājuma cipariem un tas logs ir tik liels ka nesaliem kompa monitorā   ::  tas ir: 805 baiti un tas vēl nav viss vēl pietrūkst tās taisnās kustības kodiņš (tur varētu nākt klāt kādi 50-100baiti) un tagat iedomājaties ka tās ir tikai 2 G-koda instrukcijas  (kustība uz priekšu un atpakaļ)  ::  

Liels čakars izrādījās kā parasti tie pozitīvie,negatīvie kustību virzienu, un tad ja vispār nekas nekustās (ātrums 0) un tur ir speciālas kondīcijas, ko kā darīt ja notiek tas un tas, tākā tā visa padarīšana ir tīri sarežģita, un tikai debagojot var noskaidrot vai viss katrīgi strādā.

----------


## Epis

Šodien veltīju laiku un palasīju CNCzone topiku par to CNCbrain 6asu dubultā closed-Loop kontrollieri: 
http://www.cnczone.com/forums/showthread.php?t=64794

Un tur tie čaļi galīgi traki   ::  salīdzinot ar mani manām prasībām gan pēc procesējamās jaudas,funkcionalitātes viņi ir galīgi prātu zaudējuši cik var noprast tad tur uz tās 500$ plates stāv kāda solīda fpga, kur iekšā tad ir virs 140  MPP (Massively Parallel Processing) procesors (non-Von Neumann)  Framework (proti īsti nevar saprast vai tie visi proči tur patiešām ir kā atsevišķi proči vai kā atsevišķas funkcionalitātes stateMachine, vārdsakot tie noteikti ka nav pilnvērtīgi proči bet kautkādi paštaisītie accelerātori)
  un cik sapratu lasot toi visu garo topiku tad viņu sistēma pieņem tos lēmumus ko kā darīt ar ātrumu 5-10 mikrosekundes  ::   tas būtu apmēram 100-200Khz dubūltais PID+trajektoriju gēnerātori un velns sazin kas vēll.. ā un tā fizikālā matemātika (laikam visi pāātrinājumi,ātrumi) ir ar peldošiem punktiem priekš Mega precizitātes, un kā tas izstrādātājs lielijās tad tur procesojošā jauda ir virs Miljards operāciju sekundē (Gips) 
vienīgais kas viņiem tur nav tas ir kārtīgas Flash atmiņas, ir kautkāda parsimt kb RAm buffera atmiņa (laikam fpga iekšējā) un tas kontrolieris nevar strādāt standAlone režīmā, bez kompa, un tā plate vēl ir  Test režīmā 

Es protams uz tādu performance ar visu trajektorīj ģenerēšanu netiecos, bet tās fičas kas viņiem tur man arī būtu vaidzīgas, un man tāda sajūta ka viņi tur ir pamatīgi pārcentušies, jo ko tad vispār var iekontrollēt ar 100-200Khz PID ? normāli tač ir 1-10Khz PID un trajektorīj ģenerātrs arī var vidēji iet ar 1000 trajektorijām sekundē protams ar kādu 1Mb RAm bufferi jo visu laiku tač neskries tie motori uz pillu jaudu un mūžigu paātrinājumā ? tākā viņiem tur tā domāšana man liekās ka ir tādā līmenī kā man bīj pirms kāda 1 gada kad es domāju ka katram motora solim ir PID jārēķina arī tik pat lielās >100Khz    ::   frejvencēs.
Realitātē jau tās iekārtas iet ļoti lēnu un tas dinamiskās reakcijas ātrums pašai iekārtai arī ir lēns, jo masas tad ir lielas un tāpat kā savā cepeškrāsnī, ja gribi noreaģēt ātrāk nekā tas ir iespējams mehāniski tad nākās gandrīz vai nodarboties ar Nākotnes paredzēšanu, kas ir iespējams tikai tad kad process ir noticis un tad nākošā piegājienā var to lietu labot, daļi CNC lietotāji tur pat prasīja viņiem lai uztaisa  tādu fiču ka tā elektronika varētu kompensēt kāda gara instrumenta deformāciju zem lielās slodzes, vai arī pašas iekārtas deformācijas   ::  tip tad itkā varētu slinkot uz iekārtas stiprību un iegūt precīzu detaļu uz gudrās elektronikas rēķina (vispār es arī tādu maģisko elektroniku girbētu   ::  )

----------


## Epis

Karoči es tagat mēģinu saprast kas ir ar tiem Advancētiem kontrolles mehānismiem (virs PID līmeņa) proti jēgu, un vai man tādus vaig (vispār laikam ka vaig) -> šāda tipa:
1. S-curve acceleration and deceleration (tur ir tāds (j) parametrs kas ir "jerk (time rate of change of acceleration)".
2. look ahead for velocity and acceleration limiting. 

vispār daži to Look ahead uztver kā S-curve paātrinājuma kontrolli, proti lai padarītu to iekārtas kustību plūstošu bez raustīšanās tas parasti notiek pie momentāla paātrinājuma vai arī pretēji, ātras bremzēšanas un apstāšanās, un pēc būtības tā jau nebūtu nekāda problēma ja tā iekarta tur kratītos, bet problēma ir tur ka šādi rastot iekārtu zūd tā precizitāte, jeb iekārta iziet ārā no trajektorijas apmēram tāpat kā tā mana SMD Krāsns kur sākumā laiž uz pillu ātrummu un tad kad jābremzē tempertūra tad Termodinamika dara savu darbu un viss tempertūras profils aiziet sviestā, ar iekārtām var teikt ka ir tā pat proti ja motors ir ieskrējies tad apstādināt viņu momentāli nevar un ar konstantu negatīvo paātrinājumu notiks tā nobīde no pozīcijas un tad šito problēmu risina ar to S-curve (tur var būt SInusa funkcija, vai arī bišķi sarežģitāka pagoglējot var atrast). 
Kas man tajā visā nepatīk ir tas kad visām tām funkcijām tos parametrus, limitus parasti uzstādā  pirms kods tiek izpildīts, bet kā zināms tad praktiski nav iespējams uz dullo uzminēt tos Optimālos darba parametrus katrai iekārtai + katram darba instrumentam jo no tā arī būs atkarīgas visādas slodzes,inerces tākā šajā lietā vaidzētu kautkādu Mākslīgo Intelektu, jeb Analizātoru kas analizē katru noieto G komandas posmu un Mācās no kļūdām proti ja piemēram tiek veikti vairāki identiski griezumi (pēc SFM ) ar vien un to pašu instrumentu tad piemēram pirmo veic pēc koda (konstants paātrinājums un bremzēšana, bet otrā griešanas posmā jau veic ar jauno uzlaboto trajektorīju un šeit to uzlabošanu negribās veikt ar kautkādiem Smagiem algoritmiem, es domāju ka to varētu darīt tādā samērā primitīvā stillā mainot kautkādus uzrāvienu Koeficentus proti, tā lai ar katru nākošo piegājienu sanāktu ar vien labāks, un labāks rezultāts. 
Un problēma ir tur ka taisot kautkādu detaļu ir vairāki instrumenti + to instrumentu griešanas dziļums,ātrums arī mainās, līdz ar to snāk ka katram šādam posmam vaidzēs savējo ideālo trajektorīju iespējams kopā ar kautkādiem Globāliem instrumenta trajektorijas koeficientiem.
Un šāda tipa adaptīvais kods varētu būt īsts brīnums priekš mehāniski švakām iekārtām vai instrumentiem, kur tad varētu dabūt no tādas švakas iekārtas kautcik sakarīgu precizitāti, protams, ne ar pirmo piegājienu, bet pēc kādiem 3-4 piegājieniem kautkāds efekts jau būtu.

vienīgi lai veiktu šādus iekārtu testus, tjūnēšanu neizķēzot taisāmo detaļu vaig pavisam cita tipa G-kodu proti kodā vig iekšā būt SFM (surface feet per minute) informācijai kas norādītu uz to kādas slodzes operācija tiek veikta. ja grib izmantot vienkāršāku modeli tad ir jāņem un jāstrādā ar rupjo, katra soļa ātrumma datu apstrādi un modificēšanu, un nelielām programmām šis variants varētu būt tīri OK.

Tākā ir 2 varianti: 
1. izmantot to S-curve un dinamiski mainīt viņa J parametru katram posmam pielāgot savu lielumu.
2. mainīt Rupjos datus pēc Brutālās metodes (kautkāda proporcionālā, integrālā algoritma es to domāju apmēram kā SAR ADC konvertieris meklē Analogo signālu tieši tāpat varētu šāda + - vienību metode atrast arī Ideālo trajektorīju kādos pāris piegājienos un jo vairāk piegājienu jo precīzāks rezultāts, + ja tiek taisītas vairāk detaļas un rodās instrumenta nodilums kas ietekmē visādus tur spēkus tad šāda +- metode pamazām pielāgosies jaunai situācijai un rezultāts būs ilgtermiņā stabils.  

Nu kā jums mana jaunā Ideja ?  

motivācija jo projām vecā "sabāzt ķīniešus,taivāniešus"  ::   un lai to izdarītu ir jābūt Lētai iekārtai, un lēts nozīmē švaks, ar sliktiem stiprības,vibrācijas parametriem tādēļ laidabūtu to pašu kvalitāti tur vaig īpaši krutu elektroniku  :: .

----------


## Velko

Hmm... Epis atklājis 3. atvasinājumu.

Ja jau reiz taisies to ņemt vērā, tad atceries, ka arī šis džerks (kāds nezina, kā būs pareizi latviski?) arī var būt mainīgs laikā. Sinusa funcijai tā arī ir.

Ja koordināta attiecībā pret laiku mainās pēc sinusa funkcijas, tad attiecīgais ātrums pēc kosinusa. Tālāk, paātrinājums: -sin() (mīnusa zīme, nozīmē, ka tas ir pretējā virzienā). Pēc tam šis džerks: -cos(). Tālāk, 4. atvasinājums atkal pēc sin() un tā var turpināt.

Katrā gadījumā - pieliec klāt vēl kādus 5-6 atvasinājumus - aprēķins tak nekad nevar būt pārāk precīzs  ::

----------


## Epis

> kāds nezina, kā būs pareizi latviski?


 Apstoties vārdnīcā Jerk nozīmē: Rāviens, grūdiens un tādā garā, un tā padomājot tad man nāk prātā vārds Pēcgrūdiens, jo tas ir tad kad ass apstrājās, bet paša dēļ inerces bleķis bišķi ielokās radot to neprecizitāti, un sūdīgāka, lokanāka iekārta jo tās deformācijas būs lielākas (kādai sūda iekārtai mierīgi varētu būt 1-2mm, labāk 0.05-0.1mm + ja ir parastais vītņstienis tad šajā momentā nāks klāt brīvgājiens un tad ja no liela ātrumma iekārta bremzē šī te inerce var pabīdīt to visu galdu uz priekšu pa brīvgājiena lielumu un tad var rasties vēl trakāks efekts kad ass atsitīsies pret to pretējo Vītņstieņa vītni kā āmurs pret sienu un atkal viss tur deformēsies, tākā vispār šitā problēma švakajām iekārtām ir samērā liela, un jautājums kā to atrisināt, ar kādiem super algoritmiem to defektu izlabot. 

Man nāk prātā tikai tas primitīvai variants kā es to savu SMD krāsns kodu pielaboju, proti manuāli liku kordināšu punktus ar pašizvēlētām vērtībām, kuras pats noteicu uz dullo un principā man vaidzēja pielabot tikai vienu kordināti, proti to momentu kad sildelementus ir jāslēdz ārā, CNC iekārtai tas moments būtu tad kad  tuvojās paātrinājuma beigu fāze un ātrums paliek konstants, tad lai samazinātu paātrinājumu būtu vienkārši jāuzliek 0 paātrinājums, kas nozīmētu ka motoriem būtu komanda kustēties ar itkā konstantu ātrumu, un tad notiktu tas Pēcgrūdiens un pēc kāda konkrēta laika perjoda kad tās dinamiskās inerces būtu noslāpējušās varētu pacelt to ātrummu līdz vajdzīgajam, bet jau ar minimālu paātrinājumu (tādu kas nerada to Pēcgrūdienu, galvenais tas ka šādi varētu iet ar MAximālu kopējo ātrummu 
(man piekāst uz iekārtas saudzēšanu vai citām šādi radītu pēcgrūdienu sekām man būtu galvenais ātrums, produktivitāte, un kvalitāte).
un šādas situācijas kad būtu vaidzīga šāda tipa kompensācija īstanībā ir ļoti MAZ, un tās ir katra paātrinājuma beigu fāzē, bet sākuma fāzē var iet uz pillu jaudu (vienīgi ja asīj ir brīvgājiens tad šāda situācija radīs pamatīgu triecienu jo motors būs jau ieskrējies tukšgaitā un kad vītne noies brīvgājienu tad būs tāds pamatīgs trieciens, tākā šeit atkal šo tukšo posmu vaidzētu noiet mierīgi, līdz ar to Sūda CNC sanāk tā ka katrā uzrāviena cikla sākumā beigās ir jābūt šādiem te adaptīviem kodiem kas pielabo uzrāviena vērtības.un ja tas paņēmiens būtu tik triviāls kā SMD krāsnīj tad varētu iztikt bez S-curve un tad būtu: 
 Hibrīd Trapezoidal+Jerk+backlash+look ahead -> Auto lerning compensation  algoritms  ::  
vienā vārdā sakot vaig kautko līdzīgu cilvēka smadzenēm -> Neironu čipam vai algoritmiem kas to imitē.

ķīniešus salikt var tikai tad ja tev ir labāks Stanoks, proti ātrāk,precīzāks un lētāks nekā viņiem, un strādā 24h dienā, bez apkopes, zem klajas debes (labi nojimi, un žogu tomēr vaidzētu + betona pamatu un vienu elektrības vadu + internet kabeli)  un tad vienas detaļas cena būtu matreāls+elektrība+ kautkādas kapeikas iekārtas, apkārtnes atpelnīšanai. 
bet lai kautkas tāds sanāktu iekārtai vaidzētu iemācīt pašai nomainīt instrunetu insertus un matreālu paņemt (auto Bar Feeders) tāda ir mana sapņu iekārta  ::

----------


## Vikings

"Zem atklātas debess"
Kā tad. Veci, precīzajiem koordinātu izvirpošanas darbagaldiem svarīga ir pat uzturēšanas temperatūra telpā. Kāda var būt precizitāte ja iekārtu turi zem klajas debess. Un par nojumi - man zināms viens Latvijas uzņēmums, kurš savu lāzeri un locāmo sap1sis vnk tos kādu laiku turot nojumē. Tā kā...meklē vien savai darbnīcai normālas apsildāmas telpas.

----------


## Epis

NU tad tam džekam tā lāzeriekārta bīj tāda pašvaka, proti bez aizsardzības no ārējiem laika apstākļiem, un iespējams ka iekārtu nobeidza augstais gaisa mitruma līmenis (šādās lietainās rudens dienās tas ir baigi lielais ~70-80% mitrs gais) tākā tādas švakas iekārtas vaig turēt nevis apsildāmā telpā bet gan telpā ar mitruma kontrolli jo augstums (sals) pats pa sevīm jau nekādu skādi iekārtai nenodara (ja visas eļas, smērvielas detaļas vadi ir sala izturīgi un mikročipi ar industriālo tempertūru grade (-40 -> +125C) proti tādu elektroniku var uztaisīt un viņa strādās tajos super sliktos laikapstākļos un eļas smērvielas arī ir ar speciāls.
Vienā rakstā Lasīju ka jaunās robot ROkas, kas tiek ražotas var mierīgi virs 10 gadus zem klajas debes šancēt vaig tikai betona pamatu +elektrības un komunikācij vadu, un tai robotrokai pajāt vai viņa strādā āfrikas tuksnesī vai Antarktīdā un ja vaig arī kosmosā, proti Robotiem nevaig siltumu, apgaismojumu, un citas ekstras kuras pieprasa cilvēki tādēļ arī Nav starpība vai tu štancē detaļas Taivānā, korejā, ķīnā vai arī Polārā Lokā,Lativjā (vienīgi mums cilvēkiem jāmaksā algas lielākas jo klimats ir skarbāks. bet ja 3 cilvēki var apkalpot  vairākas iekārtas un uzturēt viņas pie darba kādas 20-22h diennaktī tad tās izmaksas būs tik pat lielas kā tajā ķīnā strādājot tik pat cilvēkiem, jo ja tā tīri tehiski ņem tad tajā vietā kur ir augstāks klimats, iekārta varēs strādāt ar lielāku slodzi, un ātrummu jo motori, instrumenti ilgāk varēs strādāt dēļ šī aukstuma kas viņus dzesēs + varēs vairāk parslogot motorus, un pate lektronika arī labāk strādā, (jo zemāka čipu tempertūra jo vairāk var viņus overclockot un noslogot) tākā rezultātā Ekvadorā būs Lētāks cilvēku darbaspēks, bet zemāka produktivitāte, savkārt ziemeļos augstāka produktivitāte bet lielākas cilvēku algas. 
Un tākā transports maksā ļoti dārgi tad Lētāk ir režot Latvijā pašiem priekš sevis un eksportēt citiem. vienīgi vaig iekārtu kas var šancēt zem klajas debes un dārgas infrastruktūras. 

Vienīgais kas latvijā ir neizdevīgi tas ir Tā rūpniecība kur ir nepieciešams liels cilvēku darba spēks, jo kā jau minēji cilvēkiem vaig siltu telpu, Labu apgaismojumu un arī lielāku algu lai šajā klimata zonā vispār varētu izdzīvot un samaksāt rēķinus slīdzinot ar ekvadora valstīm kur cilvēks var dzīvot salmu mājā staigāt ar pāris T-krekliem,šortiem visu gadu un iztikt ar 5x mazākām finansēm tur arī algas ir 5-10x zemākas tādēļ visā eiropā ir iznīkušas apģērbu ražošanas, apavu, rotaļlietu un tā tālāk nozares, tiko šitās nozares būs iespējams robotizēt, automatizēt tā tie ķīnieši varēs sēdēt bez darba.

----------


## Velko

Epi, iedomājies ko varētu paveikt ķīnieši, ja pārklātu visu Ķīnas teritoriju ar automatizētām iekārtām. Ja vajag - vairākos stāvos, lai katram ķīnietim būtu ko darīt. Ja būs nepieciešams, viņi ir spējīgi to izdarīt. A ko mēs varam likt pretī  ::

----------


## sharps

> NU tad tam džekam tā lāzeriekārta bīj tāda pašvaka, proti bez aizsardzības no ārējiem laika apstākļiem, un iespējams ka iekārtu nobeidza augstais gaisa mitruma līmenis (šādās lietainās rudens dienās tas ir baigi lielais ~70-80% mitrs gais) tākā tādas švakas iekārtas vaig turēt nevis apsildāmā telpā bet gan telpā ar mitruma kontrolli jo augstums (sals) pats pa sevīm jau nekādu skādi iekārtai nenodara (ja visas eļas, smērvielas detaļas vadi ir sala izturīgi un mikročipi ar industriālo tempertūru grade (-40 -> +125C) proti tādu elektroniku var uztaisīt un viņa strādās tajos super sliktos laikapstākļos un eļas smērvielas arī ir ar speciāls.


 epi tu vispaar zini kas ir klimata kontrole? mainoties temperatuurai strauji no silta uz aukstu gaisa mitrums izkritiis visur kur vien var izkrist. aukstums iekaartaam var nodariit ljoti lielu skaadi, ja taas nav paredzeetas tam. Aukstumaa tureeta iekaarta ar lielaaku varbuutiibu tev nodegs nekaa ja taa ir tureeta pie 20 graadiem. Tikai nesaac ziileet kaapeec taa. Varu pateikt tev priekshaa. Iesleedzot iekaartu taa saak izdaliit siltumu. Aukstaa telpaa pastaav risks ka taam mikreneem var rasties mikroplaisas deelj temperatuuru starpiibas. Un kirdik tavai advanceetai mashiinai. Vareesi mekleet veel divus gadus probleemu softaa.
Attopies beidzot dzhekinj un negvelz muljkjiibas.

----------


## Epis

Lūk vienkārš sadzīves piemērs kur viena un tā pate tehnika kalpo 10-20gadus mūsu skarbos klimata apstākļos.
un tās ir mašinas ar kurām mēs varam braukt, un kas stāv zem klajas debes un kuras arī izmanto ķīnieši, taivānieši tākā ja mašina var strādāt 10-15 gadus zem klajas debes tad kādēļ gan iekārta to nevarētu darīt !
Ar ko atšķirās parastās mašinas mehāniski, elektronika no CNC iekārtām, Robotiem to elektronikas ?? 

Mana galvenā Ideja ir tāda kad Es gribu to Iekārtas darba trajektīrju komandas īstajā laikā uzlabot apmēram tādā veidā kā to dara cilvēks tjūnējot kautkādu sistēmu vodies pēc savas pieredzes un zināšanām kā panākt labāku rezultātu un tam principā vaidzētu būt ļoti primitīvam veidam ar primitīvu matemātiku un loģiku realizējamam, jo cilvēks, citas radības ar smadzenēm nedomā matemātiski sarežģiti un neveic nekādas sarežģītas operācijas.
CIlvēks darbibas pieķīlējot kādu procesu ir šādas:
Veic eksperimentu un novēro (vāc datus par notiekošo) tad kad eksperiments ir noticis, dati savākti, veic datu analīzi: Skatās kurā procesa punktā ir kļūda un tad mēģina to kļūdu izlabot pēc kādas loģikas (kautvai Proporcionālā Algortma   Laika kļūdā (laika intervāla no kura sākās Pēcgrūdiena novirze līdz novirzes maximumam, tātad sanāk koriģēt Paātrinājuma laiku par to perjodu kāds bīja pēcgrūdiena laiks un attiecīgi aprēķināt jaunās kordinātes un jaunās trajektorijas + šo koriģējošo informācju var arī izmantot lai koriģētu nākošos notikumus, kuriem vēl nav bījusi iespēja kautko koriģēt vai aprēķināt tādejādi varētu panākt to efektu, ka iekārta mācās ar katru nākošo kustību un veic tālākās kustības ar lielāku iespējamo precizitāti. lai palielinātu varbūtību, ka nākošā kustība notiks daudz gludāka.
un vēl varētu, protams, katru šādu unikālo eksperimentu Pieredzi uzkrāt proti uzkrāj tikai labākos atrisinājuma variantus  un visus sliktos met ārā un šādi ejot laikam uzkrāsies, izfiltrēsies šīs te Ideālās vadības trajektorījas kordinātes  :: 
Un šeit laikam vaidzētu izmantot hādu hardware Accelerātoru, lai piemēram meklētu, Rakstītu šo pieredzes informāciju kādā Flash,RAM Datu bāzē un tad ja piemēram uzkrājās pieredze par kādiem 1000 vai vēl viarāk gadījumiem, varētu to informāicju ātri ātrast un nenoslogot Proci ar šīs informācijas meklēšanu un dabūšanu, un vēl varētu izveidot kautkādu Fiksēto funkciju Hardware paātrinātāju kā Enkoder Datu Filtru,Analizātoru un citas lietas, kasapstrādā lielu datu masīvu un kur būtu ekonomiski neizdevīgi ķēzīt MCU resursus un arī tīri pēc energo resursu patēriņa fpga svilinās mazāk elektrības šādu masīvu apstrādēi nekā MCU.

----------


## Epis

Nu tā es tagat skatos, pētu un mēģinu saprast kā lai uzkodē iekārtai to Mākslīgā Intelekta tipa Jerk+backlash kontrolli pagaidām esu ticis tik tālu (tāds kā melnraksts uzmetums ideju piefiksēšanai) 


```
 // Nov = Novērotais; Enc= Enkoder; Sak=Sakums;
            int NovEncMaxspeed = 0;
            int NovEncMaxKordStep = 0; // Maxinālā enkodera novirzes apmlitūdas ātruma vērtība (delta kordĀtrums-EnkĀtrums, un kordināte (solis)
            int NovENcSakSpeed = 0;
            int NovEncSakKordStep = 0; // Sākuma posma pirmās Ātruma novirzes fiksētais ātrums un Kordināte
            int NovEncDeltaSpeed = 0;
            int NovEncDeltaKordStep = 0; // Starpība starp Max nov ātrummu un sākotnējo ātrumu + soļu skatis kas bīj vaidzīgs lai aizietu līdz Maximumam.
// Šeit mēs Mēginām labot tikai to posmu, kas rada šo novirzi un attiecīgi ātrummu mēģinot apstādināt iekārtu tajā momentā

            int AtrNovKoeficients = 50; // 0.5 Proporcionālais koeficients pēc kā aprēķinās laiku kad sākt Jerk.
            int LabojamaisDeltaLaiks = (NovEncDeltaSpeed * AtrNovKoeficients)/100; // Aprēķina LabojamoDeltaLaiku ar kuru tad Vēlāk meklēs EnkoderaLabojamoLaiku
// Aprēķina Kāds būs Enkodera ātrums lai labotu Jerk           
            int EncLabošanasLaiks = NovENcSakSpeed - JaunAprDeltaLaiks;
// Uzdevums1:  Atrod: EnkoderaAptuvenāpozīcija (solis), kad viņa laiks bīja tuvu EncLabošanasLaikam !
// Uzdevums2: Atrod: Trajektorijas EnkoderaAptuvenāpozīcijas adresi, un nolasa ĀTtrummu un ieliek tur šīs Izmaiņas (proti JerKControll bitu un ātrummu+soļu skaitu,
            //ar kādu jāiziet šis Posms(tas būs konstants Ātrums pēc kura varēs celt momentāni ātrummu līdz vaidzīgam!
/*Tālāk skatās vai otrai asij x,y galda lineārā kustībā arī ir tai brīdī kautkāds Jerk, ja nav tad pielabo šīs 
 * ass ātrumma kordinātes pēc (Jerk-EnkoderaAss DeltaKordināšu ātrummaSoļiem)/Koeficients un / ASsu Lineārās sakarības proporcijas 
 * un tādejādi iegūst jaunas kordinātes kā Asij uzvesties šajā posmā (šo posmu vispār arī var Pēctam pielabot! uztjūnēt!
 * Uzdevums3: Saglabā:
 * +EncLabošanasLaiks
 * +Posma Feedrate
 * +Acceleration
 * +
            
 */
// Enkodera Dati būs Jāsavāc, šādi Jāizanalizē (nosakot visus Max,min novirzes,ātrumu un soļu skaitu + Pēctam kad iestāsies šī kondīcija tad viņi Jāizanalizē Pēc iepriekšējās  
            // formulas un Jāatrod ts Jaunās trajektorijas Kordināte.
```

 Proti, nekā sarežgīta tur itkā nav, un tur ir tā problēma ka tas izskatās pārāk vienkārši lai būtu patiešām kautkas noderīgs, bet varbūt ka neko vairāk sarežģit nevaig.
Vispār es pēdējās dienas arī meklēju, lasu info par tām nākotnes prognozēšanas metodēm kas balstās uz pagātni un izdara kautkāda tipa mācību no pagātnes un tad pēc iegūtās pieredzes pieņem lēmumus, un tur ir ļoti daudz visādu metožu teoriju, grūti saprast vai man no tā kautkas vispār der ?
Skaidrs ir tas kad tur prasītos tajā kodā bišķi vairāk Fizikas Algoritmu, kur varētu noteikt iekārtas dinamisko slodzi, tukšgaitas slodzi (ko varētu uztvert kā konstantu lielumu (berzi,pretestību) bet vai tā sarežgītība ir patiešām vaidzīga ? 

par to sarežģītību tad principā ir tā ka paaugstionoties algoritumu sarežģitībai varētu samazināties nepieciešamais RAM atmiņas daudzums, kas vaidzīgs lai saglabātu to Pieredzi pie dažādiem modeļa parametriem (dažādām situācijām dažādas pieredzes kā cita tipa instruments,citi slodzes parametri,ātrummu, padeves), proti, ja šitos visus faktorus varētu ar formulām izrēķināt īstajā laikā un dabūt ārā kādu +- kvalitatīvu rezultātu (trajektorīju) tad pietiktu ierakstīt RAm atmiņā kādus pāris svarīgākos parametrus, vai arī nerakstīt vispār nekādus parametrus tādiem processiem, kur tiek izmantots 1ns instruments, un tad visus tos dinamiskos parametrus varētu tāda sarežģita sistēma pate +- izdomāt uz vietas, bet tad atkal šāda sistēma vairāk izskatītos pēc iepriekš uzstādāmas,uztjūnejamas processu vadības, kas ļoti minimāli mainās processa gaitā, un tad tur būtu zema mācīšanās, pielāgošanās pakāpe, jo vairums jau būtu kā ar akmeni iecirst fizikas forumulās, sakarībās.
Un otrs variants ir izmantot primitīvus (tāda manējā stilla) ideālās trajektorijas meklēšanas algoritmu no gūtās pieredzes, bet tad kā es tur esu komentā pierakstījis ir jāsaglabā tādi dati kā Enkoder rādijumi tajās konkrētajās situācijās, lai tos varētu izmatnot pēctam jaunas trajektorijas sintezēšanā, un tad sanāktu tā jo vairāk būs tādi kardināli atšķirīgi, pēc slodzes, padeves posmi jo vairāk vaidzēs glabāt datus atmiņā, + lai redzētu vai tas jaunais izlabotais koda variants ir devis kādu rezultātu tad atkal vaig salīdzināt veco rezultātu ar jauno + to atbilstību G-koda trajektorijai līdz ar to kopā sanāk kā minimums saglabāt atmiņā 3 posmus + lai varētu arī kautcik prognozēt nākotni tādiem processiem kas vēl nav notikuši vaidzētu analizēt tos rezultātus kas iegūti iepriekšējo processu vadībā, jo paši saprotat nevar tač ķēzīt matreālu un taisīt kādus 2-3 detaļu brāķus tikai lai iekārta noregulētos kautkādos sakarīgos precizitātes rāmjos !

ir kādas idejas ? pārdomas? vai vispār tas ir reāli ? kautkas jau ir reāli bet par to labuma ieguvumu kas to lai zin !

----------


## Epis

Atradu kodu tai B-Spline funkcijai kas ģenerē tās kordinātes un uzīmē atēlu, un to kā Spline kods zīmē var redzēt šajā bildē  ::  pagaidām es tur nēsu vēl baigi iedziļinājies tajā pašā Spline algoritmā, bet varu teikt ka izskatās viņš tīri paliels, matemātikas padaudz, bet labi ka nav nekādu Sin, Cos funkciju,  bet ir kvadrātsakne un nēsu vēl skatījies kas notiks ar rezultātu ja cipari būs Int32 tipa nevis Peldošajos punktos. 

Bez spline vispār jau tas interpolātors sanāk tāds pašvaks un vismaz 2D spline vaig  :: 

[attachment=0:3k40f0nm]SplineForm1.JPG[/attachment:3k40f0nm]

Un laikam būs tās super adaptīvās kontrolles jāatstāj uz vēlāku laiku un jānobeidz tas interpolātors un jāuzkodē tas kods priekš stm32 proča, lai varētu nosūtīt to G-kodu un saņemt atpakaļ caur USB jau apstrādātus interpolētus Datus kurus tad vizuāli varētu attēlot pārbaudot uz kļūdām

----------


## Epis

Pāris dienas atpakaļ nāca tāda kā "Kārtējā Apskaidrība" par to kādēļ principā ir tik grūti domāt par to prorammas tālāko kodēšanu, un galvenā progroblēma ir tajā kād es tajā savā kodā esu izmantojis tikai Viss primitīvāko C# kodēšanas līmeni: esu iztaisījis pārisdesmitiem matemātisku funkciju, kuras izsaucu no citiem kodiem, funkcijām, bet redzu ka šādi tā lieta uz priekšu neiet, un ir beidzot jāpāriet nākošā apstrakcijas kodēšanas domāšanas līmenī un tas ir:  jāizmanto Objekti, un Klases, kas to programmu sadalītu tādos kā Līmeņos, blokos kur katrs koda gablas varētu komunicēt ar kādu citu kodu caur saviem interfeisiem, un tā ir tā Objekt orjentētas valodas galvenā filozofija. 
Un cik esu lasījis tad tie kas taisīja to CNC brain kontrollieri programmas cepa arī šādā objekt orjentētā stillā ar vairākiem software layeriem. 

tas nozīmē ka ir jāpārdomā, jāpārtaisa visa līdz šim uzrakstītā koda struktūra, jo svādāk tās lietas uz priekšu neiet  :: .

----------


## Epis

šī jau laikam atkal ir Ntā reize ka es te rakstu ka atkal kautko atsāku savam Motion kontrolliera hobby projektam kodēt, taisīt. un katru reizi arī saku ka šoreiz nu būs tā īstā reize ka aizies tā lieta līdz kautkam Reāli ejošam, un kā parasti tiekot līdz kādam posmam tā attīstība apstājās, bet te nu es atkal saku  :: , ka šoreiz Ejot JAUNU CEĻU tā lieta, domāju ka, patiešām aizies līdz strādājošam devaisam, jo atšķirībā no iepriekšējiem mēģinājumiem esu samazinājis savas ambīcijas, jeb prasības pēc tiem Performance parametriem (motora, enkodera, PID loop ātrummiem, un vēl visādiem fantastiskiem navarotiem), un tagat mēģināšu uzkodēt tādu "Parastu" PID kontrollieri motoriem kur: 
 PID frekvence 1Khz,
motoru,enkoderu MAX ātrummi 15-20Khz
USB interfeis ar kompi, (parametru ielikšanai, un varbūt arī Step/dir informācijas nosūtīšanai (LTP porta vietā)
protams ka asu skaits ir 4 asis.
visu taisīšu uz STM32F103RBT6   tas čips kas ir uz mana Dev.kita, un arī šis čips ir nopērkams Elfā, un vēl arī ir piejama Ļoti lēts STM32-H103 HEADER BOARD no OLIMEX pa 27eiro man tas liekās ļoti lēti, un ja es uz tāda tipa plates uzķinītu savu elektroniku tad tas būtu baigi labi, jo nevaidzētu pašam neko lodēt  ::  

Līdz šim jau esu uzkodējis ejošu EnkoderDekoderi neizmantojot standartā esošo Enkoder perifēriju
(to es arī bīju uzkodējis bet aizņēma pārāk daudz Taimera resursu+DMA resurus priekš pilnas automātiskas infas saglabāšanas, vispār es šeit esu tā stipri ilgi domājis kā varētu optimālāk un,labāk izmantot kopā ar DMA kanāliem (2vi USB un 5 paliek izmantojami) un visam, Kā jauparasti ka kodē ar MCU, perifēriju trūkst, vai nav tādas kādas vaig (kodējot uz fpga šādu sūdzību pēc būtības nebūtu, bet ar MCU ir jālauza galva, jāskaita cikli cik kas ko patērē un kā to visu sabāzt esošajos kanālos))
, bet parasto Capture kanālu un softwareiski dekodējot virzienu, skaitot noietos soļus, reālo pozīciju,ātrumu, un ir arī apgūta PWM, jeb frekvences ģenerēšana, Taimeru uzstādīšana un tas viss ar C kodu bez nevienas ASM rindas.
ir protams arī agrāk jau iemēģinātais USB kods, un tagat atliek izdomāt to pašu Komandu nolasīšanas, un PID loop algoritmu, kas īstanībā nav nemaz tik viegli, jo tur ir vairāki scenāriji + fiksēto punktu cipari, un lielākas grūtības būs ar īstā laika testēšanu,kļūdu ķeršanu, jo tur vaidzēs rakstīt atsevišķu kodu, kas vāks datus un sūtīs tos uz kompi, jo ar pašreizējo debaggeri un to Ride7 softu nevaru uzlikt nekādu Real time Trace jeb kā viņi to sauc  SWV (single wire viewer) karoč nerādās man nekādi īstā laika kodu darbības logi + debagerim ir tas limits 32Kb.

nu lūk tādas ir tās jaunās idejas, un jaunais Virziens ko esu tagat izvelējies.

----------


## Epis

esu beidzot pabeidzis kodēt to jauno C# kodu ar kuru tagat varēs ģenerēt kordinātes teorētiski neierobežotam asu skaitam, praktiski ierobežojums ir G-koda sintakses nolsītāj kods. 
Vecajā kodā bīj tikai 3 asis tagat varēs kautvai 6 asis vienīgais jāpieraksta sintakes kodā klāt pāris asu burti. 
pagaidām šitas jaunais algoritms var ģenerēt kordinātes 1; 2; vai 3 asīm, vēlāk būs arī 4.,bet vairāk par 6 domāju ka nevaidzēs  :: 
neliels ieskatas kā tad ar jano kodu definē, uzstāda asu skaitu  :: 


```
            Axis[] Ass = new Axis[3];
            // Ielādē Ass[] Arrayā Uztaisītos Axis elementus(X,Y,Z)
            for (int A_i = 0; A_i < 3; A_i++)
            {
                Axis NewAss = new Axis(CPItemp, A_i); // Definē Jaunu Asi
                Ass[A_i] = NewAss; // Ielādē JaunDefinēto asi Ass[] arrayā(laukā)
            }
```

 tālāk kodā es visas matemātiskās funkcias izsaucu iekavās liekot iekšā Ass[], un kādu globālo mainīgo, vecajā stillā es mainīgos manuāli rakstīju un šādi manuāli rakstot lai pievienotu, vai noņemtu kādu asi visi kodi ir manuāli jāmaina, bet tagat nekas nav jāmaina, ir tikai jānodefinē vēlamais asu skaits  ::  
reku fragments vinai matemātiskai funkcijas izsaukšanai, sākumā vecais, lejā jaunais kods:


```
              
                    double XspeedNEW = G01Linear.AxisSpeedcalculation(Xkord, Ykord, Zkord, int.Parse(apgriezieniUzMM.Text), speedNEW, XkordV, YkordV, ZkordV);
                    double YspeedNEW = G01Linear.YspeedNEWback;
                    double ZspeedNEW = G01Linear.ZspeedNEWback;

                    //* JAUNAIS Kods ar Axis Class: 
                    G01Linear.AxisSpeedCalculation(Ass, Kord, speedNEW); // Kord ir double[] Kord (arrays ) vienīgais Globālais mainīgais ir speedNEW
```

 vēl jāiztīra ārā vecie kodu gabali, jūra ar visādiem mainīgajiem, kas tagat visi sabāzti vienā ass klasē, vizuāli būs lielāka kartība kodā, + šito kodu tagat varētu reāli mēģināt transformet uz  C valodu priekš Stm32 proča, un apskatītes cik daudz laika prasa kordināšu ģenerēšana fiksēto punktu cortex procim.

----------


## Velko

Neliels komentārs par mainīgo/funkciju/klašu utt. nosaukumiem. Centies turēties pie vienas valodas (vēlams angļu). Citādi, ja kādreiz izdomāsi parādīt to kodu kādam, kurš neprot latviešu valodu, tad viņam tas tavs Ass[] masīvs izraisīs nepareizas asociācijas   ::

----------


## Epis

parasti mainīgiem vārdus mēginu izvēlēties tādus kuri labāk izsaka lietas būtību, un priekšroku dodu tiem vārdiem kuriem nav garumzīmes, un kas izmēros ir mazāki  ::  vairums jau ir angļu vārdu. 

ja kāds grib iemēģināt manu softu darbībā varu tagat "Publiskot" EpiCNC softu uzgenerējot instalējamos failus kas vaidzīgi lai softu uzinstalētu uz kompa, kā jebkuru parasto programmu, pagaidām esu instalējis tikai uz windowsa XP, par Vistu un 7vindows un citiem nezinu, šādā softa publiskotā versijā sorce kodi nav redzami (viņi ir nocompilēti).

un esu softam pielicis klāt File menu izvēli, kur ir 
Open G-kode file // atver principā jebkuru tekst failu jo nav norādīts kodā ka tam jābūt tieši .g failam atvērto attēlo softa logā un ģenerējot kordinātes ņem info no tā faila
Save Gcode file // saglabā logā attēloto g failu ar .g faila nosaukumu.
principā progas logā var rakstīt, ielādēt,saglabāt g-koda, jeb parasto tekst failu  :: 
Open hex file // fails nav hex formāta, bet parasts tekst, kuru attēlo softs vienā no progas Logiem, un jēgas no šī pagaidām nav jo softs sūta informāciju caru com portu no g-koda uzģenerētās informācijas, ir doma to koda sūtītāj kodu atdalīt no ieksējiem rasursiem un pielikt klāt šim Output teksta logam, lai ņem info no turienes (kādā hex, vai savādākā ciparu formātā) tad šādā variantā tehiski būtu iespēja ielādēt un nosūtīt kadu esošu kodu nevis visu pārģenerēt.
save hex file // saglabā info kas ir Output teksta logā failā ar .hex nosaukumu formātprotams nav īsts Hex faila 
ir jau doma uztaisit ko līdzīgu īstajam hex failam, tip formats cik saprotu ir hex binārie cipari un vienā rindā 22 cipari un rinda sākās ar  ":"

nav vēl loga kur uzlikt katras ass parametrus kā arī to skaitu, pārējais viss interfeis ir vecais.

Tagat es kodēju jaunu fiču un tas ir LinearMoveCompress() funkcija, kas ģenerēs sūtāmo informāciju Fiksēta ātrumma gadījumā, ka asis kustās ar konstantu ātrummu, un visi soļa ātrumma cipari ir identiski visā processa laikā, un te arī būs jauns sūtāmās informācijas protokols:



> ///  LinearMoveCompress() Lineārās kustības ar Fiksētu ātrummu Arhivēšana.
>             /// Protokols ir Sekojoš:
>             ///Identifikātors: | ID[8] | 
>             /// Apakš Bloki kas var atkārtoties atkarībā no Asku skaita:
>             /// AxisID[8] | StepCountX[8-24] | SpeedX[8-32] | Kombinācija atkārtojās tik reižu cik daudz ir iesaistīto Asu!!
>             /// 
>             /// ID[8] = Identifikātors kur bitiem ir šāda funkcija:
>             /// b[7] =1;  Norāda ka šis Nav Step/DIR ID bloks! 
>             /// b[0:2] =  Motoru Skaits (max 8 motori!);
> ...


 teksts no C# koda kur pats priekš sevīm uzrakstīju kāds tad izskatīsies tas protokols, un baitu nozīmes, un lejā vecais STEP/DIR signālu arhivātor protokols, kur es šodien arī kodā ierakstīju komentu, par visiem bitiem un izskatu



> /// TimeCompres() Notiek Baitu arhivācija kur veido STEP/DIR Bloku
>                     /// Pamat step/dir Protokols kurā glabā 1na ass Soļa ātrummu:
>                     ///  | ID[7] | Speed[7-31] |  
>                     /// 
>                     /// ID baits baits sastāv no: 
>                     /// ID[7] =0;
>                     /// ID[6] = DIR bit (1=+; 0=-)
>                     /// ID[3:5]= Speed_Byte_Repeater biti, kur:
>                     ///  ID[5]= 4.speed baits, ja atkārtojās tad ID[5]=1 un Speed Blokā neraksta 4 baitu,
> ...


 un te var redzēt ka Max ass skaits protokolā ir  8.

jāuzraksta vēl abiem variantiem dekoderi un tad tos dekoderus liks iekšā stm32 procī un kautko mēģinās pagrozīt.

----------


## Epis

atkal labu laiciņu neko nēsu rakstījis, bet tas ka nerakstu nenozīmē ka neko nekodēju un nedaru šai lietā, un tagat izdevās atšķetināt problēmu kas radās pēc pēdējā mana posta, ka testēju tos signālu arhivātorus, kā viņi tos ciparus arhivē, un tad izrādījās ka mans ātruma, distances, uzrāviena, laika... aprēķināšanas algoritms ir Kļūdains, proti bīju uzkodējis tikai 1nam dzīves gadījumam to algoritmu, tad kad viena G kordināte var izpildīties 3 processu posmos:
1.uzrāviens
2. Fiksēts ātrums
3. Bremzēšana (negatīvs uzrāviens)

un skatoties tajās ciparu tabulās sākumā nevarēju saprast, kas tie pa cipariem, un kā viņus vispār atšifrēt, ta uztaisīju vēl pāris papild softus, kas to informāciju vizualizē, man mirstīgajam, saprotamā formātā un redzēju ka ir galīgi garām, un ņēmu rokā baltu lapu un reiķināju visus lielumus ar ROKU un ta sāku brīnīties, un nāca ārā kļūda pēc kļudas, sākumā bīj ļoti viltīga kļūda ar mērvienībām, bīju sarēzinājis kordinātes (metros) ar  Steps per Revolution kas bīj 100 un finālā kods gāja tā ka  no F100 G01 X5 y10 softs rēķināja Laikus, ātrummus, distances kordinātēm X500 Y1000 un tad kad pienāca kārta algoritmam kas rēķina uzrāviena katra soļa laiku, ta tika rēķināts laika intervāls 1 solim kas ir 0,01m un sanāca baigi lēnā motora rotācija (šitas man uzreiz iecirtās) un pēc noietiem soļiem tas motora ātrums bīj joprojām niecīgs, un tā es sāku labot visu algoritmu, un ka sataisīju kārtībā mērvienības, ta redzēju ka asis nevar sasniegt norādīto F100 ātrummu kas atkal pēc manām mērvienībām izrādījās 100m/s   ::   (bīj protams domāti 100mm/s bet tā nu sanāca), un tas protams ir kārtējais mērvienību grābeklis uz kura jau vienreiz uzkāpu, bet tagat redzēju ka jātaisa tas otrs Algoritms kurš izpilda G koda komandu ar 2 processa Posmiem:
1. uzrāviens
2. bremzēšana(negatīvs uzrāviens)
te redzams ka Nav fiksēta ātrumma posma, un tīri tehiski šī situācija ir jādetektē ar koda algoritma palīdzību un pēctam vēl jāaprēķina kāds tad būs tas maximālais ātrumms, uzrāvienam un viņa distance, un šitas algoritms man tagat beidzot ir uzcepts un reku varat ievērtēt katra motora soļa ātrummu (1 vienība ir 1ns)
acceleration 3m/s apgriezieni uz 1metru ir 100 (tas nozīmē ka 1 soļa distance ir 1cm)
un dešifrēts tiek F100 G01 X5 Y10  rinda un saģenerē 1500 soļus pareizā secībā. 


```
r1-115470X 
 Nr2-81650 Y 
 Nr3-33820 Y 
 Nr4-47829X 
 Nr5-25951 Y 
 Nr6-21878 Y 
 Nr7-36701X 
 Nr8-19275 Y 
 Nr9-17426 Y 
 Nr10-30940X 
 Nr11-16025 Y 
 Nr12-14915 Y 
 Nr13-27259X 
 Nr14-14009 Y 
 Nr15-13250 Y 
 Nr16-24644X 
 Nr17-12602 Y 
 Nr18-12042 Y 
 Nr19-22662X 
 Nr20-11549 Y 
 Nr21-11113 Y 
 Nr22-21094X 
 Nr23-10723 Y 
 Nr24-10371 Y 
 Nr25-19811X 
 Nr26-10051 Y 
 Nr27-9760 Y 
 Nr28-18738X 
 Nr29-9493 Y 
 Nr30-9245 Y 
 Nr31-17823X 
 Nr32-9018 Y 
 Nr33-8805 Y 
 Nr34-17029X 
 Nr35-8607 Y 
 Nr36-8422 Y 
 Nr37-16333X 
 Nr38-8248 Y 
 Nr39-8085 Y 
 Nr40-15716X 
 Nr41-7931 Y 
 Nr42-7785 Y 
 Nr43-15165X 
 Nr44-7648 Y 
 Nr45-7517 Y 
 Nr46-14666X 
 Nr47-7392 Y 
 Nr48-7274 Y 
 Nr49-14215X 
 Nr50-7162 Y 
 Nr51-7053 Y 
 Nr52-13803X 
 Nr53-6951 Y 
 Nr54-6852 Y 
 Nr55-13424X 
 Nr56-6757 Y 
 Nr57-6667 Y 
 Nr58-13076X 
 Nr59-6580 Y 
 Nr60-6496 Y 
 Nr61-12752X 
 Nr62-6415 Y 
 Nr63-6337 Y 
 Nr64-12453X 
 Nr65-6263 Y 
 Nr66-6190 Y 
 Nr67-12172X 
 Nr68-6120 Y 
 Nr69-6052 Y 
 Nr70-11910X 
 Nr71-5987 Y 
 Nr72-5923 Y 
 Nr73-11665X 
 Nr74-5863 Y 
 Nr75-5802 Y 
 Nr76-11434X 
 Nr77-5745 Y 
 Nr78-5689 Y 
 Nr79-11216X 
 Nr80-5634 Y 
 Nr81-5582 Y 
 Nr82-11010X 
 Nr83-5530 Y 
 Nr84-5480 Y 
 Nr85-10815X 
 Nr86-5431 Y 
 Nr87-5384 Y 
 Nr88-10631X 
 Nr89-5338 Y 
 Nr90-5293 Y 
 Nr91-10454X 
 Nr92-5248 Y 
 Nr93-5206 Y 
 Nr94-10287X 
 Nr95-5164 Y 
 Nr96-5123 Y 
 Nr97-10128X 
 Nr98-5084 Y 
 Nr99-5044 Y 
 Nr100-9975X 
 Nr101-5006 Y 
 Nr102-4969 Y 
 Nr103-9830X 
 Nr104-4933 Y 
 Nr105-4897 Y 
 Nr106-9690X 
 Nr107-4862 Y 
 Nr108-4828 Y 
 Nr109-9557X 
 Nr110-4795 Y 
 Nr111-4762 Y 
 Nr112-9428X 
 Nr113-4730 Y 
 Nr114-4698 Y 
 Nr115-9305X 
 Nr116-4668 Y 
 Nr117-4637 Y 
 Nr118-9187X 
 Nr119-4608 Y 
 Nr120-4579 Y 
 Nr121-9072X 
 Nr122-4550 Y 
 Nr123-4522 Y 
 Nr124-8962X 
 Nr125-4495 Y 
 Nr126-4467 Y 
 Nr127-8857X 
 Nr128-4442 Y 
 Nr129-4415 Y 
 Nr130-8754X 
 Nr131-4389 Y 
 Nr132-4365 Y 
 Nr133-8655X 
 Nr134-4339 Y 
 Nr135-4316 Y 
 Nr136-8559X 
 Nr137-4291 Y 
 Nr138-4268 Y 
 Nr139-8467X 
 Nr140-4245 Y 
 Nr141-4222 Y 
 Nr142-8377X 
 Nr143-4199 Y 
 Nr144-4178 Y 
 Nr145-8290X 
 Nr146-4156 Y 
 Nr147-4134 Y 
 Nr148-8207X 
 Nr149-4114 Y 
 Nr150-4093 Y 
 Nr151-8124X 
 Nr152-4072 Y 
 Nr153-4052 Y 
 Nr154-8045X 
 Nr155-4033 Y 
 Nr156-4012 Y 
 Nr157-7969X 
 Nr158-3994 Y 
 Nr159-3975 Y 
 Nr160-7893X 
 Nr161-3956 Y 
 Nr162-3937 Y 
 Nr163-7821X 
 Nr164-3919 Y 
 Nr165-3902 Y 
 Nr166-7750X 
 Nr167-3884 Y 
 Nr168-3866 Y 
 Nr169-7681X 
 Nr170-3849 Y 
 Nr171-3832 Y 
 Nr172-7614X 
 Nr173-3815 Y 
 Nr174-3799 Y 
 Nr175-7548X 
 Nr176-3782 Y 
 Nr177-3766 Y 
 Nr178-7485X 
 Nr179-3751 Y 
 Nr180-3734 Y 
 Nr181-7423X 
 Nr182-3719 Y 
 Nr183-3704 Y 
 Nr184-7362X 
 Nr185-3689 Y 
 Nr186-3673 Y 
 Nr187-7303X 
 Nr188-3659 Y 
 Nr189-3644 Y 
 Nr190-7245X 
 Nr191-3630 Y 
 Nr192-3615 Y 
 Nr193-7189X 
 Nr194-3602 Y 
 Nr195-3587 Y 
 Nr196-7134X 
 Nr197-3574 Y 
 Nr198-3560 Y 
 Nr199-7080X 
 Nr200-3547 Y 
 Nr201-3533 Y 
 Nr202-7027X 
 Nr203-3520 Y 
 Nr204-3507 Y 
 Nr205-6976X 
 Nr206-3495 Y 
 Nr207-3481 Y 
 Nr208-6926X 
 Nr209-3469 Y 
 Nr210-3457 Y 
 Nr211-6876X 
 Nr212-3444 Y 
 Nr213-3432 Y 
 Nr214-6828X 
 Nr215-3420 Y 
 Nr216-3408 Y 
 Nr217-6781X 
 Nr218-3396 Y 
 Nr219-3385 Y 
 Nr220-6734X 
 Nr221-3372 Y 
 Nr222-3362 Y 
 Nr223-6689X 
 Nr224-3350 Y 
 Nr225-3339 Y 
 Nr226-6645X 
 Nr227-3328 Y 
 Nr228-3317 Y 
 Nr229-6601X 
 Nr230-3305 Y 
 Nr231-3296 Y 
 Nr232-6558X 
 Nr233-3284 Y 
 Nr234-3274 Y 
 Nr235-6516X 
 Nr236-3263 Y 
 Nr237-3253 Y 
 Nr238-6476X 
 Nr239-3243 Y 
 Nr240-3233 Y 
 Nr241-6434X 
 Nr242-3222 Y 
 Nr243-3212 Y 
 Nr244-6396X 
 Nr245-3203 Y 
 Nr246-3193 Y 
 Nr247-6356X 
 Nr248-3183 Y 
 Nr249-3173 Y 
 Nr250-6319X 
 Nr251-3164 Y 
 Nr252-3155 Y 
 Nr253-6280X 
 Nr254-3145 Y 
 Nr255-3135 Y 
 Nr256-6244X 
 Nr257-3127 Y 
 Nr258-3117 Y 
 Nr259-6208X 
 Nr260-3109 Y 
 Nr261-3099 Y 
 Nr262-6172X 
 Nr263-3090 Y 
 Nr264-3082 Y 
 Nr265-6137X 
 Nr266-3073 Y 
 Nr267-3064 Y 
 Nr268-6103X 
 Nr269-3056 Y 
 Nr270-3047 Y 
 Nr271-6069X 
 Nr272-3039 Y 
 Nr273-3030 Y 
 Nr274-6036X 
 Nr275-3022 Y 
 Nr276-3014 Y 
 Nr277-6003X 
 Nr278-3005 Y 
 Nr279-2998 Y 
 Nr280-5971X 
 Nr281-2989 Y 
 Nr282-2982 Y 
 Nr283-5939X 
 Nr284-2973 Y 
 Nr285-2966 Y 
 Nr286-5908X 
 Nr287-2958 Y 
 Nr288-2950 Y 
 Nr289-5877X 
 Nr290-2942 Y 
 Nr291-2935 Y 
 Nr292-5847X 
 Nr293-2927 Y 
 Nr294-2920 Y 
 Nr295-5818X 
 Nr296-2913 Y 
 Nr297-2905 Y 
 Nr298-5788X 
 Nr299-2897 Y 
 Nr300-2891 Y 
 Nr301-5759X 
 Nr302-2883 Y 
 Nr303-2876 Y 
 Nr304-5730X 
 Nr305-2869 Y 
 Nr306-2861 Y 
 Nr307-5703X 
 Nr308-2855 Y 
 Nr309-2848 Y 
 Nr310-5675X 
 Nr311-2841 Y 
 Nr312-2834 Y 
 Nr313-5648X 
 Nr314-2827 Y 
 Nr315-2821 Y 
 Nr316-5621X 
 Nr317-2814 Y 
 Nr318-2807 Y 
 Nr319-5595X 
 Nr320-2801 Y 
 Nr321-2794 Y 
 Nr322-5568X 
 Nr323-2787 Y 
 Nr324-2781 Y 
 Nr325-5543X 
 Nr326-2775 Y 
 Nr327-2768 Y 
 Nr328-5517X 
 Nr329-2762 Y 
 Nr330-2755 Y 
 Nr331-5493X 
 Nr332-2749 Y 
 Nr333-2744 Y 
 Nr334-5467X 
 Nr335-2736 Y 
 Nr336-2731 Y 
 Nr337-5444X 
 Nr338-2725 Y 
 Nr339-2719 Y 
 Nr340-5419X 
 Nr341-2712 Y 
 Nr342-2707 Y 
 Nr343-5395X 
 Nr344-2701 Y 
 Nr345-2694 Y 
 Nr346-5373X 
 Nr347-2689 Y 
 Nr348-2684 Y 
 Nr349-5349X 
 Nr350-2677 Y 
 Nr351-2672 Y 
 Nr352-5326X 
 Nr353-2666 Y 
 Nr354-2660 Y 
 Nr355-5304X 
 Nr356-2655 Y 
 Nr357-2649 Y 
 Nr358-5281X 
 Nr359-2643 Y 
 Nr360-2638 Y 
 Nr361-5260X 
 Nr362-2633 Y 
 Nr363-2627 Y 
 Nr364-5237X 
 Nr365-2621 Y 
 Nr366-2616 Y 
 Nr367-5217X 
 Nr368-2611 Y 
 Nr369-2606 Y 
 Nr370-5195X 
 Nr371-2600 Y 
 Nr372-2595 Y 
 Nr373-5174X 
 Nr374-2590 Y 
 Nr375-2584 Y 
 Nr376-5154X 
 Nr377-2580 Y 
 Nr378-2574 Y 
 Nr379-5133X 
 Nr380-2569 Y 
 Nr381-2564 Y 
 Nr382-5114X 
 Nr383-2559 Y 
 Nr384-2555 Y 
 Nr385-5093X 
 Nr386-2549 Y 
 Nr387-2544 Y 
 Nr388-5073X 
 Nr389-2539 Y 
 Nr390-2534 Y 
 Nr391-5054X 
 Nr392-2530 Y 
 Nr393-2524 Y 
 Nr394-5035X 
 Nr395-2520 Y 
 Nr396-2515 Y 
 Nr397-5016X 
 Nr398-2510 Y 
 Nr399-2506 Y 
 Nr400-4997X 
 Nr401-2500 Y 
 Nr402-2497 Y 
 Nr403-4978X 
 Nr404-2491 Y 
 Nr405-2487 Y 
 Nr406-4960X 
 Nr407-2482 Y 
 Nr408-2478 Y 
 Nr409-4941X 
 Nr410-2473 Y 
 Nr411-2468 Y 
 Nr412-4924X 
 Nr413-2464 Y 
 Nr414-2460 Y 
 Nr415-4906X 
 Nr416-2455 Y 
 Nr417-2451 Y 
 Nr418-4888X 
 Nr419-2446 Y 
 Nr420-2442 Y 
 Nr421-4871X 
 Nr422-2438 Y 
 Nr423-2433 Y 
 Nr424-4853X 
 Nr425-2429 Y 
 Nr426-2424 Y 
 Nr427-4837X 
 Nr428-2421 Y 
 Nr429-2416 Y 
 Nr430-4820X 
 Nr431-2412 Y 
 Nr432-2408 Y 
 Nr433-4803X 
 Nr434-2403 Y 
 Nr435-2400 Y 
 Nr436-4786X 
 Nr437-2395 Y 
 Nr438-2391 Y 
 Nr439-4770X 
 Nr440-2387 Y 
 Nr441-2383 Y 
 Nr442-4754X 
 Nr443-2379 Y 
 Nr444-2375 Y 
 Nr445-4738X 
 Nr446-2371 Y 
 Nr447-2367 Y 
 Nr448-4722X 
 Nr449-2363 Y 
 Nr450-2359 Y 
 Nr451-4706X 
 Nr452-2355 Y 
 Nr453-2351 Y 
 Nr454-4690X 
 Nr455-2347 Y 
 Nr456-2343 Y 
 Nr457-4676X 
 Nr458-2340 Y 
 Nr459-2336 Y 
 Nr460-4660X 
 Nr461-2332 Y 
 Nr462-2328 Y 
 Nr463-4645X 
 Nr464-2324 Y 
 Nr465-2321 Y 
 Nr466-4630X 
 Nr467-2316 Y 
 Nr468-2314 Y 
 Nr469-4615X 
 Nr470-2309 Y 
 Nr471-2306 Y 
 Nr472-4600X 
 Nr473-2302 Y 
 Nr474-2298 Y 
 Nr475-4586X 
 Nr476-2295 Y 
 Nr477-2291 Y 
 Nr478-4571X 
 Nr479-2288 Y 
 Nr480-2283 Y 
 Nr481-4558X 
 Nr482-2281 Y 
 Nr483-2277 Y 
 Nr484-4543X 
 Nr485-2273 Y 
 Nr486-2270 Y 
 Nr487-4529X 
 Nr488-2266 Y 
 Nr489-2263 Y 
 Nr490-4515X 
 Nr491-2259 Y 
 Nr492-2256 Y 
 Nr493-4502X 
 Nr494-2253 Y 
 Nr495-2249 Y 
 Nr496-4488X 
 Nr497-2245 Y 
 Nr498-2243 Y 
 Nr499-4474X 
 Nr500-2238 Y 
 Nr501-2236 Y 
 Nr502-4461X 
 Nr503-2232 Y 
 Nr504-2229 Y 
 Nr505-4448X 
 Nr506-2225 Y 
 Nr507-2223 Y 
 Nr508-4434X 
 Nr509-2219 Y 
 Nr510-2215 Y 
 Nr511-4422X 
 Nr512-2213 Y 
 Nr513-2209 Y 
 Nr514-4409X 
 Nr515-2206 Y 
 Nr516-2203 Y 
 Nr517-4395X 
 Nr518-2199 Y 
 Nr519-2196 Y 
 Nr520-4384X 
 Nr521-2194 Y 
 Nr522-2190 Y 
 Nr523-4370X 
 Nr524-2186 Y 
 Nr525-2184 Y 
 Nr526-4358X 
 Nr527-2181 Y 
 Nr528-2177 Y 
 Nr529-4346X 
 Nr530-2175 Y 
 Nr531-2171 Y 
 Nr532-4334X 
 Nr533-2168 Y 
 Nr534-2166 Y 
 Nr535-4321X 
 Nr536-2162 Y 
 Nr537-2159 Y 
 Nr538-4309X 
 Nr539-2156 Y 
 Nr540-2153 Y 
 Nr541-4298X 
 Nr542-2151 Y 
 Nr543-2147 Y 
 Nr544-4285X 
 Nr545-2144 Y 
 Nr546-2141 Y 
 Nr547-4274X 
 Nr548-2139 Y 
 Nr549-2135 Y 
 Nr550-4262X 
 Nr551-2132 Y 
 Nr552-2130 Y 
 Nr553-4251X 
 Nr554-2127 Y 
 Nr555-2124 Y 
 Nr556-4239X 
 Nr557-2120 Y 
 Nr558-2119 Y 
 Nr559-4227X 
 Nr560-2115 Y 
 Nr561-2112 Y 
 Nr562-4217X 
 Nr563-2110 Y 
 Nr564-2107 Y 
 Nr565-4205X 
 Nr566-2104 Y 
 Nr567-2101 Y 
 Nr568-4194X 
 Nr569-2098 Y 
 Nr570-2096 Y 
 Nr571-4183X 
 Nr572-2093 Y 
 Nr573-2090 Y 
 Nr574-4172X 
 Nr575-2087 Y 
 Nr576-2085 Y 
 Nr577-4161X 
 Nr578-2082 Y 
 Nr579-2079 Y 
 Nr580-4151X 
 Nr581-2077 Y 
 Nr582-2074 Y 
 Nr583-4140X 
 Nr584-2071 Y 
 Nr585-2069 Y 
 Nr586-4129X 
 Nr587-2065 Y 
 Nr588-2064 Y 
 Nr589-4118X 
 Nr590-2060 Y 
 Nr591-2058 Y 
 Nr592-4109X 
 Nr593-2056 Y 
 Nr594-2053 Y 
 Nr595-4098X 
 Nr596-2050 Y 
 Nr597-2048 Y 
 Nr598-4087X 
 Nr599-2045 Y 
 Nr600-2042 Y 
 Nr601-4078X 
 Nr602-2040 Y 
 Nr603-2038 Y 
 Nr604-4067X 
 Nr605-2034 Y 
 Nr606-2033 Y 
 Nr607-4057X 
 Nr608-2030 Y 
 Nr609-2027 Y 
 Nr610-4047X 
 Nr611-2025 Y 
 Nr612-2022 Y 
 Nr613-4038X 
 Nr614-2020 Y 
 Nr615-2018 Y 
 Nr616-4027X 
 Nr617-2015 Y 
 Nr618-2012 Y 
 Nr619-4018X 
 Nr620-2010 Y 
 Nr621-2008 Y 
 Nr622-4008X 
 Nr623-2005 Y 
 Nr624-2003 Y 
 Nr625-3998X 
 Nr626-2000 Y 
 Nr627-1998 Y 
 Nr628-3989X 
 Nr629-1996 Y 
 Nr630-1993 Y 
 Nr631-3979X 
 Nr632-1991 Y 
 Nr633-1988 Y 
 Nr634-3970X 
 Nr635-1987 Y 
 Nr636-1983 Y 
 Nr637-3961X 
 Nr638-1982 Y 
 Nr639-1979 Y 
 Nr640-3951X 
 Nr641-1977 Y 
 Nr642-1974 Y 
 Nr643-3942X 
 Nr644-1972 Y 
 Nr645-1970 Y 
 Nr646-3933X 
 Nr647-1968 Y 
 Nr648-1965 Y 
 Nr649-3924X 
 Nr650-1963 Y 
 Nr651-1961 Y 
 Nr652-3915X 
 Nr653-1959 Y 
 Nr654-1956 Y 
 Nr655-3906X 
 Nr656-1954 Y 
 Nr657-1952 Y 
 Nr658-3897X 
 Nr659-1949 Y 
 Nr660-1948 Y 
 Nr661-3888X 
 Nr662-1945 Y 
 Nr663-1943 Y 
 Nr664-3879X 
 Nr665-1941 Y 
 Nr666-1938 Y 
 Nr667-3871X 
 Nr668-1936 Y 
 Nr669-1935 Y 
 Nr670-3862X 
 Nr671-1932 Y 
 Nr672-1930 Y 
 Nr673-3853X 
 Nr674-1927 Y 
 Nr675-1926 Y 
 Nr676-3845X 
 Nr677-1923 Y 
 Nr678-1922 Y 
 Nr679-3836X 
 Nr680-1919 Y 
 Nr681-1917 Y 
 Nr682-3828X 
 Nr683-1915 Y 
 Nr684-1913 Y 
 Nr685-3819X 
 Nr686-1910 Y 
 Nr687-1909 Y 
 Nr688-3811X 
 Nr689-1907 Y 
 Nr690-1904 Y 
 Nr691-3803X 
 Nr692-1903 Y 
 Nr693-1900 Y 
 Nr694-3794X 
 Nr695-1898 Y 
 Nr696-1896 Y 
 Nr697-3787X 
 Nr698-1895 Y 
 Nr699-1892 Y 
 Nr700-3778X 
 Nr701-1890 Y 
 Nr702-1888 Y 
 Nr703-3770X 
 Nr704-1886 Y 
 Nr705-1884 Y 
 Nr706-3763X 
 Nr707-1883 Y 
 Nr708-1880 Y 
 Nr709-3754X 
 Nr710-1878 Y 
 Nr711-1876 Y 
 Nr712-3746X 
 Nr713-1874 Y 
 Nr714-1872 Y 
 Nr715-3739X 
 Nr716-1870 Y 
 Nr717-1869 Y 
 Nr718-3730X 
 Nr719-1866 Y 
 Nr720-1864 Y 
 Nr721-3723X 
 Nr722-1863 Y 
 Nr723-1860 Y 
 Nr724-3715X 
 Nr725-1859 Y 
 Nr726-1856 Y 
 Nr727-3708X 
 Nr728-1855 Y 
 Nr729-1853 Y 
 Nr730-3700X 
 Nr731-1851 Y 
 Nr732-1849 Y 
 Nr733-3692X 
 Nr734-1847 Y 
 Nr735-1845 Y 
 Nr736-3685X 
 Nr737-1844 Y 
 Nr738-1841 Y 
 Nr739-3677X 
 Nr740-1840 Y 
 Nr741-1837 Y 
 Nr742-3670X 
 Nr743-1836 Y 
 Nr744-1834 Y 
 Nr745-3663X 
 Nr746-1832 Y 
 Nr747-1831 Y 
 Nr748-3655X 
 Nr749-1828 Y 
 Nr750-1827 Y 
 Nr751-3655X 
 Nr752-1827 Y 
 Nr753-1828 Y 
 Nr754-3663X 
 Nr755-1830 Y 
 Nr756-1833 Y 
 Nr757-3670X 
 Nr758-1834 Y 
 Nr759-1836 Y 
 Nr760-3677X 
 Nr761-1837 Y 
 Nr762-1840 Y 
 Nr763-3685X 
 Nr764-1841 Y 
 Nr765-1844 Y 
 Nr766-3692X 
 Nr767-1845 Y 
 Nr768-1847 Y 
 Nr769-3700X 
 Nr770-1849 Y 
 Nr771-1851 Y 
 Nr772-3707X 
 Nr773-1853 Y 
 Nr774-1854 Y 
 Nr775-3716X 
 Nr776-1857 Y 
 Nr777-1859 Y 
 Nr778-3722X 
 Nr779-1860 Y 
 Nr780-1862 Y 
 Nr781-3731X 
 Nr782-1865 Y 
 Nr783-1866 Y 
 Nr784-3739X 
 Nr785-1868 Y 
 Nr786-1871 Y 
 Nr787-3746X 
 Nr788-1872 Y 
 Nr789-1874 Y 
 Nr790-3754X 
 Nr791-1876 Y 
 Nr792-1878 Y 
 Nr793-3762X 
 Nr794-1880 Y 
 Nr795-1882 Y 
 Nr796-3771X 
 Nr797-1885 Y 
 Nr798-1886 Y 
 Nr799-3778X 
 Nr800-1888 Y 
 Nr801-1890 Y 
 Nr802-3786X 
 Nr803-1892 Y 
 Nr804-1894 Y 
 Nr805-3795X 
 Nr806-1897 Y 
 Nr807-1898 Y 
 Nr808-3803X 
 Nr809-1900 Y 
 Nr810-1903 Y 
 Nr811-3811X 
 Nr812-1904 Y 
 Nr813-1907 Y 
 Nr814-3819X 
 Nr815-1909 Y 
 Nr816-1910 Y 
 Nr817-3828X 
 Nr818-1913 Y 
 Nr819-1915 Y 
 Nr820-3836X 
 Nr821-1917 Y 
 Nr822-1919 Y 
 Nr823-3845X 
 Nr824-1922 Y 
 Nr825-1923 Y 
 Nr826-3853X 
 Nr827-1926 Y 
 Nr828-1927 Y 
 Nr829-3862X 
 Nr830-1930 Y 
 Nr831-1932 Y 
 Nr832-3871X 
 Nr833-1934 Y 
 Nr834-1937 Y 
 Nr835-3879X 
 Nr836-1938 Y 
 Nr837-1941 Y 
 Nr838-3888X 
 Nr839-1943 Y 
 Nr840-1945 Y 
 Nr841-3897X 
 Nr842-1948 Y 
 Nr843-1949 Y 
 Nr844-3906X 
 Nr845-1952 Y 
 Nr846-1954 Y 
 Nr847-3915X 
 Nr848-1956 Y 
 Nr849-1959 Y 
 Nr850-3924X 
 Nr851-1961 Y 
 Nr852-1963 Y 
 Nr853-3933X 
 Nr854-1965 Y 
 Nr855-1968 Y 
 Nr856-3942X 
 Nr857-1969 Y 
 Nr858-1973 Y 
 Nr859-3951X 
 Nr860-1974 Y 
 Nr861-1977 Y 
 Nr862-3960X 
 Nr863-1979 Y 
 Nr864-1981 Y 
 Nr865-3970X 
 Nr866-1984 Y 
 Nr867-1986 Y 
 Nr868-3980X 
 Nr869-1989 Y 
 Nr870-1991 Y 
 Nr871-3989X 
 Nr872-1993 Y 
 Nr873-1996 Y 
 Nr874-3998X 
 Nr875-1998 Y 
 Nr876-2000 Y 
 Nr877-4008X 
 Nr878-2003 Y 
 Nr879-2005 Y 
 Nr880-4018X 
 Nr881-2008 Y 
 Nr882-2010 Y 
 Nr883-4027X 
 Nr884-2012 Y 
 Nr885-2015 Y 
 Nr886-4038X 
 Nr887-2018 Y 
 Nr888-2020 Y 
 Nr889-4047X 
 Nr890-2022 Y 
 Nr891-2025 Y 
 Nr892-4057X 
 Nr893-2027 Y 
 Nr894-2030 Y 
 Nr895-4067X 
 Nr896-2032 Y 
 Nr897-2035 Y 
 Nr898-4078X 
 Nr899-2038 Y 
 Nr900-2040 Y 
 Nr901-4087X 
 Nr902-2042 Y 
 Nr903-2045 Y 
 Nr904-4098X 
 Nr905-2048 Y 
 Nr906-2050 Y 
 Nr907-4108X 
 Nr908-2053 Y 
 Nr909-2055 Y 
 Nr910-4119X 
 Nr911-2058 Y 
 Nr912-2061 Y 
 Nr913-4129X 
 Nr914-2063 Y 
 Nr915-2066 Y 
 Nr916-4140X 
 Nr917-2069 Y 
 Nr918-2071 Y 
 Nr919-4151X 
 Nr920-2074 Y 
 Nr921-2077 Y 
 Nr922-4161X 
 Nr923-2079 Y 
 Nr924-2082 Y 
 Nr925-4172X 
 Nr926-2085 Y 
 Nr927-2087 Y 
 Nr928-4183X 
 Nr929-2090 Y 
 Nr930-2093 Y 
 Nr931-4194X 
 Nr932-2096 Y 
 Nr933-2098 Y 
 Nr934-4205X 
 Nr935-2101 Y 
 Nr936-2104 Y 
 Nr937-4217X 
 Nr938-2107 Y 
 Nr939-2110 Y 
 Nr940-4227X 
 Nr941-2112 Y 
 Nr942-2115 Y 
 Nr943-4239X 
 Nr944-2118 Y 
 Nr945-2121 Y 
 Nr946-4251X 
 Nr947-2124 Y 
 Nr948-2127 Y 
 Nr949-4262X 
 Nr950-2129 Y 
 Nr951-2133 Y 
 Nr952-4274X 
 Nr953-2135 Y 
 Nr954-2139 Y 
 Nr955-4285X 
 Nr956-2141 Y 
 Nr957-2144 Y 
 Nr958-4298X 
 Nr959-2147 Y 
 Nr960-2151 Y 
 Nr961-4309X 
 Nr962-2153 Y 
 Nr963-2156 Y 
 Nr964-4321X 
 Nr965-2159 Y 
 Nr966-2162 Y 
 Nr967-4334X 
 Nr968-2165 Y 
 Nr969-2169 Y 
 Nr970-4345X 
 Nr971-2171 Y 
 Nr972-2174 Y 
 Nr973-4359X 
 Nr974-2178 Y 
 Nr975-2181 Y 
 Nr976-4370X 
 Nr977-2183 Y 
 Nr978-2187 Y 
 Nr979-4383X 
 Nr980-2190 Y 
 Nr981-2193 Y 
 Nr982-4396X 
 Nr983-2197 Y 
 Nr984-2199 Y 
 Nr985-4409X 
 Nr986-2203 Y 
 Nr987-2206 Y 
 Nr988-4422X 
 Nr989-2209 Y 
 Nr990-2213 Y 
 Nr991-4434X 
 Nr992-2215 Y 
 Nr993-2219 Y 
 Nr994-4448X 
 Nr995-2222 Y 
 Nr996-2226 Y 
 Nr997-4461X 
 Nr998-2229 Y 
 Nr999-2232 Y 
 Nr1000-4474X 
 Nr1001-2235 Y 
 Nr1002-2239 Y 
 Nr1003-4488X 
 Nr1004-2243 Y 
 Nr1005-2245 Y 
 Nr1006-4502X 
 Nr1007-2249 Y 
 Nr1008-2253 Y 
 Nr1009-4515X 
 Nr1010-2256 Y 
 Nr1011-2259 Y 
 Nr1012-4529X 
 Nr1013-2263 Y 
 Nr1014-2266 Y 
 Nr1015-4543X 
 Nr1016-2270 Y 
 Nr1017-2273 Y 
 Nr1018-4557X 
 Nr1019-2277 Y 
 Nr1020-2280 Y 
 Nr1021-4572X 
 Nr1022-2284 Y 
 Nr1023-2288 Y 
 Nr1024-4586X 
 Nr1025-2291 Y 
 Nr1026-2295 Y 
 Nr1027-4600X 
 Nr1028-2298 Y 
 Nr1029-2302 Y 
 Nr1030-4615X 
 Nr1031-2306 Y 
 Nr1032-2309 Y 
 Nr1033-4630X 
 Nr1034-2313 Y 
 Nr1035-2317 Y 
 Nr1036-4645X 
 Nr1037-2321 Y 
 Nr1038-2324 Y 
 Nr1039-4660X 
 Nr1040-2328 Y 
 Nr1041-2332 Y 
 Nr1042-4675X 
 Nr1043-2336 Y 
 Nr1044-2339 Y 
 Nr1045-4691X 
 Nr1046-2344 Y 
 Nr1047-2347 Y 
 Nr1048-4706X 
 Nr1049-2351 Y 
 Nr1050-2355 Y 
 Nr1051-4722X 
 Nr1052-2359 Y 
 Nr1053-2363 Y 
 Nr1054-4738X 
 Nr1055-2367 Y 
 Nr1056-2371 Y 
 Nr1057-4754X 
 Nr1058-2375 Y 
 Nr1059-2379 Y 
 Nr1060-4770X 
 Nr1061-2383 Y 
 Nr1062-2387 Y 
 Nr1063-4786X 
 Nr1064-2391 Y 
 Nr1065-2395 Y 
 Nr1066-4803X 
 Nr1067-2400 Y 
 Nr1068-2403 Y 
 Nr1069-4820X 
 Nr1070-2408 Y 
 Nr1071-2412 Y 
 Nr1072-4836X 
 Nr1073-2416 Y 
 Nr1074-2420 Y 
 Nr1075-4854X 
 Nr1076-2425 Y 
 Nr1077-2429 Y 
 Nr1078-4871X 
 Nr1079-2433 Y 
 Nr1080-2438 Y 
 Nr1081-4888X 
 Nr1082-2442 Y 
 Nr1083-2446 Y 
 Nr1084-4906X 
 Nr1085-2451 Y 
 Nr1086-2455 Y 
 Nr1087-4924X 
 Nr1088-2459 Y 
 Nr1089-2465 Y 
 Nr1090-4941X 
 Nr1091-2468 Y 
 Nr1092-2473 Y 
 Nr1093-4960X 
 Nr1094-2478 Y 
 Nr1095-2482 Y 
 Nr1096-4978X 
 Nr1097-2487 Y 
 Nr1098-2491 Y 
 Nr1099-4997X 
 Nr1100-2496 Y 
 Nr1101-2501 Y 
 Nr1102-5016X 
 Nr1103-2506 Y 
 Nr1104-2510 Y 
 Nr1105-5035X 
 Nr1106-2515 Y 
 Nr1107-2520 Y 
 Nr1108-5054X 
 Nr1109-2524 Y 
 Nr1110-2530 Y 
 Nr1111-5073X 
 Nr1112-2534 Y 
 Nr1113-2539 Y 
 Nr1114-5093X 
 Nr1115-2544 Y 
 Nr1116-2549 Y 
 Nr1117-5113X 
 Nr1118-2554 Y 
 Nr1119-2559 Y 
 Nr1120-5134X 
 Nr1121-2565 Y 
 Nr1122-2569 Y 
 Nr1123-5153X 
 Nr1124-2574 Y 
 Nr1125-2579 Y 
 Nr1126-5175X 
 Nr1127-2585 Y 
 Nr1128-2590 Y 
 Nr1129-5195X 
 Nr1130-2595 Y 
 Nr1131-2600 Y 
 Nr1132-5216X 
 Nr1133-2606 Y 
 Nr1134-2610 Y 
 Nr1135-5238X 
 Nr1136-2617 Y 
 Nr1137-2621 Y 
 Nr1138-5260X 
 Nr1139-2627 Y 
 Nr1140-2633 Y 
 Nr1141-5281X 
 Nr1142-2638 Y 
 Nr1143-2643 Y 
 Nr1144-5304X 
 Nr1145-2649 Y 
 Nr1146-2655 Y 
 Nr1147-5326X 
 Nr1148-2660 Y 
 Nr1149-2666 Y 
 Nr1150-5349X 
 Nr1151-2672 Y 
 Nr1152-2677 Y 
 Nr1153-5372X 
 Nr1154-2683 Y 
 Nr1155-2689 Y 
 Nr1156-5396X 
 Nr1157-2695 Y 
 Nr1158-2701 Y 
 Nr1159-5419X 
 Nr1160-2707 Y 
 Nr1161-2712 Y 
 Nr1162-5444X 
 Nr1163-2719 Y 
 Nr1164-2725 Y 
 Nr1165-5467X 
 Nr1166-2730 Y 
 Nr1167-2737 Y 
 Nr1168-5493X 
 Nr1169-2743 Y 
 Nr1170-2750 Y 
 Nr1171-5517X 
 Nr1172-2755 Y 
 Nr1173-2762 Y 
 Nr1174-5543X 
 Nr1175-2768 Y 
 Nr1176-2775 Y 
 Nr1177-5568X 
 Nr1178-2781 Y 
 Nr1179-2787 Y 
 Nr1180-5595X 
 Nr1181-2794 Y 
 Nr1182-2801 Y 
 Nr1183-5621X 
 Nr1184-2807 Y 
 Nr1185-2814 Y 
 Nr1186-5648X 
 Nr1187-2820 Y 
 Nr1188-2828 Y 
 Nr1189-5675X 
 Nr1190-2834 Y 
 Nr1191-2841 Y 
 Nr1192-5702X 
 Nr1193-2848 Y 
 Nr1194-2854 Y 
 Nr1195-5731X 
 Nr1196-2862 Y 
 Nr1197-2869 Y 
 Nr1198-5759X 
 Nr1199-2876 Y 
 Nr1200-2883 Y 
 Nr1201-5788X 
 Nr1202-2891 Y 
 Nr1203-2897 Y 
 Nr1204-5818X 
 Nr1205-2905 Y 
 Nr1206-2913 Y 
 Nr1207-5847X 
 Nr1208-2919 Y 
 Nr1209-2928 Y 
 Nr1210-5877X 
 Nr1211-2935 Y 
 Nr1212-2942 Y 
 Nr1213-5908X 
 Nr1214-2950 Y 
 Nr1215-2958 Y 
 Nr1216-5939X 
 Nr1217-2966 Y 
 Nr1218-2973 Y 
 Nr1219-5971X 
 Nr1220-2982 Y 
 Nr1221-2989 Y 
 Nr1222-6003X 
 Nr1223-2997 Y 
 Nr1224-3006 Y 
 Nr1225-6036X 
 Nr1226-3014 Y 
 Nr1227-3022 Y 
 Nr1228-6069X 
 Nr1229-3030 Y 
 Nr1230-3039 Y 
 Nr1231-6103X 
 Nr1232-3047 Y 
 Nr1233-3056 Y 
 Nr1234-6137X 
 Nr1235-3064 Y 
 Nr1236-3073 Y 
 Nr1237-6172X 
 Nr1238-3081 Y 
 Nr1239-3091 Y 
 Nr1240-6208X 
 Nr1241-3099 Y 
 Nr1242-3109 Y 
 Nr1243-6244X 
 Nr1244-3117 Y 
 Nr1245-3127 Y 
 Nr1246-6280X 
 Nr1247-3135 Y 
 Nr1248-3145 Y 
 Nr1249-6319X 
 Nr1250-3155 Y 
 Nr1251-3164 Y 
 Nr1252-6356X 
 Nr1253-3173 Y 
 Nr1254-3183 Y 
 Nr1255-6395X 
 Nr1256-3193 Y 
 Nr1257-3202 Y 
 Nr1258-6435X 
 Nr1259-3213 Y 
 Nr1260-3222 Y 
 Nr1261-6476X 
 Nr1262-3233 Y 
 Nr1263-3243 Y 
 Nr1264-6516X 
 Nr1265-3253 Y 
 Nr1266-3263 Y 
 Nr1267-6558X 
 Nr1268-3274 Y 
 Nr1269-3284 Y 
 Nr1270-6601X 
 Nr1271-3295 Y 
 Nr1272-3306 Y 
 Nr1273-6645X 
 Nr1274-3317 Y 
 Nr1275-3328 Y 
 Nr1276-6689X 
 Nr1277-3339 Y 
 Nr1278-3350 Y 
 Nr1279-6734X 
 Nr1280-3361 Y 
 Nr1281-3373 Y 
 Nr1282-6781X 
 Nr1283-3385 Y 
 Nr1284-3396 Y 
 Nr1285-6828X 
 Nr1286-3408 Y 
 Nr1287-3420 Y 
 Nr1288-6876X 
 Nr1289-3432 Y 
 Nr1290-3444 Y 
 Nr1291-6926X 
 Nr1292-3457 Y 
 Nr1293-3469 Y 
 Nr1294-6975X 
 Nr1295-3481 Y 
 Nr1296-3494 Y 
 Nr1297-7028X 
 Nr1298-3508 Y 
 Nr1299-3520 Y 
 Nr1300-7080X 
 Nr1301-3533 Y 
 Nr1302-3547 Y 
 Nr1303-7134X 
 Nr1304-3560 Y 
 Nr1305-3574 Y 
 Nr1306-7188X 
 Nr1307-3587 Y 
 Nr1308-3601 Y 
 Nr1309-7246X 
 Nr1310-3616 Y 
 Nr1311-3630 Y 
 Nr1312-7303X 
 Nr1313-3644 Y 
 Nr1314-3659 Y 
 Nr1315-7362X 
 Nr1316-3673 Y 
 Nr1317-3689 Y 
 Nr1318-7423X 
 Nr1319-3704 Y 
 Nr1320-3719 Y 
 Nr1321-7485X 
 Nr1322-3734 Y 
 Nr1323-3751 Y 
 Nr1324-7548X 
 Nr1325-3766 Y 
 Nr1326-3782 Y 
 Nr1327-7614X 
 Nr1328-3799 Y 
 Nr1329-3815 Y 
 Nr1330-7681X 
 Nr1331-3832 Y 
 Nr1332-3849 Y 
 Nr1333-7750X 
 Nr1334-3866 Y 
 Nr1335-3884 Y 
 Nr1336-7821X 
 Nr1337-3901 Y 
 Nr1338-3920 Y 
 Nr1339-7893X 
 Nr1340-3937 Y 
 Nr1341-3956 Y 
 Nr1342-7968X 
 Nr1343-3975 Y 
 Nr1344-3993 Y 
 Nr1345-8046X 
 Nr1346-4013 Y 
 Nr1347-4033 Y 
 Nr1348-8124X 
 Nr1349-4052 Y 
 Nr1350-4072 Y 
 Nr1351-8206X 
 Nr1352-4093 Y 
 Nr1353-4113 Y 
 Nr1354-8291X 
 Nr1355-4135 Y 
 Nr1356-4156 Y 
 Nr1357-8377X 
 Nr1358-4177 Y 
 Nr1359-4200 Y 
 Nr1360-8467X 
 Nr1361-4222 Y 
 Nr1362-4245 Y 
 Nr1363-8559X 
 Nr1364-4268 Y 
 Nr1365-4291 Y 
 Nr1366-8655X 
 Nr1367-4316 Y 
 Nr1368-4339 Y 
 Nr1369-8754X 
 Nr1370-4365 Y 
 Nr1371-4389 Y 
 Nr1372-8856X 
 Nr1373-4415 Y 
 Nr1374-4441 Y 
 Nr1375-8963X 
 Nr1376-4468 Y 
 Nr1377-4495 Y 
 Nr1378-9072X 
 Nr1379-4522 Y 
 Nr1380-4550 Y 
 Nr1381-9187X 
 Nr1382-4579 Y 
 Nr1383-4608 Y 
 Nr1384-9305X 
 Nr1385-4637 Y 
 Nr1386-4668 Y 
 Nr1387-9428X 
 Nr1388-4698 Y 
 Nr1389-4730 Y 
 Nr1390-9557X 
 Nr1391-4762 Y 
 Nr1392-4795 Y 
 Nr1393-9690X 
 Nr1394-4828 Y 
 Nr1395-4862 Y 
 Nr1396-9830X 
 Nr1397-4897 Y 
 Nr1398-4933 Y 
 Nr1399-9975X 
 Nr1400-4969 Y 
 Nr1401-5006 Y 
 Nr1402-10128X 
 Nr1403-5044 Y 
 Nr1404-5084 Y 
 Nr1405-10287X 
 Nr1406-5123 Y 
 Nr1407-5164 Y 
 Nr1408-10454X 
 Nr1409-5206 Y 
 Nr1410-5248 Y 
 Nr1411-10631X 
 Nr1412-5293 Y 
 Nr1413-5338 Y 
 Nr1414-10815X 
 Nr1415-5383 Y 
 Nr1416-5432 Y 
 Nr1417-11010X 
 Nr1418-5480 Y 
 Nr1419-5530 Y 
 Nr1420-11216X 
 Nr1421-5581 Y 
 Nr1422-5635 Y 
 Nr1423-11434X 
 Nr1424-5689 Y 
 Nr1425-5745 Y 
 Nr1426-11664X 
 Nr1427-5802 Y 
 Nr1428-5862 Y 
 Nr1429-11911X 
 Nr1430-5924 Y 
 Nr1431-5987 Y 
 Nr1432-12172X 
 Nr1433-6052 Y 
 Nr1434-6120 Y 
 Nr1435-12453X 
 Nr1436-6190 Y 
 Nr1437-6263 Y 
 Nr1438-12752X 
 Nr1439-6337 Y 
 Nr1440-6415 Y 
 Nr1441-13076X 
 Nr1442-6496 Y 
 Nr1443-6580 Y 
 Nr1444-13424X 
 Nr1445-6666 Y 
 Nr1446-6758 Y 
 Nr1447-13803X 
 Nr1448-6852 Y 
 Nr1449-6951 Y 
 Nr1450-14215X 
 Nr1451-7053 Y 
 Nr1452-7162 Y 
 Nr1453-14666X 
 Nr1454-7274 Y 
 Nr1455-7392 Y 
 Nr1456-15164X 
 Nr1457-7517 Y 
 Nr1458-7647 Y 
 Nr1459-15717X 
 Nr1460-7786 Y 
 Nr1461-7931 Y 
 Nr1462-16333X 
 Nr1463-8085 Y 
 Nr1464-8248 Y 
 Nr1465-17029X 
 Nr1466-8422 Y 
 Nr1467-8607 Y 
 Nr1468-17822X 
 Nr1469-8805 Y 
 Nr1470-9017 Y 
 Nr1471-18739X 
 Nr1472-9246 Y 
 Nr1473-9493 Y 
 Nr1474-19811X 
 Nr1475-9760 Y 
 Nr1476-10051 Y 
 Nr1477-21094X 
 Nr1478-10371 Y 
 Nr1479-10723 Y 
 Nr1480-22662X 
 Nr1481-11113 Y 
 Nr1482-11549 Y 
 Nr1483-24644X 
 Nr1484-12042 Y 
 Nr1485-12602 Y 
 Nr1486-27259X 
 Nr1487-13250 Y 
 Nr1488-14009 Y 
 Nr1489-30940X 
 Nr1490-14915 Y 
 Nr1491-16025 Y 
 Nr1492-36701X 
 Nr1493-17426 Y 
 Nr1494-19275 Y 
 Nr1495-47829X 
 Nr1496-21878 Y 
 Nr1497-25951 Y 
 Nr1498-115470X 
 Nr1499-33820 Y 
 Nr1500-81650 Y 
  Vidus 
 Beigas
```

 un tur X ass cm soļa sākotnējais iešanas laiks ir 115470ns  vidū ātrums sasniedz 3655ns un tad aiziet atpakaļ līdz sākotnējam ātrummam. uzrāviena Laiks ir 1.82 sekundes.
ja kāds grib var pārbaudīt, man liekās ka šoreiz viss ir pareizi un kā nākās.  ::  
ja šonedēļ nebūs nekādu steidzamu darbu darāmu ta novedīšu softu līdz stadījai ka var sūtīt step/dir uz stm32 plati caur USB.

----------


## GuntisK

A kāda jēga vispār pi**ies ap to visu? Tiešām ceri, ka Epja ūberkūl-softs būs labāks par MACH3, EMC2 vai TCNC? Būtu labāk ņēmies ap praktisko realizāciju- piemēram nevienu pašu dzelzi no tevis vēl neesmu redzējis...   ::  Nē-nu rakstam visādus kodu gabalus, a uz kā tad izmēģināsi to visu? Tā ka...

----------


## Epis

Nu man vaig kautkādu closed loop kontrolli tiem saviem stepper motoriem un virpas Spindle motoram,(savādāk vītni iegriezt nevarēs) un daudz naudas es tam tērēt negribu.
apstījos Match3 plug in lapu http://www.machsupport.com/plugins.php
tur ir intresanta KFLOP  8-axis Motion Control Board w/Software $249 +Tax,S&H plate, uz kuras ir TI DSP čips +Xilinx fpga un viņiem tur ir savējais softs, + tas Match3 pluggins, vispār šitas variants varētu derēt, vismaz ir vērts tuvāk papētīt, varbūt ka patiešām der un ir vērts nopirkt, kā nekā 250$ ir tīri laba cena.
un plate kā tāda arī ir vērtība  :: .

ir tā ka kad būs plate kas tiem stepperiem uztaisa closed loop ta arī liks kopā iekārtu, un pa to domās.

----------


## Epis

Šodien nometu to savu EpiCNC softu malā un ķēros pie PID loop kodēšanas un STEP/Dir saņemšanas. 
reāli strādā uz šo brīdi STEP signālu saņēmējs (2 asīm) Qenkoder dekoderis (2 asīm) un pusfabrikāta stadījā ir tas PID, un pietrūkst STEP/dir OUtputa.

ā un tas vis uz STM32 Kita.
To PID algoritma implementāciju es līdz galam izdomāju šovakar, un uz papīra ir uzrakstīts aprēķins, un būs tā ka reķinās PID ik pēc 10 no kompja saņemtajiem Step signāliem, un salīdzinās noieto enkodera soļu ātrumma summu ar ekvivalentiem STEP soļu ātrumma summu, piemēram :
Ja kompis ir izdevis 10 soļus bet enkoders pa to laiku saņēma tikai 9 soļus ta PID algoritmā grūdīs 9enkoder soļu ātrummu summu un Erroru kas rēķināts no 9Enk soliem - 9 Step soļu ātrumu summas. 
domāju ka šitas variatns ir tīri labs, jo veikt PID loopu fiksētā frekvencē nav īsti Labi.

----------


## Vikings

> veikt PID loopu fiksētā frekvencē nav īsti Labi.


 Pamato. Es tam redzu tikai mīnusus un pie maziem ātrumiem - nestrādāšanu.

----------


## Epis

> Pamato. Es tam redzu tikai mīnusus un pie maziem ātrumiem - nestrādāšanu.


 nu kā es to izdomāju lasot šito rakstu http://www.embedded.com/2000/0010/0010feat3.htm
tur rakstīts



> The rule of thumb for digital control systems is that the sample time should be between 1/10th and 1/100th of the desired system settling time.


 un sample rate ir manā izpratnē Step signāli, un setling time būs 10 motora soļu ilgums.
Nu iedomājis situāciju ja PID loops iet fiksētā laikā ik pēc 1ms (1khz) tad ir 2 galejību varianti:
1. motori iet ļoti ātri un tad PID būs jārēķina kādiem 100-1000 soļiem, labi šitas vēl ir pieņemami un varēs kautko kontrollēt.
2. ka motori iet nereāli lēni un ta 1 Pid ciklā tiks noieti 0 motora soļi, un kā ta lai es to PID rēķinu 0 Motora soļiem a ?  
proti man 2.variantā nebūs dati ar kurus tajā PID loopā likt iekšā  ::  līdz ar to būs jāizlaižtik daudz PID cikli cik reizes nebūs pagājuši nekādi soļi, un līdz ar to sanāks ka PID tiks rēķināts Katram motora solim pie zemiem ātrummiem, un nez vai tas būs baigi labi. 

Šodien debagoju to PID, un itkā viss iet un var dabūt ārā kautkādu Error ciparu, bīj arī uzkāriens koda rakstīšanā ar Pointeriem uz Structuru, kur no Main funkcijas vaidzēja iet
 PID(&ENC2, &Motors1PID); // abi ENC2 un Motors1PID ir typedef Struct {} definēti (katram motoram savs, void PID(Encoder *ENC, SPid * pid)
un tālāk savkārt Pid funkcijā es izsaucu vēlvienu PID kalkulācijas funkciju kura izmanto Motors1PID struktūras pointeri:
UpdatePID(&pid,  ENC->error , ENCsumm,&SpeedSumm); //Motor1PID -> pid  
 funkcijas definējums šāds: void UpdatePID(SPid * pid, u32 error, u32 position,volatile u32 *T)
un ta tajā UpdatePID() notiek darbības ar SPid struct  piemēram šādā stillā:
  pTerm = pid->pGain * error; 
Diemžāl šitas dubūltais struct Pointera pārnešanas variants nestrādāa, un pagaidām ieliku PID() struktūras pointera vietā parastu ciparu kas norāda vai tas ir 1, vai 2 motors, un ta pašā PID() iekšā izsaucu UpdatePID() ar  &Motors1PID vai &Motors2PID vadoties pēc tā Motora cipara

beigās es itkā atradu veidu kā pārnest to struktūras pointeri nākošā funcijā, bet tad sanāk pirmajā funckijā inicializēt jaunu struktūru un pārnest tajā esošās informāciju un tad likt pointeri uz to, vienīgi nēsu apstījies vai šādi otra funkcija spēs ierakstīt īstajā struktūrā, moš ierakstīs citur.
nu ir tādi šādi visvisādi sīki čakari, kodējot ar C.

Rīt kodēšu STEP ģenerātoru un tad mēģinās kautkādies uzrakstīt papild kodu lai varētu izdebagot un moš pielikt klāt motoru, reāli būs jāpielodē pie kita klāt kontakti lai to varētu izdarīt.
Ja kautkas grizīsies ta vienalga vaidzēs likt klāt to USB interfeisu un rakstīt softu kas uz kompja sūtīs info par to kā tad tas PID algoritms strādā lai varētu  tos Kp, Ki, Kd pareizus uzstādīt.

----------


## Vikings

> lai varētu tos Kp, Ki, Kd pareizus uzstādīt.


 Tur jau tā lieta, ka pie dažādiem apstrādes ātrumiem, IMHO, šie koeficienti būs mainīgi.

----------


## Epis

> Tur jau tā lieta, ka pie dažādiem apstrādes ātrumiem, IMHO, šie koeficienti būs mainīgi.


 kurā no variantiem (fiksēta PID frekvence 1Lhz vai ik pa 10SOļiem) tu iesaki mainīt tos PID koeficientus ? 

karoči pievienoju Fiksētas frekvences Ģenerēšanas kodu uz Taimera 4.  2 Compare kanāliem, un vēl padebagoju ar reālām vērtībām(kuras pats ieliku kodā) to PID algoritmu, lai redzētu kā rēķina Pozitīva errora, un Negatīva errora gadījumos,  un kāds tad ir izejošais rezultāts, principā es sākumā kodēju ar Unsigned u32 cipariem, bet nācās likt S32 lai rēkina pareizi negatīvās vērtības, un Konstantes man uztaisītas ar fiksētu Decimālo punktu:
1 Kp = 0.1
1 Ki =0.01
1 Kd= 0.1 

Nu itkā kods ir uzrakstīts, visas perifērijas strādā, un ir saslēgtas ar PID moduli, tākā vaidzētu slēgt klāt motoru,enkoderus,kompi lai pārbaudītu vai kautkas strādā, (protams ka no sākuma nekas neies, bet savādāk izdebaggot kodu bez reāla testa nevar, un ta redzēs cik grūti tas būs. 

tagat jāpielodē kontakti, un jāvelk ārā no skapja noputējušais steppera driveris+motori, un cnc softs jāieinstallē.  ::

----------


## Epis

> A kāda jēga vispār pi**ies ap to visu? Tiešām ceri, ka Epja ūberkūl-softs būs labāks par MACH3, EMC2 vai TCNC? Būtu labāk ņēmies ap praktisko realizāciju- piemēram nevienu pašu dzelzi no tevis vēl neesmu redzējis...   Nē-nu rakstam visādus kodu gabalus, a uz kā tad izmēģināsi to visu? Tā ka...


 Šeit godīga atbilde kādēļ es patiešām uzskatu ka tas mans softs būs 100-200x labāks par to Match3, EMC2, vai TCNC kas iet uz LTP portiem (nerunājot par USB versijām). 
Atbilde slēpjās softu spējās ģenerēt tos STep signālus, kas standart CNC softiem izmantojot LTP portu(USB versijām ir vis OK) max ātrums ir 45Khz, jeb 45K reizes sekundē softs var mainīt LTP porta IO kanāla stāvokļus un ko tas nozīmē praktiski skatoties uz motora ātrummu ko ar šādu szšķirtspēju dabūt.
Tātad šeit bišķi matemātikas:
Laika intervāls 45Khz ir 1000/45=22,2us tas ir kompja laiks kas vaidzīgs lai mainītu IO portus, un skatamies kādi ir lielākie STEP signāla ātrummi kādus softs var uzģenerēt: un tie ir:
  ___22.2us__-----22.2us--______22.2us__-----22.2us 
tātad šitas ir ātrākais Step signāls ko var caur LTP portu izspiest un ātrums ir 44.4us jeb 22.7Khz translējot uz standart Stepper motoru ar 200cprx1/8mikro soli motora ātrums ir 851.25 RPM
tagat 2. ātrākā step soļa varsīja ir šāda:
___44.4us__----22.2us--_____44.4us__---22.2us-- _
tātad sanāk 33%PWM (soli skaita tikai uz lo->hi maiņas, vai pretēji kā softs ir nokonfigurēts tādēļ var būt PWM signāls ar dažādu %.
Labi aprēkinam tagat steppera RPM ātrummu (bīj 1600cpr ar visu 1/8mikrosoli) un tagat iegūstam 66.6us kas ir 15.15Khz -> 568.12 RPM

un šāda tad ir LTP porta Performance, proti pie lieliem ātrummiem, izšķirtspēja ir zem katras Kritikas, un ļoti ļoti švaka, jo nu diez vai kādam pietiks ar 2 Top ātrummiem 850 un 568 RPM, bet ko datīt ja grib 709RPM (Tas ir pa vidu abiem Top ātrummiem) tad Mach3, EMC,TCNC softs darīt tā ka izlaidīs vienu ātro Step signālu 850RPM un vienu lēnāko 568RPM un tā visu laiku ātri, lēni,ātri, lēni, un iedomājaties ka ta notiek ar motoru(tur ir katastrofa, jo motors tač nevar tik ātri mainīt savu kutības ātrummi tik lielā amplitūdā (šai gadījumā 283 RPM   ::   tas ir baigi daudz. 

Un tagat tas pats piemērs, ar MCU kurai ir Taimers kas ietu uz 36Mhz, un ģenerētu šo STEP impulsu, un kāda tad būtu šī teorētiskā izšķirtspēja, un rezultāts ir Graujoš, piemērs:
1000/36=27.7ns 
lai dabūtu ātrummu tuvu pie 851.25 (22,7Khz) vaig 1000/22,7=44us 44000ns/27.7=1588 clk tikšķi pie 36Mhz kā Bāzes laiku aprēķinam) 
tātad sākuma frekvence būs 27.7*1588=43987.6 (ns) = 1000000/43987.6=22.73367 *1000=22733.67/1600=14.2085*60=852.512 RPM
2.tuvākais ātrumms būs 27.7*1589= 44015.3(ns) = 1000000/44015.3=22.71937*1000=22719.372/1600=14.1996*60=851.976 RPM 
un tātad ar 36Mhz taimeri var adresēt ātrumu ar 0.53 RPM precizitāti pie 852 RPM liela ātrumma
un starpība ātrumma adresācijas spējā ir Graujoša, proti MCU apsteidz LTP portu un MACH3,EMC,TCNC softus 283/0.53= 534 X 

un nemaz nerunājot par kādiem lielākiem Step/dir ātrummiem, tādēļ jau es saku ka ja grib lai normāli strādātu soļu,motori tajā microstep režīmā vaig rakstīt savu CNC softu kas sūtīs digitālus Step/dir signālus, jo standart Mach3, citas progas sūta Step signālus ar katastrofāli zemu izšķirtspēju

pa šito problēmu es vakar cncZonā lasīju, kur jauno produktu sadaļā viens uztaisīja USB step/dir ģenerātoru uz PIC18 un viņam Taimerigāja ar 12Mhz, nekādas labās atsauksmes jau tur nebīj, daudzi izbrāķēja teica ka vecais LTP ports ir labāks, bet ka viens uzreiķināja šos izšķirtspējas ciparus ta šāds USB->Step/dir variants ir simtiem reizū labāks nekā Pliks LTP kam ir sūdīga izšķirtspēja. 

Tākā nav ko slavināt tās LTp cnc softa progas, (mach3 gadījumā tur ir tās USB Plug in kartes ko mach3 atbalsta un tad var dabūt labu step/dir signālu, bet bez tām ar pliku LTP nekas labs Defaultā sanakt nevar. 

Es pārdomāju un testu ar LTP porta kompja softu netaisīšu, tā vietā es pielikšu klāt USB COm port interfeisu un Flash ierakstīšanas kodu un mēģināšu test softu (step/dir komandas) caur USB ielādēt stm32 flash atmiņā (tur ir 128MB) un izpildīt programmu no turienes un caur USB sūtīt datus uz kompi un īstajā laikā vizualizēt kādā grafikā, vai tekst formātā, jo savādāk man nav kontrolles pār informāciju ko motoram ir jādara. 

Ja kas es atceros ka man nekad nebīj sanācis soļu motorus pakustināt ātrāk par 220RPM normāli  (visos mikrosoļu režimos) un man liekās ka tā vaina ir tajā LTP porta STep komandu gļukos, jeb nespējā iedot normālu signālu pie lieliem ātrummie, un līdz ar to motors sāk raustīties, vibrēt un ātrāk neiet.

----------


## Epis

Tā diena tuvojās ka tiks uztaisīts pirmais motoru kustināšanas tests  :: .
Principā esu ticis pāri pēdējam lielajam šķērslim un vaidzēja 4 dienas, un tas kā parasti bīj USB, proti, agrāk ka es šajā topikā cīnijos ar to USB viewtopic.php?f=25&t=2707 
es itkā dabūju ejošu variantu, bet tas bīj uz demo paraug koda bāzes projekta uzķīlēts, un izrādījās ka pārnesot visus USB biblotekas failus uz jaunu projektu, saliekot visās vietās visas vaidzīgās funkcijas,definējumus nekas reāli negāja  :: , un tā es 3 dienas meklēju kas pa vainu, beigās 3 dienā aizgāju līdz tam ka uztaisīju jaunu projektu (no 0) ieliku tīru usb failu kopīju un pārējos fauilus no Demo projekta un tāpat nekas neiet  ::  un ta sapratu ka vaina ir Compileri, vai kādos standart Biblotekas failos (USB demo projektam nāca līdzi visa ST lib failu pakete, + papild faili projektam:
cortexm3_macro.s // šitas saprotu ir softa iestartēšanas faili uz main() funkciju;
stm32f10x_vector.c  
un standartā ka taisa projektu nevaig nekādus macros.s un vector.c failus norādīt, es saprotu ka compileris tos failus pats ņem defaultā no softa instalācijas mapes biblotekas, un ta es pamanīju ka demo projekts ir nokonfigurēts tā ka neņem nevienu failu no softa biblotekas, un izmanto visus savējos (izņemot default script failu), un visa 4 dienu sāga beidzās ar to ka atslēdzu default softa bibloteku un ieliku šos 2 failus projektā (pirmstam arī liku, bet ka izmantoju softa bibloteku, ta compileris tur konfiliktēja, errorus meta) un viss beidzot aizgāja.

šodien uzķīlēju RAM FIFO bufferi 2Kb kur USB rakstīs saņemtos datus un tad main() funkcijā būs loops kas tai gadījumā ka būs dati bfferī ierakstīti tos datus pagadidām rakstīs iekšā Flash atmiņā(šitas flaš ieraksta kods tagat top, bet demo kods jau ir ietestēts un ierakstīt var mierīgi).
un tad ka būs pārkačāts softs flash atmiņā, taisīs deextrātora kodu kas tad bāzīs Step taimera compare kanālā PWm vertības un grozīs motorus  ::

----------


## Epis

Uzrakstīju Test softu kompim kas strādā īstajā laikā (cik nu īsti var zem windows Os iet  ::  ) un sūtīs datu paketes uz MCU, un gaidīs atbildi, jeb Error paketi, kuru saņemot pārsūtīs informāciju vēlreiz, + visas darbības(to ko iekodēju lai parāda) ko ir kompis saņēmis un ko izsūtījis īstajā laikā varēs redzēt uz tāda kā Log tekst ekrāna.
un kā redzams tur var uzstādīt datu pakas Lielumu (baitos) kā arī paku skaitu, un Delay aizturi sūtošajam Tread :  Tread.Delay(ms) starp datu pakām. 
un vispār baigi intresanti ir pavērot kā tā programma strādā Multitread režimā tajā īstajā laikā, proti datu sūta viens Treads un saņem pavisam cits un informāciju apmaina ar Statistiski definētiem mainīgajiem.
savkārt windows teksta Log logā datus met iekšā abi divi Tread (sūtītājs, un saņēmējs) un ta var redzēt kurš process strādā un kā kas notiek  ::  
šitā pirmā reize ka uzraksīju windows īstā laika softu, izmantojot Tread. pirmstam visi softi bīj seriāli, bet šis ir paralēls softa līmenī  un notikumu līmenī. 
[attachment=0:1hviia94]Rs232softbilde1.JPG[/attachment:1hviia94]
softu testēju caur Rs232 vadu kur galā Rx ir savienots ar Tx proti kompis saņem to ko pats ir sūtījis, un tur var redzēt ko sūtīja  ::  

nākošreiz mēģinās dzīvajā testēt MCU flash ierakstīšanu caur USB, un reāli ir tā ka caur USB var nosūtīt ātrāk datus nekā MCU spēj flashā iešūt, tādēļ arī vaidzēja softu kas informāciju pārsūtītu, tajos gadījumos ka USB iekšējais RAM Fifo bufferis būs pilns un ienākošie dati sāks zust, līdz ar to vaidzēs pārsūtīt visu pa jaunu no pēdējās pareizi saņemtās datu pakas vietas.

----------


## Epis

es te vēljoprojām čakarējos ar to USB datu saņemšanu un ierakstīšanu flash atmiņā, un to usb datu saņemšanas fifo bufferi esu itkā pareizi uzkodējis, bet flash ieraksīšanu no fifo buffera līdz galam nēsu, vispār ir tā ka vakar jau bīju šitik tālu ticis, bet ta izdomāju ka var visu novienkāršot un iepotimizēt, un šodien visu pārtaisīju, un bišķi vēl ir jāpieķinī, jo softs karās augšā pie konkrētas situāicjas, vispār ar šitiem Fifo cirkularajiem bufferiem ir vienas lielas galvas sāpes, un viņi paņem daudz MCU jaudas lai aprēķinātu tās Adreses kur glabāt,un nokurienes nolasīt, un debbagojot īstajā laikā to USB datu sūtīšanu ar pašrakstīto softu es tad simuklēju visādus iespējamos variantsu tam fifo bufferim. Čakars baigais. 

bet nu galvenais ko gribēju teikt ir tas ka nesen apstījos CNCzone kā tad tur iet tam CNCbrain 6Asu Motion kontrollierim, un izrādās ka tur tam CNCbrain ir problēmas un daudzi nevar palaist uz savām iekārtām, to viņu super lēto hardware, un ir protams pasmagi Vīlušies, un vīlušies arī tajā ka pirms tiem 10 mēnešiem ka tika paziņots, viņi teica ka tā CNCbrain plate ir Ejoša, un gatava darbam, tā vismaz visi domāja un Safanojās, bet vēlāk izrādījās ka tā visa hardware ir kautkādā beta testēšanas stadījā, un visādiem Buggiem pilna, un protams ka firma sola kļūdas novērst un izlaist uzlabotāku versīju, bet kautkā tā versija nenāk un nenāk..  http://www.cnczone.com/forums/showthrea ... 401&page=4
visvairāk mani uzjautrināja  "CarbideBob" (29gadu pieredze motion controllieru izstrādē)  posts kurš tā pamtīgi nokritizēja to Dual Pid LOOP ideju cnc asu, motoru sinhronizācijā, ka uz šī trika un idejas ir ļoti daudz muļķu uzķērušies, un finālā protams ka nekas nesanāk, un arī to CNCbrain pašu hardware novērtēja kā pārāk švaku priekš reālas motoru sinhronizācijas, bet nu man palika skaidrs ka es uz savas viena stm32 to Motion controllieri diez vai spēšu uztaisīt, arī no algoritmu viedokļa, ja tur neder standart PID algoritms, (kas man jau ir uzkodēts) ta jāraksta kautkāds Eksotiskais tip SMD krāsns TIpa, ar Nākotnes paredzēšanas fičām pēc pagātnes pieredzes, bāzētu uz kautkādiem apstraktiem keficentiem, kurus vēl īsti nēsu izdomājis.
tākā pašlaik neko vairāk kā parastu USB CNC colsed Loop Stepper kontrollieri uztaisīt nevarēšu, lai kautko uztaisītu līdzīgu Motion kontrollierim domāju ka vaidzētu kautko tik jaudīgu kā BeagleBord (150$) ar COrtex-A8 proci +DSP proci, bet šitos es kodēt vēl nemāku tākā, jāiztiek ar to kas ir.

Pēct tā cnc topika var noprast ka Geckodrive nāktnē domā izlaist USB CNC kontrollieri kombinācijā ar motoru draiveri, un to USB CNC kontrollieri izstrādā kāda cita firma, un tur tas kontrollieris ies no kādas Gb FLASH atmiņas (iespējams SD kartes, faktiski es domāju ka tas ir stipri līdzīgs tam ko es tagat mēģinu uzkodēt, proti CNC kompja softs uzģenerē STEP/dir signālus (ciparu formā) un tad tos saarhivē un caur USB nosūta uz Plati kur to visu noglabā Flash atmiņā, un tad vienkārši Palaiž Plati lai tā no Flasha ņem STep/dir un nospēlē to kā Mūzikas atskaņotājs, un lieta darīta, ir iegūts augstas kvalitātes STEP/Dir signāls + vēl priekš stepperiem PID loops(kā opcija). 

Sākumā es info rakstīšu Stm32 Flash atmiņā, un ka motori grizīsies ta mēģināšu GB SD kartē (biblotek kodi itkā ir piejami).

----------


## Epis

USB to flash ierakstīsanas kods ir gatavs tagat rakstu informācijas nolasīšanas un step/dir komandu nolasīšanas no flash, un palaišanas. Šeit debagot kodu vaidzēs jau ar reāliem motoriem  ::   un būs jāpieķinī kompja softs, lai ģenerētu kautkādus valīdus soļu motora ātrumma signālus, priekš debagošanas, vecā USB komunikācij debagošanas ciparu vietā.
ka motori griezīsies ta rakstīšu nākošo postu  ::

----------


## Vikings

Epi, ir viena nianse par enkoderiem. USdigital E4P enkoderu izejas ir ar atvērto kolektoru. Tas nozīmē - pie gara izejas vada tās noteikti būs traucējumu nenoturīgas. Tā kā - iesaku padomāt par kaut kādu bufera ķēdi tieši pie enkodera lai pa vadiem līdz apstrādes platei nonāktu jau traucējumu noturīgāki signāli.

----------


## Epis

Sākumā slēgs pa taisno enkoderus pie kita, un ta redzēs.

šodien pietaisīju EpiCNC softam Hex failu ģenerētāj kodu kas ta uzģenerēs mana "EpiCNC protokola ™, ®"  ::  Hex ciparu formāta(nevis intel hex standartam atbilstošu) tekstu ko  var saglabāt kā HEx failu un vēlāk iet uz otru RS232_iet progu un tad tur es uzrakstīšu kodu kas atvērs to Hex failu dekodēs un Lādēs iekšā stm32 flashatmiņā, pēc visiem maniem komunikācij protokola standartiem  :: 
[attachment=0:gnwcsxqg]virpasG.rar[/attachment:gnwcsxqg]
te virpasG.rar ir softa uzģenerētais hex fails, pareizas X,y vertības ir tikai pirmajām 2 G instrukcijām trešai ir kļūdains aprēķins, jo nēsu beigu loopā vēl veicis pielabošanu, + man tagat dekodē tikai G1 instrukcijas tādas kur katra nākošā vērtība ir ar pretēju zīmi !!, jo nav atkal izstrādāts kods tām citām variācijām, kā zīmes nemainīšanās un vēl vienas varbūtības esamībai.

vispār mans G-dekodēšanas algoritms skaitās Look Aheadtipa, jo viņš sāk reķināt G-komandas vērtības tikai tad kad ir nolasīta Nākošā G-instrukcija un ir zināms nākošās instrukcijas kustības virziens,ātrums, un tās variacijas nav visas iekodētas, proti ir atstāti tukšumi { }, to es pabeigšu kodēt tad kad man motori griezīsies un varēs izpildīt esošo  progu.
[attachment=1:gnwcsxqg]EpiCNc softa HEX output.GIF[/attachment:gnwcsxqg]

----------


## Vikings

> Sākumā slēgs pa taisno enkoderus pie kita, un ta redzēs.


 Ja vadi ir īsi tad jau nekas. Ja gari - problēmas sāksies, esmu gandrīz pārliecināts.

Bet par Tavu uzģenerēto kodu - vai nu esmu mudaks un neko nesaprotu, bet man pēc bildītes izskatās, ka izejas dati ir daaaaaudz vairāk nekā ieejas (trīs rindiņas gkoda). Kur tad ir izslavētā atmiņas ekonomija?

----------


## Epis

> Bet par Tavu uzģenerēto kodu - vai nu esmu mudaks un neko nesaprotu, bet man pēc bildītes izskatās, ka izejas dati ir daaaaaudz vairāk nekā ieejas (trīs rindiņas gkoda). Kur tad ir izslavētā atmiņas ekonomija?


 vis ir kārtībā un step signāla arhivātors strādā godam proti tai G-kodā ir asim jānoiet 34 vienības (m vai mm) kur 1 soļa atālums ir 1/100 tātad kopā jānoiet 3400 soļi un līdz ar to softs ģenerē šos 3400 soļu ātrummus, un mans arhivātora kods šo 3400 soļu ātrummus sapakoja 7561 Baitā, tas ir 2.22 baiti uz 1 motora soli, salīdzinājumam standartā vaidzētu 1+4=5 baitus (ja solis ir 32bit cipars) tātad mans kompresors strādā ar 2.25X efektivitāti (īstanībā tā ir vēl augstāka jo uz katriem 256 sakompresētiem baitiem nāk klāt 4 Datu pakas baiti. 

šajās G koda instrukcijās visu laiku bīja uzrāviens un bremzēšana, proti nevienas lineāras kustības, ja kāda Lineārā būtu ta tā tiktu saarhivēta ar pāris baitiem (simtu vietā), bet šīs uzrāviena režima vētības neatkārtojās divreiz.

jebkāds augstāka līmeņa STEp/dir signāla raksturojums kā pierakstīt piemēram paātrinājumu un distanci +sākotnēju un beigu ātrumu, no kā var izrēķināt katra soļa vērtības jau uz MCU prasa papild MCU  JAUDU, cik? es nezinu,
 bet ka uztaisīšu šito variantu ejošu ta pamēģinās uz MCU uzlikt tā formulas un apskatītes cik ta īsti tur vaig, bet jāatgādina ka ar to kodu saarhivēt izdotos tikai lineārās kustībās uzrāvienu, bet apļa kustībā, kur paātrinājums kā konstante(lineārā) ir visu laiku mainīgs, līdz ar to šis vairants salīdzinot ar tagadējo STEP/dir ātrumma kodēšanu būtu faila apjomā lielāks, un prasītu papild MCU jaudu, tākā neregulārām formām, kur visu laiku mainās paātrinājumi nav cita ceļa kā ekonomiskāk nodot komandas MCU par tagadējo formātu, kā sūtīt MCU visu bišķi apstrādātu G-kodu hex formātā, un veikt visus matemātiskos aprēķinus uz MCU un tas ir baigi grūti uzkodējam bez FPU.
tādēļ jau es saku ka vaig GB SD karti kurā varētu ielādēt  1GByte/2.2= 0.454 G soļu ātrummus, un ja 1 solis ir 0.01mm ta noejamā distance visām asīm kopā ir ~ 4.4metri  ::  (nepārtrauktā +- paātrinājuma režimā, bet ja ir kāda taisne ta tas skaits ir bezgalīgs) 
priekš šitā aprēķina vaig 8Gbit karti. 
nu šitas mans variants priekš kādām frēzēm kur frēzē kādus 3D attēlus laikam ka nederēs, bet priekš virpas detaļu virpošanai kur pārsvarā iet pa taisno + pāris ieloki būs PRĪMĀ.  ::

----------


## Vikings

Bet neesi domājis, ka, iespējams, vienkāršāk bija pārdomāt nopietnu matemātiku lai aprēķinātu parametrus reālajā laikā nekā taisīt pašam savu standartu, kas pie tam mašīnas līmenī neļauj rediģēt programmu (atšķirībā no Gkodiem)?
Vēl par enkoderiem - gan Padomjlaikā izplatītajiem optiskajiem enkoderiem, gan ārzemju Minertia motors enkoderiem visiem kanāliem ir diferenciālās izejas. Iesaku par to aizdomāties.

----------


## Epis

> Bet neesi domājis, ka, iespējams, vienkāršāk bija pārdomāt nopietnu matemātiku lai aprēķinātu parametrus reālajā laikā nekā taisīt pašam savu standartu, kas pie tam mašīnas līmenī neļauj rediģēt programmu (atšķirībā no Gkodiem)?


 Esu esu domājis, vienīgi kā jau parasti pa domāšanu tālāk ticis nēsu  :: 

tas nākošai līmenis ir rēķināt to Acceleration Step/dir uz MCU  un tur ir vaidzīga tikai 1 formula: 


```
            double T = (-Vo + Math.Sqrt((Vo * Vo) - 2 * a * (Xo - X))) / a; // T ir Laiks (sekundēs, un X (metri) V(m/s) a(m/s^2)
```

 es šodien 1 stundas laikā izmēģināju šo formulu ar  INT data tipiem (bez float) un izrādās ka lai varētu izrēķināt ar int šo ātrummu solim kurm mazākā laika vienība būtu 32Mhz (bez precizitātes zudummiem) ir vaidzīgi 64bitu INt cipari, ar 32bitiem ir pa maz un ģenerējās nepareizas vērtības, tākā nav nemaz tik vienkārši un visu atlikušo dienu mēģināju to mazo C funkciju palaist uz MCU, bet pagaidām rezultāta ārā, katkas ar to s64 data tipu, varbūt nepareizi nolasu no flash atmiņas tos ciparus ar Pointeriem, un vēl nezinu vai kvadrātsakni sqrtf(s64); vispār varēs izvilkt moš rīt uzķilēšu formulu ejošā stāvoklī un ta uzliks performance taimeri lai redzētu cik tad MCU vaig instrukciju lai ģenerētu 1 motora soļa ātrummu.

----------


## zzz

EDIT:

izlaboji "integraaljus", nu i apsveicami.

----------


## Epis

jā jā apstījos viki ir integer un integral un latviski integer neskan tāpēc automātiski nosaucu par integrāli, bīju jau sen piemirsis kas tas vispār ir, bet nu pajāt tāpat skaidrs ka lietoju int64 (tekstā kļūda izlabota)

karoči man te uz stm32 sanāca uztaisīt to 64bit matemātiku un dabūtu rezultātu ar ļoti nelielu novirzi:
stmre aprēķināja step laiku: 3695040
bet kompis ar float: 3695042 
stapība ir 2, moš šito defektu var novērst vēl palielinot ciparu reizinātājus pa 1 nulli līdz 100'000'000

----------


## Epis

Karoč izmērīju savu ātrumma aprēķināšanas algoritma ātrummu ar(72Mhz TIMeri 2) un sāku skaitīt no tās vietas kur ielādēju Flash Datu pakas Adresi, un tālāk skaitu laiku kā nolasu 32bit ciparus (4 ) no flasha un veicu to matemātisko aprēkin ar kvadrātsaknes vilkšanu un kopā viss šis process aizņēma 2254 clk   ::  
baigi daudz !! 

un tas nozīmē ka Max 1 sekundē varētu ģenerēt 30 K soļus visām asīm !! 
varētu domāt par kautkādu Fifo bufferi kādiem pāris tūkstošiem saģenerētu Soļu vērtību, lai varētu to ātrummu pacelt lielāku.

----------


## Epis

Šodien pameģināju vilkt kvadrātsani no 32bit Int skaitļa ar standart sqrtf(s32) un rezultāts bīj arī sūdīgs 724 clk cikli (baigi švaki) un domāju ka galīgi nekasnesanāk, bet ta pagoglēju un atradu kautkādus C kvadrātsaknes kodus kur izmanto Lock up table 256byte un iemēģināju un sanāca ka 32 bitus kvadrātsakni izvelk ~110clk  ::   un šitas jau ir labs ātrums.
vēl konstatēju ka tā 64bit matemātika norīj baigi daudz resursu un ir jāizdomā kā to visu izpildīt tomēr ar 32bit cipariem mēģinot samazināt precizitāti tajās vietās kur to var izdarīt, piemēram kāda jēga no augstas precizitātes lēnam griešanās ātrumma signālam kādi 5RPM kur nav jēga no 6 cipariem aiz komanta, bet ar kādiem 2 pilnīgi pietiek kā 5.15, bet no 5.1555555 jēga nav nekāda, savkārt ka ies runa par lieliem ātrummiem kā 5000RPM tad tur uzkodēt tā lai būtu Maximālā izšķirtspēja ko sniedz MCU taimeris.
ja šito sanāks uzkodēt uz tiem 32bit cipariem ar labu MCU performance ta varētu sūtīt aceleration komandas, nevis rupju Step sigālu ātrummu. un ta ar MCU iekšējo flash kādi 90KB  pietiktu normālai G-kod programmai, nevis kā tagat pāris sekundēm.

----------


## Epis

karoči nekas ar 32 bitu Integer nesanāk, jo ja samazina izšķirtspēju tad uz lieliem ātrumiem vispār ir Vāks, galīgi nav precizitātes, proti tā precizitāte tad izksatītes tādā pašā līmenī kā LTP porta CNC softiem kur step pamatfrekvence ir tie 45Khz, un ta jau nav jēga man no tā 32Mhz taimera, līdz ar to vienīgais ir vai nu 64bit Integer, vai arī 32bit float (šito vēl jakas nēsu skatījies, lai gan varētu 32bit float precizitāte pietikt, jo testējot šitos algoritmus uz visual Studijas izmantoju Double floating point).
tākā skaidrs ir ka vaig 64 bitus ta es tagat domāju kā padarīt ātrākas dalīšanas un kvadrātsakni vilkšanas matemātikas, jo piemēram 64b/32b=64b dalīšana pēc maniem testiem aizņēma 460clk (ar compiler -o3 optimizāciju)  
un algoritmā ir 1 Sqrtf() un 1 64bit dalīšana  un kopā pašlaik ar standart arm biblotekas funkcijām tas viss aprēķins aizņem 2254 clk un atsevišķi skatoites sqrtf(s64) iet ar 1110clk un 64/32 iet ar 460 līdz ar to preikš pārējās darbības izpildās pa 684clk.
man ideja ir mēģināt vilkt kvadrātsanki ar to 256B Lock up table funkciju kas labi strādā un dod samērā precīzu rezultātu līdz pat 40bit lielam ciparam, bet pēctam vaig to precizitāti pieslīpēt ar papildus operācijām kā:
   xn = (xn + 1 + x / xn) / 2;  // X= cipars no kā velk kvadrātsakni un xn = rezultāts
lai dabūtu pēdējos ciparus, bet problēma ir tur ka x/xn kur X būs 64bit cipars un ja pam 64bit dalīšana iet tik lēnu ta  tas viss algoritms ies lēnāk nekā standart sqrtf(a64) funkcija līdz ar to ir jāizdomā kā tikt vaļā no dalīšanas un izmantot piemēram Reizināšanu, kur jakas cortex-M3 procim ir 36x36=64bit reizinātāj instrukcijas:
Multiply with 64-bit result:  UMULL, SMULL, UMLAL, and SMLAL (ASM instrukcijas)
istanībā tā laikam ir vienīgā proča insturkcija ar 64bit rezultātu, tākā būs jāpamēģina uzcept algoritms kas meklēs kvadrātsaknes atlikušos ciparus ar reizināšanu un arī mēģinās 32bit dalīšanā izmantot reizinātāju, moš sanāks atrāk izdalīt nekā ar standart bibloteku, jebkurā gadījumā šitā ir pēdējā cerība aprēķināt to soļu ātrummu ātrāk par 2254 clk.

----------


## Colibris

Neesmu gan nekaads baigais programmeetaajs, bet atljaushos pafilozofeet.
Kaa buutu ja peec kvadraatsaknes izreekjinaashanas izdariitu preteejo apreekjinu, tada veidaa apreekjinot radushos kljuudu, kuru taalaak izmantot naakamo solju apreekjinos.

----------


## Epis

nu varētu 


> Neesmu gan nekaads baigais programmeetaajs, bet atljaushos pafilozofeet.
> Kaa buutu ja peec kvadraatsaknes izreekjinaashanas izdariitu preteejo apreekjinu, tada veidaa apreekjinot radushos kljuudu, kuru taalaak izmantot naakamo solju apreekjinos.


  64bit ciparu ar chift pabīdīt pa labi tik reizes lai pataisītu pa 32bit ciparu, tad no 32bit cipara izvilkt kvadrātsakni (tagat ar to Lock up table stm32 procis to izdara pa 110clk) un tad to rezultātu ar shift pabīdīt pa kreisi sākotnēji bīdītas reizes pa labi/2 un pārbaudīt rezultātu kāpinot viņu kvadrātā un salīdzināt vai rezultāts ir lielāks, vai mazāks par 64bit ciparu, un tālāk tad aprēķināt kļūdu (a-b, vai b-a) un no rezultāta laikam ir jāmēgina izvilkt kvadrātsakne un tad to pieskaitīt, vai atņemt pirmajam rezultātam un tā kamēr kļūda būs 0; 
būs kautkas šāds jāiemēģina.

----------


## Colibris

> nu varētu 
> 
> 
> 
> 
> 
> 
> Neesmu gan nekaads baigais programmeetaajs, bet atljaushos pafilozofeet.
> Kaa buutu ja peec kvadraatsaknes izreekjinaashanas izdariitu preteejo apreekjinu, tada veidaa apreekjinot radushos kljuudu, kuru taalaak izmantot naakamo solju apreekjinos.
> ...


 Pateereejamo ciklu skaita zinjaa izdeviigaaks variants vareetu buut, ka kljuudas kaut kur summeejas un kad sasniedz kaut kaadu defineetu veertiibu tad tiek izdariita attieciiga korekcija.

----------


## Vikings

Epi, ātrāk būtu nevis shiftēt pa bitam 32 reizes, bet samainīt 64 bitiem vecākos 32 bitus ar jaunākajiem 32 bitiem (parasti ir tāda instrukcija swap, nezinu kā konkrētajam procesoram) un nomaskēt vecākos 32 bitus izmantojot AND operāciju un masku 0x0000FFFF

----------


## Velko

Var pat neko neswapot, vienkārši lietot kā ir. Teiksim, izmantojot ko līdzīgu šim:


```
union words64 {
        uint64_t ui64;
        uint32_t ui32[2];
        uint16_t ui16[4];
        uint8_t   ui8[8];
};
```

 Ja kāds tankā:


```
union words64 w; //uztaisam mainīgo
w.ui64  = 0x0001020304050607; //ierakstam 64 bitu vērtību
w.ui32[0] == 0x00010203 // tiekam klāt pie zemākajiem 32 bitiem
w.ui32[1] == 0x04050607 // ... augstākajiem 32 bitiem
w.ui16[0] == 0x0001     // ... zemākajiem 16 bitiem
w.ui8[6]  == 0x06       // priekšpēdējais augstākais baits
// u.t.t.
```

 Protams, atkarībā no proča arhitektūras (little/big endian) izvietojums var atšķirties, bet princips saglabājas.

----------


## Epis

uzkodēju 32bit sqrt () bez dalītāja un protams tā lai var fiksi pārtaisīt pa 64bit versiju un reku kods lejā Epi_sqrt(s64) funkcija (756clk)
un performance vidēji ir par 25% lielāks nekā Default sqrtf()(1054clk) un funkcija ir 3x ātrāka nekā sqrt() (pāri 2000clk) uz 64 bitiem, jāatzīmē ka pagaidām tajā funkcija  ņem tikai 32bitus. 
Lai palielinātu bitu skaitu, ir vienkārši jāpieliek papildus sākumā if (x >= cipars),  fiča kura ņem to vērtību no sqq_table[] un tad vēl jāpieliek klāt Nr cipars, kurš norāda to cipara mask[] . 
 1 while() loops iziet no 42-52 clk ciklos un 32bit ciparam apmēram sanāk cilpot cauri 15-16x un tā arī sakrājās tie clk. 
un kā noskaidrojās pēc testa ta 32x32=64b reizināšana iet 14clk ciklos (tur ir 3-4 asm instrukcijas no kurām viena ir SMUL, intresanti ka procim ir asm instrukcija kas bīda uzreiz 2 32bit reģistrus, vienīgi diez vai tā ir single cycle



```
s64 Epi_sqrt(s64 x) 
{
	    static const unsigned char sqq_table[] = {
	       0,  16,  22,  27,  32,  35,  39,  42,  45,  48,  50,  53,  55,  57,
	      59,  61,  64,  65,  67,  69,  71,  73,  75,  76,  78,  80,  81,  83,
	      84,  86,  87,  89,  90,  91,  93,  94,  96,  97,  98,  99, 101, 102,
	     103, 104, 106, 107, 108, 109, 110, 112, 113, 114, 115, 116, 117, 118,
	     119, 120, 121, 122, 123, 124, 125, 126, 128, 128, 129, 130, 131, 132,
	     133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 144, 145,
	     146, 147, 148, 149, 150, 150, 151, 152, 153, 154, 155, 155, 156, 157,
	     158, 159, 160, 160, 161, 162, 163, 163, 164, 165, 166, 167, 167, 168,
	     169, 170, 170, 171, 172, 173, 173, 174, 175, 176, 176, 177, 178, 178,
	     179, 180, 181, 181, 182, 183, 183, 184, 185, 185, 186, 187, 187, 188,
	     189, 189, 190, 191, 192, 192, 193, 193, 194, 195, 195, 196, 197, 197,
	     198, 199, 199, 200, 201, 201, 202, 203, 203, 204, 204, 205, 206, 206,
	     207, 208, 208, 209, 209, 210, 211, 211, 212, 212, 213, 214, 214, 215,
	     215, 216, 217, 217, 218, 218, 219, 219, 220, 221, 221, 222, 222, 223,
	     224, 224, 225, 225, 226, 226, 227, 227, 228, 229, 229, 230, 230, 231,
	     231, 232, 232, 233, 234, 234, 235, 235, 236, 236, 237, 237, 238, 238,
	     239, 240, 240, 241, 241, 242, 242, 243, 243, 244, 244, 245, 245, 246,
	     246, 247, 247, 248, 248, 249, 249, 250, 250, 251, 251, 252, 252, 253,
	     253, 254, 254, 255
	    };

	    s32 xn;
        u32 mask[] = { 0x1,0x2,0x4,0x8,0x10,0x20,0x40,0x80,0x100,0x200,0x400 };
    u32 Nr=0;
	    if (x >= 0x10000)
	        if (x >= 0x1000000)
	            if (x >= 0x10000000)
                    {
	                if (x >= 0x40000000) 
                        {
	                    if (x >= 65535UL*65535UL)
                            {
	                        return 65535;
                            }
                            xn = sqq_table[x>>24] << 8;
                            Nr = 7; // 8 baits = 1;                        
                        } 
                    else
                        {
                            xn = sqq_table[x>>22] << 7;
                        Nr =6;
                        }
                    }
	            else
                    {
	                if (x >= 0x4000000)
                        {xn = sqq_table[x>>20] << 6;
                        Nr =5;
                        }
	                else
                        {
	                    xn = sqq_table[x>>18] << 5;
                        Nr =5;
                        }
                    }
	        else {
	            if (x >= 0x100000)
                    {
                    if (x >= 0x400000)
                        {
	                    xn = sqq_table[x>>16] << 4;
                        Nr=4;
                        }
	                else
                        {
	                    xn = sqq_table[x>>14] << 3;
                        Nr=3;
                        }
                    }
	            else
                    {
	                if (x >= 0x40000)
	                  {  xn = sqq_table[x>>12] << 2;
                      Nr =2;
                      }
	                else
	                  {  xn = sqq_table[x>>10] << 1;
                      Nr =1;
                      }
                    }
	          //  goto nr1;
	        }
	    else
	        if (x >= 0x100) {
	            if (x >= 0x1000)
	                if (x >= 0x4000)
	                    xn = (sqq_table[x>>8] >> 0) + 1;
	                else
	                    xn = (sqq_table[x>>6] >> 1) + 1;
	            else
	                if (x >= 0x400)
	                    xn = (sqq_table[x>>4] >> 2) + 1;
	                else
	                    xn = (sqq_table[x>>2] >> 3) + 1;
	          //  goto adj;
	        } else
	            return sqq_table[x] >> 4;
u32 up =0;
u32 dw =0;        
u32 end =0;
s64 m =  0 ;        //u32 m =  0 ;   
//u32 loopCounter =0;      
        while(Nr>0)
            {
       //     loopCounter++;
            m = (s64)xn*(s64)xn;

            if(m > x)
                {
                if(up ==1)
                    { // AND Not (&~)maska Nodzes Bitu (CLEAR)
                    xn = xn &~mask[Nr];                     
                    up =0; 
                    }
                else
                    {
                    Nr++;
                    xn = xn &~mask[Nr];
                    up =1;
                    }
                    dw =1;                 
                }
            else
                {
                if(dw ==1)
                    {
                 Nr--;
                xn = xn |mask[Nr]; // Set bit ar OR | mask
                    dw =0;
                    } 
               else
                    {
                     if(up ==1)
                        {
                        Nr--;                     
                        xn = xn |mask[Nr];
                        } 
                   else
                       {
                        Nr++;                    
                        xn = xn |mask[Nr];
                        dw=1;                    
                       }
                    }
                up =1;
                }
        }  
m = (s64)xn*(s64)xn; // 64 bit variants
  //  m= xn*xn; // 32bit variants
    if (m > x) /* Correct rounding if necessary */
       xn--;
    else if(m<x)
        xn++;
// Lejaa ORiginalais koda gabals kur izmanto Dalisanu lai aprekinatu atlikusas vertiibas.
	/* Run two iterations of the standard convergence formula */
/*
	    xn = (xn + 1 + x / xn) / 2;
	nr1:
	    xn = (xn + 1 + x / xn) / 2;
	adj:

	    if (xn * xn > x)  Correct rounding if necessary 
	       xn--;*/

	    return xn; 
	}
```

 Neko vairāk es pagaidmā izdomāt nevaru kā varētu to processu paātrināt, ja nu vienīgi izmantot kādu coprocessoru, piemēram kā fpga, vai DSP, es te jau biški iemetu aci atkal TI DSP čipu kitos, un tur viņiem ir tāda simpātiska Delfino c2833x serija kas iet uz 150Mhz ar single precision FPU, vienīgi problēma jau no tā mazāka nepaliek jo tur jau tam DSP procim man liekās ka fpu nav hardware divide instrukcijas līdz ar to tur kvadrātsakni un dalīšanu arī ar matemātikas biblotekām jākodē, vienīgi tur tā lieta ietu krietni ātrāk, jo šitam stm32 ejot pie 72mhz reālais MIPS ir kautkur tikai 36Mips, jo flash laīšanas ātrumms bīj  24 MHz un tas saucamais prefech buferis vels viņzin cik efektīvi tur iet, jebkurā gadījumā tos 1.2Dmips dabūt man liekās ka nevar pie 72mhz, un vispār jau visiem ARM7 čipiem reāli tiem Mips ir bišķi zem Mhz līmeņa, arī tie kas iet no RAM.
nu ar DSP programmēšanu es domāju ka neņemšos, visticamāk likšu šito kvadrātsaknes kodu un uzkodēs to aceleration un kombinācijā ar fifobufferi kautkādu ātrummu sakarīgu step signālu ātrummu varēs sasniegt (pietiktu katrai asij ar kādim 10-15ksteps ar kopējo step nolasīšanas ātrummu kādi 40kstes.

----------


## Epis

atradu vēlvienu algoritmu sqrt() aprēķiniem kas izmanto tikai schif + Add instrukcijas un compare, nekādu reizinātāju, un dalītāju, un uzliekot uz 32biti cipariem performance bīj samērā iespaidīgs  ::  proti 32 bitus aprēķināja 280clk    ::  
salīdzinoši tas ir 2.8x lēnāks nekā tas ar lockup table (100-110clk) bet krietni ātrāks (2.1x) par manu jauno Epi_sqrt( ~ 588 cikli) un 2.5x  ātrāks par ātrāko ARM matemātikas biblotekas sqrtf( 708clk). 

un pats algoritms ir baigi vienkārš reku kods:


```
/* by Jim Ulery */
	u32 julery_isqrt(u32 val) 
{
	    u32 temp, g=0, b = 0x8000, bshft = 15;
	    do {
	        if (val >= (temp = (((g << 1) + b)<<bshft--))) 
                {
	           g += b;
	           val -= temp;
                }                

            } while (b >>= 1);
	    return g;
	}
```

 algoritmu es atradu šajā linkā : 
http://www.azillionmonkeys.com/qed/sqroot.html
īstanībā tur pat laikam es atradu iepriekšējo ar look up table kas ir viss a'trākais, bet šitas algoritms tika taisīts priekš ARM kuram ir ātrs barel schifteris

domāju ka transformējot šo jauno algoritmu uz 64 bitiem performance vaidzētu būt labam, vēlāk varētu padomāt kā sakombinēt šo ar 32bit( look up table) variantu, lai pirmos 32 bitus no 64b cipara varētu dekodēt pēc super ātrā 100clk look up table algoritma un tālāk atlikušos 32 bitus dekodēt ar šo jauno, vai manējo veco rezināšanas variantu.
labi būtu ja izdotos izvilkt to kvadrātsakni zem 500clk cikiem.

----------


## Epis

būsu beidzot uzdrukāju ātāku kvadrātsaknes algoritmu, kas pēc testa velk kvadrātsakni 732clk (64 biti) un 32bitus(165clk).
algoritmā ir vēl iespējams paātrināt 64bit vilkšanu sakot pirmos if(x>=0x..) loopus ar lielāko 64 bit ciparu un tad līdz pedejam mazakajam tadejadi paātrinot lielos ciparus un paleninot mazos, tad vaidzetu būt 64 bitiem zem 700clk  ::  domāju ka šis ir iespēju maximums, un izmantoju es to pašu savu veco reizinātāj algoritmu, vienīgi es internetā atradu Optimizētāku C koda versiju, un bez erroiem(man savā bīj erros 1 rezultāta versijā)
šeit ir smuki uzrakstīts kvadrātsaknes vilkšanas algoritms ar reizinātājiem un schift


```
u32 sqrt_iterative(u32 N)
{ // lidzigs manam pirms tam algoritmam tikai uzkodets profesionalak un bez erroriem.
  u32 x,j;

  for(j= 1<<15; j>0; j>>=1)
  {
    x = x + j;
    if( x*x > N)
      x = x - j;
  }
  return(x);
}
```

 un šitas ir kompaktāks kods un strādā arī ātrāk, protams tā ir 32bit versija. un manai Ed_sqrt(u64) funkcijai stāv 64bit versija ar Nr mainīgo cipra 15 vietā, kas dinamiski pasaka kādi ir pēdējie rezultāta cipari kurus vaig rēķināt, tādejādi izpildes ātrums ir atkarīgs no cipra lielumu, jo mazāks cipars jo ātrāk izpildīs, + pirmos 32bit ciparus no 64bit cipara aprēķina ar viss ātrāko metodi (110clk) pēc pirmā algoritma un tad rezultātu attiecīgi ar schift pielabo atpakaļ uz 64 bit rezultātu un turpina ar šo reizinātāj metodi meklēt atlikušos 32bit ciparus(16bit rezultāta ciparus).

vēl varu pateikt ka ieprieksējā julery_isgrt() uz 64 bitiem izgāzās, un izrādījās ļoti lēna 1546 clk pilnam 64bit ciparam, šeit jāatzīmē ka prastā sqrt(64bit) gāja ar 1966 clk, bet standart ātrā sqrtf() gāja ar 1000clk bet rezultāts bīj neprecīzs, un kļūdaini bīj pēdējie 3 hex cipari(12biti) un tas ir ļoti neprecīzi, un reāli vaidzētu tos kļūdainos ciparus pārēķināt un tērēt papild CLK ciklus, līdz ar to julery_isgrt() iet tik pat ātri kā uzlabota ātrākā standart sqrtf() funkcija, 
un mana jaunā ar ~700clk performance reāli būs >2-3x ātrāka nekā standartnieces.

līdz ar to STEP ātruma aprēķina ātrums varētu būt ap 50Ksteps/s (700*2 clk), tīri normāls cipars  ::

----------


## jeecha

165 instrukcijas cikli uz 32bit kvadraatsakni man neliekas gluzhi kosmiski. Cik atceros no skolas tad izmantojot saskaitiishanu, atnjemshanu, izveerstus ciklus un prekalkuleetas divnieka pakaapes veertiibas to vareeja izdariit mazaak kaa 100 instrukcijaas prieksh 32 bitiem (uz I386 arhitektuuras tiesa, bet pa cik nekas vairaak par pieskaitiishanu un atnjemshanu nebija vajadziigs arii uz ARM vajadzeetu vareet iekljauties 100 instrukcijaas).

Epis, ja nezini kas ir izveersti cikli, tad paskaidroshu ar piemeeru:
for(i= 10;i>0;i++) { dosomething(i);}
vietaa var rakstiit
dosomething(10);
dosomething(9);
...
dosomething(1);

Taadeejaadi upureejot koda garumu aatrdarbiibas labad jo nav jaateeree instrukcijas cikla mainiigaa skaitiishanai, saliidzinaashanai un jumpiem uz cikla saaakumu. Shaados gadiijumos eerti lietot kompilatora makrosus, piemeeram tavu kodu paarrakstot:
u32 sqrt_iterative(u32 N)
{
  u32 x;

#define SQRT_ITER(a) \
  x= x+a; \
  if (x*x>N) x= x-a;

  SQRT_ITER(0x8000);
  SQRT_ITER(0x4000);
  ...
  SQRT_ITER(0x1);

  return(x);
}

var ietaupiit vismaz kaadas 3 instrukcijas uz katru cikla iteraaciju (shiftoshana, cikla mainiigais). Tas gan taapat nav aatraakais algoritms.

P.S. Es gan ar koda aatrdarbiibas optimizaaciju saaktu nodarboties tad kad vispaariigos vilcienos viss buutu straadaajoshs. Shaadi iecikleejoties un teereejot laiku uz siikaam detaljaam var sanaakt ka arii peec gada tev kopumaa nekas nestraadaas, toties kvadraatsakni vilks mezhoniigaa aatrumaa  ::

----------


## Epis

citus kvadrātsaknes algoritmus es vairs nemeklēšu. Kodēšu tālāk to savu sarežģītāko variantu, nekā ierpiekēšjais,  un izdomās interfeisu kā sūtīt tās paātrināuma komandas un ejamo soļu skaitu + jaatrisina pozitīvā, negatīvā ātrumma ciparu uzvedība aprēķinā (šitas uz  64bit int vēl nav testēts uz float vis skaisti rēķinaš bez nekādiem speciāliem scenārijiem kodā).




> 165 instrukcijas cikli uz 32bit kvadraatsakni man neliekas gluzhi kosmiski. Cik atceros no skolas tad izmantojot saskaitiishanu, atnjemshanu, izveerstus ciklus un prekalkuleetas divnieka pakaapes veertiibas to vareeja izdariit mazaak kaa 100 instrukcijaas prieksh 32 bitiem (uz I386 arhitektuuras tiesa, bet pa cik nekas vairaak par pieskaitiishanu un atnjemshanu nebija vajadziigs arii uz ARM vajadzeetu vareet iekljauties 100 instrukcijaas).


 ar to ātruma mērvienību ir tā ka tie ir 72mhz taimera mērijumi,pa tiešo, jeb laika vienība 13.88ns no kuriem vaidzētu atņemt paša taimera nolašišanas laiku 12clk 
un ta reāli sanāk ka 1 asm instukcija izpildās 2 vai 3 clk, jo katru reizi ka nolasa instrukciju,informāciju no flash tiek likti 2 (nop)(pauzes) un tas ir sevišķi jūtams ja kodā ir daudz šādu branch loopu, jo ta tas flash prefech bufferis laikam ka īsti labi nestrādā rezultātā tas ātrums ir 0.5-0.4Mips/Mhz reklamēto 1.2Mips vietā, protams ka ja nolaistu clk ātrumu uz tiem 24mhz bez neviena flash waite cikla ta būtu virs 1Mips/Mhz un ta varētu salīdzināt taimera noietos clk ciklus ar proča veikto insturkciju skaitu 1:1 vairums gadījumos.




> u32 sqrt_iterative(u32 N)
> {
> u32 x;
> 
> #define SQRT_ITER(a) \
> x= x+a; \
> if (x*x>N) x= x-a;
> 
> SQRT_ITER(0x8000);
> ...


 man liekās ka šis kods īsti neder, jo tur tās funkcijas:  SQRT_ITER(0x8000); ir fikslēta skaita, kas nozīmē ka 64 bit ciparam būs vaidzīgas 32 tādas funkcijas, ja kombinē ar ātro look up table variantu ta uz pusi mazāk 16, atšķirība starp manu algorimu ir tāda ka mans algoritmam šo funkciju skatis (ciklu skaits) mainās atkarībā cik liels ir cipars, proti ja cipars ir 40bit liels ta sanāks ka vaig papildus tikai 4 šīs funkcijas ciklus, jo pirmos 32bitus aprekina pēc ātrās metodes, un atlikušiem 8 vaig 4 ciklus finālā ir tā ka mana formula jebkurā gadījumā ies ātrāk reālā dzīves pielietojumā nekā tava fiksētā lieluma versija, jo reāli tie kvadrātsaknes velkamie cipari pirmajiem soļiem ir 32biti un tālāk palielinoties soļa lielumam, motora ātrummam tas cipars aug lielāks un lielāks un kad paiet kāda 1 sekunde cipars jau ir virs 56 bitiem un tā līdz sasniedz 64 galējo robežu un ta viss uzkarās  :: .
un lai neuzkārtos būs kompja softā jāraksta programma kas pārbaudīs algoritma min, un max vērtības vai viņas gadījumā nepārsniedz aprēķinā 64bitus, ja pārsniegs ta izmetīs erroru, ka paātrinājums ir pa lielu, vai gala ātrums ir pa lielu

----------


## Epis

vēlreiz uzrakstīšu detalizētāk:

sqrtf( u64) //   0x67dfed44  rez = 0xa312 laiks 950 clk
sqrtf( u64) //  0x67f22fd8ac385616; rez = 0xA3205500  966 CLK (rezultāts neprecīzs)
sqrt( u64) //   0x67dfed44  rez = 0xa312 laiks 1950 clk
sqrt( u64) //  0x67f22fd8ac385616; rez = 0xA320549F  1950 CLK

Ed_sqrt(U64) //   0x67dfed44  rez = 0xa312 laiks  162  clk   1950/162 = 12 X ātrāk
Ed_sqrt(U64)  //  0x67f22fd8ac385616; rez = 0xA320549F  732 CLK        2.6X ātrāk

visur optimizācijas līmenis -03;

nu ir ievērojams progress no 2.6-12X paātrinājums   ::

----------


## jeecha

Nedaudz parakaajos gadiem vecaa kodaa, atradaas sekojoshs:


```
uint64_t sqrt64(uint64_t x)
{
    #define SQRT64_ITER(a) \
        t= r+(1ULL<<(a)); \
        if (x>=t<<(a)) { \
          x-= t<<(a); \
          r|= 2ULL<<(a); \
        }
    uint64_t r= 0, t;
    SQRT64_ITER(31); SQRT64_ITER(30); SQRT64_ITER(29); SQRT64_ITER(28);
    SQRT64_ITER(27); SQRT64_ITER(26); SQRT64_ITER(25); SQRT64_ITER(24);
    SQRT64_ITER(23); SQRT64_ITER(22); SQRT64_ITER(21); SQRT64_ITER(20);
    SQRT64_ITER(19); SQRT64_ITER(18); SQRT64_ITER(17); SQRT64_ITER(16);
    SQRT64_ITER(15); SQRT64_ITER(14); SQRT64_ITER(13); SQRT64_ITER(12);
    SQRT64_ITER(11); SQRT64_ITER(10); SQRT64_ITER(9); SQRT64_ITER(8);
    SQRT64_ITER(7); SQRT64_ITER(6); SQRT64_ITER(5); SQRT64_ITER(4);
    SQRT64_ITER(3); SQRT64_ITER(2); SQRT64_ITER(1); SQRT64_ITER(0);
    return(r>>1);
}
```

 Ar -O3 uz ARM tam vajadzeetu buut juutami aatraakam nekaa tava reizinaashanas metodei. Ja baigi gribas pontot var izrulleeto ciklu sadaliit teiksim 4 blokos (pa 16 biti) un saakumaa paskatiities ievaddatiem bitus un noskipot nevajadziigos blokus ieekonomeejot kaudzeem ciklu ja izejas datiem ziimiigi bija tikai jaunaakie 16/32/48 biti. Shii koda 32bit versija visdriizaak saliktu tavu 32bit versiju vienos vaartos (vari pameegjinaat un ieposteet rezultaatus kaadi tev sanaak uz tava kontroliera, tiiri taa intereses peec). Tiesa es neapgalvoju ka shis ir pats labaakais, gan jau ka var atrast arii kaadu tieshi ARM optomizeetu asamblera koda gabalu. Starp citu izrulleeti cikli (kaa manos piemeeros) kaareiz ljoti paliidz procesora cache jo nekaadiigi nevar sanaakt "cache miss" un arii vajadzeetu labaak veikties ar tevis mineeto "flash prefetch". Kaut arii ARM arhitektuuraa esmu pilniigs diletants, kaadeelj tu shito kodu saakumaa nesagaaz RAMaa un neizpildi no turienes?

----------


## Epis

tavam jecha kodam rezultāts ir tīri labs:
no 582clk - 640clk atkarībā no cipariem un to lieluma:
vidēji 1 loops izpildās 17.5 clk 

manējam kodam es izmērīju if(x>=0x400) loopu laiku un 1 loops paņem 5.2 clk līdz ar to pilnam 64 bit ciparam jāiet caur 20 loopiem un tas paņem 108clk un tas nozīmē ka ja es apgrieztu vietām loopošanas secību ka lielākos ciparus pārbauda pirmos ta manam 708clk kodam var ņemt nost 103clk un iegūtu ~605clk max laiku un minimālo kādus 200-250clk  līdz ar to mans kods sanāks tomēr ātrāks  :: .
iespējams ja ieliktu jechas kodu mana reizinātāj koda vietā ta varbūt varētu palīst zem "maģiskā" 500clk cipara  ::  būs jāpamēģina.

ar to proča ātrumu ir tā ka tikai tās branch instrukcijas paņem 3 clk ciklus pie režima ka flash nolasišanā starpā liek 2 wait ciklus (kopā paiet 3) un tad visas pārējās instrukcijas (vairums) iet ar prognozēto ātrummu 1-2 ciklā.

----------


## Epis

man liekās ka jeecha tavs algoritms nevar pabeigt jau pusizvilktu kvadrātsaknes rezultātu, vismaz es neredzu iespēju ievieto tajā kodā šo pusvilkto rezultātu tā lai viņu pabeigtu, moš vaig kādu īpašu pirms kodējumu ? 
pašlaik izskatās ka ar to algoritmu ir tā vainu velk visu 64bit ciparu vai nevelks neko  ::  
līdz ar to manējā pašreizējā  algoritmu kombinācija vinnē performance testā  ::

----------


## Epis

Jauns Square root 64bit pina cipara Vilkšanas REKORDS 364 clk  ::   ::  

rekors tika panākts uzlabojot savējo veco saknes vilkšanas algoritmu ar 36*36=64b reizināšanu, bet kodu optimizējot ar tām "macro funkcijām" ka tas ir redzams jeecha kodā vienīgi viņa kods gan uz 32bitiem, gan 64 bitiem izrādās ir krietni lēnāks nekā mans Makdro funkciju optimizētais  ::  
šeit ir mana kods pamat kodos, jeb 32bit kvadrātsaknes vilkšanas kods, kas izvelk ciparu 108 ciklos   ::  


```
u32 square32( u32 xn)
{
#define E32_sqrt(j) \
    x = x + j;  \
    if( x*x > xn) \
      x = x - j;     \
    
      u32 x,j;
     E32_sqrt(0x8000); E32_sqrt(0x4000); E32_sqrt(0x2000);   E32_sqrt(0x1000);    
    E32_sqrt(0x800);     E32_sqrt(0x400);     E32_sqrt(0x200);   E32_sqrt(0x100);  //8 funkcija 
    E32_sqrt(0x80); E32_sqrt(0x40);E32_sqrt(0x20);E32_sqrt(0x10);
    E32_sqrt(0x8); E32_sqrt(0x4); E32_sqrt(0x2); E32_sqrt(0x1);  //16 funkcija 
return x;    
}
```

 un ir tā ka ja šito kodu transformē pa taisno uz 64 bitiem ta performance ir tikai bisķi labāks par jeechas kodu proti no 520-634 clk (jechas versija 582-640)
bet mana koda unikalitāte ir tā ka es ar savu  kodu varu pabeigt vilkt jau iepriekš izvilktu zemas precizitātes kvadrātsaknes rezultātu, un tādejādi es ar super ātru 32 bit versiju izvelku cipara augsējos 32 bitus, iegūstu 16b rezultātu tad to rezultātu   rez = x<<16  un pabeidzu jau atikušos 16 rezultāta bitus ar 64 bit analogu kvadrātsaknes vilkšanas algoritmu kuram velku tikai pēdējos 16 rezultāta bitus (jo pirmie 16 jau ir izvilkti),
skaistums ir tāds ka es varu sākumā noteikt kvadrātsaknes cipara lielumu, ja tas ir 32 biti izmantot ātro variantu, ja starp 64-32 ta caur if pieprecizēt lielumu ik pa 4 bitu intervāliem un samazināt ar 64bit velkošo bitu skaitu tādejādi cipara vilkšanas ātrums būs peldoš atkarībā no velkamā cipara lieluma apmēram no ~150-376 clk 
karoči šitas man liekās ka ir ātruma TOP līmeņa algoritmu kombinācija un diez vai ir kautkas labāks  ::  priekš stm32 proča ejot uz 72mhz.

----------


## Epis

nu ko reku ir mans Magiskais kvadratsaknes kods, tur ir 2 funkcijas viena no tam ir papild 32 bit vilsanas funkcija un otra ir ista 64 bit 
ir izmeginatas 64bit ar pilniem 32bit un 64 bit cipariem kombinacijas, bet vaidzētu vēl iztestet 36,40,44,48,52,56,60 ciparu kombenes lai parliecinatos ka rezulti ir precizi.


```
//  fastest SQUARE ROOT function:
u32 square32( u32 xn)
{
#define E32_sqrt(j) \
    x = x + j;  \
    if( x*x > xn) \
      x = x - j;     \
    
      u32 x,j;
     E32_sqrt(0x8000); E32_sqrt(0x4000); E32_sqrt(0x2000);   E32_sqrt(0x1000);    
    E32_sqrt(0x800);     E32_sqrt(0x400);     E32_sqrt(0x200);   E32_sqrt(0x100);  //8 funkcija 
    E32_sqrt(0x80); E32_sqrt(0x40);E32_sqrt(0x20);E32_sqrt(0x10);
    E32_sqrt(0x8); E32_sqrt(0x4); E32_sqrt(0x2); E32_sqrt(0x1);  //16 funkcija 
return x;    
}

// typedef unsigned long long u64;  // Ja compilers nennem u64 ciparu ta nodefinee vinu sadi.

u32 E_Advanced_sqrt(u64 N)
{ // sis ir viss atrakais kvadratsaknes vilksanas algoritms kas izmanto rezultata meklesanu ar testesanas palidzibu.
// taka kvadratsaknes rezultats no binara skaitla (32bit) pec lieluma ir tiesi puse 16 biti tad algoritms sak meklet 16 bita vertibu
// viekarsi ieliekot taja 1, un sareizinot rezultatu ko salidzina ar Skaitli, ja skaitlis ir lielaks ta tas nozime ka jamekle talak liekot 
//nakoso mazako bitu 1, ja mazaks ta bitu nonulle un atkarto ieprieksejas darbibas bet jau ar nakosso mazako bitu (15) 
// tiek izmantotas + * operacijas, un lai paatrinatu izpildes atrumu ta 64 bit ciparam pirmos vertibas 32 bitus dekode ar 32 bit
// kvadratsaknes vilksanas funkciju square32( u32 xn), kas ir lloti atra,
//un atlikusos bitus mekle ar lenaku 64 bit identisku funkciju E_sqrt(j) 
// performance ir svarstigs atkariba no bitu lieluma un tas ir no 186-374 clk pie 72Mhz clk un Flash wait 2.
#define E_sqrt(j) \
   { x = x + j;  \
    if( (u64)x*(u64)x > N) \
     { x = x - j;  } }  \

 u32 Nr,nr32, x,j, Xn;  
 if (N != 0xffffffffffffffff)//64 biti
    {
    if(N< 0x1000000000000000) //60 biti
        {
        if(N< 0x100000000000000) //56 biti
            {
            if(N< 0x10000000000000) //52 biti
                {
                if(N< 0x1000000000000) //48 biti
                    {
                    if(N< 0x100000000000) //44 biti
                        {
                        if(N< 0x10000000000) //40 biti
                            {
                            if(N<0x1000000000) //36 biti
                                {
                                if(N<0x100000000) //32 biti
                                    {
                                   // Xn = (u32)N;  Atlikusos 32 bitus velk ar parasto kvadratsakni.
                                    x = square32((u32)N); //Xn); 
                                    goto end;     
                                    }
                                else
                                    {
                                    Xn = (u32)(N>>(u64)4);    
                                    Xn = square32(Xn);
                                    x = (Xn<<2);
                                    goto fnr1;            
                                     }                      
                                }
                            else
                                {
                                Xn = (u32)(N>>(u64)8);    
                                Xn = square32(Xn);
                                x = (Xn<<4);
                                goto fnr3;              
                                }
                            }
                        else
                            {
                            Xn = (u32)(N>>(u64)12);    
                            Xn = square32(Xn);
                            x = (Xn<<6);
                            goto fnr5;            
                             }                        
                        }
                    else
                        {
                        Xn = (u32)(N>>(u64)16);    
                        Xn = square32(Xn);
                        x = (Xn<<8);
                        goto fnr7;              
                        }
                    }
                else
                    {
                    Xn = (u32)(N>>(u64)20);    
                    Xn = square32(Xn);
                    x = (Xn<<10);
                    goto fnr9;            
                     }
                }
            else
                {
                Xn = (u32)(N>>(u64)24);    
                Xn = square32(Xn);
                x = (Xn<<12);
                goto fnr11;              
                }
            }
        else
            {
            Xn = (u32)(N>>(u64)28);    
            Xn = square32(Xn);
            x = (Xn<<14);
            goto fnr13;            
             }            
        }
    else
        {
        Xn = (u32)(N>>(u64)32);
        Xn = square32(Xn);
        x = (Xn<<16); // schift pa 16.
        goto fnr15; 
        }
    }
else
    {
    goto end;
    }
fnr15:
    E_sqrt(0x8000);   E_sqrt(0x4000); 
fnr13:
     E_sqrt(0x2000);  E_sqrt(0x1000);   
fnr11:
    E_sqrt(0x800);    E_sqrt(0x400);    
fnr9:
     E_sqrt(0x200);   E_sqrt(0x100);  //8 funkcija 
fnr7:
    E_sqrt(0x80);     E_sqrt(0x40);
fnr5:
    E_sqrt(0x20);     E_sqrt(0x10);
fnr3:
    E_sqrt(0x8);      E_sqrt(0x4);
fnr1:
    E_sqrt(0x2);      E_sqrt(0x1);  //16 funkcija
   end:
  return(x);
}
```

 ietestetais performance  ~(186 ; 374)-12 clk

----------


## jeecha

Nedaudz papeetiiju shodien garlaikojoties ARM instrukciju setu un vispaar par Cortex-M3 cori. Secinaajums - viennoziimiigi var aatraak nekaa tavs kods.

1) Shaads kods ir saakumaa jaaiemet RAMaa nevis jaaizpilda no flash (paanalizeejot sapratu ka shis kaareiz ir iemesls kaadeelj tava reizinaashana tikai nedaudz atpaliek no algoritmiem kas tikai shifto un saskaita - reizinaashana notiek relatiivi leeni {5 cikli minimums tevis lietotajam mcu ja nejaucu}, bet pa cik lielaakaa dalja laika taapat aiziet fetchojot no flash tad tie 5 cikli no kopeejaa laika ir saliidzinoshi maz);
2) Jaapaskataas ko tad kompilators sagjeneree jo uz ARM shiftoshana kaareiz ir ljoti leeta lieta - jo shiftot un roteet var katraa instrukcijaa un nav speciaalas shiftoshanas instrukcijas. Piemeeram 32b saknes vilkshanu vajadzeetu vareet uztaisiit 3-4 instrukcijaas uz iteraaciju (kas noziimee kaadas 55-65 instrukcijas kopaa, saliidzinaajumaa algoritms ar reizinaashanu uz vienu reizinaashanu vien zaudee vismaz 5 taktis, piemetot klaat saliidzinaashanu un jumpu - 7 instrukcijas, taatad aptuveni 2x leenaak). Savukaart 64 bitu pilnajaa gadiijumaa vienu iteraaciju ar shiftiem vajadzeetu vareet iespiest 6-7 instrukcijaas - respektiivi nedaudz virs 200 taktiim kopaa;
3) Arii manis mineetajam shiftoshanas algoritmam (tas nekaadaa gadiijumaa nav mans izgudrojums, visi shie algoritmi ir veci kaa pasaule un ne es, ne tu neko jaunu shajaa jomaa nekad neizgudrosim) var vecaakos 32 bitus reekjinaat ar 32bitu algoritmu un atlikushos ar 64bitu algoritmu, taadeejaadi sliktaakajaa gadiijumaa pilniem 64bitiem pateereejot kaadus 60+100=160 tikshkjus (kas gan nav baigais ieguvums saliidzinot ar pilnu 64bitu ciklu). Ja tu nesaproti kaa vinjaa to realizeet tad aciimredzot neesi iisti sapratis kaa vinsh darbojas un kaa little-endian procesoraa tiek glabaati skaitlji. Taapat gadiijumam ja ziimiigi ir tikai jaunaakie 32 biti tad lietot tikai un vieniigi 32bitu algoritmu (kuru kaa jau mineeju manupraat var realizeet 55-65 taktiis).

----------


## jeecha

Kautgan, laikam tomeer buushu kljuudiijies - uz Cortex-M3 32b reizinaashana tomeer arii ir 1 taktii taapat kaa uz ARM7-M. Liidz ar to ar reizinaashanu 32bitiem sanaak 4 taktis uz bitu.

Intereses peec uzliku gnuarm un paskatiijos kas tad iisti gcc sanaak dazhaados gadiijumos.
Ar reizinaashanu katra iteraacija sanaak shaada:


```
	add	r2, r2, #32768
	mul	r3, r2, r2
	cmp	r3, r0
	movhi	r2, r2
```

 Ar manis mineeto shiftoshanu savukaart shaadi:


```
	add	r3, r2, #2048
	mov	r3, r3, asl #11
	cmp	r0, r3
	orrcs	r2, r2, #4096
	rsbcs	r0, r3, r0
```

 Kautgan tas mov ar shiftu ir aizdomiigs un lieks jo to pashu vareetu panaakt lietojot shiftu ieksh cmp un rsb (rsb gan tad ir jaaaizstaaj ar sub kam argumenti otraadaa seciibaa jo shiftot vaig r3 nevis r0).

64 bitu gadiijumaa gan gcc briesmiigu kodu sagjeneree - to droshvien vajadzeetu rakstiit asambleraa.

P.S. Bet pag,  vai tad tavaa platee blakus negarlaikojas fpga? Uzraksti tajaa 64bitu kvadraatsaknes vilceeju  ::  Ja ne vienaa taktii tad vienam bitam jau nu toch var vienaa taktiim, itogo 32 taktis kopaa ;D

----------


## Epis

4 dienas internets nebīj  ::  
šitos cortex-m3 proča asm instukcij laikus var skatītes Cortex™-M3 Revision: r1p1 Technical Reference Manual 
http://infocenter.arm.com/help/index.js ... index.html
un reizināšan ir 1clk ciklā ar 32bit rezultātu bet ar 64bit rezultātu vaig 2 ciklus, un tā shiftošana 64bit gadījumā noteikti ka arī prasītu kādu papild ciklu




> P.S. Bet pag, vai tad tavaa platee blakus negarlaikojas fpga? Uzraksti tajaa 64bitu kvadraatsaknes vilceeju  Ja ne vienaa taktii tad vienam bitam jau nu toch var vienaa taktiim, itogo 32 taktis kopaa ;D


 Lieta tāda ka nejau 64bit kvadrātsakne vien ir tā lielākā problēma, reāli bez kvadrātsaknes galvassāpes rada arī 64bit dalīšana, kura standartā tiek vaikta ap 1000 ciklos, un papētot šo lietu secināju ka dalīšanu veikšu ar līdzīga tipa algoritmu proti vienīgais kas mainās ir if( a*b >c) kur a ir rezultāts b ir dalītāja cipars un c protams ir pats cipars ko dala, vecajā kvadrātsaknes variantā bīj if(a*a>c).
vēl atšķirība ir tajā kā meklē rezultāta bitu lielumu, proti ir tā ka cipara bitu skaits- dalītāja bitu skatis= rezultāta bitu skaits piemēram,
 a(32biti)/b(12biti)=c(20biti)
un principā sanāk ka ir gan a gan b jānosaka bitu skaits, un pēctam var meklēt ar šo reizināšanas algoritmu rezultātu, un tākā algoritmā jādala ir ar "a"(acceleration) kas principā ir visu laiku katrai asij konstants lielums, katrā G-koda komandā tad šo bitu skaita lielumu noteiks tikai vienu reizi katrai komandai un parejās tad ies pa ātro, un savkārt dalāmajam ciparam var to meklēšanas algoritmu arī pieslīpēt proti sākot meklēt +-1 ņemot par pamatu vecā katras ass aprēkina ciparu un tad nākošais kā parasti ir ļoti tuvu ciparam, līd ar to meklēšanas algoritms ciparu lielumiem būs samērā ātrs un  paņems maz resursu + ja cipars lielāks par 32 bitiem ta daram kā ar kvadrātsakni kur shifto ciparu pa labi izdara 32bit / a un rezultātu shifto atpakaļ pa reikisi un atlikušos bitus mkelē ar reizināšanas metodi.
pagaidām man ir pusfabrikāta stadījā (viens veiksmīgs tests, bet softs ar -o3 optimizēja kodu un izlaida dažas operācijas, tākā jāpārtaisa tests kur nevar neko nogriezt).

vēl es te uzmetu apļa interpolātor, jeb kordināšu meklēšanas algoritmu pēc standart r^2= x^2+Y^2 formulas kur y= sqrt(r^2-X^2) un līdzīga stilla +- meklēšanas metodes kur nevelk kvadrātsakni bet tikai reizina un skatās lielāks vai mazāks, bet šeit ir baigais čakars ar polaritātēm un virzieniem (pa,pret pulksteni) tākā vēl nav visi varianti iekodēti (tas ir epiCNC softam)

----------


## Vikings

> (acceleration) kas principā ir visu laiku katrai asij konstants lielums


 Negribu piekrist. Gadijumā kad dažādu asu iespējamais paātrinājums ir dažāds un, piemēram, no koordinātas X0Y0 tiek veikta komanda G0X100Y100 asij ar lielāko paātrinājumu būs jāpielāgojas asij kura savu ātrumu spēj uzņemt lēnāk.

----------


## Epis

> Epis wroteacceleration) kas principā ir visu laiku katrai asij konstants lielums
> 
> Negribu piekrist. Gadijumā kad dažādu asu iespējamais paātrinājums ir dažāds un, piemēram, no koordinātas X0Y0 tiek veikta komanda G0X100Y100 asij ar lielāko paātrinājumu būs jāpielāgojas asij kura savu ātrumu spēj uzņemt lēnāk.


 nu viss ir pareizi pateikt tikai esi izlaidis tālāko tekstu kur paskaidro šo scenāriju ka tas ir katrai G komandai.
vispār pašam pārlasot bīj grūti sapras nākošreiz rakstīšu saprotamāk.



> un tākā algoritmā jādala ir ar "a"(acceleration) kas principā ir visu laiku katrai asij konstants lielums, katrā G-koda komandā tad šo bitu skaita lielumu noteiks tikai vienu reizi katrai komandai un parejās tad ies pa ātro,


 varu vēl piebilst pa to iepriekšejo jautājumu: 



> P.S. Bet pag, vai tad tavaa platee blakus negarlaikojas fpga? Uzraksti tajaa 64bitu kvadraatsaknes vilceeju  Ja ne vienaa taktii tad vienam bitam jau nu toch var vienaa taktiim, itogo 32 taktis kopaa ;D


 šitam primer kitam blakus nekādu fpga nav un tai manai platei tur protams ka ir gan fpga, gan stm32 procis, bet skatoties reāli ja es tagat sākšu uz fpga kautkādus šādus hardware acelerātorus likt ta līdz kādam ejošam dzelzim paies vēl kāds gadiņš   :: , 
Tagat kodējot es vados pēc citiem principiem nekā toreiz ka domāju kodēt un izmantot fpga, proti tagat es mēģinu tos visus algoritmus uzkodēt augstā līmeņa valodā ar C, C# un uzrakstīt gan kompja softa C# progu, gan arī MCU C programmu tā lai kautkas kustās un strādā, un tad vēlāk skatīsies kuri posmi ir viss bremzīgākie, un kādas ir reālās MCU jaudas nepieciešamības lai realizētu uzrakstīto C kodu attiecīgā performance līmenī.
un ir jāsprot vienkārša sakarība, jo augstāks signālu gēnerēšanas ātrums, un sūtāmo signāl komandu blīvumam (blīvākais ir tīrs g-kods) jo vairāk MCU, vai DSP jaudas vaig, pagaidām es optimizējot šos te  64bit kvarātsaknes un Dalītāj algoritmus redzu ka MCU varētu normāli pavilkt tikai  paātrinājuma un soļa laika formāta komandas, kas nosedz pilnībā Lineāras kustības, standart G1 komandu.
Visām pārējām G kustības komandām sūtāmais datu apjoms dramatiski pieaug (līdz tiem Gb atmiņas līmeņiem)
un tās ir aplis, spline, un citas geometriskās figuras.
un paņemsim piemēram apli, kuru es tagat pētu un tur ir tā ka ejot pa riņķa līniju X,Y plaknē katrā kordinātē teorētiski mainās X,Y paātrinājumi, un protams ka ātrummi, līdz ar to lai šādām apļa kordinātēm uzģenerētu Step signālu ir jāveic katram solim pilna lineārā soļa aprēķina procedūra,funkcija, un lai to izdarītu ir jārēķina desmitiem formullas ar 64 bitiem, kur vairumā iekšā ir 64bit dalīšana un pāris kvadrātsaknea,  tas nozīmē ka DSP jauda kas vaidzīga lai tam aplim aprēkinātu 1 step soļa ātrumma ir 4-5x lielāka nekā aprēķināt šo step soli no Lineāra paātrinājuma. 
lai realizētu šādu apļa interpolāciju nav cita ceļa kā vai nu izmantot vēlvienu MCU, vai DSP proci, vai arī lielu RAM fifo bufferi kur saietu apmēram 2-3sekundes

pēdējās dienās saprotot kādu DSP jaudu vaig lai veiktu apļa interpolāciju fiksi apstījos kādi tad ir un cik maksā tie DSP proči, un reāli ir 2 varianti vai nu 
TMS320F28335 TI delfino 150Mhz jaunie čipi, un konkrēti viņu ControlCard pa 70$,
 vai arī Xmos XS1-G2 -15$ kuram ir 2 kodoli ar kodpējo jaudu 800Mips un xmos procim ir 32+32=64bit Lmul un zīmigi ka ir 64b/32b=32b Ldiv instrukcija, tas dalītājs ir tikai revision B čipiem līdz ar to vienkodol čipam dalītāja nav.

vispār ja salīdzina tos TI MCU ātros čipus ar xmos, labāks liekās xmos, jo viņam ir viss softs pa brīvu, integrēts hardware 64b dalītājs, domāju ka 64bit rezultāta reizinātāji ir abiem, un reāli peldošie punktu matemātika nav vaidzīga jo ar fiksēto punktu 64 bitiem pilnīgi pietiek un paliek vēl rezerve.
mīnus xmos ir tāds ka viņu programmas ir jaunas kas nozīmē visādus errorus, bugus.
vēl mīnus šiem ātrajiem čipiem gan TI, gan xmos ir tas ka viņiem vaig 2 voltu līmeņus, sarežģitāku PCB kas to plati padara vismaz 2-3x dārgāku nekā analogai cortex_m3 platei, un tas pats ir ar fpga uz plates, tā arī ar visu barošanas , konfigurācijas mehānismu uzsit cenu pasmagi nekā tas ir plikai MCU, 
līdz ar to ja grib kautko ekstra lētu, ta jāņem MCU.

kā papild MCU priekš šo smago matemātiku varētu paņemt tagdējo TI Lm3s601 kas ir lētākais 50mip cortex-m3 procis, stm32 lētākie ir ap 2x dārgāki, jo tur ir adc,krutāki taimeri, un lielāki Mhz bet stellaris čipam ir ātrāks flash kas iet ar 0 wait staite pie tiem 50Mhz kas ir bonus branch instrukcijās  ::  un šis ir pliks procis bez navarotiem, tas kas būtu vaidzīgs, priekš matemātiskās jaudas palielināšanas, pa lēto.

karoči apļa interpolāciju es pagaidām netaisīšu, jo kā paši redzat tas ir baigi smagi realizējams uz MCU.

----------


## Epis

Palaidu pirmo visa step signāla aprēķina algoritmu sākot no ciparu nolasīšanas no Flash atmiņas (Xo,Vo,x,A) un beidzot ar Step laika vertības ierakstīšanu ENC1.CNCstepSpeedBuffer[] laukā un taisīju 2 testus kur A = 15'000'000 = 1.5m/s (abos variatnos vienāds, 
pirmajā Reālā dzīves scenārijā kur X=100, jeb 0.01mm rezultāts  pie 32Mhz clk step speed = 116846 un MCU izrēķināja 652 clk   ::    (esu ļoti apmierināts ).
otrs tests ar lielāku X vērtību x= 100'000 jeb 10cm rezultāts 3695040 pareizību nezinu jo nēsu softā pārbaudījis, bet MCU izrēkināja 848clk  ::  (arī labi). 
vispār vaidzēja 32Mhz vietā ielikt 36Mhz, jo 72/2=36 to sīkumu pielabos.

tas nozīmē ka procis varēs ģenerēt virs 72K steps/s ar nelielu fifo bufferi tas būs virs 100Ksteps/s /3asis= 33K stepi gandrīz kā LTp porta CNC progas  :: .
vienīgā atšķirībā starp ltp portu un manu MCu ir step signāla frekvencē kur man tā būs 36mhz bet tur tikai 45khz.

grūti būtu iedomāties cik daudz laika prasītu kautko tādu, tādā precizitātē, izrēķināt uz 8bit PIC vai AVR , man liekās ka tur laiks būtu mērāms nevis 1000 be gan 10'000 clk ciklos  ::

----------


## Epis

> un paņemsim piemēram apli, kuru es tagat pētu un tur ir tā ka ejot pa riņķa līniju X,Y plaknē katrā kordinātē teorētiski mainās X,Y paātrinājumi, un protams ka ātrummi, līdz ar to lai šādām apļa kordinātēm uzģenerētu Step signālu ir jāveic katram solim pilna lineārā soļa aprēķina procedūra,funkcija, un lai to izdarītu ir jārēķina desmitiem formullas ar 64 bitiem, kur vairumā iekšā ir 64bit dalīšana un pāris kvadrātsaknea, tas nozīmē ka DSP jauda kas vaidzīga lai tam aplim aprēkinātu 1 step soļa ātrumma ir 4-5x lielāka nekā aprēķināt šo step soli no Lineāra paātrinājuma.
> lai realizētu šādu apļa interpolāciju nav cita ceļa kā vai nu izmantot vēlvienu MCU, vai DSP proci, vai arī lielu RAM fifo bufferi kur saietu apmēram 2-3sekundes


 šiten būšu bišķi pārspīlējis ar to apļa interpolācijai nepieciešamo papild 4-5x DSP jaunu, jo vakar skatoties apļa kustības formullu konstatēju ka ķermenis pa apli iet ar konstantu paātrinājumu(biju šito piemirsis)  līdz ar to apļa kustības kordinātēm soļa laiku aprēķināt būs samērā vienkārši, nebūs jāiet cauri visai lineārāi interpolācijai kā bīju domājis, bet tikai jānosaka step signāls ar aceleration režima forullu tākā koda ātrdarbība varētu būt bišķi zemāka nekā aceleration režīmam, ap 1000 clk.

tākā es tagat likšu klāt apļa interpolāciju, jo reāli bez viņas nevar, jo parati sarežītākas geometriskās formas var izeksportēt gan kā mazus līniju segmentus, gan arī kā līniju+ apļu segmentus, un g-koda faila lielums šādam apļa+līniju g-koda failam būs tūkstošiem reižu mazāks nekā izmantotjot tikai līnijas (tad apli būs jāiet arhivētā Step/dir režimā un ta vaig Gb flash atmiņu, tākā gribi vai negribi apli vaig  ::  )

----------


## Vikings

> ķermenis pa apli iet ar konstantu paātrinājumu


 Vai nu es atkal neko nesaprotu, vai man liekas, ka zīmējot apli, asis nepārtraukti maina savu ātrumu pie tam nevis lineāri, bet pēc sin un  cos funkcijām. Instruments, jā, tas gan pārvietojas ar lineāru ātrumu.

----------


## Velko

He he... Abiem taisnība  :: 

Kustoties pa apli paātrinājuma absolūtā vērtība tiešām ir konstanta. Diemžēl paātrinājuma virziens mainās - tā lai būtu vienmēr vērsts uz apļa centru.

Protams, ja noprojicējam to uz asīm tad gan koordināta, gan ātrums, gan paātrinājums mainīsies pēc sin() un cos().

----------


## Epis

> He he... Abiem taisnība 
> 
> Kustoties pa apli paātrinājuma absolūtā vērtība tiešām ir konstanta. Diemžēl paātrinājuma virziens mainās - tā lai būtu vienmēr vērsts uz apļa centru.
> 
> Protams, ja noprojicējam to uz asīm tad gan koordināta, gan ātrums, gan paātrinājums mainīsies pēc sin() un cos().


 es saprotu ka ir tā ka piemēram apļa rādius R 100m kur sākum kordināte 
x0  y100  beigu kordināte x100 y0 
un ja piemēram ass pirmstam veica lineāru kustību X ass virzienā ar ātrummu 50m/s ta ejot apli ar tieši tādu pašu ātrummu paātrinājums aplī būs 
a = v^2/R 
a= 2500/100 = 25m/s^2

un es saprotu ka X 1 Y100 apļa lineārai kustībai X1 jārēķina ir pēc standart double T = (-Vo + Math.Sqrt((Vo * Vo) - 2 * a * (Xo - X))) / a; 
man liekās ka pirms kvadrātsaknes bīj +- variācija nevis tikai + kā tagat.
kur X kordināti rēkinot a= -25m/s^2; Vo =50m/s;Xo=0; x=1; 
finālā sanāk:  -0.0199 (s) tas ir laika intervāls kurā aplī aiziet līdz X1 Y100 kordinātei X motors.
pārbaudīt pareizumu varētu tad ja aprēkinātu y99 x=? kordināti un ta aprēkināt Y paātrinājuma laiku 1 vienībai un salīdzināt ar X laiku summu
x= sqrt( r^2-y^2)
x= sqrt(10000-99.5*99.5)=sqrt(100)=10 ; 
y=99,5 tādēļ ka cipari noapaļojās un ši ta ir robeža no kuras viss apaļosies.
piemēram ja x=10 y= sqrt(100000-100) = sqrt(9900)=99.5 noapaļojot kordināte =99 līdz ar to jārēķina x no y=99.5  ::  

tagat skatamies kas notiks ja rēkināsiem laiku šādām kordinātēm:
x=0 y=100  // paātrinājums X=-25m/s^2  ;  y=25
x10 y99  //  XVo = 100m/s  YVo = 0m/s

Time X = -0.1908s
time y = 0.282s

te kautkas nav kā vaig tādēļ pārēkināju uz precīzāku kordināti x18 y99 
ta sanāca x= -0.332 s
 šitas x itkā ir tuvāk y vertībai, bet dīvaini ka nesanāk precīzas tās vērtības, būs vēl jāpadomā kāpēc tā ?  jo rēķinot lineārai kustībai laikus prasti tie ir beigās ir vienādi !

----------


## Epis

atkal sajaucu to matemātiku, ir tā ka:
ja y=99 tad x = 14.106

tad X laiks = 0.2646 s 
un y = 0.2828 s 
 starpība laikos 0,0182s  ir apmēram 6-7% errors  no kurienes viņš rodās es nesaprotu  :: 



> Protams, ja noprojicējam to uz asīm tad gan koordināta, gan ātrums, gan paātrinājums mainīsies pēc sin() un cos().


 tā tava pieminētā sin() cos() metode var dot precīzākas vērtības ?  
man te pagaidām sanāk paliels errors

----------


## zzz

> atkal sajaucu to matemātiku, ir tā ka,,,
>  errors  no kurienes viņš rodās es nesaprotu


 Hmmm, no taas pashas vietas kaa gaisa dzineeji ar "uzlabotajiem" liederiibas koeficientiem un Karno likuma "apgaazshana"?

Ko nu termodinamika, sheitan epis pamanaas pamatskolas fizikaa/matemaatikaa sapiities.

*shrug*


Vareetu likt plusinju par centiigumu, ka cilveeks ciitiigi rushinaas, kaut arii ljoti vaargi apjeedz ko dara.

Pamatjeedzienus apguut/izprast gan joprojaam buutu veelems, jo kaa redzams sheitan, razhiigi rezultaati no centiiguma bez zinaashanaam neko vis nerodas.

----------


## Velko

Epi, atceries ka ātrums un paātrinājums ir vektoriāli lielumi. Tas, ko tu aprēķini ar a = v^2/R  ir tikai vektoru absolūtās vērtības (lielo bultu garums bildē).
[attachment=0:4elcpkp3]rotation.png[/attachment:4elcpkp3]
Cik daudz no tā būs X un cik Y komponentē visu laiku mainās - pēc sin() un cos() atkarībā no leņķa. Nu un ja ir vienmērīga rotācijas kustība, tad arī pēc laika. 

Ok, dažas formulas:
alpha = pagrieziena leņķis
x0, y0 = centra koordinātas
R = radiuss
V = lineārais ātrums
A = paātrinājums,  A = V^2/R

Koordinātas atkarībā no leņķa:
x = x0 + R * sin(alpha)
y = y0 + R * cos(alpha)

Ātrumi:
vx = V * cos(alpha)
vy = -V * sin(alpha)

Paātrinājumi:
ax = - A * sin(alpha)
ay = - A * cos(alpha)

----------


## Epis

nevar īsti saprast kā tad pēc tās sīn cosin formulas ta aprēkināt katra soļa ātrumu.
man tajā savā x18,y99 piemērā sanāca leņķis 6,34 grādi
tatad Vx = 50*cos(6,34)=49,85 m/s
Vy = 50*sin(6,34) = 5.53m/s 

un šitie cipari tā īsti nesakrīt ar tiem cipariem kas būtu ja rēķinātu to distanci kā lineāru, tad 
X būtu 18/19*50=47,36m/s
y būtu 1/19*50=2,63m/s 
un jautājums vai vispār tiem cipariem ir reāli jāskarīt ? vai tomēr aplis ir kāds izņēmums, vai arī es nepareizi kautko te rēķinu a?

----------


## Velko

Ja godīgi - īsti nesaprotu kā tu tur rēķini, tomēr:



> ja y=99 tad x = 14.106
> 
> tad X laiks = 0.2646 s
> un y = 0.2828 s


 Tev nešķiet, ka aprēķinam kāda jēga ir tikai tad, ja tu rēķini kur instruments atradīsies kādā konkrētā laika momentā, nevis 2 atršķirīgos? y=99 tad x = 14.106 tak vispār nepieder pie riņķa līnijas ar radiusu 100 kuras centrs atrodas 100,100. Man kautkā izskatās, ka tu rēķini X koordinātu pirms 2 dienām, kad grieznis vēl stāvēja plauktā, bet Y - šobrīd uz virpas  ::

----------


## Epis

reku bildē ir mans aprēķins ar zīmējumu un OpenOfis.Math uzīmētām formulām un aprēkinu, nu ir tur pareizi vai nav ?
[attachment=0:2lgnc3mn]Apļa kustības aprekinas.JPG[/attachment:2lgnc3mn]




> Ko nu termodinamika, sheitan epis pamanaas pamatskolas fizikaa/matemaatikaa sapiities.


 nu es nezinu vai pamatskolā fiziku kādam māca tādā līmenī lai šito aprēķinātu, lai gan nesen apskatījos fizikas eksāmenus uz kuriem linku bīj beztēmā viens ielicis un tur bīj uzdevumi sarežģitībā līdzīgi, bet reāli pamatskolā nesūda nēsu iemācījies  ::  es tā īsti pat nesapratu kas ir Volti, kas ampēras, nemaz nerunājot par to kas ir Nūtons, īsta bezfilma fizikā, jo parasti fizikas stundās vis bļaustījās, un fufeli dzina  :: , kurš pie tā vainīgs skolnieki, vai skolotāja es nezinu, bet matemātikas, geometrijas stundās bīj klusums un daudz lielāks respekts pret skolotāju, un rezultāti labāki.

goglējot ja kas arī nav tik viegli atrast šitās formulas kā rēķināt X,Y kordintēm ātrummus aplim. tikai vakar uzgāju pareizos google atslēgvārdus pēc kā meklēt litratūru šiem aprēkiniem un tie ir "circular projectile motion "  pirmstam meklēju bez projectile un meta arā parstās formullas, bet ne x,y plaknes.

----------


## zzz

Ciktaalu tu tur liec ciiparinjus Velko priekshaa uzrakstiitajaas formulaas tiktaalu jau laikam ir pareizi (pakalj tev jau nereekjinaashu, dariit man njefig ko)

Suudi saakas tur kur tu pats savas laika apreekjinu formulinjas izgudro.

Izvinjite-s, hernjas sanaakushas.

Korekti tur buutu jaalieto integraalis (tas kursh patieshaam integraalis, nevis integer datu tips). Ja galiigi pochujisms - tad vismaz tuvinaati aproksimeet uz lineaaru, nelieliem soljiem droshi vien buus cieshami.

Un laiks iisteniibaa nihrena nav 2 sekundes, bet apmeeram kaadas 0.3 sek. 

Tu tur esi uzklekjeejis aritmeetisku podjobku, saputrojot vietaam ax un ay skaitliskaas veertiibas. 

Es joprojaam nebeidzu briiniities kaa ar shaadu attieksmi pret skaitljiem, tu, epi, pamanies straadaat par graamatvedi vai ko jau nu tur un netikt noshauts vienaa jaukaa dienaa vai ieseedinaats cietumaa. Nu maakslinieka dveesele, chista.

----------


## Raimonds1

Vajag uzzīmēt bildi:
1. Sinusoīda šķērso nulli viena apgrieziena laikā 2 reizes, saniedz maksimumu un minimumu 1 reizi, citas vērtības - 2 reizes augšupejošā un lejupejošā grafika daļā. Pēc tā  - apgriezienu skaitu - 90 vai 450 vai 540 utt = 90 + 360n, kur n apgriezienu skaits.
2. Sinusoīda tikapt labi var startēt ne no 0, bet jebkura cita punkta, tāpat var nešķērsot nulli, bet izpildīties virs vai zem 0 ass.
3. Pēc tā, noskaidrojot, kāda funkcija ko apraksta, rēķina ātrumu, pagrieziena leņķi utt.

----------


## Epis

beidzot  Pieleca, nāca apskaidrība kā tad izrēķināt patiesās laika vērtības, īstanībā tas ir ļoti vienkārši, bez nekādiem integrāļ vienādojumiem(ko te ZZz pieminēja) un tātad aprēķins ir balstīts ja ejam pa riņķi ar konstantu ātrummu, paātirnājumu rādius vecais 100m, ātrums 50m/s paātrinājums 25m/s^2

un tātad ejam no X0 Y0 uz  Y1, X14.106 kordināti kur Y kordinātes ejamais Laiks atiecīgi būs:
1. aprēķina ejamā  riņķa loka leņki kas sanāk 8.1712 grādi:
2. aprēķina laiku pēc parastās formulas ko izmanto pilna riņķa laika aprēķinam un pilnam riņķim formula ir šāda:
T=(2*pi*R)/V  = 2*3,14*100/50=12.56 (s)
tākā es nerēķinu pilnam rinķim bet gan mazam riņķa segmentam tad no šī aprēkina 8.1712 grādu ejamā loka laiks būs:
T(x14,106 y1) = 360/T*Leņkis = 360/12.56*8.1712=0.285(s) 
tas būs tīrais motora soļa ātrums no Y0 līdz Y1 kordinātei un tākā manā piemērā motora solis ir 1m tad stepTIme =0.285(s) 

savkārt X1 soļa laiks būs attiecīgi: 
1. aprēķinam X1 y=? kordināti  y=100- sqrt(10000-1)=0.00501;
2. rinķa loka lenķi:   invertējam tg0.00501=0.28704945grādi *2=0.574098 grādi 
3. izrēkinam X1 laiku = 360/12.56*0.574098= 0.0203 (s)

un pēc visām formulām palielinoties X kordinātei X2; X3 X viena soļa laiks pakāpeniski pieaugs (samazinot motora griešanaš ātrummu), bet Y protams ka samazināsies palielinot motora ātrummu. 

šito es Loģiski izsecināju pētot google atrastās formulas un ta man šorīt vienā momentā nāca tā doma, jeb salikās formullu puzlis, ka šis ir īstais veids kā to lietu rēķina  ::

----------


## Velko

Nu, ko - daži komentāri:



> un tātad ejam no X0 Y0 uz  Y1, X14.106 kordināti kur Y kordinātes ejamais Laiks atiecīgi būs:
> 1. aprēķina ejamā  riņķa loka leņki kas sanāk 8.1712 grādi:


 Nesaprotu, kāpēc tik "neapaļu" skaitli paņēmi, nu bet apmēram tā sanāk (pēc maniem aprēķiniem gan - 8.109 grādi). 



> 2. aprēķina laiku pēc parastās formulas ko izmanto pilna riņķa laika aprēķinam un pilnam riņķim formula ir šāda:
> T=(2*pi*R)/V  = 2*3,14*100/50=12.56 (s)


  OK



> tākā es nerēķinu pilnam rinķim bet gan mazam riņķa segmentam tad no šī aprēkina 8.1712 grādu ejamā loka laiks būs:
> T(x14,106 y1) = 360/T*Leņkis = 360/12.56*8.1712=0.285(s) 
> tas būs tīrais motora soļa ātrums no Y0 līdz Y1 kordinātei un tākā manā piemērā motora solis ir 1m tad stepTIme =0.285(s)


 Dīvaina tev tā formula. Aprēķinot 360/12.56*8.1712 dabūjam ko citu. Bet rezultātu esi pierakstījis tādu, kādam jābūt.



> savkārt X1 soļa laiks būs attiecīgi: 
> 1. aprēķinam X1 y=? kordināti  y=100- sqrt(10000-1)=0.00501;
> 2. rinķa loka lenķi:   invertējam tg0.00501=0.28704945grādi *2=0.574098 grādi 
> 3. izrēkinam X1 laiku = 360/12.56*0.574098= 0.0203 (s)


 Un te jau sākas kautkāda putra. Kas tas par otro leņķi un laiku? Ja neizlasīji pirmoreiz, tad atkārtošu: *Man kautkā izskatās, ka tu rēķini X koordinātu pirms 2 dienām, kad grieznis vēl stāvēja plauktā, bet Y - šobrīd uz virpas*  ::

----------


## Raimonds1

Būtu labi to visu uzzīmēt.

----------


## Epis

jā rīt uzīmēšu apli kā un trīstūri no  kura tiek iegūts lenķis.



> Un te jau sākas kautkāda putra. Kas tas par otro leņķi un laiku? Ja neizlasīji pirmoreiz, tad atkārtošu: Man kautkā izskatās, ka tu rēķini X koordinātu pirms 2 dienām, kad grieznis vēl stāvēja plauktā, bet Y - šobrīd uz virpas


 tur ir tāda lieta ka es rēķinu Liku X asij no punkta X0 līdz X1 un lai to izdarītu man jāatrod Y=? kad X=1 un y=0.00501
un tad es izrēķinu to tangensu trīstūrim kur punkti A(x=0,y=0) B(x=0,Y=0,00501) C(x=1,y=0) kur magiskais Lenķis sanāk ir C= 0.28704945 grādi un tākā ja zīmē apļa loku un novelk starp 2 rinķa līnijas punktiem līniju veidojās vienādmalu trīstūris kur augšējie lenķi ir vienādi tad tie aukšējie  vienādie lenķi manā gadijumā ir 90-0.28704945 = 89.7129 grādi un tad aprēķinam centra lenķi kas ir 180-89.7129*2=~0.574 gradi līdz ar to faktiski loka lenķis ir 2*tandgens(C)
bildi pielikšu rīt lai būtu skaidrs visiem kas pa trīsturiem, un lokiem.

bez šī aprēķina man vaig vēl vienu algoritmu kurā varētu aprēķināt kustības pa apli aceleration,deceleration režimā  X,Y ātrummus, proti šitas ko esu aprēķinājis lineārās kustības analogā ir kustība ar fiksētu ātrummu, un man vaig uzrāviena fāzi, šajā piemēra analogā, tas izskatītos tā ka sākotnējās X vektora ātrums būtu 0, kā y=0m/s, bet pēc algoritma X būtu jāiet momentāni ar gandrīz vai 50m/s, un tas protams ka nav iespējams, līdz ar to vaig papildus uzrāviena fāzi, līdz tai vērtībai kādai vaidzētu X būt kādā no rinķa līnijas punktiem, kā to aprēķināt es vēl nezinu, bet gan jau ka izdomāšu.

----------


## zzz

> beidzot  Pieleca, nāca apskaidrība kā tad izrēķināt patiesās laika vērtības, īstanībā tas ir ļoti vienkārši,


 Nu apsveicami ka beidzot tas siikums tev pieskjiila (tas bija veids kaa es apreekjinaaju aptuveni 0.3 sek un pat bez kalkulatora pielietoshanas :P). Atgaadinaashu ka variantu reekjinaat laiku no aatrumu/paatrinaajumu x/y projekcijaam centies uzlipinaat tieshi tu pats, izreekjinaat var arii taa, tachu kaartiigi to darot integraaliits vajadziigs buus. 




> šito es Loģiski izsecināju pētot google atrastās formulas un ta man šorīt vienā momentā nāca tā doma, jeb salikās formullu puzlis, ka šis ir īstais veids kā to lietu rēķina


 Shito "puzli" apjeedz normaali attiistiits pamatskolnieks. Nekas, epi, labaak veelu, kaa nekad. Kaut kad tach bezjeedziigi nodzertaas jauniibas kljuudas jaasaak labot.  :: 




> bez šī aprēķina man vaig vēl vienu algoritmu kurā varētu aprēķināt kustības pa apli aceleration,deceleration režimā  X,Y ātrummus


 Hehee, welkomeets uz funi.  ::  Kaartiigi darot - integraaliits.  ::  Ja kjibinaasi pa lineaariem soliishiem, pie neveiksmiigas realizaacijas uzrausies uz kljuudu uzkraashanos. 

Ladna, buushu humaanists, pateikshu priekshaa vienkaarsho veidu - to paatrinaajumu kas tev iet pa rinjkja liiniju, reekinji kaa lenjkjisko, nevis kaa lineaaro. Un vispaar beidz spokoties ar graadiem, radiaani rotaacijas kustiibas fizikaalo buutiibu izsaka daudz jeedziigaak kaa babilonieshu skaitiishanas sisteemas paarpalikumi graadi.

----------


## Vikings

> paatrinaajumu kas tev iet pa rinjkja liiniju, reekinji kaa lenjkjisko, nevis kaa lineaaro.


 He he, esmu par šīm lietām domājis tīri teorētiski un līdz sakarīgam, pieņemamam risinājumam nekad tā arī neesmu nonācis. Bet šis ieteikums, šķiet, noderēs kā risinājums arī man, paldies.  ::

----------


## Epis

reku uzīmēts aplis un var redzēt kā nosaka lenķi d un tas sanāk d= tg(a/b)*2
[attachment=0:gfb4x3wl]Circle move geometry1.JPG[/attachment:gfb4x3wl]




> tākā es nerēķinu pilnam rinķim bet gan mazam riņķa segmentam tad no šī aprēkina 8.1712 grādu ejamā loka laiks būs:
>     T(x14,106 y1) = 360/T*Leņkis = 360/12.56*8.1712=0.285(s)
>     tas būs tīrais motora soļa ātrums no Y0 līdz Y1 kordinātei un tākā manā piemērā motora solis ir 1m tad stepTIme =0.285(s)
> 
> 
>  Dīvaina tev tā formula. Aprēķinot 360/12.56*8.1712 dabūjam ko citu. Bet rezultātu esi pierakstījis tādu, kādam jābū


 tur ir kļūda vaig būt tā ka (12.56/360)*8.1712   proti T/360*grāds a bīj uzrakstīts 360/T.

Pagaidām nēsu vēl to paātrinājumu rēķinājis, bet domāju to darīt tādā stillā ka izrēķināšu līdz vaidzīgai kordinātei rinķa līnijas garumu tad izrēķināšu pēc paātrinājuma formulas cik lielu ātrumu sasniegs noejot šo rinķa loku, un kad būs zināms ātrums tad liks to ātruma ciparu 50m/s ātruma vietā un rēķinās laikus kā pa vecam, un laika rezultātu saglabās, lai katrai nākošai kordinātei varētu atņemt iegūto Laiku no vecā laika, jo loks no kā rēķinās punkta ātrumu sāksies vienmēr Sākumpunktā(šai piemērā: x0,y100) punktā, un rēķinās tik ilgi paātrinājuma režimu kamēr nesasniegs vaidzīgo ātrumu, reāli tas punkts pie kura vaidzētu sasniegt vaidzīgo ātrumu būs jāizrēkina uz kompja, lai mazāk jākodē MCU.
vēl nēsu ar cipariem pārbaudījis kā šis variants strādās.

----------


## Epis

kopš pēdjā posta es reāli atkal iegruzījos visādās Mikrenēs, jaudās, gatavajos Single board computer plašu piedāvājumos, arī COM(computer on Module) platēs, tādēļ vaidzēja sūtīt no digikey pāris 2.4Ghz RF modulīšus pa 12$ un lai nesanāktu tā pa tukšo sūtīt ta meklēju ko lai piemet klāt pie sūtījuma, un nācās ta izvērtēt cik ta jaudas vaidzēs MCU lai dabūtu normālu step/dir performance ar lineāro,circulāro interpolāciju, un googlojot atradu visādas krutas SBC ARM9 plates, par fantastiskām cenām, piemēram:
http://www.embeddedarm.com/products/boa ... ct=TS-7500 plate kas vairumā q1=140$ q10 = 100$ 

īpaša ar to ka ir 250Mhz arm9 procis +Fpga Xp2 5K lut un 2USB host 1USB slave 10/100 ethernet, 64 MB DDR-RAM; 4 MB NOR Flash 
karoči pilns kompleksts gandrīz vai gatavs produkts, kur iemet ieksā savu kodu un viss gatavs, nelaime tāda ka procis lai iekodētu ir jāņemās ar embaded linuxu, ar tiem GNU compileriem, no kā man nav nekādas sajēgas + būs arī jāpārkodē tā fpga, kas arī nav nemaz tik viegli, finālā aizietu kāds pus gads kamēr iemacītos to proci uz linuxa uzkodēt.
reku vēl viena plate kas ir computer on module (bez visādiem internet,usb konektoriem, visur ir heder IO izvadi)
MICRO2440 http://www.armdesigner.com/MICRO2440.html

maksā arī baigi lēti ap 60$ bet nav neviena perifērijas kontakta, tas nozīmē ka jātaisa vēlviena PCB ar visiem kontaktiem priekš USB,bet + tāds ka ir vēl jaudīgāks Samsung  S3C2440A 400Mhz arm9 procis.
ar softu ir tādas pašas problēmas kā pirmai platei, kur būtu jākodē zem kautkāda linuxa. 

cenas tām platēm ir tik zemas jo cik lasīju ta tās pielieto masveida produktos, līdz ar to ražo lielos apjomos un ir zema pašizmaksa, un gala cena, līdzīgi kā PC mātesplatēm, līdz ar to tie ir vieni no labākiem Price/performance dealiem starp arm9 proču platēm, ar cortex-m3 platēm ir tā ka to īsti vēl nav, tas kas ir dārgs, un reāi jaudas procim priekš šī CNC kontrolliera arī ir pa maz.
finālā es izmodāju ka pagaidām vēl neņemšos ar arm9 pročiem un kā risinājumu izmantošu 2 stm32 pročus no kuriem
 1 būs: stm32f103VET6-> 4Mb flash, 8taimeri; 3ADC konvertieri,2DAC, external memory interface priekš SRAM,PSRAM,NAND,NOR čipiem manā gadijumā klāt domāju likt 4Mb(16b) SRAM čipu
2.būs viss lētākais 32kB cortex-procis (tie kurus fpga platei liku virsū) kam ir 1ADC +4taimeri.
abi proči būs savstarpēji savienoti ar SPI 18Mbpskas iekšēji sūtīs datus caur DMA fifo bufferiem un viens procis veiks smago lineāro,circulaŗo interpolāciju(mazias), bet otrs, lokālo PID un step/dir +USB komunikācija un flash lasišana.
domāju ka ar 4Mb step signālu bufferi vaidzētu pietikt .

protams būs jātaisa jauna pCB kur to visu uzlodēt, bet to bišķi vēlāk, ka uzdrukāšu to  circulāro interpolātor kodu.

----------


## Epis

pirms garā teksta gribu pateikt ka esu uztaisījis uz msp430 un Cypress LETO WirelessUSB™ Moduļa  izmantojot  250kbps DSSS režimu bračkam zibspūldzes raidītāju  :: , un gribējās arī pašam apstītes kā tie wireless čipi iet un cik ātri reaģē, un man pagaidām lielākais ātrums ko izdevās dabūt pārsūtot 8informācijas bitus ir 660us (1.5Khz) priekš wireless enkodera laikam ka ir stipri pa lēnu, vēl nēsu mēģinājis GFSK  1 Mbps režimu 
ar to gribēju teikt ka esu iemācījies kodēt (pa 2nedēļām) tos sīkos msp430 čips ar C uz kuriem uzķīlēju tās SIN optiskā enkoder plates,bet vēl iekodējis nēsu.

karoči izdomāju ka jāsāk pamazām taisīt jauna PCB, kas faktiski pēc idejas būs līdzīga vecajai fpga+ARM platei proti: būs vecā ecp2 fpga(lodēšu to kas palicis pāri no iepriekšējā ordera) tālāk pie fpga tiks pievienota 4Mb SRAM ar 16bit ceļu (vecajai platei bīj vieta SDRAM čipam ko reāli uzlodēju, bet tā arī nemēgināju iedarbināt, jo pārāk liels čakars ar tiem refresh un citiem sūdiem(slinkums ņēma virsroku), tālāk pie fpga tiks pieslēgts stm32103vet6 ar 20 I/O piniem caur FSMC atmiņas kontrollieri ko ir doma konfigrēt uz NAND flash čipa interfeisu (D[15:0];A17;A16;NOE;NWAIT piniem), un tad caur to sazināties ar fpga, un tad caur fpga tikt pie  SRAM čipa, tālāk bez lielā stm32 proča ir doma uztaisīt vietu arī mazajam, lētajam stm32 procim, varbūt ka tas atrastos tieši zem lielā, un būtu pieslēgts tam pašam 20bit fpga I/O interfeisam, lai būtu iespēja komunicēt, un doma te ir tāda ka es īsti nezinu kas ir izdevīgāk mazais vai lielais, un varbūt ka vaidzēs abus divus un tādēļ taisot pCB ielikšu vietu abiem. 

un uz jautājumu kādēļ uz plates atkal būs fpga un tieši ECP2: atbilde vienkārša:
tādēļ ka pašreizējam cnc kodam ar lineāro, un vēljoprojām topošo CIrculāro interpolāciju ir vaidzīgs liels FIFO bufferis, un cik es skatījos ta paša stm32 FSMC SRAM kontrollieris nav neko ātrs proti ātrākais nolasīšanas performance ir kādi 18-14Mhz  a reāli manas nopirktās Ram ātrums ir 100Mhz pie 16 bitiem.
un vispār fpga ir kā Drošinātājs, proti ja izrādīsies ka to cirkulāro interpolāciju MCU ir pa smagu izkalkulēt ta nāksies grūtāko daļu algoritmu likt iekš FPGA DSP blokiem, un 20 I/O pinu interfeis, kas sūtīs 16 bitus var tīri ātri fpga ielādēt vaidzīgos skaitļus 6clk (1. 32bit ciparam vaidzēs 4clk+2clk adrese) un tad ja izdodās uz fpga paātirnāt kādu matemātisku operāciju kas man tur velkās 200-300clk kā kvadrātsakne, uz kādiem 30-40clk ta tas jau ir izdevīgi + fpga varētu noņemt slodzi step/dir signālu ģenerēšanā un QEI saņemšanā un laika skaitīšanā tā lai izdod enkoder stāvokli ik pēc 1ms, jo esam reāli MCU ir MCU, un var vienlaicīgi darīt 1 darbu, bet fpga var vienlaicīgi darīt tik cik gribi operācijas. 

Līdz ar to sanāk tā ka vienīgais labums no tā lielā stm32 čipa ir tas ka viņam ir daudz Flash atmiņas 512KB, un ir DAC ko man arī vaig, bet vispār domāju ka varētu arī iztikt ar lētāko stm32, un tākā skaidri nezinu kā būts ta taisīs tā lai var sabāzt visus čipus kas sasūtīi un vēl nav uzlodēti  :: 
un mēginās taisīt PCB tā lai visas detaļas lodētos no aukšas.

----------


## Epis

pasūtiju no digikey TMS320F28335 Experimenter Kit 100$  un vēl RF msp430 kitu


un sanāk ka esu mainījis savas domas tajā ko rakstīju iepriekšējā postā, par jaunās plates taisīšanu ar stm32+SRAM+fpga, tagat es nekādas jaunas plates netaisīšu, bet izmantošu gatavu produktu, kuram ir manā skatījumā tieši tik liela FPU jauda kādu vaig lai aprēķinātu lineāro+circulāro interpolāicju.
TMS320F28335 = 150Mhz FPU procis.
+ man baigi iepatikās CodeComposer studio v4.0  eclipse IDE bazētais softs.

1. tā eclipse IDE vide pēc savas kvalitātes ir tuvu Visuālai studijai ar savām IntelSense fičām kas atvieglo, paātrina kodu drukāšanu, līdz ar to arī produktivitāti.
2. Single precision FPU hardware. 
 jo esam reāli kodēt tik sarežģītus fizikālus algoritmus Veselos skaitļos ir Totāla Laika šķērdēšana (pēc pēdējās pieredzes esu šito sapratis un izsecinājis), un man laika pēdējā gadā paliek ar vien mazāk un mazāk šim cnc projektam, tādēļ vainu es atrodu veidu kā paātrināt to izstrādes, kodēšanas processu, vai arī tā arī nekad to nepabeigšu !
3. Gatava ejoša Plate ar visiem  elementiem par saprātīgu cenu arī nenormāli ietaupa Laiku, un šeit vaidzētu nākotnē tikai uztaisīt savējo DIMM 168pin socket konektora PCB, kurā salikt motora,enkoderu, barošanas bloka konektorus, 3.3uz 5V IO translātorus + uzlikt savējo 4Mb SRAM čipu jo tam proča modulim nav nekāda ārējā RAM čipa, un tas arī viss, nebūs nekādu papild fpga,MCU čipu jo šajā čipā ir pilnīgi viss.

šoreiz domāju ka veiksmes % ir lielākais no visām iepriekšējām tehnoloģijām ko izmantoju.

----------


## jeecha

Ar veiksmi tam visam nav nekaada sakara - shai gadiijumaa iespeeja uztaisiit konkureetspeejiigu (labaaku vai leetaaku vai abus) kontrolieri tev ir tieshi tik pat liela kaa liidz shim - faktiski nekaada. Paarsvaraa deelj ljoti savdabiigas un haotiskas pieejas projektam.

P.S. Cik simtus tad esi liidz shim izteereejis dazhaados fpga un mcu devkitos, savas fpga plates eksperimentos, nodedzinaatos chipos utt utjp? Nebuutu bijis leetaak uzreiz nopirkt industriaalu servo kontrolieri nevis cik jau gadus chikaaties uz vietas?

----------


## Epis

> Ar veiksmi tam visam nav nekaada sakara - shai gadiijumaa iespeeja uztaisiit konkureetspeejiigu (labaaku vai leetaaku vai abus) kontrolieri tev ir tieshi tik pat liela kaa liidz shim - faktiski nekaada. Paarsvaraa deelj ljoti savdabiigas un haotiskas pieejas projektam.
> 
> P.S. Cik simtus tad esi liidz shim izteereejis dazhaados fpga un mcu devkitos, savas fpga plates eksperimentos, nodedzinaatos chipos utt utjp? Nebuutu bijis leetaak uzreiz nopirkt industriaalu servo kontrolieri nevis cik jau gadus chikaaties uz vietas?


 es domāju ka nebūtu izdevīgāk nopirkt industriālo asu kordinātoru, jo esam reāli ja tāds kā es pamuļķis pirms 3 gadiem nopirktu tādu mantiņu (normāli cena ap 1500$) ta notiktu kas: es to dārgo apaprātu toč nosvilinātu, vai kautkādīgies sačakarētu, vai arī vispār nevarētu plaist, un finālā vaidzētu pirkt ko citu, līmenim atbilstošāku, un rezultātā tāpat nebūtu ejošas iekārtas  ::  un būtu vēl slitkāk nekā tagat, tākā neapšaubāmi esu 100% ieguvējs  :: ,
 reāli jau ir tā ka viss atkarīgs no tā no kādas perspektīvas, kritērījiem skatās vai esu zuadētājs vai ieguvējs, šeit minētā perspektīva parāda ka esu ieguvējs, bet ja skatās no cita punkta ta būtu totāls zaudētājs.
 tākā pirms vērtēt ir jānoskaidro kas ir tie nozīmīgākie vērtēšanas kritērīji pēc kuriem ta varētu noteikt vai bīj jēga mēģināt taisīt CNC kotnrollieri vai nebīj jēga ?
bez šādiem kritērijiem jebkāds vērtējums ir subjektīvs, proti ne objektīvs, kam nav nekāda jēga.

----------


## a_masiks

> bez šādiem kritērijiem jebkāds vērtējums ir subjektīvs, proti ne objektīvs, kam nav nekāda jēga


 Jeechas vērtējumam kritēriji ir vienkārši - naudas izdevumi pret iegūto labumu.
Pirms diviem (!!!!)  gadiem, epis uz tieši uzdotu jautājumu par to, cik viņa čikāšanās ar elektroniku ir izmaksājusi, atbildēja : ap 1000$ (vai pat Ls)  Tas bija pirms 2 gadiem. Pirms aizraušanās ar devaiskitu pirkšanu.

Uz šo brīdi summa virs 1500$ ir krietni pārtērēta. Cenšoties uzbūvēt lētāku (!!??) kontrolieri. Pat ne iekārtu, TIKAI kontrolieri.

No tās mistiskās otras puses - kādi mums ir nenovērtējamie ieuvumi no šādas čikāšanās? Izņemot brīvā laika pavadīšanu niekojoties ar elektroniku un programmēšanu tādā kā tvīterī... kas mums ir?  Mūsu zināšanu vērtību nosaka tas, ko mēs mākam izdarīt, cik mūsu izdarītais darbs ir vērtīgs. Kas ir paveikts? Dīvaina lodēšanas krāsns, kuras darbības algoritms ir miglā tīts pašam autoram (laikam ne pārāk precīzi nokopētas programmas dēļ..). Bet tas nav cnc.... Kas vēl? Ko mēs te mākam uztaisīt konkrēti priekš cnc? Kādas tad ir mūsu zināšanas par cnc? Manuprāt - apaļš zīro. Es protams saprotu, ka tad, kad mūsu varonis mazliet paaugsies - tad gan visiem parādīs, kāds viņš spics nazis iraid... bet kad tas būs? /jautājums retorisks, atbildi neprasošs/

Pie kam, apzinoties, ka visa šitā figņa paredzēta virpai, kura pati par sevi ir radiālās apstrādes iekārta, ij pati smuki griežas radiāli - es vdosku nesaprotu vajadzību pēc cirkulārās interpolācijas darba instrumentam. Te kas būs? Virpa tiks nofiksēta un ar mehānisko roku pa riņķi dzenās griezni??? Tad jau arī jāaprēķina griežņa orientācija pret detaļas centru. To ar nedrīkst aizmirsst!!! 
Manuprāt, ja mums ir detaļas leņķiskā pagrieziena devējs - mēs katru izmērīto pagrieziena leņķisko vienību ņemam kā lineāras kustības soli, un bīdām griezni izejot no šī soļa. Ja vajag uzgriezt vītni - mums papildus nepieciešama tikai 0 punkta (0 leņķa) iezīme, lai mēs varētu sākt vītni griezt katrā nākošajā gājienā no viena un tā paša sākuma punkta. 
Es pieņemu, ka neko no cnc nesaprotu - tāpēc ar prieku uzklausītu dajebkurus argumentus, kas pamatotu šādu čakarēšanos ar riņķa līnijas aprēķiniem, kurus te ir vēlme  uzkraut nabaga kontrolierim.

----------


## Epis

> .. kas mums ir? Mūsu zināšanu vērtību nosaka tas, ko mēs mākam izdarīt, cik mūsu izdarītais darbs ir vērtīgs. Kas ir paveikts? Dīvaina lodēšanas krāsns, kuras darbības algoritms ir miglā tīts pašam autoram (laikam ne pārāk precīzi nokopētas programmas dēļ..). Bet tas nav cnc.... Kas vēl? Ko mēs te mākam uztaisīt konkrēti priekš cnc? Kādas tad ir mūsu zināšanas par cnc? Manuprāt - apaļš zīro.


 vispirms jau jāsaprot ka uz katras elektronikas platformas kuru esu mēģinājis esu sadrukājis visādus kodus pārsvarā tos varētu nosaukt par zemākā līmeņa draiveriem priekš enkodera,Step/dir signālu ķeršanas, ģenerēšanas, un vēl viskautkas cits, un katru reizi ka izvēlos jaunu Dev.kitu, vai uztaisu jaunu Plati(reāli ar dev.kitiem tā lieta iet uz priekšu divtikātri  :: ) es sasniedzu jaunu līmeni, pasperu vienu soli tuvāk reālam ejošam Devaisam, solīši protams ka ir maziņi, bet naivi cerēt ka būtu kāda alternatīva ka varētu tā uzreiz 1;2 un gatavs. 

Reāli jau laikam ka es tās savs spējas pašā sākumā pārvērtēju pēc pirmās neveikses ar atmegu128 ķēros klāt tām fpga, kas tehniski ir pārāk sarežģiti, un jaudas tur ir pārāk daudz, + tākā tehnoloģija ir padārga un nebīj piemērota dev.kita, un  tā es īstanībā 1.5 gadus nočakrējos ar to savu fpga plašu taisīšanu un reāli secināju ka tas ir baigi laikietilpīgs darbs un protams ka tā tā lieta neiet, un izdevīgāk ir nopirkt Dev.kitus gatavas plates un taisīt to kontrollieri uz tām, un  tikai 2009.gadā sāku ņemties ar otro Dev.kitu ko visā savā elektronikas karjerā bīju pircis (stm32 circle kits). 
šogad laikam ka progress uz šī kita ir bījis viss lielākais, pēdējo mēnesi es ņemos ar 3 (jau sen nopirkto  eZ430 USB stick 25$ kitu kā rezultātā atklāju cik kruta ir tā Eclipse IDE un saņemos drosmi nopirkt Kārtīgu Kitu kur ir Viss jaunākais močnākais MCU delfino serijas Procis 150Mhz ar FPU atblastu, un priekš sirdsmiera, gadijumā ja tomēr jaudas būs pa maz tur ir nopērkamas tās Plates arī ar 200Mhz un 300Mhz delfino pročiem, tākā šai MCU serijai ir Potenciāls un es sāku ar vis švakāko. reāli ir tā ka tiem 200 un 300mhz delfino proči nāk ar lielu RAM, bet bez Flash atmiņas, un viņus var uzskatīt jau kā reālus DSP nevis MCU.

Reāli cik esu redzējis tad visi kaut cik nopietni CNC kontrollieri iet uz DSP pročiem kam ir FPU, un visi pārējie USBCNC brīnummi kas iet ar ARM7 un citiem 32bit,8bit fiksēto punktu pročiem ir pa kārtu zemāka līmeņa, var pat teikt tas līmenis ir pašvaks, jo mans stm32 kods rāda ka tur nekas labs nesanāk.

ja kāds sekoja ta es jau sāku ķīkstēt par performance ka sapratu ka vaidzēs matemātiku veikt 64 bitos, un redzot standart matemātiskās biblotekas performance jau jutu ka tā tā lieta neiets, bet mēgināju būt optimists, un turpināt. Protams tiko redzēju ka varu pavilkt kautko jaudīgāku, un ka tas ir reāli tā sapratu ka nav ko tērēt savu laiku mokoties ar fiksēto punktu pročiem.

----------


## Epis

ir 1 Laba ziņa un 1 slikta 
Labā ziņa ir tāda ka Salodēju savu PCI plati  ::  
bet sliktā ir tāda ka Izdarīju galīgi tupu kļūdu, proti uzlodēju nepareizi fpga čipu :  ::   ::  un šito es pamanīju ta ka viss bīj salodēts un slēdzu pie strāvas ņēmu voltmetru un mēriju vai ar barošanu (3.3v un 1.25v ) vis kārtībā un izrādījās tā ka 3.3 v vietā rāda pie 2V un 1.2v zem 1 v, noslēdzu barošanu, sāku skatīties ar testeri zvanīt plati un redzu ka 3.3v ir īsajā ar 1.25v, un tieši tas pats ar GND un abiem VCC līmeņiem  ::  karoči viss īsajā.
sāku domāt ko esu sķībi salodējis, ta pamanīju ka čips kautkā dīvaini novietots, salīdzinot ar iepriekšējo FPGA plati, izrādās ka čips stāv 90 grādu pagriezts pa pūlksteni.
cik skatījos IO VCC izkārtojumā ta liekās ka tie VCC core IO un VCC IO pini griežot čipu pa 90 grādiem nepārliekās, līdz ar to tieši VCCcore nesaiet īsajā ar VCC IO bet sanāk tā ka abi divi Voltu līmeņiem daži IO pārliekās pāri GND piniem līdz ar to arī Īssavienojuma izskaidrojums.
barošanas bloks bīj tāds pašvaks (no kāda ultra veca mobīlā)- kādi 10V 100ma tādēļ čips ka bīj pie strāvās vispār nekarsa (es karšanu ar roku nepamanīju) un nekas svilt arī nesvila (LDO Dc regulātori varētu būt OK.
ko lai tagat dara ? lodēt nost un mēgināt pārlodēt ?   (vairāk fpga čipu nepielodētu un ejošu man nav)


domāju lodēt nost kautkā šadi pa 1nam IO pinam 
[attachment=0:fiwdpdag]PCI-stieple.JPG[/attachment:fiwdpdag]
atceros ka vienu FPGA es jau nosvilināju, un ja kas šoreiz arī varētu tā sanākt, jo tas LDO tps7930 1.2v regulātros nosvila ka pēc lodēšanas pārbaudīju plati, izrādās ka viņš nosvila no Testera līniju  izzvanīšanas (pirmā detaļa kas no testera sabojājās) un beigtā vietā ieliku Lm317 tas no testera zvanīšanas nesvilst.

----------


## Epis

ir tā ka es to čipu pārlodēju un nekas protams negāja, tagat šodien nolodēju pēdējo ejošo čipu un esu viņu itkā uzlicis ar pāris lodējumiem pa stūriem uz plates un tāda sajūta ka atkal nekas nesanāks jo nez kādēļ 1.2v vietā rāda ap 2.5v.  ::  
man liekās ka problēma ir tāda ka šāda operācija nolodēšana ar vada palīdzību nekam neder un sabojā tā čipa kājas līdz tādai pakāpei ka vairs nav iespējams viņu normāli pielodēt, jo kājas ir līkas, kopā salipušas, un baigi grūti tur kautko iztaisnot, līdz ar to mācība sekojoša:
nelodēt nost čipu izmantojot vadu (kā tajā bildē) un ta ar to vadu+lodāmuru karsējot kājas, tā lai ka velk vadu kājas atdalītos no PCB (salocās uz augšu) nelaime tāda ka šādi viņas nevis nolocās smuki uz augšu bet gan salocās šķībi + kopā salodējās, un šadi deformātas kājas (izksatās šausmīgi) vairs praktiski bez īsajiem nevar atpakaļ pielodēt, jo lai arī var itkā kādu taisno nolocīt atpakaļ, ta problēma ir tajā ka tās kājas no locīšanās ir sagriezušās un stāv ar nelielu slīpumu, ko praktiski iztaisnot nevar, un šādi sagriztas kājas beiži veido īso, finālā ļoti mazs izdošanās %. 
rezultātā laikam būšu sadirsis atlukušos 2 veselos fpga čipus (vairs nav neviens ejoš ECP2 čisp  ::  ) 
jāsūta jauna partīja  :: .

secinājums DIY lodēšana daudzkāju TQFP čipiem ar parastu lodāmuru ir vienreizējs pasākums, ja kautkas noiet greizi ta nevella nevar nolodēt un nolodēto pārlodēt, proti jānolodē (nogriežot kājs čipam) un jālodē vietā Jauns svaigs čips. zinu ka ir speciālā apratūra ( kantaini lodēšanas uzgaļi ar kuriem var smuki nolodēt bet tie ir dārgi.) 
varbūt ar fēnu varētu normāli nolodēt, bet man tāda nav

----------


## jeecha

Tev tachu ir tava super lodeeshanas kraasns - iemet tajaa, uzkarsee un peec tam zibeniigi (kameer alva veel shkjidra) pakjer plati ar stangaam un nokrati nost detaljas :P
Veel labaak "10 reizes nomeeri pirms nogriez", vai paarfraazeejot "10 reizes paarbaudi pirms pielodee". Vai arii lieto feenu vai karstaa gaisa staciju ar dotajam korpusam paredzeetu uzgali.

----------


## Epis

Ir vēl cerība ka pēdējais čips tomēr strādā, jo vakar bīj tā ka nolodēju nost to savu fpga (švaki pielodēto (tikai pa stūriem) čipu, un skatos DC regulātors kā rāda 2.3v tā rāda   ::  tad es padomāju moš LM317 beigts (bez LM317 1.2v daļā bīj 4.7k rezistors(slodzei)+10uf cap), nolodēju, paņēmu jaunu uzlodēju un atkal bilde tāda pate, visu vakaru štukoju, lodēju, nost gan rezistoru, gan kapacitātoru, vēlreiz pārlodēju, nesapratu kas pa lietu, šorīt apstījos google par Lm317 un izlasīju tādu lietu ka viņam vaig minimālo slodzi 120omi ja iekšā laiž lielu spriegumu (>35V) apstījos nupat datashītā un patiešām tur ir minimālais Load reiting 3.5-5ma skatījos tālāk un atradu grafiku ar minimālo Load un Vi-VO attiecību un pie mazas voltu starpības sodze bīj 0.5ma tātad pietiek ap 2.2K rezistoru, es pielodēju 1K slodzes rezistoru un nupat nomērot viss iet, nāk ārā 1.25V  :: .
kas zin moš es iepriekšējo fpga čipu norakstīju veselu, dēļ tā LM317 regulātora, jo pārlodējot laikam ka to rezistoru arī izlodēju, izmetu, tākā tagat mēginās vēlreiz lodēt visrū pēdējo fpga čipu, jo uz stūra kājām ko bīju fiksācijai pielodējis neatrodās ne GND ne VCC Io pini.  ::  pirmstam uz skrūvspīlēm mēginās Io kājas atlodēt un iztaisnot.

----------


## Epis

Sanāca tā ka sačakarēju čipu, nejauši lodējot un bakstot JTAG VCC pinu (viņš man kļūdas deļ nav izvilkts uz PCB tādēļ jālodē vads klāt pa taisno) nolauzu  :: , proti Pina kājas vairs nav  ::  un līdz ar to JTAGs nestrādā, un var teikt ka no čipa nav nekādas jēgas (jāmet ārā). Pēc šitā kārtīgi saskādējos, ta izdomāju ka jāpameģina pielodēt pina kājas vietā smalks vadiņš, un sāku mēgināt to lodēšanu, un sākumā nekas nesanāca, ta pamazām uzlaboju savus lodešanas skilus, noasināju plakano lodāmura galu uz spicu lai varētu tikt klāt tuvāk čipa kājas nolaustai vietai (no čipa kājas vietā nebīj it nekā, tikai balsts metalisks spīdums kājas vietā.) un finālā pēc 3 h mocīšanās ar radošu pieju pie lodēsanas izdevās brīnums un pielodēju vadu pie praktiski nekā  ::  šeit mana mission impossible bilde  ::  
un iemēgināju JTAG un pa brīnumu Fpga strādā (programmēsanas softs atpazīst čipu). 
Līdz ar to tagat man beidzot ir PCI plate (vēl līdz galam nesalodēta) ar ejošu fpga čipu  ::  
[attachment=0:3rep8lue]PCI_32-Jtag-VCC pins.JPG[/attachment:3rep8lue]

----------


## Epis

Esu salodējis līdz galam savu PCI-32_ fpga plati vis strādā konfigururējās, un pa tiešo pašu plati vēl spraudis nēsu kompja PCI slotā bet esu iemēginājis iespraust beigto PCI plati (kur fpga un DC regulātori ir nolodēti, palikuši tikai 10bit BUS switch sn74cbtd3384c (5->3.3v konvertieri) un iespraužot to plati kompī pamēriju ar voltmetru kādi PCI signāli nāk no kompja 5v slota un tanīs vietās kur bīj V I/O (5 vai 3.3v) barošanas strāva nāca ārā 5v tas nozīmē ka plate ir tīra 5v pēc V I/O strāvas lieluma bet intresanti tas ka no IO logiskais Hi bīja ne lielāks par 3.3v (es tur 5v neredzēju braukājot pa IO piniem ar testeri) tākā iespējams ka varētu pat iztikt bez tiem Buss Switch sn74cbtd3384c translātoriem.
secinājums par tiem PCI slotiem ir tāds ka visos kompjos reālais IO signālu līmenis no mātesplates chipset PCI slota ir 3.3v bet Vcc IO tiek padoti 5V tākā tas ir 5v slots, līdz ar to var spraust vecās 5v kartes kam pa IO iet tie 5v signāli, principā varēju projektēt plati kur pa taisno FPGA IO pieslēgts pie PCI slota IO, vienīgi šādā konvigurācijā nevar spraust PCI papild slotā veco 5V karti ar 5V signāliem, ta fpga IO sasvils.

Tākā viss itkā strādā ta esu sācis rakstīt fpga kodu, domāju izmantot PCI_target_32bit Reference Design free IP kodu (free ir tikai priekš Lattice fpga čipiem, tā rakstīts licenzē) kā pamatu kuru var nolādēt šeit:
http://www.latticesemi.com/products/int ... t33mhz.cfm
man sanāca to projektu palaist sipLever softā nosintezet uz savas fpga (bez IO pinu assignment) un pēctam nolēmu pārbaudīt to kodu simulātorā (Active-HDL) un pēc demo testbench vhdl faila, pēc pāris dienu čakara, iemācijos tos testbench palaist, pirmstam biju tikai ar vector Vawform failiem testējis kodu, bet tās testbench simulācijas ir daudz advancētakas, un palaižot simulātoru ieraudzīju smuku PCI signālu grafiku, ar visiem inicializēšanas cikliem, READ, Write transakcijām, vispār tur to transakcijas veidu ko tas PCI target atbalsta ir tīri daudz proti:
no PCI komandu signāliem  C/BE[3:0]  tiek atbalstītas šādas komandas:

2h : IO Read
3h : IO Write
6h : Memory Read
7h : Memory Write
Ah : Configuration Read
Bh : Configuration Write

vairāk C/BE komandas es nenovēroju testbench simulācijas laikā tātad pieņemu ka vairāk komandu arī nav.
un bez tām sadaļām tiek atbalstīti Single cycle and burst mode for read and write cycles

koda defaultā ir uzlikti šadi konfigurācijas setingi:

 Device ID  0120h -- PCI kataloga  ir pāris devaisi ar tadu ID
Vendor ID1022h    -- AMD  
Class Code  0580h. -- Tipa Memory controller pec dešifrējuma
Revision ID 01h
tur vēl ir vairāki setup parametri, 
kodā tiek atbalstīta PCI piejamā atmiņas vieta 1Mb liela
PCI Ip core otrā gala interfeis ir Back END interfeis kas ir tāds parasts, un ta te man jāuztaisa kautkāda periferijas kas pie tā piliktos (varētu paņemt kādu FIFO koda gabalu no viena cita Reference IP koda (PCI/WISHBONE Bridge) kur ir 2vi fifo buferi starp šito PCI kodolu un Wisbone Master datu līniju un ta tur galā var kabināt wisbone perifērijas. man liekas ka vienkāršāk sākumā būtu uztaisīt vienkāršu RAM atmiņas PCI kontrollieri kurā ta varētu caur PCI ierakstīt datus Ramā un tad nolasīt, tādejādi pārbaudot vai vispār kautkas iet.un pēc tam varētu mēignāt izmatnot to Wisbone datu magistrāli priekš kādas reālas perifērijas (timeri, QE dekoderi utt.. (līdz par MCU kodolam)
no kompja draiveru puses nekā daudz pagaidām nav, ir piejams viens lattice draiveris ( win 2000 un XP priekš linuxa atrast nevaru (tur noteikti ka būtu klāt SOrce kods)) ar test programmu konfigurēšanai viņu PCI lētajam dev.kitam (tam pa 150$) tur ta ja es šitam kodolam ieliktu to Lattice Devise ID un Vendor ID ta vaidzētu tam draiverim atpazīt šo PCI karti, iespājams ka tā vaidzētu arī darīt.  
Vel iesēja ir pamegināt tos gatavos PCI-33mhz target Ip kodus caur IPexpress kombinācijā ar Micro System Builder uzsintizēt PCI+LatticeMicro32+GPIO ports un ta apskatīties vai vai kautkas iet. (tagat kačāju jauno softa versiju ispLever 8.0m1). jo ir tā ka gribās redzēt vai vispār kautkas tur strādā, un vis ātrāk to pārbaudīt ir ar gataviem Ip evaluation kodiem, un ja kautkas ies ta var domāt kā dabūt pie dzīvibas to Free IP kodu.

----------


## JDat

nu nu. salodeeji jau pirms kaada laika. beidzot iespraudi kompii arii? palaidi?
marasms ne topiks. npat google botam nepietiktu energijas izlasiit tavus palagus.

----------


## Epis

man kautkā bail to PCI karti spraust ejošā kompī, jo 1 platei PCI kontakta forma tika izfrezeta bišķi pa daudz, proti, plati iespraužot iekšā viņas pozīcija var staigāt par 1-1.5 mm līdz ar to ja neiesprauž čotka centrā ta var gadīties ka saiet uz īso signāli, nu labi to +- ar uzmanīgu spraušanu var atrisināt.
Labi īstanībā bīju nometis to plati malā kādus 3-4 menešus un nesen atkal sāku domāt ka kautkas būtu jauztaisa ejoš, un tākā motion kontrollieri ar visiem tur saviem CNC softiem USb interfeisiem, vai PCI, ir sarežgīti, un ātru rezultātu tur nesasniegt, tādēļ atgriezos pie sākotnējās domas par parastu Step/die closed Loop (pid) elektronikas uztaisi stepper motoram tipa iesākumam ko vienkāršu tā lai būtu. 
un tākā gribēju ko vienkāršu ta pardomāju uz kā lai taisa uz Ti Delfino ContrL Card + Base Station kita (99$), cortex-M3, Lattice ECP2 paštaisītās plates, + ciklon fpga platēm (man tur ir gan CII pašlodētā, gan CIII BGA platītes un lielais CII DevKits ED1, karoči sākumā izdomāju iemegināt to TI DELfino 150Mhz FPU proci. 
2 Dienas palasīju proča manuāļus papetiju tās perifērijas un pamegināju CCS v4 softā tur pāris example kodus un kautkā likās tās perifērijas pārāk sarežgitas, tipa likās ka vaidzēs kādas pāris nedeļas lai uzstādītu visus vaidzīgos taimerus, capture kanālus + 2 haedware enkoder dekoderus (vaig 4 iesakumam bet velak vaidzētu kādus  :: , 
karoči izdomāju apstīties kas ir ar Alteras NIOS IIe proci un cik no tām gatavajām IP ir pa velti (bez Evaluation limitiem) un tos testus es tagat (šodien) veicu uz paša pirmā Kita ko jebkad esu pircis -> Ciklon II ED1 kits  (149$) 
karoči līdz šim esu uztaisījis niosIIe sistēmu ar SRAM 256x16 IP +taimers+PIO+JTAG UART+avalon tristate Bridge +onchip RAM 16KB un viss visa sistēma nocompilējās un veiksmīgi uzgenerējās .sof un .pof faili, talāk ar NIOS II IDE palaidu hello world example softu, kods gaja no SRAM čipa, un pieliku klāt vienkāršu LED spīdināšanas sekvences C kodu kur iemegināju to C prifērij kodēšanu, un tas arī iet. 
karoči dienas kārtībā Rīt iemegināt paralēlā FLASH IP, SDRAM Ip vai tie abi ir Free IP komplektā. 
tālāk jamegina uztaisīt kādai vecajai paštaisītajai Petiferijai Software HAL draiveri, agrāk ka nebīj pieredzes ar embedded C nevarēju saprast neko no tiem draiveriem, bet tagat uzmetot aci example kodiem un kā tie kodejās šķiet ka sāku saprast, un tam nevaidzētu būt pārāk sarežģīti.
Vel pamanīju ka nios II IDE softs ir kļuvis krutāks, projektā failu struktūra ir labāk sakārtota, agrāk tur grūti bīj ko atrast tagat secība ir labāka,  + kautkā par brīnumu debbagers strādā un var C kodu hardwarā ietestēt, ja kas agrāk man liekās ka man tā arī nesanāca tos C kodus hardwarā izdebagot, tikai caur speciālo debug client softu ASMā varēju ietestēt.

----------


## JDat

A tev nav kaads mates deelis, kuru tu vari noziedot? protams veelreiz visu kaartiigi paarbaidi...

Sorry, varbuut tu tieshmaam esi nazis FPGA, bet palasot forumu, parauj smiekli. Vakar atkal bija aizsitusies elpa, lasot frekvenchmeera piedziivojumus.

----------


## Epis

karoči vakar ietestēju savu Pārtaisīto veco encoder perifēriju. uzrakstīju vienkāršu Registru REad/Write Heder failu (C draivera sastāvdaļa) un iemetu pāris C test koda rindiņas lai parbaudītu kā strādā perifēirja, un itkā viss strādā (enkoder A,B kanāli bīj izvilkti uz dev.kita KEY[3..0] pogām un debagojot spaidīju 2 pogas Enkoder Sekvencē un itkā COunters skaitīja soļus  :: . 

karoči tagat par pašu Enkoder Perifēriju:
3 registri REad/Write:
0. Timers R/W -> Reads full Step Time OR Writes directly to Timer register, 
1. Counters R/W 
2. Controll  -> 
+ 1 IRQ kanāls
bit0 (Clear Timer ), -- varēju šito bitu nemaz nelikt j
bit1(Clear Counter )
bit2(Enable Enkoder periferiju)
bit3(Clear IRQ),
bit4 DIRection
īstanībā bez bit0 un bit1 fincijām varēja iztikt ierakstot registros 0, bet tīri eksperimentāli uztaisīju tā lai būtu.
rekāds ir Heder Fails kurā definē visus Registrus. Par paraugu nēmu PIO heder failu


```
#ifndef ALTERA_AVALON_ENCODER_H_
#define ALTERA_AVALON_ENCODER_H_

#include <io.h>

#define IOADDR_ALTERA_AVALON_ENCODER_TIMER(base)	 __IO_CALC_ADDRESS_NATIVE(base,0)
#define IORD_ALTERA_AVALON_ENCODER_TIMER(base)             IORD(base, 0)
#define IOWR_ALTERA_AVALON_ENCODER_TIMER(base, data)       IOWR(base, 0, data)

#define IOADDR_ALTERA_AVALON_ENCODER_COUNTER(base)      __IO_CALC_ADDRESS_NATIVE(base, 1)
#define IORD_ALTERA_AVALON_ENCODER_COUNTER(base)        IORD(base, 1)
#define IOWR_ALTERA_AVALON_ENCODER_COUNTER(base, data)  IOWR(base, 1, data)

#define IOADDR_ALTERA_AVALON_ENCODER_CONTROL(base)       __IO_CALC_ADDRESS_NATIVE(base, 2)
#define IORD_ALTERA_AVALON_ENCODER_CONTROL(base)         IORD(base, 2)
#define IOWR_ALTERA_AVALON_ENCODER_CONTROL(base, data)   IOWR(base, 2, data)


#endif /* ALTERA_AVALON_ENCODER_H_ */
```

 reku test C kods:


```
#include "system.h"
#include "altera_avalon_pio_regs.h"
#include "altera_avalon_encoder.h"

int main()
{
	int count = 0;
	int delay;
	int Enc_control =0;
	int Enc_counter =0;
	int Enc_timer =0;
 // printf("Hello from Nios II!\n");  // šitas PrintF aizņem baigi daudz RAM -> 35KB
	while(1)
	{
		IOWR_ALTERA_AVALON_PIO_DATA(PIO_0_BASE, count); // & 0x01);
		delay = 0;
		IOWR_ALTERA_AVALON_ENCODER_CONTROL(ENKODERIS_0_BASE,0x4);// Enable Start  set Bit2
		IOWR_ALTERA_AVALON_ENCODER_COUNTER(ENKODERIS_0_BASE,0x12345); //Write Counter register
		while(delay < 2)
		{
		delay++;
		}
	count++;
		Enc_control = IORD_ALTERA_AVALON_ENCODER_CONTROL(ENKODERIS_0_BASE); // REad Controll Register
		Enc_counter = IORD_ALTERA_AVALON_ENCODER_COUNTER(ENKODERIS_0_BASE); // Read Counter Value
		Enc_timer = IORD_ALTERA_AVALON_ENCODER_TIMER(ENKODERIS_0_BASE); // REad_Timer value
		IOWR_ALTERA_AVALON_ENCODER_CONTROL(ENKODERIS_0_BASE,0x6); // REset COuner ar bit1
		Enc_counter = IORD_ALTERA_AVALON_ENCODER_COUNTER(ENKODERIS_0_BASE);// REad counter value
	}
  return 0;
}
```

 Forši tas kad Intelisense fiča NIosII IDE strādā līdz ar to nav problēmu gramatiski pareizi rakstīt tos garos nosaukumus  ::  
Nēsu vēl Interuptu ar C uzkodējis, pagaidām īsti nav skaidrs kā to var dabūt gatavu, būs jāpameklē Alteras Forumā kāds Example koda gabals, 
Tālāk uztaisīšu fiksi Capture kanālus priekš Step/Dir keršanas no LPT porta, + apstīšos kā kodēt DMA, jeb Avalon MM Master perifēriju kas varētu apkalpot visus Capture kanaļus + ekoder kanālus lai nevaidzētu proci mocīt atbildot uz Interuptiem.
Shēma domāju ka būs tāda ka DMA generēs Interuptu ik pēc 1ms (1Khz) vai arī vairāk kādā 5-10Khz frekvencē, un pa to laiku DMA atbildēs uz Enkoder, Step/Dir capture kanālu IRQ un nolasīs perifērij datus un tos noglabās SRAM atmiņā, un tad pēc 1Khz procis ies un skatīsies SRAM vietā cik tur daudz datu sakrājies un veiks kautkādu PID, sinhronizāciju utt. + DMA IP sadaļā varētu ielikt pa vidu kautkādu step/dir Datu kompresētāju, gļuku filtru, arī ko līdzīgu frekvences palielinātājam, proti no kāda 10Khz step signāla uztaisīt 40Khz, vai 80Khz, un lai zinātu kas tur notiek vaidzēs uzkodēt kādu interfeisu ar Kompi caur RS232 un uz kompja kādu grafisko datu vizualizēšanas interfeisu, lai redz kā tas PID strādā, + kādi erori. 
jāatgādina ka man tam NIOS IIe procim būs tikai kāda 20MIPS jauda  ::  pie 120Mhz clk, baigi sūdīgs performance, bet ja visu signālu keršanu, vakšanu , kompresēšanu utt aizbīda uz Hardware ta procim to jaudu nemaz tik lielu nevaig.

----------


## Epis

karoči Interupts un C kods ar IRQ handler funkciju man tagat stradā, un ejot tālāk esu uzkāries uz bootloder koda  :: .
Nevaru uzgenerēt tos flash programmēsanas failus + fpga iekšējās atmiņas proča ROM bootloder progas failu tā lai varētu ielādēt fpga config.flash atmiņā (.pof fails) to fpga dizainu+ ROM bootloderi un parallel flaškā programmu, ko proča bootloderis pie reset sāks kopēt SRAM atmiņā.  un tad no SRAM ņemt kodu.

Par paraugu uzmantoju Application Note 458 manuāli un example kodu.

tagat par to kas strādā:
iet variants kad fpga ielādē  .sof failu (visu proča sistēmu bez nekādiem bootloder ROM kodiem), un tad caur Nios IDE flash programmer softa Logu uztaisa tos flash failus un nospiežot start ielādē flash atmiņā to programmu, un tad pēc Reset dev.kits sāks strādāt un proga iet, problēma ir tur ka tiko izslēdz platei barošanu un ieslēdz atkal nekas neiet, jo tas ejošais dizains iet tādā kā debbug režīmā proti fpga ielādē .sof failu caur JTAG, bet man vaig lai fpga ielādētu .pof failu caur Configurācijas flash atmiņu bez Jtagiem, līdz ar to ir tā ka debug režimā viss čotka iet bet Stand Alone nekas vēl neiet. 
un cik esu sapratis ta tam Stand alone režimam vaig to fpga iekšējās RAM, vai ROM bootloder progu, kas ielādējās kopā ar fpga konfigurāciju un likt proča reset adresi uz to Bootloderi un tad tas bootloders ielādē no flash SRAM ā pamat programmu, un tālāk parslēdzas koda izpildē no SRAM, pagaidām man šitas vēl neiet.

2. veicu testus proča darbibas ātrummam un ISR rutīnas ātrummam un vispār rezultāti bīj baigi sūdīgie proti 4 asm instrukcijas izpildījās 44clk pie 120Mhz clock  ::   un ISR rutīna enkoderim izpildījās 2872clk   ::   tad sāku domāt, ko tuk sūdīgs performance, izrādās ka kods iet no ārējās SRAM atmiņas, iekšējā atmiņa dizainā bij, bet no turienes kods negāja jo tā ir pārāk maza lai programmu iegrūstu.
izdomāju pamegināt viss ātrāko Nios IIf core proci ar identisku perifērij klāstu un to pašu programmu un rezultāti bij vairāk reizes labāki, proti 4asm instrukciijas aizgāja ar 18clk ātrumu un ISR rutīna paņema 445clk (6.4x ātrāk nekā nios IIe core). 
skaidrs ir viens ka šitā no ārējā SRAM kodu laist nevar, jāizmanto iekšējā fpga RAM atmiņa, bet tākā tās atojoms ir maziņš tad tā ram atmiņa būtu līdzīga Cash atmiņai, īstanībā NIOS IIf procim konfigurācijā tiek piedāvāta Instrukction Cash un Data Cash atmiņas varianti. manā variantā jāņem parastais RAM bloks kā iekšējā atmiņa jāpieliek kāds DMA controllieris un tad jākodē, un kā lai uzraksta tādu programmu es nezinu ! 

vot tā.

----------


## Epis

Palaidu to BootLoder example kodu, kļūda bīj tajā shell comand skriptā ko pa taisno norakstīju no pdf, vaidēj izņemt "\" simbolu un skripts aizgāja un to .flash failu uztaisīja tālāk flash-programmeris ielādēja, pectam ar reset komandu proci resetoju un talāk caur nios2-terminal saņemu savu "Hello world"

reku komandas kādas izmantoju lai no nocompilētā C koda .elf faila uztaisītu flash lādējamo failu: 


```
make_flash_image_script.sh enc_33.elf
bin2flash --input=enc_33.elf.flash.bin --output=enc_33.flash --location=0x00240000
nios2-flash-programmer --base=0x00400000 enc_33.flash
nios2-download -r -g
nios2-terminal
```

 šitās komandas ieliku text failā enc_33_Load_flash.sh un tagat kad jāparbauda kā strādā C kods uz fpga palaižu šo failu šādi " ./enc_33_Load_flash.sh "  un viss čotka aiziet, 
pēdējais dizains Proča sistemai bīj tāda ka pieliku on-chip RAMu, un uzliku to Exception Vector- setup logā, Reset vectora vietā stāv boot-ROMs.
lai C kods ielīstu iekšējā RAM atmiņā izmantoju samazināto "alt_stdio.h" un dabūju koda izmēru samērā mazu ap 2.2KByte.
un tālāk skatījos kāds ir proča performance Interupt rutīnai no starta līdz beigām = 1082clk  ::  (ka kods gaja no SRAM ta bīj 2872clk tākā ir 3x uzlabojums  ::  )
un References tests jeb 4 asm instrukcijas ldw,ldw,sub,stw izpildījās 16clk  ::  (no sram bīj 44clk)
karoči šis tests parāda ka procis iet ar ātrumu 1 instrukcija 4clk  ::  nu pēc datashēeta tā arī sanāk ka e(economiskais) COres tā arī iet, līdz ar to sanāk ka mans 120Mhz mostrs iet ar 30-25 MIPS. 

tālāk darbu sarkastā ir uzlabot ISR ātrumu ar hardware VIC ip, vaidzētu no 1082clk dabūt vismaz 100-200clk ātrumu, un tad jau būtu normāli

----------


## Epis

jaunumi tādi ka partaisīju Enkoder Perifēriju, un pielaboju pašu QE dekoderi, precīzāk, virziena noteicēju, jo vecajā variantā bīj tā ka virziens gļukoja kad raustīju vienu enkoder kanālu, to pamanīju kad ar pogām uz dev kita spaidīju tās 2 enkoder pogas un situācijā ka spiež vienu pogu vairākas reizes vaig enkoder counterim lēkāt +1 un -1 lai pozīcija nemainītos, bet man bīj tā ka bīj vislaik +1 +1 utt.. un otrai pogai vispār nekādas reakcijas uz counteri, īsāk sakot vecie enkoder kodi visi bīj ar defektu (iet viņi iet, bet šadās gļukainās situācijās skaitīja pozīciju greizi.)
Jaunajā kodā:
[attachment=0 :: ehv969l]enkoder_Slave.rar[/attachment :: ehv969l]
gļuku vairāk nekādu nav, pozīcija iet pareizi, un pārsteigums tāds ka jaunā perifērija ir VERLOG kodā rakstīta. ja, jā esu pārgajis uz verlog, un šitas ir pirmais kods kur iemegināju roku verlog kodēšanā, vispār lielāko koda daļu +- varēja pa taisno no VHDL pārkopēt, ar nelielām sintakses izmaiņām, un pārsvarā tās izmaiņas bīj tādas ka vaidzēja kautko nodzēst, proti verlogā kods sanāk mazāks, mazāk jāraksta.

motivācija pamatā bīj tāda ka vairums avalon buss example kodu, un visādi reference design ip ir verlogā, + ja kāds vēl atcerās to laiku ka ņēmos ar Lattice fpga ta tur LatticeMicro32 procis ekskluzīvi bīj tikai Verlogā, un ja es gribētu pārslēgties no nios IIe uz LM32 proci ta tagat ar Verlog perifēriju es to varētu izdarīt ar nelielām ip izmaiņām interfeisā:  avalon būtu jāpartaisa par Wisbone slave standartam atbilstošu interfeisu.

Perifēriju es esu ietestējis uz sava Dev.kita ar veco C kodu un viss iet.

Nākošais ko taisīšu būs 4kāršā enkoder perifērija, kur būs 2 taimeri, viens 1 - 10khz signālam (priekš PID loopa) un otrs enkoder signālu keršanai, 
ideja tāda ka procesors nolasīs enkoder perifēriju ar to intervālu 1-10Khz (būs uzstādāms laiks) lai nevaidzētu kā iepriekšējā variantā procim reagēt uz katru enkodera IRQ signālu un to informāciju lasīt, proti šāda IRQ lēkāšana prasa daudz proča resursus (1082clk) , it sevišķi ja ir tik švaks procis kā nios IIe  ::  
un pārējās perifērijas kā Step/dir kerāju es arī domāju taisīt tādā pašā stillā lai varētu savākst visus Step soļus (kādā Ram fifo bufferī) un tad ik pēc 1ms nolasīt to kas sakrājies un uztaisīt tos PID aprekinus un iegruzīt tālāk signāl generātor perifērijā, kurai arī būs savs fifo bufferis. 

un ja kas nav izslēgts ka es nākotnē pāriešu uz lattice fpga (1 plate man ir ejoša  ::  un to LM32 proci, jo tam ir 4-5x ātrāks par nios IIe + tur būs arī vectorrInterupt controller pielikums lai ātrāk reagētu uz IRQ signāiem a to paši saprotat 1082 clk priekš IRQ tas ir baigi švaki.

----------


## JDat

Epi! A tu ievērtēji Cyclone IV. Kādas atsauksmes? Labāks,jaudīgāks,mazāk enerģiju patērē utt, par Cyclone III?

----------


## Epis

> Epi! A tu ievērtēji Cyclone IV. Kādas atsauksmes? Labāks,jaudīgāks,mazāk enerģiju patērē utt, par Cyclone III?


 Cyclone IV ir labs, vienīgi nopirkt vel nevar, domājams ka cena arī būs daudz zemāka salīdzinot ar vecajiem, par to jau liecina pirmo čipu cenas kas izlikti online store. vispār CIV čipa sūtība ir PCIe-X1 risinājumi, arī lētā gala devaisi, jo čips ir lēts.
Minus čipam ir viens un tā ir Configurācijas shēma kurā atkal nav atbalsta SPI flashkai, jāizmanto viņējo speciālās spi flashkas kas maksā xx reiz dārgāk, tas man besī, ka nevar uztaisīt kā xilinx un lattice kur der lēta SPI flaska

energijas patēriņs man ir samērā vienaldzīgs, galvenais ir Cenas attiecība starp Logiku+ free IP core klāstu , proti cena čipam var būt zema, bet ja ir papildus jāmaksā par IP kodiem ta kopā sanāk viss pasākums padārgs, un Alteras čipiem ar tiem Free IP ir tā pašvaki, proti par brīvu ir tikai zemākās jaudas Nios II procis "e" kas ir totāls "Sūds" salīdzinot ar to ko pa velti piedāvā LatticeMicro32, protams, par maksu situācija ir apgriezti otrāda un tie pa maksu ir daudz Krutāki, ātrāki. 

Manā variantā (taisīt devaisu pāris eksemplāros) lētāk sanāk Lattice čipi ar viņu LM32 proci nekā Altera ar niosIIe 

vispār lielākas izmaksas beigu beigās sanāk Programmās ( Ip, un citos gatavajos risinājumos)

Runājot tālak par CNC kontrollieri ko itkā taisu   ::   man ienāca prāta doma ka jāuzmet acs vēlreiz tam EMC2 CNC softa Sorce kodam safaļi kur dekodē G-kodu + generē tos Step/dir signālus, pirms kāda laika pasen, skatījos un neko tur saprast nevarēju moš tagat ka vairāk no C kodēšanas rubīju kautkāda apgaismība nāks. 
Agrāk man bīj tada ideja ka jauztaisa tāds kā Stand Alone CNC kontrollieris/vadītājs kas dekodētu G-kod analogu un pats Rekinātu tos Step/dir un švaka proča gadījumā uzgenerētu step/dir signālus un noglabātu GB flash atmiņā un tad atliktu fpga čipam nospēlēt no flashkas step/dir signālus + procis nodarbotos ar to PID un asu kordināciju + ziņotu par situāciju kompim, vai printētu ziņas uz kāda miniatura LCD. Tākā es pats neko tālu nēsu ticis ar to G-koda dekodešanu (lineārā ir, un daļēja ejoša Circulārā interpolācija) tad būtu labāk ja paņemtu kādu gatavu koda gabalu un pameginātu to dabūt pie dzīvības.
jebkurā gadījumā būtu intresanti uz debuggera palaist to EMC2 step/dir generātor koda Palagu un ievērtēt kā tur viss notiek, un arī salīdzināt ar savējo  ::

----------


## JDat

Offtopikam:
1. Ko tu domā par AVR+FPGA viena korpusā? Esi skatījies?
2. Kā iet ar DIY PCI plati? Esi iedarbinājis?

----------


## Epis

> Offtopikam:
> 1. Ko tu domā par AVR+FPGA viena korpusā? Esi skatījies?
> 2. Kā iet ar DIY PCI plati? Esi iedarbinājis?


 1. avr-fpga jeb FPSLIC ir tāds neizdevies produkts, kas kā redzams nav guvis lielu popularitāti, vispār daudzi šādi kombo varianti fpga+CPU ir izgāzušies, ja kas tagat atkal itkā nāk tāds vilnis ka ražotāji liks nākošos produktos blakus Fpga- vienu vai 2vus CPU, piemēram actels iemeta cortex-M3 hard IP proci ar visu ekosistēmu savās SmartFusion fpga, nesen Xilinx paziņoja ka likšot nākošajās Virtex fpga jaudīgākos, jaunākos ARM  pročus, nu izskatās ka šī lieta fpga+procis reanimējās, galvenais veco meginājumu klupšanas akmens bīj programmu un visas izstrādes vides zemā kvalitāte(maz gatvu IP, nebīj C-to HDL kodu convertieri, kas dod iespēju C koderiem iegrūst savu C kodu Fpga bez garas logikas kodēšanas, testēšanas, utt,, šitie visi softa instrumenti pamazām ir evalucionējuši un tagat fpga firmas skatās uz MCU,DSP koderu pusi kas neko no logikas nerubī (visi kodē C) un es arī būtu baigi priecīgs ja varētu C-kodu pārvērst logikā un caur krutu GUI pievienot to procim, vai sistēmai, tādas programmas ir bet par tām ir jāmaksā vairāki tūkstoši $$, ceram ka nāktonē tas būs ražotāja free softa pakā, pa velti, domāju ka tāds brīdis pienāks 1-2gadu jautājums.

2. Plate kā tāda strādā, fpga čips iet un konfigurējās, bet PCI karti kompī bāzis nēsu jo nav vēl nekāda koda ar ko varētu testēt PCI interfeisu, bīj ideja izmantot lattice PCI komerciālo IP demo režimā + LM32 proci, bet procim nevarēju dabūt programai vaidzīgo koda izmēru kas saietu fpga RAM atmiņā, pāris dienas,nedeļas atpakaļ itkā izdevās pēc viena example nogriezt C kodā rījīgās programmu daļas un dabūt parastu Led blink softu 2KB (2156byte) izmērā 
ko var iebāzt iekšējā 4Kb Ram, priekš debagošanas (lai ietu debbgeris jākonfigurē proci tā kad Ram atmiņa paliek tikai 2048 baiti kas ir pa maz pat priekš šī softa, līdz ar to reāli debagg režimā proci laist nesanāks (debgers aizņem 2 RAM blokus no 3 blokiem kas ir fpga iekšā  ::  ) 
un lai iemeginātu to PCI IP core būs jāiztiek bez Debaggera.

----------


## JDat

Interesnti a ko saka Windows, kad ieraua DIY PCI plati?  ::  Kā identificē un kādus draiverus prasa...  ::

----------


## Epis

> Interesnti a ko saka Windows, kad ieraua DIY PCI plati?  Kā identificē un kādus draiverus prasa...


 tākā tas ir maksas PCI ip tad viņam nāk klāt windows xp,linux demo example draiveri kas ir jāieinstalē un tad ja fpga plate ies ta kompis atpazīs PCI karti.

----------


## JDat

tas ir skaidrs, ka atpazīs. Bet kās tas par dzelzi būs no logu viedokļa? SCSI kontrolieris, Ethernet karte vai kas cits? Vai arī to var norādīt pats PCI kartes būvētājs. Kāda pieredze? Varbūt kādu ekr
ānšāviņu un koda gabaliņu...

----------


## Epis

vari apstītes GUI un draiverus šajā demo koda example pakā: 
PCI Master/Target 33 MHz/32-Bit Demo v1_0 http://www.latticesemi.com/dynamic/inde ... ce=sidebar

es caru sakonfigurēt to savu PCI perifēriju tā lai viņa ietu zem tā demo draivera un viņējā GUI.

----------


## Epis

esu iemeginājis LM32 proci, kā to programmēt tā lai tas ietu uz mana mazā LFE2-6E fpga čipa, un tagat par to ko esu noskaidrojis sīkāk:
. slikti tas ka LatticeMicro32 proča JTAGs debaggers neiet ar Paralēlā prota programmeri, tikai ar USB (tipa advancētāku) salīdzinājumam Alteras NIOs II debagers Gāja !  Līdz ar to hardware debag režima man nav.
. Sūdīgi tas ka proča koda iztestēšanai jāpārcompilē viss fpga dizains lai uzgenerētu to Fpga configurācijas failu ko ar JTag palaist, Alterai bīj tāda fiča kā Incremental compilation kur quartus nepārsintizēja visu fpga logiku ja izmaiņas bīj tikai iekšējā Fpga RAM bloka datos, tai vietā proga nomainīja RAM saturu un pārtaisīja failu attiecīgi, kas paņēma pāris desmit sekunžu, bet ispLever softs visu pārcompilē un jāgaida kādas 5minūtes (man ir 2kodol AMD procis ar 2Gb ram), cik esu lasījis par to IspLever8.1 softu ta viņiem vaidzētu būt tai incremental compilation fičai bet kautkā savai Free versijai šito nevaru atrast vismaz ne uz Generate Bit stream Data.
. PCI_target_33 ip kas ir Evaluation nosintezējot ar proci generē fpga programmējamos failus bez nekādiem Limitiem, un izdevās pat ielādēt SPI Flash čipā un procis iet stand Alone režimē, protams pagaidām nēsu vēl pašu PCI karti kompī iekšā spraudis un skatījies vai tas IP pats par sevi strādā, bet Salīdzinot ar NIOS II maksas IP kurš gāja tikai 1h un tikai tad kad plate bīj pie Jtag ar atvērtu Quartus softu un nemaz nerunājot to ka netika generēti nekādi flash program faili, šeit Lattice ļauj generēt visus Ip un nekādu linitu, vispār šitas ir kautkā Dīvaini !!.
. Sataisīju fpga konfigruācijas shēmu lai spi flash iekonfigurētu fpga, līdz šim man kautkā negāja, proti gāja tikai kad pabakstīju fpga ProgramN pinu (tipa ar 1nu LO (0) impulsu tiek inicializēta konfigruācija, un es nesapratu kādēl tā konfigurāicja nesākaš pate no sevis, izrādās pie vainas bīj D[0]/SPIFASTN pins ko vaidēja pielikt pie Pull_UP vai Pull_downs bet es bīju atstājis gaisā karājamies, līdz ar to čipa konfig shēma gļukoja, dīvaini tas ka otrā PCB tipā (bez PCI slota, tam kam bīj ARM procis +MACH4000 CPLD) konfig shēma strādāja no pirmās dienas (ka varēju ieprogramēt Spi flashku, izrādās ka tur tas D[0]/SPIFASTN pins bīj aizvilkts pie CPLD čipa kas tad arī defaultā stāvēja ar aktivizētu Pull-UP IO rezistoru līdz ar to viss gāja pats par sevīm, un šito es atklāju ka salīdzināju PCI plati ar to plati, nočakarējos vairākas dienas.
Tehniski varētu kautkad tagat spraust to karti iekšā un skatīties kā to PCI IP konfigurēt lai ietu. un skatīties vai kautkas iet.

----------


## JDat

Aiziet Epi!.
Iemauc kompī to plati jau šovakar. Ne jau lai kaut ko pētītu, bet lai redz ka kaut kas funciklionē. Varbūt pat video vai bildes parādīsi.

----------


## Epis

pirmais tests iespraužot karti kompī: neveiksme ! nekas neiet, velāk izrādījās ka vaina DC-DC LDO regulātorā tas neiet pie 12V, specenē rakstīts ka Max strāvā ir kādi 16V bet darbojās no zem 10V, un par to es tagat pārliecinājos, vispār jau pēc Shēmas tur vaidzēja būt citam regulātoram kas varētu iet pat pie 16V, bet sanāca tā ka pielodēju to kas bīj pa rokai.
rīt pārlodēšanu plašu celiņus un ņemšu strāvu no PCI 5V termināliem.

----------


## JDat

Heh progresiņš. Salīdzinot ar tavu naivumu, kas bija pirms gada. Esi paaudzies. Pat ja tev nesanāks iecerētais CNC kontrolieris, veru ka izkodīsi PCI lietas un varēsi izmantot nopietnākās lietās. Veiksmi.

Izskatās ka zzz uz tevi vairs tik ļoti nebrauc virsū. Tas liecina tikai par to ka esi pieņēmies prātiņā. Malacis.

----------


## Epis

kautkādi gļuki man ar to PCI slotu notiek proti mērot ar Voltmetru rāda ciparu 1 ! kreisajā malā principā cipars 1 parādās tad kad pieliek melno(zemes) kaju pie kāda PCI slota Pina  šito nevaru saprast. Mēgināju arī pamērīt citas PCI kartes kā parasto Ethernet PCI karti un tur arī neizdodās nomērīt nekādus volta līmeņus vislaik rāda 1  (dažreiz kautkā nogļuko testers bet tā ir 1).
bet Tad kad mana fpga PCI karte atrodās ārpus kompja un padod strāvu no parastā 10V DC barošanas bloka ta rāda gan bloka strāvu pareizi gan arī 3.3v un 1.2v līnijas, bet ka liek pie kompja un megina ko nomērīt ta neko nevar nomērīt tipa atkal ir 1  :: .

Izrādās ka Plate bīj uzprojektēta tā ka barošana tika ņemta no 5V PCI piniem tas nozīmē ka DC-Dc regulātoram vaidzētu iet (pārlieicnāt nēsu bet domāju ka vaidzēja iet jo nomērit ar V-metru nesanāk ) un dīvaini ka fpga neiet  :: , ka pieslēdz pie ārējā barošanas bloka ta viss iet. 

nezinu ko lai dara ? pirkt jaunu Multimetru ? 

varu vēl pateikt ka man tas Multimetrs neiet no standart 9V baterijas (es to jau pasen izmetu ārā un pielodēju tur klāt 9V barošanas bloku tā lai nevaidzētu bačas pirkt, moš tam ir kāds sakars ar to Barošanas bloku un Kompja barošanas līniju trokšņiem, tipa multimetrs nevar neko nomērīt jo trokšņi lieli ? tā varētu būt ?

----------


## JDat

Varētu būt arī barošanas problēma multimetram... Sakārto multimetra jautājumu.

----------


## Vikings

Diez vai trokšņi. Drīzāk pamēri citus spriegumus un ja nemērās - pērc jaunu, Tev tā pat viņš ir lētais ķīnietis.

----------


## Epis

Laikam problēma ir fpga koda dizainā, kur es proča Reset_n pinu piekabināju PCI sota PCI_reset_n fiziskajam pinam un sanāk tā ka resets visu laiku stāv aktīvs laikam "1" jo manir logikā ielikts kods kas sīdina Led diodi ja Reset nav aktīvs: 


```
reg LedToggle;

always @(posedge clk33)
begin
  if (reset_n == 0) 	  
	LedToggle <= 0;
	else 
	LedToggle <= 1;
end
assign LedR = LedToggle;
```

 kodu uztaisīju jo sākumā b'ji problēmas ar to Reset (procis negāja) un tagat procis iet tad kad Reset LEds spīd, un ieliekot PCI slotā Reset leds nespīdēja Značit procis logiski ka arī negāja. izeja ir vienkārša jāpārliek Reset_n proča signāls uz citu (brīvo IO ar pul-up), lai proča un PCI_ip reset pini būtu atsevišķi nevis kopā salikti pie viena IO pina.  

a cik maksā multimetrs kam ir barošans bloka Opcija papild baterijām? jo besi ārā tās beterijas mainīt, un vislaik slēgt ārā multimetru ka nevaig, a tā ar barošanas bloku piesledz un ka vaig paņem + bačas nav jāpērk. 

vispār nezinu kā es to PCI interfeisu debbagošu ja uzreiz ar pirmo neaizies ?  ::   proti multikanālu  Oscilaman nav (kādus 5-8 kanālus vaidzētu), kas ietu 33Mhz.
mans 1Mhz 2 kanāl oscils tur neko izdarīt nevarēs  ::  
+ nezinu kā caur datoru debaggot to PCI interfeisu, gan jau kautkā var bet kā? 

pēc pieredzes haļava ar pirmo reizi ir ļoti reta parādība, parasti lai ko tik sarežģitu palaistu nākās pasvīst  kādu nedēļu,mēnesi.

----------


## JDat

Tieši tā, nav tas viss tik vienkārši kā tev liekas. Galvenais sasniegums ir tāds, ka ieliekot PCI karti datorā, neparādījās zili dūmi un ne kas nenosvila. Par Oscili. Kāpēc tev vajadzīgs oscilis? Vai tad nepietiek ar daudzkanālu logisko analizatoru (nopērc vai uzbūvē pats, teiksim kaut vai kaut kas līdzīgs http://www.bitscope.com/ nahrenizējot osciņa daļu un izmantot ligiskā analizatora daļu). Par multimentru ir tā ka barošanas bloks var ienest traucējumus multimentra mērījumos. Nevajag mocīties ar multimentu barokli un baterijām. No manas praktiskās pieredzes darbā: man un kolēģim ir kaut kas līdzigs šitādam http://www.argus.lv/product_info.php...2ee8c00beb9a19 mutimetram uz 9V baterijām. Galvenā ērtība ir automātiska diapazona pārslēgšana. Reizēm mums patīk pazīmēties ar šitādiem multimetriem un tad ieslēdzam Ommetra režīm'un iebāžam 220 V rozetē  :: . Protams ne kas nenodeg, bet ne jau par to ir stāsts. 9V baterija kalpo 6-12 mēneši, jo multimetrs tie ieslēgts tikai tad kad vajag un autorange testerim vajag mazāk tirkšķināt slēdzi ai ieslēgtu to ko vajag. Epim vispār pietie ar DC voltu un ommetra-pīkstuļa režīmiem.   ::  Bez tam mēs ne kad nepērkam (V baterijas, jo mums ir davi kanāli. Reizi gadā aizbraucam pie skaņu kompānijas un savācam no viņiem lietotās 9V baterijas, kuras vairs radiomikrofonos neliek. Neskatoties ka betrijas ir lietots, tik un tā nosēžas 6 mēnešos tikai. Tas no pieredzes.
Tagad Epi padomā racionāli. Pieņemsim ka tev ir sūda testeris. Baterijas jāmaina regulāri. Uzliec tam sūdam barokli un izmanto kā pīkstuli-ommetru. Ja vaja nomērīt kaut ko smalkāk, tad nopērc labu multimetru uz baterijām un ieslēdz un lieto tikai tad kad tam tiešām ir nepieciešamība. Un ne maz nemēģini analizēt to visu no grāmatveža-ekonomista santīmu pisēja viedokļa. Katram darbam paredzēts savs instruments. Auto elektiķim (varbūt) pietiek ar lēto ķīniešu multimetru (Lai arī mana pieredze rāda, ka dažiem auto elektriķiem drošāk iedot auto range multimetru). Ja gribi garantiju ka tavs mērinstruments rāda pareizi, tad lieto attiecīgu mērinstrumentu ar attiecīgu barošanu attiecīgos apstākļos. Lai aina būtu pilnīgāka, Manam kolēģim ir arī kaut kāds 200 Ls vērts multimetrs nopirkts štatos (nosaukumu nezinu), bet to kolēģis izvelk tikai reiz 2 gados, kad intereses pēc nolemjam pārbaudīt vai nokalibrēt mūsu ikdienas multimetrus. Tā ka, atkārtošos. Ikdienas LED mirkšķināšanais vai kontaktu pārbaudei izmanto to pašu ķīnieti ar pašbūvētu barošanas bloku bet ja reizēm vajag nomērīt kaut ko nopietnākā līmenī (PCI barošanu), tad nopērc labāku mantu ar baterijām. Pa cik labo mantu lietosi reti, tad baterija āri strādās gadu. Ehh kāds man palidziņš sanāca.  ::

----------


## Epis

paskatījos Netā oscilus un iebraucu ka vaig meklēt USB logic analyzer  ::  ir visādi brīnumi cenās no 200-300$ tipa virs 100Mhz ar 8-32kanāli, un tad vienā vietā uzgāju OpenSorce projektiņus kur uz FPGA taisa šitos verķus tur performance ir 200Mhz uz kanālu  ::  domāju ka vaig paņemt vainu kādu veco ejošo CIII plati (ar USB uart) vai arī savu Lielo CII dev.kitu tam ir dafiga fpga Logikas + SRAM,SDRAM kautkas būs jāizdomā. 
http://sigrok.org/wiki/Main_Page  kompja programma
un fpga logika ir šai saitā http://www.sump.org/projects/analyzer/ tur viņiem ir arī sava programma bet tā kas augšā ņem vairākus aprarātus, jāskatās kurš man varētu derēt.
Plāns tāds meginās nosakuma palaist PCI tākā tur ir, ja neies tad taisīs augšā to FPGA logisko analizātoru (vispār varētu to analizātoru ieintegrēt pašā PCI kartes FPGA, lai pārbaudītu vai no kompja tiek saņemti visi Signāli, tādejādi pārbaudot čipa Lodējumu, un konstatēt vai viss ir attiecīgi salodēts, kruta būtu ja varētu ieintegrēt to analizātoru  kopā ar procesoru un PCI_IP, bet diemžēl fpga nav tik daudz resursu (vaidzētu RAM atmiņu), lai ko tādu uztaisītu tākā vainu viens vai otrs.

Tas tavs testers izskatās labāks par manējo, vismaz bačas AAA ir normālas (var nopirkt Akumulāt ladējamās un ta lādēt ka vair neiet).
vispār cik esu lasījis ir speciālie fpga analizētor softi tipa kā JTAGs kur ieliek papild logiku iekš fpga un ta skatās kā orginālā logika iet.

----------


## JDat

Vot tā jau ir vīru runa. Vienīgi, negaidīju ka testeris uz AA baterijām, bet enīvei. Mana Filosofija par testriem: ikdienai vajag vienkāršu un lētu (protams man patīk autorange gan ērtuma, gan drošības ziņā). Max ko savam testerim darbā esmu izdarījis, pāris reies izbliezu 350 mA drošinātāju mērot baterijas uz ampēriem. Nepatīkami, jo jājauc ārā un ja tas drošinātājs čupā, nevaru kodiķiem kapacitāti mērīt, jo tas uz to pašu izvadu. Ja jūti, ja vajag niknāku un precīzāku testeri, tad paņem kādu dārgāku, bet lieto tikai izņēmuma gadījumos nevis ikdienā.

Protams, par analizatoriem taisnība. Vari gan pats uztaisīt, gan arī ielikt savā esošajā FPGA, kā debug apendiksu. Neesmu FPGA speciālists, bet es darītu tā: iedzītu iekš FPA LED mirkšķinātāju ar 1 Hz frekvenci, kas mirkšķina visas vajadzīgās FPA mikrenes kājas. Līdz ar to attiecīgajās vietās brutāli ar LED palīdzibu pārbaudītu visus savienojumus uz aci. Savus FPGA pročus (ja kādreiz kaut ko tādu darīšu) debugotu tā: pieliktu klāt kaut ko no liģiskajām ķēdēm tādā veidā, ka varētu mikšķināt ledus uz FPGA kājām. Rezultātā, ka manā loīkā notiek tas un tas, tad LED iedegas, līdz ar to zinu, ka strādā. Apmēram tādā garā.

Zini, pēdējā laikā man sāk parādīties cieņa pret tevi: teksti īsāki, nopietnāki, balstās uz tavu pieredzi, nav plātīšanās, nenotiek katra lodējuma apspriešana, skats uz sitēmām paliek nopietnāks un rcionālāks. Un interesanti: No ZZZ kritikas nav. Tas nozīmē vai nu ZZZ galīgi vecs palicis, vai arī tu viņam vairs nedod iemeslu, lai tevi kritizētu.

----------


## Epis

nopirku testeri, iemēriju PCI kartes barošanas voltus iekš kompja un vis ir normāli, tur kur jābūt 5v ir 5v, kur 3.3 ir 3.3.
Neiešanas problēmu arī atrasu un tas ir SPI config pins Chip Select ko es taisot PCB nepieslēdzu spi flash atmiņai bet gan PCI slot signāliem caur to 3384 bufferi, un man nācās pielodēt to spi flash Cs pinu pie fpga pina, kas ir pielodēts pie PCI slota buffera ar "lidojošo vadu", līdz ar to kad karte ir PCI slotā fpga čips nekonfigurējās   :: . 
lai šo teoriju apstiprinātu pamegināju iekonfigurēt nevis fpga Flash atmiņu (kā pirmstam ar neveiksmi) bet pašu Fpga  ar jtag un ta fpga aizgāja.
būs jāatvieno tas Cs pins no PCI slota un tur jāpievelk kāds brīvā IO sānu vads, nez kā būs ar signāla kvalitāti tādam lidojošam vadam  :: , šito kļūdu ielaidu jo domāju ka spi flshkai to Cs signālu nevaig, ka var to Cs pielikt pie GND (lai vislaik būtu ON un viss ies, tādēļ arī to fpga kāju aizvilku kā GPIO pie PCI slota, un tagat nākās pārtaisīt.

reku bilde [attachment=0:1j8ifx9x]PCI_plate_kompi_v2.JPG[/attachment:1j8ifx9x]

----------


## Vikings

> Neesmu FPGA speciālists, bet es darītu tā: iedzītu iekš FPA LED mirkšķinātāju ar 1 Hz frekvenci, kas mirkšķina visas vajadzīgās FPA mikrenes kājas.


 Doma laba. Ja kāda kāja būs nejauši pievienota pie +, masas vai nepievienota tad to varēs noteikt viegli. Bet ja būs savienotas divas kājas tad gan ar šo paņēmienu nevarēs to noteikt, jo abas kājas mainīsies vienādi nekādi nekropļojot signālu. Drīzāk šādam gadījumam der variants, ja katra kāja mainās ar savu frekvenci - vienkāršākajā gadījumā kā binārais skaitītājs. Tā uzreiz var noteikt problēmas pēc signāla formas kropļojumiem.

----------


## JDat

> ...Bet ja būs savienotas divas kājas tad gan ar šo paņēmienu nevarēs to noteikt, jo abas kājas mainīsies vienādi nekādi nekropļojot signālu. Drīzāk šādam gadījumam der variants, ja katra kāja mainās ar savu frekvenci - vienkāršākajā gadījumā kā binārais skaitītājs. Tā uzreiz var noteikt problēmas pēc signāla formas kropļojumiem.


 Es atkal darītu savādāk. Tad kad notestētu pirmo variantu, ko piedāvāju. Pēc tam vienu pinu uzprogrammētu kā aout un pārējos kā IN, un lasītu IN kāju saturu. Salīdzinātu ar Out kājas saturu, ja redzu anomālijas, tad iemidžinu LED vai kaut ko citu izdaru. Nedomāju ka noteikti vajag tik sarežģīti kā Vikings piedāvā. Bez tam, nesen pirms dažām nedēļām uzrāvos uz kapacitātes problēmām AVR kotrolierī. Nu nedrīkst tā vienkārši raustīt kājas ar 16 MHz fekvenci. No sākuma nevarēju sapras kur problēma, bet pēc tam ātri pieleca, ka I/O piniem ir kapacitāte, uz kuras pārlādēšanu paiet laiks, kā rezultātā teiksim paceļot output pinu no 0 uz 1 un ar nākošo komandu lasa IN pinu, kas pieslēgts klāt (plus vēl manis uzlikta diode, pullup pretestība, līki vadu utt). Tā nedrīkst darīt, jāpagaida nedaudz lai kapacitātes pārlādējas. Kāpec šitas offtopic? Tāpēc, ka Epis, kā jau iesācējs elektronikā (Epis zin kaut ko no programmēšanas, bet ar elektronikas lietām nav tik labi), noteikti uz to uzrausies. Tā ka, programmēšana ir viena lieta, fizika pa visam cita lieta viens no elektronikas baušļiem: tev nebūs ignorēt fizikas likumus, lai ko tu darītu. Tu drīksti izmantot fizikas likumus savā labā (reizēm to sauc par fizikas apčakarēšanu).  ::

----------


## Vikings

Tavs variants ir sarežģītāks par manu. Veidot analītisku programmu viennozīmīgi ir sarežģītāk nekā uzprogrammēt bināro skaitītāju un katrai kājai piebakstīt ar oscili.

----------


## JDat

> Tavs variants ir sarežģītāks par manu. Veidot analītisku programmu viennozīmīgi ir sarežģītāk nekā uzprogrammēt bināro skaitītāju un katrai kājai piebakstīt ar oscili.


 Varbūt ka taisnība. Man pagaidām nav bijis tik daudz kāju ko testēt.  ::  Es joprojām (kā Epis teiktu ::  "niekojos" ar mikrokontrolieriem. Rakstot firmwari utml lietas, parasti kodā iezogas arī dažādas testēšanas padarīšanas (sevišķi ja kaut kas nestrādā) un bieži vien sanāk prototipā ieliks vairākās vietās vienkārši LED mirkšķināšanu ar pogu. Pa cik man ūberduperporgrammētājs (AVR STK500 daļa) mani nedaudz apbēdināja, jo nav debugwire funkcija, nākas visu testēt vai nu stimulatorā vai uz reālas plates. Tas nav efektīvākais variants, bet labāk ne kā nekas un minēšana, pie tam, galvenais ka tādas (arī Vikinga) metodes strādā.

----------


## Vikings

Man softa debugošanai parasti palīdz RS232. Bibliotēkas man priekš tā uzrakstītas, vnk pie konkrētiem procesiem izvadu konkrētus simbolus vai ik pa laikam kāda procesa skaitļus, mērījumus, aprēķinu rezultātus. Ja vajag vēl advancētāk tad nodrošinu abpusēju saikni.

----------


## JDat

Jā, jā. Seriālo portu neņēmu vērā. Uzskatīju ka pie sākotnējās diagnostikas tā stāvoklis ir nezināms. Vispār tā ideja par dažādām frekvencēm nav slikta, ja pie rokas labs oscilis. Enīvei, ir 100 un viens variants kā vekt diagnostiku. Interesanti ka Epis ar savu FPGA pieredzi, pats to neiedomājās un nezināja par logic analizatoriem. Vispār jau Epja gadījumā ne kāds logic analizators nav jāpērk. Esmu pārliecināts, ka vajadzīgo analizatoru Epis var pats uzbūvēt uz kāda no esošajiem kitiem vai pat iebāzt savā motoru kontroliera mikrenē iekšā. Galvenais ir nevis mācēt softu lietoto, bet radoši domāt.   ::

----------


## Vikings

Nu tas ir kā katram ar pieredzi un māku apieties ar instrumentiem.  ::  Ja māk tikt galā ar barošanas pievienošanu un Tx Rx vadu pievienošanu tad jau problēmu nav. Mana ķēde parasti salikšanā un testēšanā ir Barošana -> Programmēšana -> RS232 (ja vispār vajag) -> Perifērijas.

----------


## JDat

Tas lai būtu jautrāk un ar smaidu varētu atcerēties vecos laikus:



> Tādēļ ka parastajiem pročiem, un mātesplatēm nav tādas perifērijas kā quadratūro signālu dekoderi, un frekvences ģenerātor loģikas, ja gribēsi tādas perifērijas tad vaidzēs spraust klāt kādu PCI karti uz kuras būs tā pate FPGA, (es zinu tādas kartes ir) kas tieši domāta priekš signālu ģenerēšanas un arī dekodēšanas maksā ap 200$ tākā tas kas nosākuma izskatījās ļot lēt (procis + mātesplate ->20+20=40Ls beigās izmaksās vēl 140Ls par PCI karti, a man būs kādi 40-60ls (stand alone versija bez kompja (kompis tikai progas ielādēšanai).
> 
> Ir tā ka šādai signālu dekodēšanai un ģenerēšanai viss labāk piemērta ir FPGA,CPLD, un arī mikrokontrollieri kā AVR, PIC 
> līdz ar to vai tas ir prātīgi izmantot Ghz Proci šādām operācijām ???
> 
> Es izmantoju FPGA lai samazinātu detaļu skaitu uz plates, ieliekot fpga 32bit proci + visus hardware signālu dekoderus, ģenerātorus, ja nebūtu FPGA tad man vaidzētu normālu CPLD ar kādiem 500 loģikām + kādu arm7 proci vai pat ko jaudītāku kā AVR32 A7000 proci, tākā ar FPGA es ietaupu uz lodēšanas un detaļu skaita, un kopā energo patēriņš būs zems jo 65nm ciklon 3 ēd ļoti maz varēs darbināt no USB vada (ja gribēs DDR atmiņu darbināt tad vaidzēs ārējo barošanas bloku jo tā atmiņ viena pate var noēdīs ap 1Watu (tur bīj dokumentos ka ēd 200-400ma (2,5V) lasot netiek vēl skaitīts ko noēd katra DQ datu līnija, kopā tas cipars būs ap un pat virs 1Wata. lai tādu vienu DDR čipu darbinātu.


 http://www.elfa.lv/forum/viewtopic.p...lit=pci#p21727

----------


## JDat

slēgts, jo epis vairs nebūvē.

----------

