Ostatnie wiadomości

Strony: 1 ... 4 5 [6] 7
51
Asembler / Odp: RS232 / USB
« Ostatnia wiadomość wysłana przez Nevar dnia Grudzień 02, 2012, 12:39:11 »
Od razu przepraszam za opóźnienie ale nie pisze tutaj zbyt dużo osób i trochę jestem uśpiony.

Generalnie nie jest to tak proste jak by się wydawało. Gdy były jeszcze montowane w komputerach porty równoległe LPT to tam można było ustawiać lub zerować odpowiednie wyjścia wg uznania. W przypadku RS to jest transmisja szeregowa, więc to jest zupełnie inaczej. Z poziomu PC masz do dyspozycji jeden z portów na który wysyłasz bajt i sam sprzęt zajmuje się wywoływaniem odpowiednich stanów wyjść żeby ten bajt przesłać szeregowo. Co wywołuje pewną sekwencje stanów tych wyjść nie kontrolowanych przez ciebie bezpośrednio. W ramach potrzeby użycia tylko jednego przycisku to przypuszczam że dało by się wykorzystać jedną z linii statusowych do komunikacji wejściowej jak i wyjściowej. Wystarczy poczytać o tym w sieci http://pl.wikipedia.org/wiki/RS-232.

Najlepiej jak byś miał z drugiej strony coś więcej niż tylko przycisk np jakiś mikroprocesor z obsługą RS. Możesz się pobawić i wlutować jakiś sterownik który odbierze ci wysłany bajt i zapisze w jakimś rejestrze.
52
Asembler / RS232 / USB
« Ostatnia wiadomość wysłana przez codex dnia Listopad 23, 2012, 20:30:02 »
Witam. Od razu przejdę do rzeczy:
Potrzebuje w Windows uruchomić program przy pomocy sprzętu* samoróbki podłączonego do RS232 lub USB.

*Dla uproszczenia niech sprzętem będzie zwykły wyłącznik na początek.

1. Którego złącza lepiej użyć RS232 / USB
2. Jakie piny połączyć i w jaki sposób  - jaki materiał ogarnąć, żeby to zrozumieć ?

Wszystko chciał bym zrealizować w asembly ponieważ nie znam innego języka ( i myśle, że nie muszę znać ).   
53
Asembler / Odp: Propozycja współpracy
« Ostatnia wiadomość wysłana przez mangado dnia Lipiec 17, 2012, 11:40:03 »
Co do ARM-a (Advanced RISC Machine) to nawet ponoć można speca zassać!
RISC?
Czyżby to był RISC?
Uuuu...
Tych ARM-ów to też 5000 odmian...
...ć!

Ale... Tera rządzi cortex...

Jest całkiem ładny GCC pod łindołz, zwie się Code Sourcery G++!

http://www.codesourcery.com
54
Asembler / Odp: Propozycja współpracy
« Ostatnia wiadomość wysłana przez Nevar dnia Lipiec 14, 2012, 14:39:41 »
Moje plany zwykle przewidywały pisanie systemu, szczególnie jądra w czystym asemblerze. Tak się właśnie zastanawiałem czy by nie napisać systemu na jakiegoś ARMa. Nawet posiadam jakiś sprzęt. Jednak styczność z tym na niskim poziomie miałem bardzo małą więc pewnie większość czasu bym musiał poświęcić na macanie procesora i urządzeń niż na projekt systemu, ale czemu nie. Jeżeli jesteś chętny bawić się w ARMy to można to obadać. Jest chyba możliwość zmuszenia Qemu to emulacji ARM. 
55
Asembler / Odp: Propozycja współpracy
« Ostatnia wiadomość wysłana przez mangado dnia Lipiec 10, 2012, 18:22:17 »
WOW! Sie zgłaszam!  :D

Ale oprócz architektoory intel/amd cza pomyśleć intensywnie na ARM!!!
56
Asembler / Propozycja współpracy
« Ostatnia wiadomość wysłana przez Nevar dnia Lipiec 04, 2012, 15:39:27 »
Oferuje możliwośc współpracy przy projekcie pisania prostego jądra systemu operacyjnego.

Założenia: Stworzyć coś co zaoferuje minimum (mikrojądro) funkcjonalności. Stworzenie systemu wątków, procesów, komunikacji, systemu driverów, zarządzania pamięcią, procesorami. Jako język dla samego jądra będzie stosowany czysty asembler. Docelowo jednak nie będzie ograniczenia tylko i wyłącznie na ten język dla dalszego użycia jądra systemu. Czyli pisanie samych aplikacji driverów lub modułów wyższego poziomu będzie możliwe z poziomu języka C. Jako że jądro będzie napisane w asemblerze to skupiam się tutaj na architekturze minimum x86_64. Kod ma działać na architekturze Intel jak i AMD.
Jeżeli chodzi o cel całego projektu to jest to czysta przyjemność z programowania w asemblerze i tworzenie czegoś od podstaw. Jest też przede wszystkim możliwośc nauczenia się tego wszsytkiego o czm już wspmniałem jak i dużo więcej.

