TTY (terminal) in KolibriOS?

Post here questions, problems and suggestions in English language
  • 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.
  • 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 325 times
    terminal.png
    terminal.png (3.48 KiB)
    Viewed 8422 times
    Last edited by hidnplayr on Thu Jan 16, 2014 10:17 pm, edited 3 times in total.
    "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
  • hidnplayr, kudos to you!
  • 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
  • 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
  • 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
  • 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
  • You can find the compiled terminal program in the latest nightbuild
  • 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
  • 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.
  • 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
  • Who is online

    Users browsing this forum: Google [Bot] and 8 guests