Minisumo Haker2- worklog

[klonyyy]

Heh skomplikowane sosnus, ale dobre dzięki, dzięki

Ps19 ,ale diody i reszta działa poprawnie problem to odbiornik na porcieA.1

[Sen]

No robocik prezentuje się dość interesująco. Ciekawe jak będzie się prezentował na zawodach i czy te silniczki dadzą radę. + dla Ciebie za ciekawą inną konstrukcję. Nie rozumiem zbytnio czym się różni nowa płytka od tej starszej ale to twój projekt i twoje decyzje. Jak znajdziesz więcej funduszy to radzę Ci dopracować troszkę tą płytkę o TB6612 i silniczki Pololu a tak wielki + i czekam na efekt końcowy. Pozdrawiam

[klonyyy]

Dzięki Sen, płytka poprzednia była okropna kilka złych połączeń i juz zrobił się pająk, i możliwe zwarcia które mogły ukatrupić li pola o którego przy każdej próbie cholernie się boję ten robot może doczekać się co najwyżej nowych silników, ponieważ został zaprojektowany do pracy z ta przekładnią.

A z tym programem to coś dziwnego się dzieje- np w AVR studio nie mogę napisać DDRA ani PORTA, bo się nie chce skompilować. Próbowałem również z tsopem podpiętym do pb4 i dalej to samo - zero reakcji, za to w bascomie wyszystko działa śpiewjąco. Czy miał ktoś podobny problem ?

[ Dodano: 26-08-2012, 18:25 ]

#include <avr/io.h>
#include <util/delay.h>

#define czujnik (1<<PA1)


int main (void){


   DDRD=0xff;

   DDRB=0xff;
   PORTB = 0xff;

   DDRA&=~0xff;
   PORTA&=~czujnik;

   TCCR1A|=(1<<COM1A0);
   TCCR1B|=(1<<WGM13)|(1<<WGM12)|(1<<CS10);

   ICR1=13;

while(1){

       PORTD|=(1<<PD4);
           _delay_ms(1);

           if( !(PINA & czujnik) ) PORTB = 0xff;
            if( PINA & czujnik ) PORTB = 0x00;

        PORTD&=~(1<<PD4);
        _delay_ms(1);

   }

}

Działajacy program gdyby ktoś potrzebował. Muszę podziękować Mirkowi36 za wytłumaczenie mojego błędu polegającego na zczytywaniu stanu TSOP'a. Taktowanie również było złe

[piotreks-89]

Jakiego masz TSOP'a? Bo widzę, że ustawiasz pin PA1 jako wejście, a potem ustawiasz je w stan niski. Twój odbiornik jak wykryje dane to ustawia wyjście w stan wysoki?

Przydałyby się komentarze. Oczywiście sam mogłem walnąć byka w tym co powyżej napisałem (również stawiam pierwsze kroki w C dla AVR ).

[klonyyy]

Na 36kHz - to ja w prgramie walnąłem byka, powinno być tam :

PORTA|=czujnik;

jeśli wykryje 36kHz to gasi diody

[piotreks-89]

Więc jednak coś z tego C już załapałem Z TSOP'em to chodziło mi o to, jaki stan wystawia kiedy wykryje wiązkę (widzę, że twój daje stan niski).

[klonyyy]

Mam pytanie co do mojego kodu w C, który właśnie piszę - czy muszę pisać kod z takich warunków :

