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.


Nachrichten - BL1

Seiten: [1] 2 3 ... 7
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 / Re: Flash über 64k
« am: Juni 03, 2015, 08:58:33 Vormittag »
Danke!


Gibt's da irgendwie einen Bootlader(für den PC), der das berücksichtigt oder Code-Schnipsel(vielleicht sogar in Delphi/ObjectPascal)?

Wer will schon jedes einzelne Rad zum 300. mal erfinden müssen.


BL

5
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

6
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?

7
Programmiersprache C / Re: Denkfehler?
« am: April 08, 2015, 10:32:29 Vormittag »
Ja, so ähnlich. Das ist ein 18F4455, da sind das in einem ADCON-Register vier Bits.

8
Programmiersprache C / Re: Denkfehler?
« am: April 02, 2015, 19:23:42 Nachmittag »
Ja!

9
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?

10
Programmiersprache C / Re: Carrybit in MCC18
« am: März 31, 2015, 15:23:25 Nachmittag »
STATUSbits.C



Wer's liest, Danke für's Lesen!

11
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!

12
PIC Mikrocontroller Allgemein / Re: ICSP Programmierung 18f67k22
« am: Februar 20, 2015, 15:47:38 Nachmittag »
Ich hatte hier zwar schon mal ein großes Dankesschreiben reingehackt, dass der Tipp half. Aber komischerweise steht's hier nicht. Hoffentlich schlug da die Senilität nicht zu.

Wie dem auch sei, der Tipp mit der ICD-Versorgungsspannung half erstmal.
Aber das war nicht der Fehler.

Der Fehler war eine falsche Beschaltung an den Pins VDDCORE(nur 100nF  nach Masse) und ENVREG. Letzterer muß bei 5V nach 5V und bei 3,3V nach Masse gelegt werden. Ansonsten greift ein interner Regulator ein und macht Mist.

Fehlermeldung war übrigens 0086. Da wird man lediglich auf das Testinterface verwiesen, welches aber keinen Fehler brachte.

13
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ß!

14
PIC Mikrocontroller Allgemein / Re:Wieder mal I2C
« am: Mai 27, 2013, 17:11:19 Nachmittag »
War ein Timing-Problem.

Das ganze ist für einen Bootlader. Der lief im Polling-Betrieb. Es wurde also immer eine Endlosschleife durchlaufen, in der SSPIF abgefragt und -wenn es 1 ist- in den i2c-Handler wird. Das SSPIF wird gesetzt nach dem 9. Takt(jedenfalls wenn es so eingestellt ist). Dabei kam es nun (oft) vor, dass das die Abfrage in der Endlos-Schleife zu spät kam und somit der i2c-Handler erst aufgerufen(und damit der SCL mit CLK angehalten) wurde, als der 1. Takt des nächsten Bytes schon auf dem Bus war. Danach nimmt das SSPBUF nichts mehr an. In den Status-Bits sieht man das aber nicht. Nur im Oszi.

Den Bootlader auf Interrupt umgestellt, geht es. Das Problem ist nur, dass die Application dann einen anderen Interrupthandler haben muß.

Noch ein Problem: Im Datenblatt glaubte ich zu lesen, dass das CLK den Bus sofort anhält, also automatisch und nicht erst zu Fuß in der Software. Das funktioniert irgendwie nicht.


BL

15
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

Seiten: [1] 2 3 ... 7