Serial programming in C , in DOS - c

I need to do some basic serial programming in C, in old 16-bits MS-DOS. I know the basics, i had coded some serial comm. in some microcontroller some decades ago, but that's now ancient knowledge, and it's not so easy to find information.
I'm looking for some reliable (not necessarily free or open source) library or code, and general information.
I'm also looking for some instructions/advise about how to test it, assuming I'm developing on a Win7 machine. For example, if it would be possible to emulate a null-modem connection from a console terminal in my Win7 machine to a emulated COM port running my DOS program in a DOSBOX environment, or something like that.

What a coincidence. Just finished a college class on low level hardware using it.
These will guide you (rolling your own, no libs, not hard!):
Course slides on serial port
BeyondLogic tutorial on it
Course lab script on the practical project using the serial port
The last one's in Portuguese, but the code samples/tables are commented and with variable names in english.
Good luck.
About emulating. Virtual PC, for example, allows piping of data through a virtual serial port using a text file. Google it. You can also use Windows 98 with DJGPP for compiling this. Use old command.com (which is a self contained dos emulator, basically). You can also restart in MS-DOS.

Download virtual box, and install DOS (available with MSDN subscriptions, as are free alternatives as FreeDOS).

Related

Dynamically Configure FPGA From Host Program

I was wondering if anyone knows an efficient way to program the FPGA(PL) for a Xilinx Zynq-7 series or related devices,from a host C program (not on the SoC, but from the host PC). Is there an Xilinx API I can use/include in my program. As the only way I can think of doing it at the moment is invoking command line programming via Impact.
Basically I want to put the SDK "Program FPGA" functionality in my host C program where the user selects a prebuilt .bit file (and .elf file if possible) to program the FPGA/(SoC). This is just for a test of concept, later I would like to put this dynamic configuration onto one of the ARM CPU's.
Many Thanks
Sam
At the very least you'll need an intermediate MPU/MCU that can read from USB, as at startup most FPGAs aren't capable of much at all. I'm guessing this'll make it hard to find a MPU/library pair to do so, because there are so many options, each of which would be pretty application-specific. You're better off starting with programming them off an ARM chip, since you'll need some CPU with the FPGA in any case.
This seems somewhat useful.

Interacting with terminal in Linux using C/C++

Is it possible to have an interactive session with terminal using a C code.
I need to open a PORT using terminal and then start GtkTerm and then send hexadecimal code to it . So, can I do this all using a C code.
Please suggest me other alternatives to communicate through serial Port . But I need to make a GUI , so that I dont need to go to terminal again and again because it is not expected from every user.
Thanks :)
Many years ago, I used Greenleaf's CommLib for serial communications and found it to be an extremely high quality product. It looks like they've added some terminal emulation capabilities to it as well, so there is some ability to add interactivity to the your code. They have C and C++ versions of the library.
It is a bit pricey, but I suppose you have to pay for high quality. http://www.greenleafsoft.com/
This is a Windows library though, so maybe it won't work for you. I found a free eBook for serial communications on POSIX systems here:
http://www.easysw.com/~mike/serial/serial.html
Now you need to add in terminal emulation for the interactive part. libvterm looks like it tries to provide emulation: http://sourceforge.net/projects/libvterm/
It looks like there is a terminal emulation widget for QT too, which might work better: http://qt-apps.org/content/show.php/QTermWidget?content=82832
Good luck...not many people deal with serial communications anymore.

how to make winxp ms-dos virtual machine work like win98 ms-dos especially graphics

Initially...
I started programming in C. that was was 10 years back(college). The IDE i used was Turbo C++ IDE.
All my c programs were 16bit.
Memory Model : Huge.
Graphics : 4bit (16 colors).
Graphics Driver: EGAVGA.BGI
Resolution: 640x480.
OS: MS-DOS 6.0 (under windows98 it is 7.0 - which always gave an accelerated execution of code)
Sample programs were [my computer like win3.1 still have some pending work], [paint brush - 16 colors], [graphics mouse pointer generator], 16 bit font generator... and so on..
(these i have not yet published anywhere).
It is huge(memory model) because i extensively used C Graphics Library of Borland Turbo C.
Here is my request...
I wanted to document my work. Just in leisure time. and to just rewind the old concepts
and to implement the same in win32 api.
I like the way i wrote the codes and i really enjoyed seeing the outout as expected but still wanting more for which i never gave up but it got outdated and i am with win32api.
The emulation of win98 16bit graphics was perfect. BUT in windows xp the virtual machine output was totally different and the graphics was shabby when i run my graphics programs(GUI).
Because of this i could not take a print screen of a module.
One alternative i have is to use a win98 machine... run my programs and then can do the print screen.
What i thought was there should be an option to emulate the real 16 bit environment in windows xp like in windows98. So i am here to get some suggestions. Thank you.
Have you tried DOSBox? It's something people use to emulate an old DOS environment for games. Try it out.
DOSBox comes with the emulated hardware most games and graphical applications from that era need (VESA VGA modes, Soundblaster/Adlib sound...)
Also, see the comparison of platform virtual machines on Wikipedia
For running MS-DOS applications you may use DOS-Box. It runs even on Windows Vista and 7.

