SPI_SS beim XMega?

  • 1
  • 2
  • Page 1 of 2
ThomasW69
 
Avatar
 
Subject:

SPI_SS beim XMega?

 · 
Posted: 29.09.2010 - 08:42  ·  #1
Man konnte ja bisher bei Nichtverwendung von des SS-Ausgangs
SPI_SS =false;
definieren.

Geht das auch beim Xmega so. Ich habe zum beispiel 2 SPI-Geräte am Bus (SPI_F) hängen und will aber hierfür PortA.1 und PortA.2 als SS nehmen. Die Steuerung dieser soll durch die Software erfolgen. Im HAndbuch steht, daß SPI_SS= False; beim Xmega nicht geht?
Kann ich überhaupt beim XMega mit dem Low Level treiber SPI_F mehrere Alternative SS-Leitungen verwenden oder muss ich da auf den Software-Treiber wechseln?
rh
Administrator
Avatar
Gender:
Location: Germany
Age: 24
Homepage: e-lab.de
Posts: 5558
Registered: 03 / 2002
Subject:

Re: SPI_SS beim XMega?

 · 
Posted: 29.09.2010 - 13:38  ·  #2
Hallo Thomas,

an diesen Fall hatte ich nicht gedacht. Deshalb ist mit dem nächsten Update auch das zulässig:

SPI_SSF = none;

rolf
ThomasW69
 
Avatar
 
Subject:

Re: SPI_SS beim XMega?

 · 
Posted: 29.09.2010 - 17:07  ·  #3
Dann bitte die andern SPI's nicht vergessen und nicht nur den SPI_F.
rh
Administrator
Avatar
Gender:
Location: Germany
Age: 24
Homepage: e-lab.de
Posts: 5558
Registered: 03 / 2002
Subject:

Re: SPI_SS beim XMega?

 · 
Posted: 29.09.2010 - 17:17  ·  #4
klaro :bandit: :police:
ThomasW69
 
Avatar
 
Subject:

Re: SPI_SS beim XMega?

 · 
Posted: 29.09.2010 - 17:21  ·  #5
Wie ist das eigentlich beim RTC vom Xmega.
Ich hab den so initialisiert, aber er springt nie in die Callback Function

Import SysTick, RTClock,...
From RTclock Import RTCtimer;
From SysTick import SystemTime32;

define
OSCtype = int32MHz, PLLmul=4, prescB=1, prescC=1;
SysTick = 10, adj;
RTclock = iData, DateTime;
RTCsource = SysTick;

{--------------------------------------------------------------}
{ functions }


Procedure RTCtickSecond; {CallBack procedure}
begin
Writeln(SeroutC1,'Tick'); //kommt nicht
end;
rh
Administrator
Avatar
Gender:
Location: Germany
Age: 24
Homepage: e-lab.de
Posts: 5558
Registered: 03 / 2002
Subject:

Re: SPI_SS beim XMega?

 · 
Posted: 29.09.2010 - 17:52  ·  #6
Hallo Thomas,

das ist extrem gefährlich:

Procedure RTCtickSecond; {CallBack procedure}
begin
Writeln(SeroutC1,'Tick'); //kommt nicht
end;

In einer CallBack Funktion hi-level Treiber ansprechen -> Register Zerstörung und lange Interrupt Sperrzeit. Wenn dann SerOut noch auf Interrupts wartet die den TxBuffer leeren müssen, stirbt das ganze System, da in CallBacks (aus Interrupts) ja die Interrupts gesperrt sind.

Hier lieber mal ein Port-Pin toggeln...

Sollte da ein Compiler Fehler vorliegen, dann muss ich das Testen.

rolf
ThomasW69
 
Avatar
 
Subject:

Re: SPI_SS beim XMega?

 · 
Posted: 29.09.2010 - 18:45  ·  #7
Ah ok, das erklärt einige Probleme, die ich ab und zu hatte.
ICh muss aber in bestimmten zeitabständen, nämlich genau sekündlich umfangreiche astronomische Berechnungen durchführen. Die will ich aber nicht in die Hauptschleife packen. Ich könnte evtl. einen Prozess/Task anlegen, der das erledigt und dann in der Callback Funktion nur den Prozess neu starten. Sobald er fertig ist, wird er im falle eines Prozesses schlafen gelegt. Sollte doch gehen oder?
rh
Administrator
Avatar
Gender:
Location: Germany
Age: 24
Homepage: e-lab.de
Posts: 5558
Registered: 03 / 2002
Subject:

Re: SPI_SS beim XMega?

 · 
Posted: 29.09.2010 - 21:07  ·  #8
Hallo Thomas,

ja, das macht Sinn. Der CallBack startet den Prozess mit Resume(processX). Hier wiederum auf die Register Benutzung achten. Wenn der Prozess dann seinen Job erledigt hat legt er sich mit Suspend zum Schlafen. Allerdings gibt es hier auch noch ein Problemchen: auch wenn der Prozess eine hohe Priorität hat, dann ist nicht genau vorauszusehen wann er wirklich gestartet wird. Das kann von einem Bruchteil eines SysTicks bis zu x SysTicks reichen, abhängig davon wieviel Prozesse aktiv sein können und welche Prioritäten (Laufzeit in SysTicks) diese haben. Dieser Prozess muss also einen Priority Wert (SysTicks) haben, der grösser ist als die grösste Rechenzeit für einen Durchlauf. Das hilft aber trotzdem nicht gegen den Prozess Start jitter.

Eine zweite Möglichkeit wäre den JOB als suspended Task mit Priority 1 zu implementieren. Im Callback wird der Task mit Resume(Task) gestartet und der Task wird innerhalb eines SysTicks gestartet. Der Task Lockt sich gegen einen Schedule, macht seinen Job und verabschiedet sich wieder mit einem Suspend.

rolf
  • 1
  • 2
  • Page 1 of 2
Selected quotes for multi-quoting:   0

Registered users in this topic

Currently no registered users in this section

The statistic shows who was online during the last 5 minutes. Updated every 90 seconds.
MySQL Queries: 15 · Cache Hits: 14   137   151 · Page-Gen-Time: 0.023646s · Memory Usage: 2 MB · GZIP: on · Viewport: SMXL-HiDPI