SSN-688

[yetislawo]

Andrzeju 1 jak pragnę zakwitać w zinie nic z tego nie pojmuję ;)

[Andrzej1]

yetislawo napisał:

Andrzeju 1 jak pragnę zakwitać w zinie nic z tego nie pojmuję ;)

Witam
Jak próbowałem na patyczkach, to dowiedziałem się że nudne. Jak pominąłem podstawy,
to nie można mnie zrozumieć. Chyba się pochlastam.

Dzisiaj udało się uruchomić transmisję szeregową do PC. W ten sposób uzyskałem potężne
narzędzie do szukania błędów w programie. Mogę wysłać łańcuch do PC i wyświetlić go
na ekranie. Poprawna inicjalizacja portów ATMega32 z zegarem 16MHz aby otrzymać
transmisję szeregową RS232 z prędkością 9600 bez kontroli parzystości, 8bitów na znak, 1 bit stopu
wygląda tak :
Jest to fragment programu nie da się skompilować.

[code:1]
#define F_CPU 16000000ULL /* 16,0Mhz */
#define UART_BAUD_RATE 9600ULL /* 9600 baud */
#define UART_BAUD_SELECT ((F_CPU/(UART_BAUD_RATE*16ULL))-1ULL)
:
void WyslijZnak(unsigned char Znak)
{
while (!(UCSRA & (1<UDR = Znak;
}
:
int main( void)
{
:
/* set baud rate to 9600 */
UBRRL = (unsigned char)UART_BAUD_SELECT;
UBRRH = (unsigned char )(UART_BAUD_SELECT >> 8);

/* URSEL bit must be High, 8bit char */
UCSRC = _BV( URSEL) | _BV( UCSZ1 ) | _BV( UCSZ0 );

/* enable TxD */
UCSRB = _BV( TXEN );
:

}
[/code:1]

Udało się również uruchomić inklinometr. Przyrząd ten wskazuje mi, czy okręt pochylony
jest na dziób czy na rufę. Zasada działania jest taka :
Inklinometr podaje w postaci napięcia odchylenie od pionu w trzech osiach. Ja używam tylko
jednej osi. Nie wiem co zrobić, gdy wykryłbym, że okręt ma szlagzajtę na jedną burtę, więc nie
pytam inklinometru o to.
Inicjalizacja procesu pomiarowego (przetwornik A/D). Przetwornik potrzebuje czasu na
wykonanie pomiaru. Zakończenie pomiaru sygnalizowane jest przerwaniem. Przerwanie ustawia
wartość przechyłu i flagę mówiącą o tym, że pomiar został wykonany. Ze względu na możliwe szumy
i zakłócenia biorę pod uwagę tylko starsze osiem bitów. Dwa najmłodsze pomijam.
Procedury obsługi wyglądają tak :

[code:1]
#include "stdafx.h"
#include "PortDefs.h"
#include "inklinometr.h"
// Inklinometr przylaczony jest do portu A bit 6
// Przetwornik jest jeden, mozna przetwarzac na raz tylko jeden sygnal

static volatile uint16_t przechyl = 0;
static volatile unsigned char PrzechylValid = 0;

SIGNAL( SIG_ADC )
{
przechyl = ADCH;
PrzechylValid = 1;
}

void StartMeasureShipInclination()
{
/*
REFS1, REFS2 = 01 - Napiecie odniesienia AVCC z zewnętrznym kondensatorem
ADLAR = 1 - osiem bitów w ADCH, najmlodsze pomijane
= 0 - operacja normalna
MUX4:0 = 00110 - ADC6
*/

ADMUX = 0b01100110;
/*
ADEN = 1 wlacz
ADSC = 1 start przetwarzania
ADATE = 0 wyzwalanie nie automatyczne
ADIF = 0 znacznik zakonczenia konwersji
ADIE = 1 koniec przetwarzania to przerwanie
ASPS2..0 = 111 preskaler 128 częstotliwosc pomiaru 16Mhz/128= 125kHz
*/
ADCSRA = 0b11001111;
PrzechylValid = 0;

}

unsigned char IsInclinationValid()
{
return PrzechylValid;
}

uint16_t GetInclination()
{
if ( IsInclinationValid() )
{
return przechyl;
}
return 0xFFFF;
}
[/code:1]

Nie ma gwarancji, że jest to całkiem poprawne, ale działa.

Z ukłonami
Andrzej Korycki

[Tomasz_D]

Tak się zastanawiam Jędruś o czym ty w ogóle rozmawiasz ?:laugh:

[radek]

Andrzeju
Co konkretnie przesyłasz po RS, tak, aby zrobić debug - same dane np. z przetwornika, czy masz jakiś program co Ci wywala n. wartości zmiennych?

Pozdrawiam.

[Andrzej1]

Witam

Radek:
W tej chwili przesyłam wyłącznie dane odczytane przez inklinometr. Nie jest to jakaś imponująca ilość
danych bo jeden bajt, ale pozwala na stwierdzenie, czy to cudo działa. I działa. Jak pochylam płytkę,
to zmieniają się odczyty. Nic nie stoi na przeszkodzie, aby przesyłać RSem więcej, choć nie próbowałem
jeszcze. Końcowy fragment poprzedniego zdania uzmysłowił mi, że należy spróbować wysłać na ten
naprzykład trzy bajty i zobaczyć, czy przejdą trzy. Dziś wieczorem to uczynię.
Teraz program jest malutki, idę po kroczku, aby mieć działające peryferiały. Jak skomplikuję go bardziej,
to i pojawią się błędy i będę musiał ich szukać (wyjmę z piwnicy szklany sedes, żebym widział co
narobiłem). Nie mam żadnego wzorca, jak to się powinno zachowywać, wszystko muszę se uroić.
Jako narzędzia do debugowania mam teraz niebieskiego leda i łącze RS. Nie jest to CodeView, ale
zawsze (za pchłę) cóś. Jak uruchomię rozdzielnię mocy, to będę miał jeszcze trzy ledy (te co będą świeciły
na sterze) wtedy to mogę szaleć a szaleć.
Opublikowałem te fragmenty kodu, bo zajęło mi parę ładnych godzin wyszukiwanie jak te bity mają być
ustawione. Tu jest gotowy przepis prania i można go użyć do innych rzeczy. Wystarczy, że w układzie
będzie procesor ATMega32, a to już nie jest bardzo silny warunek.
Nie mam żadnego stanowiska uruchomieniowego do mikrokontrolerów, nie mam symulatora, całe
oprogramowanie procesora jest tworzone od zera. Za mną stoi tylko 30lat programowania a przeciw :
oporna materia, skleroza, umiarkowana znajomość j. angielskiego i wrodzone lenistwo.
Jak przeczytałem co napisałem, to zdziwiłem się niepomiernie, że w ogóle cóś powstało.
Bezsprzecznie powstało dzięki Kodze, bo teraz wstydziłbym się Was bardzo porzucić LAlę w dezabilu.


Z ukłonami
Andrzej Korycki

[radek]

Jak robiłem swój mikrokontroler, to zrobiłem sobie w ten sposób, że ustawiłem sobie środowisko kompilatora na dwa różne komliatory C - jeden gcc pod PC, a drugi kompilator C do atmela. W ten sposób mogłem pisać kod i go kompilować na PC bez potrzeby wielokrotnego wgrywania na atmela aby sprawdzić czy wszystko działa. W tym celu stworzyłem sobie dodatkową (includowaną w zależności od typu kompilacji) bibliotekę we-wy która nieco inaczej wyglądała w przypadku atmela (odczyt i sterowanie bezpośrednio urządzeniami we-wy) i inaczej w przypadku kompilacji na PC (wtedy dane zamiast z urządzeń we-wy były pobierane np. z plików lub wyliczane algorytmem). W ten sposób mogłem sprawdzać, czy mi się sam program zachowywał poprawnie bez ciągłego wgrywania go do kontrolera plus miałem całkiem dobre narzędzia do debugu (standardowy debug PC). Raz na jakiś czas oczywiście wgrywałem ten kod na atmela i sprawdzałem, czy jest ok. Bardzo mocno przyśpieszyło mi to budowanie kodu, uprościło debug i nie zajeżdżało pamięci Atmela.

Może to Ci pomoże.
Pozdrawiam,
Radek.

[Andrzej1]

Dzięki Radku. Też nad takim rozwiązaniem myślałem, ale tu musi być żywy obiekt do badań, czyli
wieczór, basen, okręt w wodzie, laptop i zmiana programu na bieżąco i kolejna próba. To, że będą się kręciły silniki, i ruszały stery nie oznacza, że zabawka będzie zachowywała się sensownie w wodzie.
Basen sobie wynajmiemy w jakiejś szkole za półlitry. Z całą pewnością woźny, jak nie jest całkiem
skapcaniały, się chętnie popatrzy na tego rodzaju próby. Może nawet załatwimy to z dyrekcją
i będą jakieś pozalekcyjne zajęcia z mikroprocesorów w szkole. Może pojawi się jakiś młody, zdolny
modelarz na Kodze, zwabiony tym co zobaczy.
Takie są plany, co z nich wyjdzie, czas pokaże.
Ale najprzód będą próby w rybkarium, też może z połóweczką.
Od dziś zaczynam formować pakiet akumulatorów. Bo bez niego nie uruchomię elementów wykonawczych.

Z ukłonami
Andrzej Korycki

[Edit]P.S.
Producent podaje minimalną ilość możliwości programowania procesora na 100 000. Na razie
wykorzystałem około 100 więc palę dalej spokojnie. 100 na tydzień, czyli po 1000 tygodni to wszystko
padnie, daje to 20 lat circa. Jakoś nie zmartwiło mnie to za zbytnio.

[oksal]

Tak nadrabiam zaległości, i kurcze, ta LAla "przeraża";) Masz Andrzej MÓZG:whistle:

[Andrzej1]

oksal napisał:

... Masz Andrzej MÓZG:whistle:

To prawda, ale nie ma gwarancji jak długo jeszcze.
Ten czas (czas końca mózgu, niezależnie czy dużą czy małą literą) może się niebezpiecznie zbliżać.
PESEL jest bezwzględny.

Z ukłonami
Andrzej Korycki

[Andrzej1]

Witam

Sterownik zbiornika 1 przygotowany do testów.
Mnóstwo kabli, części nie widać - jestem przerażony.



Z ukłonami
Andrzej Korycki

P.S.
Sprostowanie :
Producent gwarantuje możliwość przeprowadzenia 10 000 przeprogramowań procesora a nie jak podałem
poprzednio 100 000 razy.
Muszę się sprężać.