Beiträge anzeigen

Diese Sektion erlaubt es ihnen alle Beiträge dieses Mitglieds zu sehen. Beachten sie, dass sie nur solche Beiträge sehen können, zu denen sie auch Zugriffsrechte haben.


Themen - BL1

Seiten: [1] 2 3
1
Entwicklungswerkzeuge / PIC32 LCC Demo
« am: Oktober 18, 2017, 12:46:35 Nachmittag »
Moin,


hat jemand schon mal mit diesem Demo gearbeitet?

2
Entwicklungswerkzeuge / 8-fach-Programmer Prime8
« am: September 14, 2016, 07:22:59 Vormittag »
Moin,


ich habe mir letztes Jahr zum Masters in Berlin den Prime8-Programmer von CCS geleistet. Jetzt soll der zum Einstaz kommen aber das ist ehrlich gesagt eine Katastrophe.
Der Programmer hat 3MB internen Speicher und noch einen SD-Slot für eine 2GB-SD. Deshalb hab ich die 800Eumel ja auch ausgegeben. Nur, nirgends ist beschrieben, wie man auf den Speicher zugreift oder wie dort ein Hex-File abgelegt werden muß. Schließt man den Programmer an einen PC, auf dem vorher die zugehörigen Treiber und Software geladen wird, kann man den Programmer bedienen. Ohne PC gar nicht. Der läßt keinen Tastendruck oder Kombination zu. Drückt man am Programmer eine Taste, während der Verbindung zum PC hat, schmiert er ab. Nur noch Kauderwelsch im Display.

Der Hit kommt aber beim Service. Auf den CCS-Seiten steht eine Kontaktmöglichkeiten und darunter, dass man auf jeden Fall binnen 4 Stunden eine Antwort bekäme. Deren Vorstellungen von 4 Stunden, ist die Zeit von 09:00 bis heute 07:00Uhr und diese angebliche Antwort beinhaltet lediglich, dass man derzeit zur Beantwortung der Frage keine Zeit hat.

Also wenn ich meine Geräte so ausliefern oder mit meiner Kundschaft so umgehen würde, wär's das schon lange gewesen.


Kann hier irgendjemand etwas zu diesem Programmer sagen?


Danke!

BL

3
MPLAB / Hex-Dateien zusammenbasteln
« am: Dezember 15, 2015, 15:38:49 Nachmittag »
Hallo zusammen,



ich habe auf MPLAB 8.66 für ein Projekt einen Bootlader und eine Firmware gemacht. Das ganze ist in CC8E programmiert, weshalb es zwei Programme sein müssen. Geht (zumindest) da nicht anders.

Nun wollte ich der Zeitersparnis wegen die Hex-Dateien beider Programme zusammenbasteln, in MPLAB importieren und auf einmal in den Controller schieben. Macht er aber nicht und ich komm nicht dahinter, wieso eigentlich nicht.

Hatte jemand schon mal ähnliche Ambitionen und weiß was drüber?



Besten Dank!

BL

4
PIC Mikrocontroller Allgemein / Flash über 64k
« am: Juni 02, 2015, 14:19:35 Nachmittag »
Moin,

wenn man einen PIC mit großem Flash hat und man will einen Bootlader basteln, dann stößt man auf folgendes im Hexfile:

Zitat
:10FFD000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF31
:10FFE000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF21
:10FFF000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF11
:020000040001F9
:10000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF00
:10001000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF0
:10002000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFE0

Das "FFF0" ist die Flashadresse 0x0FFF0, also der letzte Block unter 64k.
Das "0000" ist dann aber nicht die Adresse 0x0000 sondern müßte 0x10000 sein.

Seh ich das richtig und wenn ja - gibt es da eigentlich irgendwelche besseren Erfahrungen, wie man im Bootlader mit dieser Regelung hinkommt?



Danke erst mal!


BL

5
Programmiersprache C / 1-Wire
« am: April 08, 2015, 10:33:37 Vormittag »
Hat eigentlich schon mal jemand einen Pic als 1-Wire-Slave verwendet und gibt's da irgendwo etwas vorgefertigtes?

6
Programmiersprache C / Denkfehler?
« am: April 02, 2015, 17:14:58 Nachmittag »
Nee, irgendwie kein Denkfehler. Oder doch?

Ich teste das Pin RA1. Das Tris-Bit ist 1, das Pin auf Eingang, Durch Pull-up liegen 4,2V, gleiche Höhe, wie Betriebsspannung an dem Pin und der Controller testet Null.

Muß das sein?

7
Programmiersprache C / Carrybit in MCC18
« am: März 31, 2015, 14:53:51 Nachmittag »
Hallo,


ich finde es nicht.
Wie lautet denn die Syntax, wenn man im MCC18 das Carrybit im Statusregirster ansprechen will?


Nicht aufregen über solche Gurkenfragen!



Besten Dank!

8
PIC Mikrocontroller Allgemein / ICSP Programmierung 18f67k22
« am: Februar 05, 2015, 14:37:16 Nachmittag »
Moin zusammen,


