Page 1 of 1
Keyboard Driver Issues
Posted: Fri May 23, 2008 8:21 pm
by DrLink
Code: Select all
kernel.c: In function ‘KeyboardIsr’:
kernel.c:102: error: ‘byte’ undeclared (first use in this function)
kernel.c:102: error: (Each undeclared identifier is reported only once
kernel.c:102: error: for each function it appears in.)
kernel.c:102: error: expected ‘;’ before ‘new_scan_code’
I am attempting to use examples on
this page for writing a keyboard driver to see if I can get input from the user. I am literally lost. Here is my code in question...
Code: Select all
// Taking input...
unsigned char inportb (unsigned short _port)
{
unsigned char rv;
__asm__ __volatile__ ("inb %1, %0" : "=a" (rv) : "dN" (_port));
return rv;
};
// ...and gathering output.
void outportb (unsigned short _port, unsigned char _data)
{
__asm__ __volatile__ ("outb %1, %0" : : "dN" (_port), "a" (_data));
};
// It's self explanitory: The Keyboard ISR (and accompanying variables).
void KeyboardIsr()
{
byte new_scan_code = inportb(0x60);
/* Do something with the scancode.
* Remember you only get one byte of the scancode each time the ISR is invoked.
* (Though most of the times the scancode is only one byte.)
*/
/* Acknowledge the IRQ, pretty much tells the PIC that we can accept >=priority IRQs now. */
outportb(0x20,0x20);
}
What's the problem here? I've been doing C for a year now and this is a strange error.
In addition, I'm wondering if there's a direct tutorial on making a sort of ... command shell for the kernel. I'm exhausted from working on my OS for a day and I need a break, my brain is literally fried.
Posted: Fri May 23, 2008 8:49 pm
by piranha
Either replace byte with unsigned char or typedef it.
EDIT: The basic shell is the easy part. Gather char inputs into a buffer and then compare them with commands.
-JL
Re: Keyboard Driver Issues
Posted: Sat May 24, 2008 4:58 am
by codemastersnake
byte new_scan_code = inportb(0x60);
Add this to your code
or change
byte new_scan_code = inportb(0x60);
to
unsigned char new_scan_code = inportb(0x60);
It'll work
Posted: Sat May 24, 2008 8:56 am
by DrLink
I spent about 3 hours just now, trying to write a keyboard driver so that I could get data from the keyboard, and place it in video memory. When the "Enter" key is pressed, the kernel should read from video memory and place it in the "input" buffer (a char value) so that it may be manipulated.
I'm literally stuck and the "I'll give you a hint" lines on the wiki link to pages that are not relevant to what I am searching for.
Are there tutorials on creating a keyboard driver so that I can accomplish what I stated above? (P.S. Feel free to smack me at any time, since I'm so new to this).
Posted: Sat May 24, 2008 9:01 am
by piranha
Posted: Sat May 24, 2008 9:09 am
by DrLink
Funny thing, I was using that before, but the main.c solution for the memory functions in main.c are buggy and refuse to compile, hence, I'm not sure if I can do that.
Posted: Sat May 24, 2008 9:44 am
by piranha
Do you have interrupts set up?
Why wasn't it compiling?
-JL
Posted: Sat May 24, 2008 9:50 am
by DrLink
I was using the EXACT code from the memcpy, memset, memsetw, and strlen functions. Here's the exact error messages I get from my build.sh script (assembles, compiles, links, and merges with GRUB all in one fell swoop):
Code: Select all
kernel.c: At top level:
kernel.c:88: error: expected declaration specifiers or ‘...’ before ‘size_t’
kernel.c:89: warning: conflicting types for built-in function ‘memcpy’
kernel.c: In function ‘memcpy’:
kernel.c:92: error: ‘count’ undeclared (first use in this function)
kernel.c:92: error: (Each undeclared identifier is reported only once
kernel.c:92: error: for each function it appears in.)
kernel.c: At top level:
kernel.c:96: error: expected declaration specifiers or ‘...’ before ‘size_t’
kernel.c:97: warning: conflicting types for built-in function ‘memset’
kernel.c: In function ‘memset’:
kernel.c:99: error: ‘count’ undeclared (first use in this function)
kernel.c: At top level:
kernel.c:103: error: expected declaration specifiers or ‘...’ before ‘size_t’
kernel.c: In function ‘memsetw’:
kernel.c:106: error: ‘count’ undeclared (first use in this function)
kernel.c: At top level:
kernel.c:110: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘strlen’
Now, for a starter, that's a bit overwhelming... Please explain what is going on here. I'd really appreciate it.
EDIT: I can handle warnings. I just need to get past the errors.
EDIT 2: For the nitpicky, here is the code in question:
Code: Select all
void *memcpy(void *dest, const void *src, size_t count)
{
const char *sp = (const char *)src;
char *dp = (char *)dest;
for(; count != 0; count--) *dp++ = *sp++;
return dest;
}
void *memset(void *dest, char val, size_t count)
{
char *temp = (char *)dest;
for( ; count != 0; count--) *temp++ = val;
return dest;
}
unsigned short *memsetw(unsigned short *dest, unsigned short val, size_t count)
{
unsigned short *temp = (unsigned short *)dest;
for( ; count != 0; count--) *temp++ = val;
return dest;
}
size_t strlen(const char *str)
{
size_t retval;
for(retval = 0; *str != '\0'; str++) retval++;
return retval;
}
EDIT 3: And I'm in protected mode. No interrupts, remember?
Posted: Sat May 24, 2008 10:06 am
by piranha
Now, for a starter, that's a bit overwhelming... Please explain what is going on here. I'd really appreciate it.
Do you have size_t defined? Change all the 'size_t' to 'unsigned int'.
How long have you been doing C programming?
Now, the warnings: Your CFLAGS (or the arguments passed to gcc) should include:
There
are interrupts in protected mode. Thats how the devices signal that something happened. The interrupts (plus GDT + IDT) must be set up in order to use the devices.
EDIT: You need to learn more about C programming if you want OSdev to be more fun.
-JL
Posted: Sat May 24, 2008 10:24 am
by DrLink
Yes, I suppose I have become a bit rusty (though I did learn C++ before C, and I'm taking an advanced C/C++ course this summer). I'll try out what you said, and thanks for your help... I might check back in this thread if there are any more keyboard driver problems, because, as the rule goes, once you get past the low-level stuff that never seems to end, it becomes a helluva lot easier.
I also thought I stated earlier I've done both C and C++ together for a year?
Though, I guess I have relied on the standard libraries for too long...