Nachrichten

41

Lowlevel-Coding / Re: Serielle Schnittstelle unter Windows

« am: 21. July 2008, 12:48 »

Moin ich verwend das so.
     

Code: [Auswählen]

if (!WriteFile ( hInterface,             // Port handle
                 pabTransmitData,       // Pointer to the data to write
                 (DWORD)wTransmitData_len,  // Number of bytes to write
                 &dwNumBytesWritten,   // Pointer to the number of bytes written     
                 NULL))   
{
   // WriteFile failed. Report error.
}


42

Lowlevel-Coding / Re: Serielle Schnittstelle unter Windows

« am: 21. July 2008, 12:17 »

Moin

ja mit WriteFile kann man daten auf den handel rausschreiben.
Mit ReadFile daten empfangen.

CreateFile // öffnen des com ports
CloseHandle // nach gebrauch den handel wieder löschen

WriteFile // daten schreiben
ReadFile // daten lesen

noch ein paar nützliche Funktionen zum Comm port

GetCommState // staus des ports ermittlen
SetCommState // staus verändern bautrate, stopByts Parity, ...
GetCommTimeouts // timeouts ermitteln
SetCommTimeouts // timeouts setzen

mehr gibts wie immer unter der MSDN

43

Lowlevel-Coding / Re: Serielle Schnittstelle unter Windows

« am: 04. July 2008, 09:34 »

Moin

willst du nur wissen, was auf der Schnitstelle passiert?

oder Willst du pc seitig auch ein eigenes Programm haben.

1. Möglichkeit währe Hyperterminal, wenn der deine Daten versteht,
2. Docklight

3. brauchst du selbstgeschriebenes Programm,
3a. Win API
3b. Es gibt meines wissens auch eine AktivX componente dafür
3c. Es gibt das gleiche auch für Borland CBuilder und Delphi
3d. für java gibts auch zwei Bibliothek RTXComm und Comm.jar von sun ( wenn die noch existiert )

gruss

44

Lowlevel-Coding / Re: memalloc

« am: 14. June 2008, 15:54 »

moin

Ich hab das bisher so verstanden, das der Speicher den malloc verwaltet in einer art verkettten liste verwaltet wird. Vor jedem Speicherbereich ist eine kleine Datenstrucktur die Auskunft über grösse des Speicherbereiches, den vorherigen und nachfolgenden Datensatz auskunft gibt. Insgesamt werden 2 listen verwaltet, die des freien speichers, und die des belegten speichers. wird speicher angefordert, wird eine neue datenstruktur angelegt, oder eine aus der liste des Freienspeichers verwendet, und in der Liste des belegten speichers eingetragen. Entsprechend wird dann aus der liste des Freispeichers der bereich entfernt. Wird der speicher wieder freigegeben, wandert der eintrag in die liste des Freien speichers.

deine map hat ein Problem, wenn mehr Speicher angefordert wird, als in einer page platz hat, geht das nicht die verwaltungsstruktur liegt dann irgendwo dazwischen. Du limitierst damit den maximal anzufordernden speicher auf page size - verwaltungsdaten.

45

Lowlevel-Coding / Re: Multitasking

« am: 06. June 2008, 15:24 »

Jede Task Thread oder auch Prozess braucht seinen eigenen Stack. sonst knallt das ganz böse.

46

Offtopic / Re: Text mit CSS in einer Zeile

« am: 04. June 2008, 16:41 »

Hallo,

hab mich mit html nie intensiev auseinander gesetzt.

aber soweit ich das in errinerung hab gibst du nur den style für den inhalt an.

du kanst aber auch das div durch die gegend schieben wie du lustig bist.

sagt dir http://de.selfhtml.org/ etwas? schau mal dort unter CSS dort sollte sicher die lösung auf dein problem zu finden sein.

gruss

47

Lowlevel-Coding / Re: ___stack_chk_fail was fehlt ld an der stelle?

« am: 03. June 2008, 18:00 »

