Board.KolibriOS.org

Official KolibriOS board
It is currently Tue Jun 25, 2019 11:03 pm

All times are UTC+03:00




Post new topic  Reply to topic  [ 12 posts ] 
Author Message
PostPosted: Wed Jan 15, 2014 4:20 am 
Offline

Joined: Mon Jan 13, 2014 12:20 am
Posts: 17
Is there a TTY program in Kolibri that will let me use the RS232 port?

I don't need any fancy terminal emulation or modem dialling stuff (both which seem to be a really big deal with DOS & Windoze TTY programs), just something to send characters out that I type (with echo) and write incoming characters to the screen. Of course I need some way of setting the COM port parameters (baud, stop, parity...)

I can't find anything on these forums, and google gives me nothing (useful) for "KolibriOS TTY" or "KolibriOS Terminal Emulator".

Cheers,


Top
   
PostPosted: Wed Jan 15, 2014 8:12 am 
Offline

Joined: Mon Sep 24, 2007 11:11 am
Posts: 2814
Bad news: we haven't RS232 TTY emulator.
Good news: it's very easy to write one. We have console.obj - virtual tty emulator; you can use ports (like in DOS) to access COM port and its control register. I suppose it'll be 100 lines in assembly or 20-30 on C.


Top
   
PostPosted: Thu Jan 16, 2014 5:41 pm 
Offline
Mentor/Kernel Developer
User avatar

Joined: Fri Jun 30, 2006 9:01 am
Posts: 1247
Good news: I wrote a terminal application for you.
Bad news: I ran out of time, so it's not finished. The code to set parity, speed, flow control and all that isnt implemented...
So put on your coding hat, read this page http://en.wikibooks.org/wiki/Serial_Pro ... rogramming and you'll be having fun very soon!

EDIT: I had to take the train today, so had an additional half an hour to code... everything but flow control should work now.


Attachments:
terminal.asm [13.37 KiB]
Downloaded 115 times
terminal.png
terminal.png [ 3.48 KiB | Viewed 2452 times ]

_________________
"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction." Albert Einstein


Last edited by hidnplayr on Thu Jan 16, 2014 10:17 pm, edited 3 times in total.
Top
   
PostPosted: Thu Jan 16, 2014 8:37 pm 
Offline

Joined: Mon Sep 24, 2007 11:11 am
Posts: 2814
hidnplayr, kudos to you!


Top
   
PostPosted: Thu Jan 16, 2014 10:42 pm 
Offline
Mentor/Kernel Developer
User avatar

Joined: Fri Jun 30, 2006 9:01 am
Posts: 1247
SoUrcerer wrote:
hidnplayr, kudos to you!

thanks!

_________________
"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction." Albert Einstein


Top
   
PostPosted: Fri Jan 17, 2014 1:19 am 
Offline

Joined: Mon Jan 13, 2014 12:20 am
Posts: 17
Crikey! That was fast!

Kids have a habit of slowing one down (almost to zero in most cases).

