Hallo, ich heiße Florian und bin Student. Innerhalb meines 6. Semesters habe ich in einer Firma ein BAC-Praktikum zu absolvieren, in dem ich eine BAC-Arbeit schreiben soll. Als Aufgabenstellung wurde mir die Implementierung eines Linux-Gerätetreibers aufgegeben, für den BeagleBone Black(Sitara AM3358). Dieser soll eine SPI Schnittstelle zur Verfügung stellen, in der der BeagleBone als Slave arbeitet. Damit ich das bewerkstelligen kann, möchte ich einen Linux-Treiber schreiben. Ich beschäftige mich nun zum ersten mal praktisch mit Linux-Treibern, also bitte ich um Nachsicht... ;) Ich bin nun schon so weit, dass der Char Device Treiber läuft. Um nun die Register des Prozessors zu manipulieren, hätte ich nun mit request_mem_region() mir einen Speicher allokiert und mit ioremap() die Register in den virtuellen Speicher geholt. Leider funktioniert die Funktion ioread() nicht, obwohl ich ihr den Pointer von ioremap() übergebe. ich hoffe, jemand weiß weiter... LG - ein schönes Wochenende Flo
Florian R. schrieb: > Dieser soll eine SPI Schnittstelle zur Verfügung stellen, in > der der BeagleBone als Slave arbeitet. https://groups.google.com/d/topic/beagleboard/0ge_TozyTIE https://groups.google.com/d/topic/beagleboard/UC6pUfQXsWg > ich hoffe, jemand weiß weiter... Ohne Quellcode?
Da das mit den oben genannten Möglichkeiten nicht geht, würde ich es gerne mit dem Linuxkernel implementieren, der Prozessor kann als Slave arbeiten, jedoch muss ich dazu auf die Register des Prozessors zugreifen können. Anbei der Code:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
25 | |
26 | |
27 | |
28 | |
29 | |
30 | |
31 | |
32 | |
33 | |
34 | |
35 | |
36 | |
37 | |
38 | |
39 | |
40 | |
41 | |
42 | |
43 | |
44 | |
45 | |
46 | |
47 | |
48 | |
49 | |
50 | |
51 | |
52 | |
53 | |
54 | |
55 | |
56 | |
57 | |
58 | |
59 | |
60 | |
61 | |
62 | |
63 | |
64 | |
65 | |
66 | |
67 | |
68 | |
69 | |
70 | |
71 | |
72 | |
73 | |
74 | |
75 | |
76 | |
77 | |
78 | |
79 | |
80 | |
81 | |
82 | |
83 | |
84 | |
85 | |
86 | |
87 | |
88 | |
89 | |
90 | |
91 | |
92 | |
93 | |
94 | |
95 | |
96 | |
97 | |
98 | |
99 | |
100 | |
101 | |
102 | |
103 | |
104 | |
105 | |
106 | |
107 | |
108 | |
109 | |
110 | |
111 | |
112 | |
113 | |
114 | |
115 | |
116 | |
117 | |
118 | |
119 | |
120 | |
121 | |
122 | |
123 | |
124 | |
125 | |
126 | |
127 | |
128 | |
129 | |
130 | |
131 | |
132 | |
133 | |
134 | |
135 | |
136 | |
137 | |
138 | |
139 | |
140 | |
141 | |
142 | |
143 | |
144 | |
145 | |
146 | |
147 | |
148 | |
149 | |
150 | |
151 | |
152 | |
153 | |
154 | |
155 | |
156 | |
157 | |
158 | |
159 | |
160 | |
161 | |
162 | |
163 | |
164 | |
165 | |
166 | |
167 | |
168 | |
169 | |
170 | |
171 | |
172 | |
173 | |
174 | |
175 | |
176 | |
177 | |
178 | |
179 | |
180 | |
181 | |
182 | |
183 | |
184 | |
185 | |
186 | |
187 | |
188 | |
189 | |
190 | |
Florian R. schrieb: > Um nun die Register des Prozessors zu manipulieren, Was hat das mit einem SPI-Devicetreiber zu tun? Was für Daten soll der "Slave"-Treiber denn dem Master zur Verfügung stellen? Das klingt reichlich wirr.
Gast
#4478645
Moin, von einem solchen Vorhaben kann ich gleich abraten, ein Linux-Host kann niemals zuverlässig als SPI Slave arbeiten. Das hat schlicht damit zu tun, dass das Timing von Linux nicht garantiert werden kann. Was geht, ist i2c. Tut mir leid, aber hier erschleicht sich der Eindruck, dass der Aufgabensteller nicht viel nachgedacht hat. Für einen SPI Slave ist auf jeden Fall eine HW-Implementierung nötig. Also, wenn es denn eine Übungsaufgabe mit Sinn sein soll: Gleich zum FPGA greifen. Grüsse, - Strubi
Es wäre vielleicht eine bessere Idee, den SPI-(Master-)Treiber entsprechend anzupassen: https://e2e.ti.com/support/arm/sitara_arm/f/791/p/281877/987362 https://patchwork.kernel.org/patch/76677/
Strubi schrieb: > ein Linux-Host kann niemals zuverlässig als SPI Slave arbeiten. Eine allgemeine SPI-Schnittstelle, bei der man in Echtzeit reagieren muss, ist in der Tat nicht möglich. Allerdings haben die McSPI FIFOs und DMA-Unterstützung; je nach Art des tatsächlich verwendeten Protokolls könnte man damit durchaus etwas anfangen.
Gast
#4481978
Schau dir mal die PRUs auf dem BBB an.
Ich kann hier nur auf die Möglichkeit verweisen mit dem reservieren eines der Cores für den Echtzeit betrieb. Stichwörter „Mercury” und „Cobalt”. So würde das Linux um den Echtzeit fähigen „Cobalt” erweitert.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.