Kogo szukam: Osób które znają asembler i programowały w nim programy pod DOS i Winows/Linux minimum rok. Znajomość języka C i minimum rok doświadczenia. Nie wymagam znajomości konkretnych systemów operacyjnych Windows/Linux od strony jądra. Jest jednak wymagana znajomośc elementów jądra systemu operacyjnego i ich funkcjonalności.

Czego ja bym oczekiwał: Nie szukam na pewno osób, które są zajebiste w programowaniu i napisały już dwa systemy w swoim życiu. Szukam przede wszystkim ludzi którzy chcieliby poświęcić 2 lata (może więcej) ze swojego życia na nauczenie się dobrego programowania w asemblerze i dobrego zaznajomienia z docelową architekturą PC.
Jeżeli ktoś ma duże braki w znajomości sprzętu lub samego języka to oczywiście czeka go więcej czytania niż praktyki, ale oczywiście zgłaszać się mogą wszyscy. Postaram się bezpośrednio zweryfikować czy szukam danej osoby.
57
OS-Dev / Odp: Wykrywanie typu FAT
« Ostatnia wiadomość wysłana przez mangado dnia Grudzień 10, 2011, 15:57:13 »
I cześć pieśni!
Temat wyczerpany!
Dźwiękuje!
58
OS-Dev / Odp: Wykrywanie typu FAT
« Ostatnia wiadomość wysłana przez Nevar dnia Grudzień 10, 2011, 01:25:08 »
Zgodnie ze specyfikacją to jest właśnie tak:
"The FAT type — one of FAT12, FAT16, or FAT32 — is determined by the count of clusters on the volume and nothing else."

Oczywiście można stworzyć dysk FAT32 o zbyt małej liczbie klastrów, ale wtedy z powodu braku zgodności każdy OS ma prawo olać taki dysk i uznać go za uszkodzony lub po prostu samemu go uszkodzić.
Dla testu utworzyłem taką partycję i w hex edytorze zmniejszyłem jej parametry tak żeby miała mało klastrów. Windows mimo wszystko operował na niej bez problemu. Tylko, że w tym przypadku on chyba bazował na wpisie PartitionType z sektora MBR. Można by się jeszcze bawić z utworzeniem systemu FAT32 na dyskietce.
Ja radzę brać przede wszystkim pod uwagę wpisy z MBRa. W specyfikacji FAT jest taki warunek rozpoznawania podany ponieważ nie obejmuje ona istnienia tablicy partycji i MBR. Tam gdzie jest jawnie podany typ to nie ma co się bawić w rozpoznawanie.
59
OS-Dev / Odp: wykrywanie liczby rdzeni cpu
« Ostatnia wiadomość wysłana przez Nevar dnia Grudzień 10, 2011, 01:08:27 »
Ja nie czekam. U mnie to wygląda tak:
  • 1. BSP po starcie przechodzi do LongMode i inicjuje jakieś podstawy systemu czyli pamięć, przerwania, scheduler.
  • 2. Potem ustawia wszystko co trzeba do startu innych procesorów. Wysyła odpowiednie przerwanie i startuje wszystkie pozostałe procesory AP.
  • 3a. BSP na nic nie czeka tylko skacze bezpośrednio do funkcji CPUInit
  • 3b. W tym samym czasie wszystkie AP przechodzą w LongMode i potem również skaczą do CPUInit.
  • 4. CPUInit ustawia wszystkie struktury procesora do pracy w systemie i przechodzi do oczekiwania na zadania w schedulerze.

Jeżeli mam w systemie jeden procesor czyli tylko BSP to tylko on będzie wykonywał zadania. A jeżeli mam 3 procesory to wszystkie zostaną obudzone i przejdą do wykonywania zadań.
To wszystko zależy jak się zaprojektuje budowę systemu. Ja mam jedną listę zadań w schedulerze. Każdy procesor jak nie ma co robić to bierze z niej najstarsze zadanie.
60
OS-Dev / Odp: wykrywanie liczby rdzeni cpu
« Ostatnia wiadomość wysłana przez mangado dnia Grudzień 09, 2011, 21:13:37 »
Oj chyba ważne!
Ponieważ po IPI-startup należy poczekać, aż wszystkie CPU się uruchomią!
Jeżeli nie będę wiedział ile mam "procesorów" to nie będę wiedział kiedy to już wszystkie będą wystartowane!!!
No chyba, że jednak nie trzeba szczekać?...
Strony: 1 ... 4 5 [6] 7