@ ReadEagle

hast du den code mal ausprobiert? ich würde sagen, der hat noch 2 3 Fehlerchen.

1. char c wird doppelt verwendet ( Laufvariable und temp )
2. char c wird in der for schleife nicht innitallisiert ( unschön )
3. c = (ulNumber & 0xf) >> 28; wird wohl immer 0 werden, wenn ich nicht total daneben liege

für die Ausgabe von Hex zeichen verwend ich normalerweise eine art lookup table.

Code: [Auswählen]

const char []  HEX  = {'0', '1', '2', '3', '4', '5', '6', '7', '8', '9', 'A', 'B', 'C', 'D', 'E', 'F'};

for ( i = 0; i < 8; i++ )
{
   c = ( ulNumber >> 28) & 0x0F;
   PrintChar(HEX[c], , ulColor);
   ulNumber <<= 4;
}



48

OS-Design / Re: HAL

« am: 16. May 2008, 12:08 »

Genau ich weiss nicht wie lang sie sind. daher definier ich sie ja selber.  Dies ist ein part, der bei der Portierung auf eine andere plattform angepasst werden muss. Wenn meine selbst definierten typen ohne kontrolle auf eine neue platform übernehme, kann ich probleme bekommen. Da sie aber an einer zentralen stelle definiert sind, kann ich recht einfach anpassungen vornehmen.

Ich geb ja zu das dies problem eher auf exotische plattformen zu finden ist. Das beispiel ist sicher nicht representative, aber für den 8051 gibt es zumindest keinen mir bekanten ANSI C Compiler. es ist auch ein MCU und keine CPU, aber quasi industrie standard.

49

OS-Design / Re: HAL

« am: 16. May 2008, 10:50 »

entschuldigung sollte ich dich angegriffen haben.

Ich kenn WORD eigentlich nur aus pascal zeiten. und aus der MSDN und da war es meist 16 bit gross. (wobei MS sicher nicht das mass aller dinge sein sollte)

aus gründen der Portabilität sollten Variablen typen selber definiert werden. Nicht jeder compiler muss sich entsprechend standard verhalten. somit kann da viel stehen, nur wenn es nicht so implementiert ist bringt das recht wenig.

Die von mir erwähnte MISRA regeln schreiben das nicht ohne grund vor.

und die im Standard beschriebenen int32_t setzen wir hier auch ein. nur definieren wir diese selber, damit wir wissen, wie gross die auch wirklich sind.

gruss

50

OS-Design / Re: HAL

« am: 15. May 2008, 20:24 »

* Portzugriffe

Manche Architekturen haben keinen gesonderten I/O Portbereich, sondern bei denen wird I/O über den "normalen" physischen Adressraum gehandhabt.

damit hab ich die letzten 9 monate beruflich zu tun gehabt. Ein ARM ist halt doch ein lustiges spielzeug.

# Größe word, dword, qword

1. Was ein {d,q}word ist, ist imho nie wirklich festgelegt worden und jeder versteht was anderes darunter, insofern evtl. unsinnvoll in einem Kernel.
2. Der C standard definiert bereits Typen fester Größe, es ist mitunter sinnvoll (für andere die den Code lesen, aber auch für dich) diese zu verwenden (zumindest den Namen, muss ja nicht in der gleichen Header sein)

Da muss ich wiedersprechen. es mag zwar definiert sein was ein int, ein short int und ein long int ist, nur hält sich nicht jeder compiler auch wirklich daran. bzw ist es bei int sogar platform abhängig. es gibt in der MISRA nicht umsonst eine Vorschrift, alle typen zu redefinieren. Daher sollten wenn der Code partabel sein soll alle basistypen redefiniert werden. eine anpassung an die platformgegebenheiten ist dann durch änderungen an einer zentralen stelle möglich.

und zu word dword und qword. ein word ist 16 bit gross. und was dann dWord und qWord sind sollte dann klar sein. es gibt sicher geschicktere type definitionen. z.B.
U8 I8 U16 I16 U32 I32
uint8 sint8 uint16 sint16 uint32 sint32

