Hallo, sind die LPC11Cxx als vollwertiger Ersatz für z.B. die
Kombination ATMEGA, MCP2515 und MCP2551 nutzbar? Hätte ja einen enormen
Charme, alles in einem Chip. Unter C_CAN-Beschreibungen konnte ich mir
das nun leider nicht rauslesen. CANopen driver sind mit drin; das Ganze
scheint ja eine eigene Protokolldefinition zu sein. Aber kann man das
auch wie oben gefragt nutzen?
Der Hit wäre ja noch, wenn auch der Transceiverteil mit 3.3 V auskommen
würde.
Rumbalotte schrieb:> Hallo, sind die LPC11Cxx als vollwertiger Ersatz für z.B. die> Kombination ATMEGA, MCP2515 und MCP2551 nutzbar?
Ja, manche haben komplett CAN-Controller UND CAN-Tranceiver (natürlich
auch noch den Cortex M0) in einem Chip :-D
Schon geil die kleinen Scheißerchen...
A. K. schrieb:> Man sollte nur beachten, dass ein zerblitzter 8-beiniger MCP2551> leichter austauschbar ist als ein LQFP48.
Ja, dass stimmt natürlich.
Ist aber fast immer der Nachteil wenn man es kompakt haben möchte.
LQFP finde ich noch gut von Hand zu löten, ab QFN wirds eklig.
Ich denke mal die 2 Punkte, Platz und Preis, sind allerdings ein
wichtiger Punkt. Ein Atmega alleine kostet ja schon so viel wie ein
LPC11C.
Der MCP2515 und MCP2551 sind dann auch nochmal 1,50EUR.
Vom Platz ganz zu schweigen.
Hätte ich gerade was mit CAN vor, würde ich mir die echt mal näher
anschauen.
die Dinger haben einen CAN- und CANOpen-Treiber im Rom. Muss man aber
nicht nutzen. Es geht auch über normales Register setzen.
Die Rom-Routinen werden in etwa so angesprochen:
1
/* Send a simple one time CAN message */
2
msg_obj.msgobj=0;
3
msg_obj.mode_id=0x345;
4
msg_obj.mask=0x0;
5
msg_obj.dlc=4;
6
msg_obj.data[0]='T';//0x54
7
msg_obj.data[1]='E';//0x45
8
msg_obj.data[2]='S';//0x53
9
msg_obj.data[3]='T';//0x54
10
(*rom)->pCAND->can_transmit(&msg_obj);
Der Transciverteil möchte aber seine 5V haben.
Unter Beitrag "Re: Problem mit der Beschaltung eines CAN-Knoten" habe ich mal
eine kleine Platine entwickelt die ich hier zum Basteln verwende. Falls
jemand an den Eagle-Dateien interesse hat bitte pm.
Die LPC11Cxx sind mir auch schon als äußerst interessant aufgefallen.
Mit 32 kB Flash, 8 kB RAM, integriertem Transceiver, bis zu 50 MHz,
relativ kleinem Gehäuse LQFP 48 und dem Preis (zumindest bei
Futureelectronics, bei den Standarddistributoren eher nicht) echt gut.
Mit Adapterplatine wären die auch noch ganz gut einsetzbar, sofern man
keine eigenen Platinen ätzen oder Einzelstücke bauen will.
Was ich beim Überfliegen des User Manuals allerdings noch nicht
verstanden hatte war das GPIO-Handling. Das scheint (zumindest auf den
ersten Blick) ganz anders als sonst zu sein; irgendwas mit MASK-register
in einem Addressraum ...?
Das habe ich so auch noch nirgends wo anders gesehen.
Man kann das Portregister wie bei den AVRs auch ganz normal beschreiben
1
LPC_GPIO0->DATA|=(1<<bitPos);
Durch folgenden Aufruf kann man den Pin am Port unabhängig vom Zustanbd
der anderen Pins setzen und rücksetzen in einem Rutsch. Dafür haben die
LPC17xx bzw. STM32 SET und CLR Register.
Schade nur, daß die LPC11Cxx keine sleep-modes haben. Das haben nur die
L-Varianten. Deshalb leider nichts für mich, da der Stromverbrauch dann
viel zu hoch ist.
Ich hab vor lauter Schreck auch mal schnell den Keil mit dem
LPC11C14-Example angeworfen; und dort git es auch deep-sleep etc.
Also scheint es die sleep-modes dort zu geben. Wäre ja eigentlich auch
ein Hammer, wenn nicht.
Dann müssen diese Power Profiles was anderes sein als ich dachte. Puh!
Da habt ihr sicher was falsch verstanden. Da wo die C-Typen den
CAN-Treiber im Rom haben, wird der Platz bei den Normalen Typen für
Rom-Routinen in der Art:
1
(*rom)->pPWRD->set_power(command,result);//set system power
2
(*rom)->pPWRD->set_pll(command,result);//set the PLL
benutzt. Eine nette Zugabe aber nichts was nicht auch mit den Registern
geht.