if(PINA & CZUJNIK1 && !(PINA & CZUJNIK2) && !(PINA & CZUJNIK3) && !(PINA & CZUJNIK4) && !(PINA & CZUJNIK5) && !(PINA & CZUJNIK6) && !(PINA & CZUJNIK_LINII1) && !(PINA & CZUJNIK_LINII2)){     	SKRETP;
   	_delay_ms(100);
   	ATAK;
   	PORTB = 0xff;
   	_delay_ms(2000);

czy mogę dać po prostu coś takiego :

if(PINA & CZUJNIK1 ){    	
                SKRETP;
   	_delay_ms(100);
   	ATAK;
   	PORTB = 0xff;
   	_delay_ms(2000);

Są to fragmenty kodu odpowiedzialne za zczytywanie stanów z czujników. Jest ich sześć + 2 czujniki linii (nie korzystam z adc by ułatwić kod (na razie)) I chodzi mi o to czy mogę zczytywać tylko stan wysoki czy muszę także zczytywać stany niskie z pozostałych czujników ?

[ Dodano: 02-09-2012, 18:12 ]

Ma ktoś może pomysł czemu przy takim kodzie silniki w ogóle mi nie działają, a diody (portb) działają znakomicie (gdy czujniki widzi/ nie widzi)?

PORTD|=(1<<PD7) ; 
   _delay_ms (1); 

     if(!(PINA & CZUJNIK3)){
         ATAK;
         PORTB=0x00;


           }

    if(PINA & CZUJNIK3){
       TYL;
       PORTB=0xff;


           }

        PORTD&=~(1<<PD7);
        _delay_ms(1);

Silniki działają normalnie w innych programach- a w tym nawet gdy włączam program drgną przez chwilę a potem stają do ponownego włączenia robota. Próbowałem z delay'ami - nic, a diody działają prawidłowo.

Przykladowy program w którym dzialają silniki:

/*
* PRZOD.c
*
*  Created on: 2012-08-23
*      Author: Piotr Wasilewski
*      TEST KIERUNKU OBROTU KÓŁ W HAKERZE 2
*/

#include <avr/io.h>
#include <util/delay.h>

//DEFINICJE STAŁYCH
#define ENABE2 PORTC|=(1<<PC6) //ENABLE2 MOSTKA
#define ENABLE1 PORTC|=(1<<PC4) //ENABLE1 MOSTKA
#define ATAK PORTC|=(1<<PC6)|(1<<PC4)|(1<<PC2)|(1<<PC7) //SILNIKI PEŁNA MOC DO PRZODU
#define TYL PORTC|= (1<<PC6)|(1<<PC4)| (1<<PC5)|(1<<PC3) //JAZDA DO TYŁU
#define SKRETP PORTC|=(1<<PC6)|(1<<PC4)|(1<<PC3)|(1<<PC2) //SKRĘT W PRAWO SZYBKI
#define SKRETL PORTC|=(1<<PC6)|(1<<PC4)|(1<<PC7)|(1<<PC5) //SKRĘT W LEWO SZYBKI
#define OBROT PORTC|=(1<<PC6)|(1<<PC4)|(1<<PC3)|(1<<PC2) //SZYBKI OBRÓT W POSZUKIWANIU PRZECIWNIKA
#define DIODY PORTB //DIODY LED

int main (void) {
DDRC=0xff;
PORTC=0x00;

while(1){
   ATAK;
_delay_ms(1000);
 }
}

Wiecie co ja juz z tymi jtagami nie dam rady - chyba znowu robię nnowa płytkę - jeszcze żaden robot nie sprawiał mi tylu problemów Te silniki nie działają, nawet przy kodzie w którym to ktir nimi steruje. To znaczy że winny jest procek, który nie zmnienia stanów na pinach portu C. Najgorzej że akurat się zepsuło żelazko a rodzice wyjeżdżają na tydzień do krakowa i żelazka pewnie nie będzie przez najbliższy miesiąć

Zastanawiam się nad zmienieniem procka na atmege 32 - ma ona domyslnie wyłączony jtag ? Proszę o jakieś komentarze bo juz kompletnie nie wiem co robić - to będzie moja chyba 4 plytka, niechciałbym jej zepsuć z powodu złej decyzji co do procka..

Z góry dzięki

[piotreks-89]

Chyba wszystkie AVR'y z JTAG'iem mają go domyślnie włączonego. Nie wiem w czym widzisz problem - w fusebitach możesz wyłączyć (bit JTAGEN). Wtedy powinny działać jak normalny piny I/O.

[klonyyy]

No właśnie powinny - ale czy masz pomysł czemu powyższy program nie działa ?? Mimo dobrego podłączenia i działania silnikow z innym programem ?

[ps19]

klonyyy, Zobacz do książki jak się ustawia porty jako wejście i wyjście.

Wyjście |=, a u ciebie jest =

[klonyyy]

Ale chyba jeśli piszę PORTB=0xff to nie muszę dawać kreski,(zobacz w kursie abxz) nawet okazało się że to on była problemem tutaj:

#define ATAK PORTC|=(1<<PC6)|(1<<PC4)|(1<<PC7)|(1<<PC2)

Tutaj po "PORTC" w ogóle nie powinnno jej być !!!

PS:Naprawiłem żelazko i zarobilem 2dyszki, dzisiaj jest chyba mój szczęsliwy dzień

[ps19]

Otwórz wszystkie porty po kolej tak jak ci napisałem i wtedy zobacz. Takie drobiazgi potrafią doprowadzić do szału.

Jeżeli działa pod innym programem to atmega uszkodzona nie jest.

EDIT: Prawie podłączyłem atmegę pod 48V

[klonyyy]

Już wszystko działa, tak jak pisałem wyżej, problemem byla kreska

Teraz mam kolejny mały problemik - napisałem program do Hakera v2 na dwa czujniki odległości, działa wyśmienicie, jedynym problemem jest to że działa tylko na dohyo zrobionym z dwóch kartek a4, a czarny brystol, bierze za białą linię i cały czas się cofa. I chcę się zapytać czy można jakoś rezystorami wyregulować czułość czujnika ? Ja próbowałem dając 1 k zamiast 220r przy diodzie ir ktira. Dalej to samo, bez żadnej poprawy, mimo że dioda ledwo się świeci. Problem na pewno stanowi dohyo, bo ten sam problem występował w Hakerze. A jeśli łatwiej jest wyregulować czujnik programowo to poproszę o fajną czytelną funkcję do obsługi adc w mikrokontrolerze. I byłbym naprawdę bardzooo wdzięczny gdyby ktoś kto ma dostęp do dohyo z prawdziwych zawodów sprawdził czy ktir0711s z rezystorem na diodę 220r i 20k pullup do fototranzystora dobrze reaguje na białą linię Przy warunku np .

If ( pina & czujnik ) {
diody_on;
}
if (!( pina & czujnik )){
diody_off;
}

Chodzi mi o to by nie używać adc w kontrolerze - chcę mieć pewność że na zawodach robot nie zacznie mi uciekać do tyłu bo weźmie czarne dohyo za białą linię.

[piotreks-89]

Właśnie po to masz ADC, aby wyregulować próg po jakim robot ma traktować biały za biały Czułość regulujesz przede wszystkim pull-up'em.

[Bobby]

klonyyy, u mnie w nuggecie przy R diody 270ohm i pullupie 100k w domu działał dobrze, a we Wrocławiu już nie, pomogła zmiana na 10k. Ogólnie jak masz je podpięte pod ADC, to z niego skorzystaj, możesz nawet zaimplementować autokalibrację.