I was just getting my act together and seeking out documents on COM ports, looking at the example 'console.c' (in shell.r4460), looking at how to compile for Kolibri (I haven't even set up GCC, letalone anything to FASM it afterwards).

My question that I was about to ask is whether the I/O ports and Interrupts are accessed directly from the application, or go through the OS... but I will look at the source, that should explain it all.

Hidnplayr... thanks very much!!
MM


Top
   
PostPosted: Fri Jan 17, 2014 1:23 am 
Offline
Mentor/Kernel Developer
User avatar

Joined: Fri Jun 30, 2006 9:01 am
Posts: 1247
Let me know if it works, I'm not sure about the RX...

_________________
"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction." Albert Einstein


Top
   
PostPosted: Sat Jan 18, 2014 6:01 am 
Offline

Joined: Mon Jan 13, 2014 12:20 am
Posts: 17
You're going to think I'm really stupid, but I can't get this to compile.

I've searched all over, and I have not been able to find any sort of guide that tells me how to set things up (libraries, etc) to assemble programs. I am booting off CD (LiveCD version 0.7.7.0+). From this point I would expect I would have to copy the appropriate library/include files to somewhere (where though?) on the RD. @hidnplayr : you obviously have your environment set up in a particular way, looking at your program... include '../../proc32.inc' etc.

I read the documentation "use of various compilers in Kolibri" which is quite good, but gives general information, not where to put/find libraries, and says you have to convert (for example) a GCC compiled C program into a binary, but doesn't say how. The WIKI page "writing applications for KolibriOS" is quite similar, but deals with ASM only.

I've looked fairly hard - obviously not in the right place though - and I can't find the INClude files in the SVN.

I think once I find where the right files are, I'll be off and running. Can someone please point me in the right direction?

Thanks,
MM


Top
   
PostPosted: Sat Jan 18, 2014 6:58 am 
Offline

Joined: Tue Oct 05, 2010 6:05 pm
Posts: 214
You can find the compiled terminal program in the latest nightbuild


Top
   
PostPosted: Sat Jan 18, 2014 1:52 pm 
Offline
Mentor/Kernel Developer
User avatar

Joined: Fri Jun 30, 2006 9:01 am
Posts: 1247
Yes, the sources need to be in the programs/system/terminal/ folder of our SVN repository.
I have uploaded the program to our SVN, so if you want to 'compile' yourself, get yourself a copy of the SVN repository :)

To make a local copy of the repository on your computer, install an SVN client.
If you're using windows, I recommend tortoiseSVN, it's GUI based so very easy to learn/convenient to use.
Once you have the client installed you need to 'checkout' svn://kolibrios.org.

_________________
"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction." Albert Einstein


Top
   
PostPosted: Wed Feb 05, 2014 7:30 am 
Offline

Joined: Mon Jan 13, 2014 12:20 am
Posts: 17
I haven't downloaded the CVS to do any development with (at this stage), but I have had a bit of a play with 'terminal'.

Reading through the source, most of it is setup (not surprisingly), and I did note the comment about receiving interrupts on the application level. Does that mean that an interrupt driven TTY would have to link deeper into the base/core OS? Would I be right in assuming that there are no 'drivers' in the core to handle an interrupt from this source?

I was using 'terminal' at 38400 baud to talk to a Seagate Hard Disk (which is its' default), and the responses back seemed very strange (ie: stranger & more cryptic than usual). I figured out before too long that characters were being dropped because 'terminal' could not keep up. Because I couldn't understand the response from the HDD, I had to resort to windoze to talk to it. Anyway, once I got windoze to spit out the response to change baud rates, I could set it to 9600 without a problem, and it would work fine.

No doubt this time is taken drawing pixels, because the code is really tight (being assembler). Without writing to the screen, an 'Rx' loop would be less than 1uS at 700MHz (my machine). Making a double buffer scheme would likely fix the problem, but make it much more complicated too.

Interestingly, I couldn't find any DOS terminal emulator that could go any faster than 19200! Probably because that was as fast as they could write to the screen.


@hidnplayer:
With no flow control, simply looping the TX pin back to the RX pin (link pin 2 & 3) will echo what you type back to the screen. Hardware: a screwdriver tip, or for a more robust solution, an old 0.1" pin jumper.

Cheers,
MM.


Top
   
PostPosted: Wed Feb 05, 2014 12:43 pm 
Offline
Mentor/Kernel Developer
User avatar

Joined: Fri Jun 30, 2006 9:01 am
Posts: 1247
Thanks for the test report.

With no flow control and only polling the UART, these problems were bound to happen..
Removing the mcall 5, 1 will increase speed, but CPU usage will be 100%.

Our API document mentions being able to receive IRQ's 0 - 15, but I'm afraid the system function to enable this was removed for some reason, and this is just a part of the documentation that wasnt updated...
A solution would be to write a small driver, that receives the data from COM ports using interrupts and puts it in a larger buffer.

_________________
"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction." Albert Einstein


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 12 posts ] 

All times are UTC+03:00


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Limited