Test med MAX232 och PIC16F628A

[bos]

Jag fick mina MAX232-kretsar förra veckan, så jag satte mig ner för att leka runt lite och se vad som gick åstadkomma. Med http://www.piclist.com/techref/microchi ... RTtest.htm som referens (samma kopplingsschema och grund till min kod) kopplade jag upp rubbet på däcket och hackade ihop följande:

--------------8<-------------------

Kod: Markera allt

#include <htc.h>
#include <pic16f62xa.h>

__CONFIG(UNPROTECT & LVPDIS & BORDIS & MCLREN & WDTDIS & PWRTDIS & INTIO);

void send(char letter) {
   TXREG = letter;
   while (!TRMT) {
       // Delay until sent
   }
}

void message(void) {
   char msg[] = "16F628A on the air.";
   char *p = msg;

   while (*p++) {
       send(*p);
   }
}

void main() {
   char tmp = 0;

   // Asynch USART, BRGH = 1, Baud = 9600, Error = 0.16%, SPBRG = 25
   // 8n1
   // LSB first
   TRISA = 0;
   TRISB = 0b00000010;                         // Setup RX/TX-pins
   SPBRG = 0x19;
   TXSTA = 0b00100100;                         // Asynch TX + BRGH
   RCSTA = 0b10010000;                         // Asynch RX + SPEN

   while (--tmp > 0) {
       // Short delay to enable proper startup
   }

   // Flush receive buffer
   tmp = RCREG;
   tmp = RCREG;
   tmp = RCREG;

   message();
   send('Y');
   send('o');
   while (1) {
       if (RCIF) {
           tmp = RCREG;
           tmp += 1;
           send(tmp);
       }
   }
}

--------------8<-------------------

Drog sen igång HyperTerminal, ställde in 9600 baud, 8 bitar och ingen stoppbit, och hoppades sen vid kretsens påslagning få se "16F628A on the air." på skärmen, men så lätt kom jag tydligen inte undan. Ingenting dyker upp på skärmen, men om jag vidrör TX-pinnen på PIC:en så sprutar det upp massa skräptecken på skärmen, så någon sorts kontakt finns iallafall.

Jag har trippelkollat kopplingarna men hittar inga fel. Har även från PIClist's inrådan provat att byta kabel till RX/TX då detta tydligen hjälpte vid ett tillfälle, men här är det resultatslöst.

Förslag på felkälla?



EDIT: Lade till code-tagg.

[Icecap]

TXSTA = 0b001001x0;
Du har 0b00100100 men jag användar 0b00100110 vilket fungerar för mig.

Sedan är jag mycket tveksam till din definition:

Kod: Markera allt

void message(void)
  {
  char msg[] = "16F628A on the air.";
  char *p = msg;
  while(*p++)
    {
    send(*p);
    }
  }

Jag hade ju skrivit:
void message(void)
  {
  const char msg[] = "16F628A on the air.";
  char *p = msg;
  while(*p++) send(*p);
  }

och såhär (finputs bara):
void send(char letter)
  {
  while (!TRMT); // Wait for TX to be free
  TXREG = letter;
  }

Men när du får en massa "brus" när du pillar betyder att portpinnen inte är ställd till utgång och då undrar man: startar den alls?

[bos]

Om jag kör "const char msg[]" så vill inte kompilatorn tugga "char *p = msg", med anledningen "Warning [359] main.c; 15.14 illegal conversion between pointer types". Jag ser heller ingen anledning med att köra en konstant där, förutom att spara ett antal bytes kod. Men nu är ju det här bara ett testprojekt, så kodstorlek är inte så relevant.

Du har i övrigt rätt i att koden inte kördes, för den 628:a som jag använde gick aldrig igenom verifieringssteget på Wispen. Så jag kastade den och körde in en ny, och nu klagas det inget vid programmeringen.

Dock så ser jag fortfarande inget på skärmen, trots finputsningarna du föreslog. Har dubbelkollat seriekabeln, och den är rakt kopplad (GND-GND, RX-RX, TX-TX), dubbelkollat kopplingarna på däcket och allt är som det ska vara. Dubbelkollade för säkerhets skull Hyperterminal, och där har jag 9600 baud, 8 data bits, "None" på parity, 1 stop bits och "None" på Flow control.

Kondingarna (alla på 1uF i enlighet med databladet för MAX232) är förvisso inte nya, de kommer från min "junk box", men min DMM säger 1.1uF på samtliga så de kan jag antagligen utesluta. Skulle iofs kunna byta 232:an, men eftersom den är purfärsk från Maxim så verkar det väldigt osannolikt att den skulle vara kajko.