gruss

51

OS-Design / Re: HAL

« am: 15. May 2008, 09:00 »

Moin

kleine gemeinheit am rande, was für einen Mac meinst du? die neuen oder etwa die alten? (G5 und G4 Modelle sind nicht von intel die neuen schon somit würden sie laufen, wenn die sache mit dem nichvorhandensein eines BIOS nicht währe. Glaub EFL heist das ding)

Als ergänzung
Alles was in ASM geschrieben ist.

52

Lowlevel-Coding / Re: Eigenes flashfähiges OS?? -> Flex OS <-

« am: 12. May 2008, 10:56 »

Hallo,

Wiedersprecht mir wenn ich falsch liege: Meines Wissens wird Flash von einem, nennen wir es mal Interpreter interpretiert und dargestellt. Diesen Flash-Interpreter gilt es nun für dein OS nachzubauen. Selbst wenn du aus einem Flash Programm eine EXE machst, wird nichts anderes getan, als den Interpreter davor zu hängen. Der Interpreter selber wiederum setzt auf Funktionen auf, die ihm Windows oder Linux zur Verfügung stellt.

Das was du brauchst, ist ein Flash Interpreter, (ggf gibts sowas schon als OpenSource)
Einen Kernel der zusätzlich zu den Grundaufgaben, die vom Flash Interpreter notwendigen Funktionen bereitstellt, wie Grafikdarstellung, Soundausgabe, Dateisystem, ...
und eine Booter der das ganze starten kann. ( ggf ist grub eine Lösung für dieses Problem )

gruss

53

Offtopic / Re: Kleine Vorstellung

« am: 18. April 2008, 12:51 »

und wenn kein zeichen im puffer ist, wartet deine konsole so lange bis über dein Tastatur interrupt ein zeichen in den puffer geschrieben wird. Das kann man dann z.B. über Betriebsystem synchronisations mechanismen lösen. geht aber auch über eine volatile variable.

54

Lowlevel-Coding / Re: Bildpunkt auf Monitor setzen

« am: 08. April 2008, 13:08 »

Die Frage ist eher welcher GrafikModus?

Auflösung und Farbtiefe?

VGA 320x200 / 256 out of 64KFarbtiefe
SVGA 640x480 / 800x600 / ... 8 /15/16/24 bit farbtiefe

VGA Im RM Bios int 10h mode 13 und dann direkt im Framebuffer pinseln
oder direckt die VGA register manipulieren z.B. für den Mode x 
SVGA IM RM über VESA BIOS Extension und dann mit Frambuffer und Frambuffer umschaltung ( langsam )

SVGA Im PM etwas aufwendiger VESA BIOS auch aus verwendbar.

55

Offtopic / Re: Das Lowlevel-Wiki bekommt eine Lizenz

« am: 23. March 2008, 13:18 »

Und wie sieht das für die neuen aus? müssen die unter die Lizenz gestellt werden, oder darf man wählen?

gibt das dann nicht irgendwann ein grosses durcheinander? welche artikel haben die Lizenz, welche nicht? (Die bis jetzt erstellten sind ja in eine entsprechende gruppe gewandert)

56

Offtopic / Re: Das Lowlevel-Wiki bekommt eine Lizenz

« am: 23. March 2008, 10:39 »

Lizenz is ok. by-sa währe auch OK.

wird die lizens dann in zukunft auch pflicht um einen wiki zugang zu bekommen?

57

Offtopic / Re: gcc will nur über direktaufruf

« am: 19. March 2008, 20:17 »

Moin scha mal nach wie lang der path ist. ggf ist der path für make einfach zu lang.(hat irgendwas mit cygwin zu tun) ein kolege hate so ein problem schon mal. ggf im path die einträge für den gcc nach vorne schieben.

58

Lowlevel-Coding / Re: RPC und Treiber