ich habe jetzt einen 18f67k22 auf dem Board. Der sollte mit 5V laufen lassen, weil ein Grafik-Display dranhängt.

Jetzt will ich den mit einem ICD3 zum Leben erwecken, aber das ging nicht. Nach 5h Verzweiflung habe ich dem mal 3,3V angeboten und siehe da der ICD3 erkennt ihn.

Ist das normal?


Besten Dank falls jemand was weiß!

9
PIC Mikrocontroller Allgemein / Wieder mal I2C
« am: Mai 24, 2013, 08:09:25 Vormittag »
Moin Moin,


Ich ärgere mich seit Jahren mit den I2C-Modulen rum und hatte schon im 16F818/819 einen definitiven Fehler, wo sich der Cotroller komplett aufhing und auch mit Reset nicht wiederzubeleben war. Sei's drum, inzwischen setzen wir den 16F1827 ein, da geht's.

Jetzt habe ich einen 18F46K22 und das Ding macht wieder Mist. Ich habe eine selbstgeschriebene Software, seit Jahren erprobt, funktioniert. Der Pic arbeitet hier als Slave:
_I2CTE = 0;
CKP = 0; //Bus anhalten
_I2CTE = 0b.0011.1101 & SSP1STAT;
_i2cslaveok = 0;
switch (_I2CTE)
{
//state0
case 0b.0000.1001: //letztes Byte war ADR,transceive-mode
SSPOV = 0; //00001001: D/A=0,S=1,R/W=0,BF=1
SSP1BUF = 0;
_I2CCO = 0; //Zeiger null setzen
SSP1CON1 = 0b.0010.1110; //SSP gleich scharf machen
break;
Bei    CKP = 0; wird der Bus angehalten, SCL auf Null gehalten. Klappt auch. Das komische ist aber, dass bei SSPOV = 0; SCL wieder freigegeben wird. Dürfte doch nicht sein, das hat doch miteinander gar nichts zu tun.


Bei dieser Sequenz wird unabhängig davon das SSP1BUF mit irgendwelchen Mondwerten beschrieben. case 0b.0000.1101: //letztes Byte war ADR,receive-mode
BF = 0;
SSPOV = 0; //
_I2CCO = 0; //Zeiger null setzen
        do
{
WCOL = 0;
SSP1BUF = i2cS_out[0];
}
  while (WCOL);//
_I2CCO = 1;
SSP1CON1 = 0b.0010.1110; //SSP gleich scharf machen
break;
In i2cS_out[0]steht das Richtige. Im SSPBUF bleibt aber konsequent die Adresse stehen und gesendet wird dann ein 0x5A, was ich mir ganz und gar nicht erklären kann.

Im 18F26K20 funktioniert das alles problemlos.

Ich muß dazu sagen, manchmal geht's. Oft aber eben nicht. Das macht sich dann richtig gut, wenn man in einem Bootlader 12 oder 16K rüberschaufeln muß.

Bei folgender Sequenz hängt er sich auf do
{
SSP1BUF = 0;
SSP1CON1 &= 0b.0010.1111; //WCOL,SSPOV und CKP löschen
SSP1BUF = i2cS_out[0];
}
  while ((SSP1BUF!=i2cS_out[0])||(WCOL));//;
Das SSP1BUF wird nicht beschrieben, beim Versuch kommt sofort WCOL und das CKP bleibt im Register immer 1, die SCL-Leitung auf Null. Jedenfalls, wenn man den Anzeigen im Debugger glauben darf.



BL

10
PIC Mikrocontroller Allgemein / ADC-Wandler "hängt" irgendwie
« am: Juni 26, 2012, 08:33:53 Vormittag »
Moin Moin,


ich hänge wieder, weil der Pic komischen Mist macht.

PIC 16F1827

Ich habe eine Spannung zu messen, die sich an sich ständig ändert. Als Meßroutine habe ich das://----------------------------------ADC_Read---------------------------------------
uns16 ADCRead(char ADSW)
{
uns8 i;
uns16 a;
        GIE = 0;
ADCON0 = ADSW; //ANx,1/2FOSC, starten
for (i=25;i>0;i--)
nop();
GO = 1;
while (GO);
ADIF = 0;
        GIE = 1;
a.low8 = ADRESL; //Werte übergeben
a.high8 = ADRESH;
ADCON0 = 0; //alles aus;
ADRESL = 0;;
ADRESH = 0;;
return a;
}
//---------------------------------------------------------------------------------
Aufgerufen wird das von a16 = ADCRead(0b.0001.0001);//AN4;
Gemessen wird alle Zehntelsekunde. Der Meßwert am Pin ändert sich mitunter von 1,3 bis 4,0V und andersrum.

Es kommt ein Meßwert an und der stimmt auch ungefähr mit dem Vielfachmesser überein.

Aber! Sonundsooft bleibt das Meßergebnis stehen, während sich der wirkliche Meßwert am Pin ändert. Mitunter sekundenlang. Als wenn irgendwas den ADC-Wandler aug genau einem Wert blokcieren würde.
Ich habe das ganze über eine Mimik an den Rechner gehangen und da ein Diagramm mitgeschrieben. Die Grüne Linie ist die, wie die blaue Linie(Spannnung) bzw. die daraus errechnete rote Linie(physikalischer Meßwert) ungefähr reagieren müßten. In der Tabelle unten sieht man ganz rechts das Meßergebnis in Digits, wie es aus dem ADRES-Register rauskommt. Die 6. Spalte von rechts ist die daraus errechnete Spannung. Da sieht man den Sprung von 2,424 auf 3,9003V. Der war so nicht da. Die Meßgröße änderte sich so ähnlich iwe die grüne Linie, was auf dem Voltmeter zu sehen war.
Kann mir nicht erklären, wie das Ding sich seinen Meßwert merkt. Die zugehörigen Variablen lösche ich bevor die Messung startet, bzw. das ADRES-Register nach der Messung.

Es ist, als wenn der interne AD-Wandler auf einem Wert verharrt.


BL

11
Schnittstellen (Allgemein) / SPI Geschwindigkeit
« am: März 07, 2012, 15:44:11 Nachmittag »
Halo,


ich bin gerade dabei, am 16F1827 den SPI-Bus am MSSP-Modul anzuregen. Prinzipiell geht das auch. Nur, die Geschwindigkeit ist zu schnell.

Lt. Datenblatt bestimme ich die mit den unteren 4Bit des SSPxCON1. 0000=FOSC/4;0001=FOSC/16;0010=FOSC/64. Die Version mit Timer2 lass ich mal weg, den brauch ich später noch für was anderes. Da kann ich aber nun einstellen, was ich will, ich krieg das Ding auf nichts anderes. als 2MHz.
Prozessortakt ist 8MHz intern.

Kann das sein, dass ich für die SPI-Geschwindigkeitseinstellerei einen externen Takt bräuchte? Oder übersehe ich da was?



BL

12
PIC Mikrocontroller Allgemein / ICD3-Debuggen zu Fuß programmieren
« am: Januar 17, 2012, 21:06:12 Nachmittag »
Hallo,

ich habe eine Compiler, der von haus aus keine fertige Debug-Funktion zur Verfügung stellt. Wie macht man denn sowas zu Fuß? Steht dazu irgendow, irgendwas zu lesen?


Danke!


BL

13
PIC Mikrocontroller Allgemein / Register retten bei Interrupt
« am: September 21, 2011, 22:06:57 Nachmittag »
Moinsen,

wie ist denn das eigentlich beim 18er PIC?
Wenn ich meinen HighPriotityInt habe, geht der Controller auf 0x08 und findet dort seine Routine. Diese verweist ihn in der Regel auf eine ISR und hier werden zunächst die Systemregister gerettet und nach der ISR wieder hergestellt.

Nur, wenn ich einen Bootlader habe und der Bootlade-Speicherbereich nicht für die ISR reicht, bzw. gar nicht reichen soll(damit man da später bei der Firmware noch eingreifen kann), dann muß man doch die Speicherrettung/wiederhesrstellung in den Bereich ab 0x08 schreiben. Das aber geht doch gar nicht, wenn man ab 0x18 die LowISR stehen hat. Das paßt doch da nicht hin.
Alternative wäre natürlich, man macht zwei Levels von ISR. Eine auf 0x08, die springt z.B. nach 0x0900, dort werden dann die Register gerettet und dann einen Call nach 0xXXXX, wo man später mit der Firmware noch eingreifen kann. Dann aber hat man doch schon drei Levels von 8(?) im Stack verschenkt.


Wie macht man denn sowas elegant, so im guten Programmierstil?




BL

14
Schnittstellen (Allgemein) / I2C Clock-Stretching
« am: September 17, 2011, 08:41:32 Vormittag »
Hallo,


ich habe einen 18F26K20 im Slave und frage den im Polling nach dem SSPIF ab. Ist das High, geht er in die entsprechende Routine. Dort setzt er als erstes das CKP auf Null, dass die SCL-Leitung runtergezogen wird und der Master solange mit der nächsten Bus-Aktivität wartet.

Die gleiche Routine funktioniert im 16F1827 ganz hervorragend.

Das Problem ist nun, dass das CKP-Bit im SSPCON1-Register zwar wunderschön Null ist, es die SCL-Leitung aber gar nicht interessiert. Die ist High. Im SSPCON2-Register gibt es das Bit SEN(StretchEnable-Bit). Das ist gesetzt.

Ist da noch irgendwo was zu setzen/zu löschen?



BL

15
PIC Mikrocontroller Allgemein / Flash löschen, Blockgröße bei 16er Pics
« am: August 01, 2011, 10:42:00 Vormittag »
Hallo,

wenn man im Flash lösen will - das muß man doch, um denselben neu zu beschreiben - gibt es doch eine Blockgröße, unter der man nicht löschen kann(?). Beim 18er-Pic sind das doch 64 Byte. Sind das bei 16nern auch 64 Byte oder weniger?



BL

Seiten: [1] 2 3