Nu kommer jag inte på fler saker som kan vara orsaken, iallafall inte saker som jag inte dubbelkollat. Serieporten är t.ex hel, eftersom jag kör Wispen på den.

[bos]

Nu gjorde jag såhär: jag kopplade min hembyggda logikanalysator till seriekabelns RX och TX. När jag i terminalprogrammet skriver lite tecken så blinkar dioden för TX, dvs programmet skickar ut tecken. RX lyser dock inte, vilket innebär att PIC:en inte skickar något (vilket den ska).

Med andra ord är det jag som får skrota tutorialen jag hittade och istället får dyka ner i 628ans datablad en gång till. Oftast så funkar ju cargo culting när det gäller testkod, men inte idag tydligen.

[Icecap]

Förklara gärna för mig HUR du får en variabel till att få ett fast värde vid uppstart utan att deklarera den som en konstant?

Jag använder det mycket och när kompilern gnäller (händer "jämt") är det bara att cast'a den:

Kod: Markera allt

void message(void)
  {
  char msg[] = "16F628A on the air.";
  char *p = (char*)msg;
  while(*p++)
    {
    send(*p);
    }
  }

[bos]

> Förklara gärna för mig HUR du får en variabel till att få ett fast värde vid uppstart utan att deklarera den som en konstant?

Det här blir deluxe-offtopic, men OK: Du får en variabel till ett fast värde vid uppstart genom att tilldela den ett värde, förstås.

Ponera:

Kod: Markera allt

#include <htc.h>

void foo1(void) {
	int i;
	char bar_in_foo1[4];

	i = 0;
}

void foo2(void) {
	int i;
	char bar_in_foo2[4] = "Hej";

	i = 0;
}

void main(void) {
	foo1();
	foo2();
	while (1) {};
}

ger (med Hi-Tech PICC, har ingen annan kompilator till hands som klarar PIC):

Kod: Markera allt

1:                 #include <htc.h>
2:                 
3:                 void foo1(void) {
4:                 	int i;
5:                 	char bar_in_foo1[4];
6:                 
7:                 	i = 0;
   7F1    0183     CLRF 0x3
   7F2    01A0     CLRF 0x20
   7F3    01A1     CLRF 0x21
8:                 }
   7F4    0008     RETURN
9:                 
10:                void foo2(void) {
11:                	int i;
12:                	char bar_in_foo2[4] = "Hej";
   7F5    3048     MOVLW 0x48
   7F6    0183     CLRF 0x3
   7F7    00A2     MOVWF 0x22
   7F8    3065     MOVLW 0x65
   7F9    00A3     MOVWF 0x23
   7FA    306A     MOVLW 0x6a
   7FB    00A4     MOVWF 0x24
   7FC    01A5     CLRF 0x25
13:                
14:                	i = 0;
   7FD    01A0     CLRF 0x20
   7FE    01A1     CLRF 0x21
15:                }
   7FF    0008     RETURN
16:                
17:                void main(void) {
18:                	foo1();
   7EE    27F1     CALL 0x7f1
19:                	foo2();
   7EF    27F5     CALL 0x7f5
20:                	while (1) {};
   7F0    2FF0     GOTO 0x7f0

Kort sagt: const är inte ett nödvändigt verktyg för att initialisera en variabel vid deklarationen, men om variabeln i fråga ska tolkas som konstant så kommer det att hjälpa kompilatorn längre fram. Ju mer kompilatorn / länkaren vet om hur konstruktioner används desto effektivare kan de optimera. Man sparar lagringsutrymme om man inte sätter variabler som är globala och/eller static till 0 explicit. Sätter man dem till 0 hamnar de i binärens datasegment och tar upp plats både på disk/flash/ROM och i RAM (om variablerna är skrivbara (dvs inte const) så måste de ju kopieras till RAM innan binären exekveras, även om kod och konstanta variabler ligger kvar i flash/ROM).

Sätter man inte variablerna explicit kommer de istället hamna i BSS-segmentet som enbart allokeras i RAM och sätts till 0 när binären startar. C-standarden garanterar inte detta, men enligt välinformerad källa så garanteras det av ABI:t på de flesta plattformar som mikrocontrollers sitter på.

Om man vill banta ner kod så är ett annat bra sätt att minska binärstorleken när man räknar bytes att sätta alla funktioner och globala variabler som inte används utanför en given fil till static, och alla variabler som inte modifieras till const.

I min kod ligger strängen lokalt i en funktion, och initialiseras alltså vid funktionsanropet. Ganska mycket overhead, men som redan skrivet så är koden bara en testkod där det primära målet är att få upp text i terminalprogrammet. Nästa steg är att lära mig ytterligare om USART-modulen, och sen - *sist av allt* - mikrooptimera saker och ting.