hallo, ich habe zig launchpads hier rumliegen, bei denen ich mir nicht sicher bin, ob sie tadellos funktionieren. ich möchte jetzt gerne ein programm entwickeln, mit dem ich jede funktion des msp430 (der 20 pin chip) testen kann. ich weiß nur nicht, wie ich damit am besten beginnen kann. hat da jemand ein paar ideen für mich?
Es reicht wenn du die Ein/Ausgaenge testes ob die funktionieren. Das intern z.B. ein Timer nicht funktioniert und der Rest geht duerfte sehr unwahrscheinlich sein.
Danke, das sehe ich auch so, würde aber dennoch gerne eine nahezu 100% Prüfung haben, sprich die timer, analog digitalwandler die serielle Schnittstelle, etc.... und dann auch gerne Wissen, woran es bei dem µC hapert, sprich eine Art von Ausgabe des Fehlers. ich dachte mir, dass ich ein programm schreibe, bei dem die ports zuerst getestet werden, also sprich die Sachen zuerst, die am häufigsten kaputt gehen. Evtl. noch ein 2. msp verwenden, der über die serielle Schnittstelle den zu prüfenden MSP "abfragt" oder ist das schon wieder zu kompliziert gedacht....
Warum sollten die µCs denn überhaupt defekt sein? Lohnt der Test-Aufriss bei einem Zwei-euro-fünfzig-Bauteil? (Einzelpreis, Netto, 'G2553 bei Farnell, in Stückzahlen wirds deutlich günstiger)
geht halt darum einen paar schülern die vorhandenen launchpads in die hand zu drücken, damit die rumprobieren können. Wir haben etwa 100 launchpad packages hier rumliegen, bei denen ich mir nicht sicher sein kann, ob die alle funktionieren. ist doch blöd, wenn jemand ein launchpad bekommt, bei dem der µC nicht funktioniert. Neu kaufen ist auch ne möglichkeit, aber ich möchte lieber die vorhandenen resourcen nutzen. natürlich soll auch die funktionsprüfung dazu dienen, dass wenn jemand den MSP kaputt gemacht hat, ihm zu erklären, woran es gelegen hat, damit sowas nicht nochmal passiert.
Fall 1. Bei kleinen Stückzahlen siehe Kommentar von Rufus T. Firefly. Fall 2. Bei großen Mengen (z.B.) Produktsmengen: - a. Such dir einen Test-Ing. / Meßtechniker oder - b. * Mach denn erst Schritt und schreib dir eine Testspec in der du erstmal festlegst welche Funktionen getestet werden sollen und/oder welche Funktionen charakterisiert werden sollen (behilflich dabei ist natürlich das Datasheet vom MSP430). Dabei schreibst du auch gleich die Limits und Conditions dafür auf. * Und dann kannst du überlegen ob sich der Aufwand noch lohnt -> wenn es sich lohnen sollte: Überleg dir eine Methodik wie du am schnellsten alle Tests durchführen kannst. Dabei wird dir sicherlich auch jemand aus dem Forum behilflich sein können.
Schön wäre es doch diese Aufgabe an die Schüler zu geben. Jede Gruppe schreibt ein Teil des Testprogramms :)
vielen dank @ huthut ist eine sehr gute idee @ Jörg S ich muss nur zuerst alles selbst einwandfrei hinbekommen. also ich möchte die sache schon gerne selbst machen und nicht auslagern. denke zu prüfen sollte ich Ports,Uart, Usart,Timer,Adc und die Schnittstelle. grundlegende idee: ich hab 2 launchpads miteinander verbunden, port mit port. ich schreib ein programm, was jede funktion mal testet, zuerst die ports, lasse dann für z.b. 0,5 s ne 1 auf die ports, das 2. launchpad soll dann eine routine drin haben, die die 1 auf dem bestimmten port erwartet. so mit allen anderen sachen auch. tritt ein unerwartetes event auf, wird die sache abgebrochen. schön wöäre es natürlich auch, wenn man sehen könnte, wo es hapert.
>also ich möchte die sache schon gerne selbst machen Ja, mein Gott dann mach es doch und laber hier nicht rum. Wo ist eigentlich dein Problem? >denke zu prüfen sollte ich Ports,Uart, Usart,Timer,Adc und die >Schnittstelle. Und das alles für 2 Euro fuffzig? Ach nö. >grundlegende idee: >ich hab 2 launchpads miteinander verbunden, port mit port. Ja, ist ok. Machen Sie es so;)
danke für deinen konstruktiven beitrag holger, du hast einige sehr wichtige informationen zu meinem beitrag hinzugefügt und mein brainstorming entscheidend bereichert, ich hoffe du bereicherst noch viele andere user mit deinem wissen, sodass du nicht mehr länger hier im thema mit deiner fachkompetenz herrumstrunzen musst. DANKE!
Meiner Meinung nach reicht es, wenn du GPIOs und die Peripherie (ADC, Komparator, ...) testest. Interne Funktionen wie Timer, RAM, CPU, SPI, UART, PWM, DMA, ... gehen normalerweise nicht einzeln kaputt.
>ich hoffe du bereicherst noch >viele andere user mit deinem wissen, sodass du nicht mehr länger hier im >thema mit deiner fachkompetenz herrumstrunzen musst. DANKE! Lern erst mal Rechtschreibung. >ich weiß nur nicht, wie ich damit am besten beginnen kann. Das disqualifiziert dich doch schon von Anfang an. Mach dir einen Plan wie du prüfen möchtest. Dann fängst du ganz klein mit den Port IO Funktionen an. Koppel die beiden per Uart. Der Tester sendet Befehle und das Testobjekt muss sie ausführen. Das ist der erste Schritt. Weitere werden folgen falls du das auf die Reihe bekommst. Die Testtiefe hängt dann davon ab wie gut du programmieren kannst.
Hallo, ich bin der selben Meinung wie "Der". Den Umweg über zwei Msps finde ich etwas zu aufwändig, da du die beiden ja "syncronisieren" musst. Einfacher wäre es doch, auf EINEM Launchpad die Ports zu verbinden...
Da es hier darum geht Studenten was beizubringen: - IAR IDE nehmen dann kannst du dir die einzelnen Register mit aktuellem Content anzeigen lassen. - Referenzapplikationen entwickeln / Library bereitstellen. - Einen billigen LA anschaffen ( z.B. Open Logic Sniffer ~50 € ) und live debuggen - Vielfachmessgerät hilft auch . Das ganze beeindruckt die Kids und steigert wahrscheinlich deren Neugierde. Und wenn mit den oben genannten Mitteln der Fehler immer noch nicht gefunden wurde -> neues Launchpad geben und weiter machen. Im Normalfall sind die Funktionalitäten durch TI selber schon in der Produktionslinie geprüft worden - wenn auch nur mit statistischen Waferprobe etc. - so das es hoffentlich nicht zu deinen Befürchtungen kommt.
>Im Normalfall sind die Funktionalitäten durch TI selber schon in der >Produktionslinie geprüft worden - wenn auch nur mit statistischen >Waferprobe etc. - so das es hoffentlich nicht zu deinen Befürchtungen Es geht hier darum uC zu prüfen die von den Probanden grob misshandelt wurden.
holger schrieb: >>Im Normalfall sind die Funktionalitäten durch TI selber schon in der >>Produktionslinie geprüft worden - wenn auch nur mit statistischen >>Waferprobe etc. - so das es hoffentlich nicht zu deinen Befürchtungen > > Es geht hier darum uC zu prüfen die von den Probanden > grob misshandelt wurden. Das ist mir bewusst. Aber das kann man am schnellsten mit einem Vielfachmessgerät und den angefertigten Referenzapplikationen testen.
Bei allen 100 Launchpads den MSP430G2553 auzuwechseln dauert etwa 20 Minuten und kostet ungefähr 100€. Frage: Lohnt sich dann noch die ganze Testerei?
Gregor B. schrieb: > Bei allen 100 Launchpads den MSP430G2553 auzuwechseln dauert etwa 20 > Minuten und kostet ungefähr 100€. > Frage: Lohnt sich dann noch die ganze Testerei? Wenn man nach jeder Unterrichtsstunde diesen wechsel machen muss wahrscheinlich schon :)
Such doch mal nach EasyMSP. Das ist eine Lib fuer das Launchpad. Damit kannst Du eignetlich alles testen.
hallo, hab jetzt mal ein wenig gebastelt. hab nun also 2 launchpads auf einander gesteckt, oben das zu testende mit dem 2231 er und unten der große 2553 er als tester. der tester hat folgenden code:
1 | #include <msp430g2553.h> |
2 | #define BIT0 (0x0001)
|
3 | #define BIT1 (0x0002)
|
4 | #define BIT2 (0x0004)
|
5 | #define BIT3 (0x0008)
|
6 | #define BIT4 (0x0010)
|
7 | #define BIT5 (0x0020)
|
8 | #define BIT6 (0x0040)
|
9 | #define BIT7 (0x0080)
|
10 | |
11 | |
12 | int main(void) |
13 | {
|
14 | WDTCTL = WDTPW + WDTHOLD; // Stop watchdog timer |
15 | P1OUT = 0x00; |
16 | P1IN = 0x00; |
17 | P1OUT = BIT0; |
18 | P1DIR |= BIT0 + BIT6 + BIT2; |
19 | if (((BIT1) & P1IN)) |
20 | {
|
21 | P1OUT =BIT2 ; //wenn 1 an bit1 dann 1 an bit 2 |
22 | }
|
23 | else
|
24 | {
|
25 | while(1) |
26 | {
|
27 | volatile unsigned int i; |
28 | |
29 | P1OUT ^= BIT6; // Toggle P1.0 using exclusive-OR |
30 | |
31 | i = 50000; // Delay |
32 | do (i--); |
33 | while (i != 0); |
34 | }
|
35 | }
|
36 | |
37 | |
38 | |
39 | P1IN = 0x00; |
40 | P1DIR |= BIT4; |
41 | if (((BIT3) & P1IN)) |
42 | {
|
43 | P1OUT |=BIT4; |
44 | }
|
45 | else
|
46 | {
|
47 | while(1) |
48 | {
|
49 | volatile unsigned int i; |
50 | |
51 | P1OUT ^= BIT6; // Toggle P1.0 using exclusive-OR |
52 | |
53 | i = 50000; // Delay |
54 | do (i--); |
55 | while (i != 0); |
56 | } //sonst ok =0 damit abgebrochen wird |
57 | }
|
58 | |
59 | |
60 | |
61 | |
62 | |
63 | P1IN = 0x00; |
64 | P1DIR |= BIT6; |
65 | if (((BIT5) & P1IN)) |
66 | {
|
67 | P1OUT |=BIT6; |
68 | }
|
69 | else
|
70 | {
|
71 | while(1) |
72 | {
|
73 | volatile unsigned int i; |
74 | |
75 | P1OUT ^= BIT0; // Toggle P1.0 using exclusive-OR |
76 | |
77 | i = 50000; // Delay |
78 | do (i--); |
79 | while (i != 0); |
80 | } //sonst ok =0 damit abgebrochen wird |
81 | }
|
82 | |
83 | |
84 | |
85 | P1IN = 0x00; |
86 | P1DIR |= BIT1; |
87 | if (((BIT7) & P1IN)) {P1OUT |=BIT1;} //wenn 1 an bit7 dann 1 an bit 1 |
88 | else
|
89 | {
|
90 | while(1) |
91 | {
|
92 | volatile unsigned int i; |
93 | |
94 | P1OUT ^= BIT6; // Toggle P1.0 using exclusive-OR |
95 | |
96 | i = 50000; // Delay |
97 | do (i--); |
98 | while (i != 0); |
99 | } //sonst ok =0 damit abgebrochen wird |
100 | }
|
101 | |
102 | P1IN = 0x00; |
103 | P1DIR |= BIT3; |
104 | if (((BIT0) & P1IN)) {P1OUT |=BIT3; } //wenn 1 an bit0 dann 1 an bit 3 |
105 | else
|
106 | {
|
107 | while(1) |
108 | {
|
109 | volatile unsigned int i; |
110 | |
111 | P1OUT ^= BIT6; // Toggle P1.0 using exclusive-OR |
112 | |
113 | i = 50000; // Delay |
114 | do (i--); |
115 | while (i != 0); |
116 | } //sonst ok =0 damit abgebrochen wird |
117 | }
|
118 | |
119 | |
120 | |
121 | |
122 | P1IN = 0x00; |
123 | P1DIR |= BIT5; |
124 | if (((BIT2) & P1IN)) {P1OUT |=BIT5;} //wenn 1 an bit2 dann 1 an bit 5 |
125 | else
|
126 | {
|
127 | while(1) |
128 | {
|
129 | volatile unsigned int i; |
130 | |
131 | P1OUT ^= BIT6; // Toggle P1.0 using exclusive-OR |
132 | |
133 | i = 50000; // Delay |
134 | do (i--); |
135 | while (i != 0); |
136 | } //sonst ok =0 damit abgebrochen wird |
137 | }
|
138 | |
139 | P1IN = 0x00; |
140 | P1DIR |= BIT4; |
141 | if (((BIT4) & P1IN)) {P1OUT |=BIT7;} //wenn 1 an bit4 dann 1 an bit 7 |
142 | else
|
143 | {
|
144 | while(1) |
145 | {
|
146 | volatile unsigned int i; |
147 | |
148 | P1OUT ^= BIT6; // Toggle P1.0 using exclusive-OR |
149 | |
150 | i = 50000; // Delay |
151 | do (i--); |
152 | while (i != 0); |
153 | } //sonst ok =0 damit abgebrochen wird |
154 | }
|
155 | }
|
und der zu prüfende:
1 | #include <msp430g2231.h> |
2 | #define BIT0 (0x0001)
|
3 | #define BIT1 (0x0002)
|
4 | #define BIT2 (0x0004)
|
5 | #define BIT3 (0x0008)
|
6 | #define BIT4 (0x0010)
|
7 | #define BIT5 (0x0020)
|
8 | #define BIT6 (0x0040)
|
9 | #define BIT7 (0x0080)
|
10 | |
11 | |
12 | int main(void) |
13 | {
|
14 | WDTCTL = WDTPW + WDTHOLD; // Stop watchdog timer |
15 | P1OUT = 0x00; |
16 | P1IN = 0x00; |
17 | P1DIR |= BIT1; |
18 | if (((BIT0) & P1IN)) |
19 | {
|
20 | P1OUT =BIT1 ; |
21 | }
|
22 | //else
|
23 | //{
|
24 | // while(1)
|
25 | // {
|
26 | // volatile unsigned int i;
|
27 | |
28 | // P1OUT ^= BIT6; // Toggle P1.0 using exclusive-OR
|
29 | |
30 | // i = 50000; // Delay
|
31 | // do (i--);
|
32 | // while (i != 0);
|
33 | // }
|
34 | //}
|
35 | |
36 | |
37 | |
38 | P1IN = 0x00; |
39 | P1DIR |= BIT3; |
40 | if (((BIT2) & P1IN)) |
41 | {
|
42 | P1OUT |=BIT3; |
43 | }
|
44 | //else
|
45 | // {
|
46 | // while(1)
|
47 | // {
|
48 | // volatile unsigned int i;
|
49 | |
50 | // P1OUT ^= BIT6; // Toggle P1.0 using exclusive-OR
|
51 | |
52 | // i = 50000; // Delay
|
53 | // do (i--);
|
54 | // while (i != 0);
|
55 | // } //sonst ok =0 damit abgebrochen wird
|
56 | //}
|
57 | |
58 | |
59 | |
60 | |
61 | |
62 | P1IN = 0x00; |
63 | P1DIR |= BIT5; |
64 | if (((BIT4) & P1IN)) |
65 | {
|
66 | P1OUT |=BIT5; |
67 | }
|
68 | //else
|
69 | //{
|
70 | // while(1)
|
71 | // {
|
72 | // volatile unsigned int i;
|
73 | //
|
74 | // P1OUT ^= BIT0; // Toggle P1.0 using exclusive-OR
|
75 | //
|
76 | // i = 50000; // Delay
|
77 | // do (i--);
|
78 | // while (i != 0);
|
79 | // } //sonst ok =0 damit abgebrochen wird
|
80 | // }
|
81 | |
82 | |
83 | |
84 | P1IN = 0x00; |
85 | P1DIR |= BIT7; |
86 | if (((BIT6) & P1IN)) {P1OUT |=BIT7;} |
87 | // else
|
88 | // {
|
89 | // while(1)
|
90 | // {
|
91 | // volatile unsigned int i;
|
92 | |
93 | // P1OUT ^= BIT6; // Toggle P1.0 using exclusive-OR
|
94 | |
95 | // i = 50000; // Delay
|
96 | // do (i--);
|
97 | // while (i != 0);
|
98 | // } //sonst ok =0 damit abgebrochen wird
|
99 | //}
|
100 | |
101 | P1IN = 0x00; |
102 | P1DIR |= BIT0; |
103 | if (((BIT1) & P1IN)) {P1OUT |=BIT0; } |
104 | //else
|
105 | //{
|
106 | //while(1)
|
107 | // {
|
108 | // volatile unsigned int i;
|
109 | //
|
110 | // P1OUT ^= BIT6; // Toggle P1.0 using exclusive-OR
|
111 | //
|
112 | // i = 50000; // Delay
|
113 | // do (i--);
|
114 | // while (i != 0);
|
115 | // } //sonst ok =0 damit abgebrochen wird
|
116 | //}
|
117 | |
118 | |
119 | |
120 | |
121 | P1IN = 0x00; |
122 | P1DIR |= BIT2; |
123 | if (((BIT3) & P1IN)) {P1OUT |=BIT2;} |
124 | //else
|
125 | //{
|
126 | // while(1)
|
127 | // {
|
128 | // volatile unsigned int i;
|
129 | //
|
130 | // P1OUT ^= BIT6; // Toggle P1.0 using exclusive-OR
|
131 | //
|
132 | // i = 50000; // Delay
|
133 | // do (i--);
|
134 | // while (i != 0);
|
135 | // } //sonst ok =0 damit abgebrochen wird
|
136 | //}
|
137 | |
138 | P1IN = 0x00; |
139 | P1DIR |= BIT4; |
140 | if (((BIT5) & P1IN)) {P1OUT |=BIT4;} |
141 | //else
|
142 | //{
|
143 | // while(1)
|
144 | // {
|
145 | // volatile unsigned int i;
|
146 | // //
|
147 | // P1OUT ^= BIT6; // Toggle P1.0 using exclusive-OR
|
148 | |
149 | // i = 50000; // Delay
|
150 | // do (i--);
|
151 | // while (i != 0);
|
152 | // } //sonst ok =0 damit abgebrochen wird
|
153 | //}
|
154 | |
155 | P1IN = 0x00; |
156 | P1DIR |= BIT6; |
157 | if (((BIT7) & P1IN)) {P1OUT |=BIT6;} |
158 | //else
|
159 | //{
|
160 | //while(1)
|
161 | // {
|
162 | // volatile unsigned int i;
|
163 | |
164 | // P1OUT ^= BIT6; // Toggle P1.0 using exclusive-OR
|
165 | |
166 | // i = 50000; // Delay
|
167 | // do (i--);
|
168 | // while (i != 0);
|
169 | // } //sonst ok =0 damit abgebrochen wird
|
170 | // }
|
171 | |
172 | |
173 | |
174 | |
175 | |
176 | |
177 | }
|
wenn ich die pinne an den pads einzeln drücke, also die beiden boards seprariert benutze und 1 auf die jeweiligen zu prüfenden pinne l lege klappt alles ganz gut. mein problem ist jetzt, dass ich eine art shake hands brauche. beide codes laufen auf jedem µc ab, ich brauche es aber sequentiell. ideen fürs brainstorming? vereinfacht ausgedrückt: wenn der tester auf p1.0 ne 1 gibt muss der zu prüfende solange warten, bis die 1 an p1.0 kommt, oder aber eine bestimmte zeit überschritten ist und dann ein feedback an den tester gibt, damit der tester anzeigen kann, dass die zeit überschritten wurde. ich brauche also irgendwie eine funktion des wartens. leider hab ich noch nicht die ahnung von timern, vllt. kann jmd. ein bsp geben?
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.