Developing kernels and testing them in virtual machines

I like programming challenges, and writing a kernel seems a programming challenge.
Unfortunately, kernels are particularly hard to test because they are basically the core of operating systems and so they can't be easily ran on top of an operating system.
However, I know about applications called Virtual Machines that can emulate computer hardware.
What is the easiest/best way to develop and test kernels(C+Assembly) using Virtual Machines?
While BOCHS seems to be better at letting you know when something goes horribly wrong with your pet OS... it is very slooooow! I use VirtualPC for general purpose testing and BOCHS when things get murky.
Also, you will more than likely be booting the OS every 2 minutes, so it helps to have some sort of automated way to build a boot image & fire off the Virtual PC.
I built a GRUB boot floppy image with all the necessary stuff to get it to boot the Kernel.Bin from the root. I use a batch file to copy this file to the virtual project directory, use FAT Image Generator to copy my kernel to the image. Then just launch the VirtualPC project. Vola!
Excerpt from my batch file:
COPY Images\Base.vfd Images\Boot.vfd /Y
fat_imgen.exe modify Images\Boot.vfd -f Source\Bin\KERNEL.BIN
COPY Images\Boot.vfd Emulators\VirtualPC\ /Y
START Emulators\VirtualPC\MyOS.vmc
One last suggestion: Set the VirtualPC process priority to low - trust me on this one!
I'd be happy to exchange some code!
Tools: DGJPP, NASM, GRUB.
Code: osdev.org, osdever.net
You might be interested in looking at HelenOS. Its a from scratch microkernel that has been ported to many architectures (boots just fine on bare metal) developed using simulators such as Simics and QEMU.
We use a static grub that is copied to the final ISO during the build process. Some things just have to be that way until the OS becomes self hosting. I highly recommend NOT implementing your own userspace C library unless you really do want to do everything from scratch .. you'll become self hosting much sooner :)
Though Simics is non-free, I highly recommend it (and its built in debugging/profiling tools) while making your kernel. Once you have some kind of kernel console and logger in place, QEMU does a very nice job.
It's straightforward. Set up a virtual machine, write your kernel, copy it to the virtual machine, boot the virtual machine.
You'll need to be more specific if you want more specific advice.
Probably just setting up a machine (x86, I guess), and then investigate exactly how it behaves during boot. There should be one or more files in the host machine's file system that act as the virtual machine's file system, and then you'd need to put some boot sector information there that causes your in-development kernel to boot.
That would of course mean that the build system on the host has a way to write the kernel to the virtual machine's file system, which might vary in difficulty.
Picking one at random, bochs seems to support editing the boot media from the outside using standard tools like dd etc.
The first question that you need to ask yourself is what hardware architecture are you targeting? I'll assume for the sake of this discussion that you are targeting the IA_32 architecture, which would probably be a wise choice as there is plenty of readily-available documentation on that processor.
If you're truly serious about this undertaking, then you will definitely want to run your debug/code/build/deploy cycle against an emulator or VM. Someone mentioned BOCHS, which is very popular. If emulation speed is your thing, there is also an emulator called Qemu that is faster than BOCHS.
I'd suggest that your development environment run under Linux or Windows, which again would probably be a wise choice due to the available documentation for those dev environments.
Make is your friend. Use it to automate the build/execute process. I'd advise you to pick your toolsets/compilers up front, and spend some time learning them well. It will save you in the long run.

Serial Port Communications

I am trying to create a GUI for a c code written in LINUX.
This code basically connects two systems, opens the serial port, writes data from one system to the other via the port.how do I go about this?
The development tools present with me are Qt designer version 3.3.5 and K Develop, which one should I use.and how to go about it?
In Linux, every hardware device is mapped to the file-system using standard file-system permissions.
If you're just using a simple serial port protocol under Linux, you can treat any serial port device as a file. Meaning, they can be opened, read, written and handled just using standard files.
The 'filename' for a serial port is typically /dev/ttyS0 or /dev/ttyUSB0 depending on the type of serial port. It is often symlinked to /dev/modem on regular distributions.
I think you may be looking in the wrong place. You should probably search the web for a tutorial on C++ programming, or get a book on it (there are plenty out there). Once you're comfortable with C++ (it'll take a while if you're not already), you can start to read about writing KDE applications. There are probably some introductory things to read on the KDE website, and don't forget that Google is your friend throughout the process ;-)
By the way, Qt Designer is just a program for doing GUI layouts, while KDevelop is a full featured IDE that combines Qt Designer, a text editor, and a bunch of other stuff. You can use KDevelop for writing anything from very simple "Hello World" C++ programs up to, well, something as complex as KDevelop itself.
If you've actually got to write the serial port part (I'm not clear on this from your question), the other system calls you'll need to know about are 'ioctl' and 'termios', to set various serial port parameters.
Seems your using QT. You should try QextSerialPort which is a serial port class for QT.
The doc.trolltech.com site has a huge amount of documentation. You should go definitely take a look.
I would use the latest available Qt library for your distro, since it is a new developpment.
Regarding the serial port C code, I would keep it and call it from your C++ code. Beware of time consuming operations that can ruin the interactive feeling of your app.

Resources