Svenska ElektronikForumet

Nu blandar jag ihop µs och ms igen

det ska förstås vara ms (även om det räcker med 50 eller mindre nu när du räknade)

Jag ändrade lite och nu funkar det hyffsat, dock ingen pwm.

Kod: Markera allt

[...]
  while (1) {
     read = 1;
     while (read) {
           if (UART1_Data_Ready()) {     // If data is received,
             uart_rds[s] = UART1_Read();     //   read the received data,
             if (uart_rds[s] == 's' ) { read = 0; }
             if (s == 3 ) { s = 0; }
             s++;
           }
     }
     UART1_Write_Text(uart_rds);
     Delay_ms(50);
     if (uart_rds[0] == '1' ) {
        pwmValue1 = xtoi(uart_rds[1,2]);
        UART1_Write('1');
        UART1_Write('/');
        UART1_Write_Text(uart_rds[1,2]);
        UART1_Write(uart_rds[1]);
        UART1_Write(uart_rds[2]);
        Delay_ms(10);
     }
[...]

UART1_Write_Text(uart_rds[1,2]); funkar inte, däremot funkar UART1_Write(uart_rds[1]); och UART1_Write(uart_rds[2]); så jag misstänker att det är därför pwmValue1 = xtoi(uart_rds[1,2]); inte funkar. Hur ska jag skicka två char till xtoi istället?

Kod: Markera allt

Sent: 1ffs

Eller gör en egen variant av xtoi.
Det är ju bara 2 hex siffror och du vet exakt hur det ser ut.
xtoi innehåller en hel del kod som du inte behöver för att t.ex kunna
hantera olika längder på hex-strängen och för att verifiera att det är
en korrekt hex-sträng. Eftersom du har full kontroll på den sändande
sidan också, så behöver du knappast det.

En variant är att skicka det som en decimal textsträng också.
Vissa delar av konverteringen till binärt/integer blir enklare, bl.a
så ligger alla "siffror" i en kontinuerlig följd. En hake med hex är att
det hoppar från 0-9 till A-F, så det går inte bara att räkna av en
konstant...

Det kanske man skulle kunna göra, får tänka på det en stund.

Den här fungerar i simulatorn:

Kod: Markera allt

  while (1) {
     read = 1;                    // Endless loop
     while (read) {
           if (UART1_Data_Ready()) {     // If data is received,
             uart_rds[s] = UART1_Read();     //   read the received data,
             if (uart_rds[s] == 's' ) { read = 0; }
             if (s == 3 ) { s = 0; }
             s++;
           }
     }
     s = 0;
     //UART1_Read_Text(uart_rds, 's', 3);
     UART1_Write_Text(uart_rds);
     //sprintl(string, uart_rds[1], uart_rds[2]);
     Delay_ms(50);
     if (uart_rds[0] == '1' ) {
        dummy = xtoi(uart_rds[1]);
        dummy2 = xtoi(uart_rds[2]);
        pwmValue1 = dummy * 10 + dummy2;
        UART1_Write('1');
        UART1_Write('/');
        UART1_Write_Text(uart_rds[1,2]);
        UART1_Write(uart_rds[1]);
        UART1_Write(uart_rds[2]);
        UART1_Write(pwmValue1);
        Delay_ms(10);
     }

Visserligen bara två siffror men det går ju att ändra enkelt. Ska testa "på riktigt" sen.

Om det fortfarande är hex du skickar så border det väl
vara pwmValue1 = dummy * 16 + dummy2; !?

xtoi är hex men den får jag inte att funka, atoi är med siffror (därför bara två siffror, 99 är högsta)

Jo, men du använder xtoi i ditt exempel.
Man, å andra sidan så ger den ju samma resultat med enbart ett
tecken som är 0-9... Skit samma, vet i fan vad du igentligen menar...

> xtoi är hex men den får jag inte att funka, atoi är med siffror

Hex använder "siffrorna" 0-9 och A-F...

Jag får säga att de kodsnuttar jag ser i denna tråd visar att trådskaparen har ganska dåligt koll på hur saker och ting fungerar. Jag värderar självklart efter mina preferenser men att det inte ens är möjligt att initiera UART'en utan att använda de inbyggda funktioner verkar helt åt skogen för mig, speciellt med tanke på "stabiliteten" i MikroC.

Jag tror att trådskaparen ska ta ett steg tillbaka och få koll på UART-hanteringen först, sedan testa en del med att skriva ut värden på rätt sätt och sedan sy ihop det hela.

>Jo, men du använder xtoi i ditt exempel.
Förlåt, måste ha kopierat koden mellan testen. Med atoi fick jag det att funka förut men nu svarar den inget öht. måste ta en paus och kolla samt tänka lite.

>men att det inte ens är möjligt att initiera UART'en utan att använda de inbyggda funktioner verkar helt åt skogen för mig, speciellt med tanke på "stabiliteten" i MikroC
UART1_Init(9600); är väl en inbyggd funktion? eller menar du att jag ska initiera den på samma sätt som man blir tvungen när man skriver i assembler, genom att sätta en massa register?

Men som sagt, jag måste ha en paus, det blir bara värre och värre.

Ja, att sätta UART registren själv har den lilla fördelen att du vet vad du gör.

Mikroelektronika har tyvärr inget bra "track-record" när det gäller sina produkter,
att dessutom deras dokumentation är lite dålig gör det inte enklare. Det är
flashigt och ser snyggt ut, men kör man fast så är inte dokumentationen till
stor hjälp.

Ett annat problem är att många tycks tro att det ska gå att få ett fungerande program
med bara ett par 10-tal rader, bara man kör med C och använder färdiga bibliotek.
Det är inte alltid det är så.

Det är inte alls fel att använda C men ändå köra direkt på registren, man får en
helt annan kontroll på det hela på det sättet. Specellt som, som sagt, Mikroelektronika
är dåliga på att ge komplett information om sina lib'ar om vad de gör.

Slutligen, när det gäller xtoi/atoi så var min tanke att inte använda dom alls utan
skriva en egen lite rutin för den konverteringen. Som sagt, både xtoi och atoi har nog
en hel del overhead som du inte behöver. Men det var bara en tanke...

Pajn: Att omvandla en numerisk sträng till ett värde är otroligt enkelt, vara sig det är en hexadecimal eller decimal, att omvandla andra hållet är lika enkelt.

Att ställa register har inget med assembler att göra, detta är en av de saker som visar mig att du har svårt med förståelse av hur en µC fungerar och precis som sodjan skriver är MikroElektronika inte vassaste verktyget i lådan. Jag har upplevd att det är enkelt att göra program med deras C-kompiler, jag har även upplevd att det skiter sig totalt just pga. detta verktyg och det hände självklart ute hos kunden så jag fick åka dit, försöka hitta felet, åtgärda det och komma därifrån snabbt och effektivt, allt med kunden "hängande på mig".

Efter att ha löst problemet med en fuling analyserade jag i lugn o ro vad som hände och det var bankningsfel och därmed fel i vilka register som fick vilka data.

Så MikroC är trevlig, hyffsat IDE osv. men att lita på att det är bra bara för att man använder de funktioner som lovar att ta hand om allt som kräver att man förstår vad man egentligen håller på med är inte speciellt smart.

@sodjan jag förstår vad du menar. Ska fixa det senare...
Men jag pausar några dagar och ska läsa igenom databladet till picen samt manualen till MikroC.

sodjan håller inte med dig rikitgt, ställer man en fråga i dersa forum så får du rätt information tillbaka.

> sodjan håller inte med dig rikitgt,

Jo, jag vet att det är många som tycker att MikroElektroniks prylar är bra,
men det gör som sagt inte jag riktigt. Men det hänger ju även mycket ihop
med vad man menar med "bra" och vad man tycker är viktigt med t.ex en
kompilator. Jag håller dokumentationen som något av det allra viktigaste.

Jag har nu fått det att funka med ASCII kommunikation. Jag skickar en sträng som både väljer pwm och "duty" så det borde inte kunna "gå ur synk".
Strängen ser ut på följande vis: '1234s' där '1' står för "pwm 1" och '234' är "duty" samt 's' är slut (man skickar även ett s innan för att vara säker på att countern står på noll).
"Biblioteket" jag använder är UART då jag inte har orkat skriva något eget som sköter den biten.

Jag tackar för all hjälp jag har fått.

Trevligt !

Svenska ElektronikForumet

16F648A Uart MikroC

Re: 16F648A Uart MikroC

Re: 16F648A Uart MikroC

Re: 16F648A Uart MikroC

Re: 16F648A Uart MikroC

Re: 16F648A Uart MikroC

Re: 16F648A Uart MikroC

Re: 16F648A Uart MikroC

Re: 16F648A Uart MikroC

Re: 16F648A Uart MikroC

Re: 16F648A Uart MikroC

Re: 16F648A Uart MikroC

Re: 16F648A Uart MikroC

Re: 16F648A Uart MikroC

Re: 16F648A Uart MikroC

Re: 16F648A Uart MikroC