« am: 16. March 2008, 15:10 »

Stimmt der kernel krigt sicher immer alles kaput.

(ich geh mal davon aus das wir von systemen mit paging und MMU reden)

nur hat der kernel auch immer alle speicherseiten der user tasks mit eingeblendet?

Fehler will man nie machen. Es schleichen sich doch immer wieder mal welche ein.

Und von was für systemen reden wir? 80486 oder aktuelle PC Systeme?
wie gross ist der Speicherdurchsatz so eines systems, (10MB/s oder 3GB/s)  und wie gross ist die Datenmenge die ich kopieren will. ( 1kb 100kb oder 10MB ) und was sind hinterher ein paar µs? kleinfieh macht auch mist sicher. nur ist es hinterher würlich spürbar?

59

Lowlevel-Coding / Re: RPC und Treiber

« am: 16. March 2008, 14:30 »

Es kommt immer darauf an, wie du das kopieren realisierst.

man kann byte weise kopieren in einer for schleife ( sicher das langsamste )

man kann das ganze auf ein alligment von 4 Byte bringen und die länge auf ein vielfachen von 4 definieren. und dann keine Bytes sonder DWords in einer for schleife kopieren. sind schon mal 3 speicherzugriffe weniger je schleifen durchgang.

man kann auch string befehle des Befehlsatzes verwenden. spart den ganzen zähloverhad den man selber implementiert.

[edit hat sich erledigt. gibt es auf pcs wohl nicht.]
oder ich verwende z.B. DMA. der kopiert mir die daten im hintergrund durch die gegend. Entlastet dadurch den Prozessor bus. und die CPU kann ggf was anderes machen. Sicher nicht interesant für 8 Byte [ jedes billige embeded system bietet mitlerweile  GPDMA an mit dem ich von MEM to MEM kopieren kann. teilweise sogar mit richtig inteligenten mechanismen]

Sicher ist nicht kopieren schneller als kopieren.

nur ist es z.B. aus sicherheits sicht gewollt, user speicher im kernel speicher sichtbar zu haben? bzw direckt darauf zu arbeiten?

du must den user speicher im kernel einblenden. ( muss man auch beim kopieren )
du must die addresse umrechnen. ein teil davon ist auch beim kopieren notwendig.

Wie sieht es z.B. mit Treibern aus, die auf grund eines implementierungs fehlers daten auserhalb der gewollten datenstruktur verändert? Der Fehler wird vom Treiber verursacht, wirkt sich aber auf den user space aus. Der Fehler tritt dann auch erst im user space auf. Wo wird man den Fehler als erstes suchen. Im userspace programm oder im treiber?

So ein Fehler kann mit jedem neuen treiber wieder passieren. Wohingegen die Implementierung solcher copy from user / to user funktionen nur einam gemacht werden müssen.

gruss

60

Lowlevel-Coding / Re: RPC und Treiber

« am: 16. March 2008, 13:53 »

Hi

ich weiss nur das das so in linux kernel treibern gehandhabt wird. Der kernel stellt hierzu die funktionen

unsigned long __copy_from_user(void *to, const void *from, unsigned long bytes_to_copy);

und

unsigned long __copy_to_user(void *to, const void *from, unsigned long bytes_to_copy);

zur verfügung.

und was soll langsam sein? das umkopieren? Kommt auf den Prozessor und die speicherbandbreite an. Stimmt man muss die daten nicht umbedingt durch den prozessor nageln. aber das muss man ja nicht. wozu gibt es dma der das für einen erledigen kann?

Anlegen und freigeben der Datenstrukturen im Kernel? ggf ist das sogar gar nicht notwendig, für die RTC könnt ich mir vorstellen, das die Struktur nur einaml existiert und immer wieder verwendet wird. Sprich anlegen und löschen entfällt. Sollte sogar für eine HD funktionieren. Das speichermanagement ist ja user sache. Und sollten doch mehrere benötigt werden könnte ein Pool helfen.