Back in the early 1990's, I used a library of routines in C called TCXL. I just wonder what ever happened to the guys who made that. I was about 25 years old the time, and learned C from a manual I printed out on my dot matrix printer. I think was using Turbo C, and I guess I downloaded TCXL from some bulletin board, or maybe Compuserve?
That library had cool routines to create "windows" for pop-ups and to create regions on the screen, as well has many other cool things that I can't fully recall. All this was in DOS of course.
http://cd.textfiles.com/swheaven1/UTILITY/
Mike Smedley, CXL's original author:
http://www.mikesmedley.com/
Related
I learned to program with Pascal in high school, and more recently I decided to get out of the sandbox and try to figure out how my computer actually works. So I installed ubuntu on my iMac (i686) and started learning C, which seemed like a good way to get "under the hood."
One of the basic things I'm trying to figure out is where the kernel ends and the standard libraries begin. A book told me that the linux system calls (which I understand to be the interface between the kernel and the libraries) could be found in the header file unistd.h, so this seemed like a good place to start. But when I tried to find the header on my system (using locate unistd.h), I got this result:
/usr/include/unistd.h
/usr/include/asm-generic/unistd.h
/usr/include/i386-linux-gnu/asm/unistd.h
/usr/include/i386-linux-gnu/bits/unistd.h
/usr/include/i386-linux-gnu/sys/unistd.h
/usr/include/linux/unistd.h
/usr/lib/syslinux/com32/include/unistd.h
/usr/src/linux-headers-3.5.0-27/arch/alpha/include/asm/unistd.h
/usr/src/linux-headers-3.5.0-27/arch/arm/include/asm/unistd.h
/usr/src/linux-headers-3.5.0-27/arch/avr32/include/asm/unistd.h
/usr/src/linux-headers-3.5.0-27/arch/blackfin/include/asm/unistd.h
/usr/src/linux-headers-3.5.0-27/arch/c6x/include/asm/unistd.h
/usr/src/linux-headers-3.5.0-27/arch/cris/include/arch-v10/arch/unistd.h
/usr/src/linux-headers-3.5.0-27/arch/cris/include/arch-v32/arch/unistd.h
/usr/src/linux-headers-3.5.0-27/arch/cris/include/asm/unistd.h
/usr/src/linux-headers-3.5.0-27/arch/frv/include/asm/unistd.h
/usr/src/linux-headers-3.5.0-27/arch/h8300/include/asm/unistd.h
/usr/src/linux-headers-3.5.0-27/arch/hexagon/include/asm/unistd.h
/usr/src/linux-headers-3.5.0-27/arch/ia64/include/asm/unistd.h
/usr/src/linux-headers-3.5.0-27/arch/m32r/include/asm/unistd.h
/usr/src/linux-headers-3.5.0-27/arch/m68k/include/asm/unistd.h
/usr/src/linux-headers-3.5.0-27/arch/microblaze/include/asm/unistd.h
/usr/src/linux-headers-3.5.0-27/arch/mips/include/asm/unistd.h
/usr/src/linux-headers-3.5.0-27/arch/mn10300/include/asm/unistd.h
/usr/src/linux-headers-3.5.0-27/arch/openrisc/include/asm/unistd.h
/usr/src/linux-headers-3.5.0-27/arch/parisc/include/asm/unistd.h
/usr/src/linux-headers-3.5.0-27/arch/powerpc/include/asm/unistd.h
/usr/src/linux-headers-3.5.0-27/arch/s390/include/asm/unistd.h
/usr/src/linux-headers-3.5.0-27/arch/score/include/asm/unistd.h
/usr/src/linux-headers-3.5.0-27/arch/sh/include/asm/unistd.h
/usr/src/linux-headers-3.5.0-27/arch/sparc/include/asm/unistd.h
/usr/src/linux-headers-3.5.0-27/arch/tile/include/asm/unistd.h
/usr/src/linux-headers-3.5.0-27/arch/unicore32/include/asm/unistd.h
/usr/src/linux-headers-3.5.0-27/arch/x86/include/asm/ia32_unistd.h
/usr/src/linux-headers-3.5.0-27/arch/x86/include/asm/unistd.h
/usr/src/linux-headers-3.5.0-27/arch/xtensa/include/asm/unistd.h
/usr/src/linux-headers-3.5.0-27/include/asm-generic/unistd.h
/usr/src/linux-headers-3.5.0-27/include/linux/unistd.h
/usr/src/linux-headers-3.5.0-27-generic/include/linux/unistd.h
Why the heck are there so many versions of this file--and other header files--in my system? Some of them seem to be for other CPUs (like sparc), so why did ubuntu bother to install them on my computer? And how does the all of this fit with what Eric Raymond calls the SPOT rule: "every piece of knowledge must have a single, unambiguous, authoritative representation within a system." (The Art of Unix Programming, p. 91.)
Thanks in advance for any help. I'm happy to read big books if necessary.
I think these header files are directly from linux-3.5.0-27 source code. Ubuntu developers didn't know what kind of target they are dealing with. Maybe Intel x86/powerPC/ or even a mobile hand set(ARM), so they just copy all the head files and make a simple link.
I'm doing a project where I need to create some kind of GUI for the user as well as control some servo motors.
I'm thinking of using ActionScript for the GUI and C for to control the hardware. Is this even possible? How do I make ActionScipt talk to C and vice-versa?
Obviously the C part will be driving the motors and will send the data to the ActionScript GUI
to be displayed to the user.
Is the above possible? If yes, could someone kindly provide me some pointers?
Thank you very much!
Edit: How do I pass a variable (e.g. x = 5) from ActionScript to be printed in C? Or is this not possible?
"You could go via ASP to a DLL as TG suggested or you could probably call an ANSI C (command line) app and pass in variables (at least on a Windows PC)... that owuld be done using FSCommands. see this tutorial
http://www.actionscripts.org/tutoria...es/index.shtml"
Originally replied by
Jesse Stratford
ActionScript.org Cofounder
This is taken from here
I don`t know the specifics of programming servo motors but basically, if you want some C to AS3 interaction you could do one of the following:
Compile your C/C++ code using flascc.
Wrap your C code in a native extension (if you are targeting AIR).
As sberry suggested - use Sockets.
I am learning c programming in Linux. There are a lot of linux functions I need to look at. Is there a website that gives me the details of the Linux functions?
Are you referring to system calls in Linux? There are lots of sources. The man pages are your good friends in this regard. Try also http://linux.die.net/man/2/syscalls. I am sure there are lots of others.
The standard reference by far is "Advanced programming in the UNIX environment" by Richard Stevens. Unfortunately this book is quite old, so there is a revised edition by Eric Raymond, which covers new stuff in Linux. This -- more than anything else -- is the de facto standard for learning "old world" systems programming in Linux. (And most other *ixes, there are of course differences, but you won't notice them until you're much more advanced, and by that point you'll be familiar with the man pages and know where to look.)
You can look at the LSB (Linux Standard Base) website:
http://www.linuxfoundation.org/collaborate/workgroups/lsb
Here are is the last Linux Standard Base Core Specification:
http://refspecs.linuxfoundation.org/lsb.shtml
IMHO http://linux.die.net/man/ is the easiest to get to start with.
It has useful sections introductions, so you can get your bearings
Most usefully are the one line synopsis pages, e.g. http://linux.die.net/man/3/
This shows the scale of what you are asking, and also lets you search for a key word describing each function within your browser, which can be very handy.
As has been pointed out, it is not the most up-to-date, but IMHO it is easier for a beginner to use than the alternative I've seen (not that there can't be something better, just google doesn't bother to show it).
Also worth trying apropos or man 3 -K or aman -k`
I find the glibc manual very good. It is organized by topic and contains concise background material and examples. It'll allow you to get the big picture and serves as a reference. Manpages are a quicker way to access function descriptions but there are only useful if you already know what you are looking for.
I have developed a graphic program on a desktop system. But when I tried to run it on the hp compaq laptop it's not getting executed. I developed it using Turbo C. Then i tried writing a simple graphic program in Turbo C on the laptop, but the problem I am getting is in 'initgraph' statement it is unable to detect the driver.
Can you please tell me what might be the problem?
Turbo-C, much like my first girlfriend, will always have a special place in my heart.
But its time to let her go. She's not the same girl you remember, and just cannot keep up with modern times. She may have been hip and cool at the time, but she can't handle modern trends at all. Even 32-bit memory is a real challenge for her. You're a better man now, and deserve a real woman. Go find yourself a good Visual Studio, or a nice GCC environment.
I'm not saying you have to forget Turbo-C. I know she was your first and will always be magical, but put her pictures in a shoebox, and don't take them out more than once a year. Its time to move on, buddy.
It sounds like it can't detect what kind of graphics card you have. Try setting the graphdriver parameter to either VGA or IBM8514.
In Turbo c goto options->Linker->Liabraries-> add Graphics Library.
It might help
I'm assuming that all the other prerequisites like linkers are satisfied.
Now, as we know the BGI folder is usually in the following path(i.e. if you've followed the default installation):
C:\TurboC++\disk\TurboC3\BGI
As you can see the BGI folder is inside "TurboC3" and not TC.
So the code you need to put in your program is as follows,
initgraph(&gd, &gm, "C:\\TurboC3\\BGI");
I hope this helps :) Happy graphics programming :D
you need to initialize the graphics function first.
below is the code to initialize.
int gd=DETECT,gm;
initgraph(&gd,&gm,"c:\\tc\\bgi");
this will initialize the graphics.
The Steps to make your TC able to run graphics program are as follows:
copy CGA.BGI and EGAVGA.BGI files from TC\BGI folder and paste them in TC\BIN directory.
Open TC by clicking on TC\BIN\TC.EXE.
Click on Options -> Linker -> Libraries .
Select the Graphics Library option and Press OK.
Now you can compile your graphics program with Zero Compilation Errors.
Thanks!
I have a requirement for porting some existing C code to a IEC 61131-3 compliant PLC.
I have some options of splitting the code into discrete function blocks and weaving those blocks into a standard solution (Ladder, FB, Structured Text etc). But this would require carving up the C code in order to build each function block.
When looking at the IEC spec I realsied that the IEC Instruction List form could be a target language for a compiler. The wikepedia article lists two development tools:
CoDeSys
Beremiz
But these seem to be targeted compiling IEC languages to C, not C to IEC.
Another possible solution is to push the C code through a C to Pascal translator and use that as a starting point for a Structured Text solution.
If not any of these I will go down the route of splitting the code up into function blocks.
Edit
As prompted by mlieson's reply I should have mentioned that the C code is an existing real-time control system. So the programs algorithms should already suit a PLC environment.
Maybe this answer comes too late but it is possible to call C code from CoDeSys thanks to an external library.
You can find documentation on the CoDeSys forum at http://forum-en.3s-software.com/viewtopic.php?t=620
That would give you to use your C code into the PLC with minor modifcations. You'll just have to define the functions or function blocks interfaces.
My guess is that a C to Pascal translator will not get you near enough for being worth the trouble. Structured text looks a lot like Pascal, but there are differences that you will need to fix everywhere.
Not a bug issue, but don't forget that PLCs runtime enviroment is a bit different. A C applications starts at main() and ends when main() returns. A PLC calls it main() over and over again, 100:s of times per second and it never ends.
Usally lengthy calculations and I/O needs to be coded in diffent fashion than a C appliation would use.
Unless your C source is many many thousands lines of code - Rewrite it.
It is impossible. To be short: the IL language is a 4GL (i.e. limited to
the domain, as well as other IEC 61131-3 languages -- ST, FBD, LD, SFC).
The C language is a 3GL.
To understand the problem, try to answer the question, which way to
express in IL manipulations with a pointer? for example, to express call a
function by a pointer. What about interrupts? Low level access to the
peripherial devices?
(really, there are more problems)
BTW, there is the Reflex language, aka "C with processes". Reflex is a 4GL for the
control domain with C-like syntax. But the known translators produce
C-code and Python-code.
If the amount of code to convert is a few thousand lines, recoding by hand is probably your best bet.
If you have lots of code to convert, then an automated tool might be very effective.
Using the DMS Software Reengineering Toolkit we've built translators to map mechanical motion diagrams into RLL (PLC) code. DMS also has full C parser/analyzers/front ends. The pieces are there to build a C to RLL code.
This isn't an easy task. It likely takes 6-12 man-months to configure DMS to something resembling what you want. If that's less than what it takes to do by hand, then its the right way to do it.
There are a few IEC development environments and target hardware that can use C blocks... I would also take a look at the reasons why it HAS to be an IEC-61131 complaint target. I have written extensively on compliance and why it doesn't mean squat.
SOFTplc corp can help I'm sure with user defined loadable modules... and they can be in C..
Schneider also supports C function blocks...
Labview too!! not sure why IEC is important that's all!! the compiler if existed would create bad code for sure:)
Your best bet is to split your C code into smaller parts which can be recoded as PLC functional blocks and use C to PASCAL convertor for each block which you will rewrite in structured text. Prepare to do a lot of manual work since automated conversion will probably disappoint you.
Also take a look at this page: http://www.control.com/thread/1026228786
Every time I've done this, I just parsed and converted it by hand from C directly to ST. I only ran into a few functions that required complete rewrites, although there was very little that dealt with pointers, which is something that ST generally chokes on, unfortunately.
Using the existing C code as blocks that are called by the PLC program would have the added advantage that the C blocks could run at the same periodicity that they did before, and their function is likely already well documented and tested. This would minimize any effect on changes from the existing control system. This is an architecture for controls with software PLCs that I have seen used before.