From: Jan W. <we...@ef...> - 2008-08-29 20:50:58
|
Daniel, >Anyway, I think simulator should simulate only, and GUI should provide >easy_to_use functionality. They can and should be different tools, >working together of course. > I disagree. IMHO, they _can_ be different tools, but they _don't_need_ to be different tools. I, as a _user_, don't care HOW is a tool done, built, written; I want to _use_ it. I don't mind it is separate, provided the UI is there, ready to use without any special hassle. It does not need to be graphical - your "beta DOS" version was not either, as were none of the half dozen or so '51 DOS-based simulators circulating around - they were all text-mode. Contrary - I don't like the windowey style of most of the "modern" simulators, they burn up too much of the precious pixels for the useless window borders and stuff. >It was fun to develop ucsim, and I planed to write a GUI for it, but >now I have an other "two month old son project" to deal with which is >more funny... > Oooooh, gratulalok! Jan |
From: Richard E. <ed...@id...> - 2008-08-29 16:13:33
|
Jan, see below, please. regards, Richard Erlacher ----- Original Message ----- From: "Jan Waclawek" <we...@ef...> To: <sdc...@li...> Sent: Friday, August 29, 2008 2:52 AM Subject: [Sdcc-user] Quickstart document,was: Virus in SDCC-2.8.0-setup.exe - MD5 etc tutorial > Richard, > >> [...] and I'd be happy to help generate a more > user-manual-for-Windows-Users sort of document >> that assumes nothing about one's knowledge of LINUX or *NIX, >> and targets those who would prefer to utilize this tool set from Windows > rather than having to move to LINUX, >> if only I could find out how to use the tool set in the first place. > > OK. Ask. > I have a 'C' program, which I hope will work, on paper in my hand ... There's a computer running Windows on the desk in front of me. I want to compile this program for introduction by whatever means might be available into a system based on one of the target MCU's supported by SDCC. What's my first step? ... then what ... ? > > For those developers here who knows the ins and outs of SDCC very well is > hard to imagine what should be the content of a "quickstart" document. > "Quickstart" is not how I'd describe a User Guide. Maybe you're onto something, Jan ... maybe a "QuickStart" is what's called for as a first step. > > And, please note, that regardless of whether there is an up-front > specification for a software or not, the user documentation may be very > different from this specification or any other document a developer is > likely to write, if it has to be of any use for a real user; plus that > there > may be several "levels" of users (beginner, advanced user, > administrator...) > Yes, I know ... that ship has sailed ... Since the program already exists, there's no way to "un-create" it and go back to what, perhaps, should have been done before it was coded. > >> I'd even be interested in helping with the generation of a simulator for > the various MCU's, starting of course, >> with the 805x's as those are the ones of current interest, > > There _is_ a '51 simulator which comes with SDCC, but it is rather > cumbersome to use and has a command-line interface only (read: command > line, > no text-screen). It is not intended to be used by human, rather, in an > automated simulation setup (primarily for the regression testing after a > new > build of SDCC). > I've looked for it, but haven't found one that operates as one might expect. Perhaps its doc's need clarification. Are there any? I recall reading something about a simulator and a link to a website that seemingly no longer works. I always found simulators quite straightforward. The difficult part is getting a complete characterization of whatever's to be simulated. Approximations don't make a simulator work well. In this context, the "trick" is to predefine the environment within which the simulator has to function. Handwaves don't help, either. Some things have to be clearly defined, at least in terms of inputs, outputs, and processes. > > Jan Waclawek > |
From: Jan W. <we...@ef...> - 2008-08-29 20:40:19
|
Richard, >I have a 'C' program, which I hope will work, on paper in my hand ... Yeah, the BBC (bare-brain-computer). ;-) >There's a computer running Windows on the desk in front of me. I want to >compile this program for introduction by whatever means might be available >into a system based on one of the target MCU's supported by SDCC. What's my >first step? ... then what ... ? I assume some prerequisites which might not hold true. For example, that you have some experience with programming under Windows (I don't mean writing programs for Windows but using Windows-based PC as a host for cross-development). Please say "stop" if I miss a step. 0. Download and install SDCC. 1. Create some suitable directory (aka folder) for your program. For example, C:\SW\Blinkey. Sidenotes: 1a. Micro$oft has some ideas about where you should place files created by you, like "C:\Documents and Settings\Username\My Documents\something". If you like that scheme, proceed accordingly. I personally don't like it. 1b. For start, I assume your program will be something simple (blinkey.c), single-file, includes only the standard headers and local headers, uses no other than standard libraries etc. All SDCC-generated files will then go into this directory, together with your sources. Things might get more complicated later. 2. Type in your blinkey.c program, using some suitable editor. 3. Run a command window (a.k.a. DOS window, DOS box). Click Start->Run, in W9x type "command", in W2k/WXP type "cmd". Go to your directory (e.g. using "cd C:\SW\Blinkey"). 4. Type 'sdcc blinkey.c' (if the target is 8051, which I assume is your case). 4a. If it says 'Bad command or file name', something went wrong during installation and the path to the SDCC executables did not get into the PATH environment variable. In this case, you need to type '"C:\Program Files\SDCC\bin\sdcc" blinkey.c' 4b. Enjoy SDCC's opinion on your program :-) 5. Providing SDCC was completely happy, the output you are looking for is in the same directory (C:\SW\Blinkey), named 'blinkey.ihx', and it is a standard intelhex (note the suffix is different than the standard .hex). Please comment. Jan |
From: Richard E. <ed...@id...> - 2008-08-29 21:12:03
|
see below, please. regards, Richard Erlacher ----- Original Message ----- From: "Jan Waclawek" <we...@ef...> To: <sdc...@li...> Sent: Friday, August 29, 2008 2:49 PM Subject: Re: [Sdcc-user] Quickstart document,was: Virus in SDCC-2.8.0-setup.exe - MD5 etc tutorial > Richard, > >>I have a 'C' program, which I hope will work, on paper in my hand ... > > Yeah, the BBC (bare-brain-computer). ;-) > Yes, we're all supposed to use that ... but how does it help with SDCC? > >>There's a computer running Windows on the desk in front of me. I want to >>compile this program for introduction by whatever means might be available >>into a system based on one of the target MCU's supported by SDCC. What's >>my >>first step? ... then what ... ? > > I assume some prerequisites which might not hold true. For example, that > you have some experience with programming under Windows (I don't mean > writing programs for Windows but using Windows-based PC as a host for > cross-development). Please say "stop" if I miss a step. > > 0. Download and install SDCC. > Seems reasonable, and the doc's include considerable info about that. > > 1. Create some suitable directory (aka folder) for your program. For > example, C:\SW\Blinkey. > Sidenotes: > 1a. Micro$oft has some ideas about where you should place files created by > you, like "C:\Documents and Settings\Username\My Documents\something". If > you like that scheme, proceed accordingly. I personally don't like it. > Nor do I. I usually create a "work" directory in the same environment as the software tools I'm using. That way related filenames don't get mixed up from one context to another. There might well be a project in which I'm evaluating several MCU options, so I might have a "workHC0x, and a work5x, and a workZ80 (not likely) directory, all under SDCC. > > 1b. For start, I assume your program will be something simple (blinkey.c), > single-file, includes only the standard headers and local headers, uses no > other than standard libraries etc. All SDCC-generated files will then go > into this directory, together with your sources. Things might get more > complicated later. > > 2. Type in your blinkey.c program, using some suitable editor. > Yes, and let's assume, for now, it's ultimately saved in a project-relevant "working directory" under SDCC. > > 3. Run a command window (a.k.a. DOS window, DOS box). Click Start->Run, in > W9x type "command", in W2k/WXP type "cmd". Go to your directory (e.g. > using "cd C:\SW\Blinkey"). > Maybe a few words would be helpful about what makes one editor more "suitable" than another, or what might make it less-suitable. A few suggestions as to "convenient" features might be helpful in this context, too. > > 4. Type 'sdcc blinkey.c' (if the target is 8051, which I assume is your > case). > 4a. If it says 'Bad command or file name', something went wrong during > installation and the path to the SDCC executables did not get into the > PATH environment variable. In this case, you need to type '"C:\Program > Files\SDCC\bin\sdcc" blinkey.c' > > 4b. Enjoy SDCC's opinion on your program :-) > Fortunately, there is already some helpful doc on what those compiler-generated "complaints" might mean. > > 5. Providing SDCC was completely happy, the output you are looking for is > in the same directory (C:\SW\Blinkey), named 'blinkey.ihx', and it is a > standard intelhex (note the suffix is different than the standard .hex). > > Please comment. > OK ... The path, etc, is a pretty standard thing under Windows, so it's a matter of preference. The target MCU might change ... but not for now. The output includes an ASM file, right? What else should I look for? > |
From: Mark S. <mar...@ch...> - 2008-08-29 21:50:40
|
Richard Erlacher wrote: > >> 5. Providing SDCC was completely happy, the output you are looking for is >> in the same directory (C:\SW\Blinkey), named 'blinkey.ihx', and it is a >> standard intelhex (note the suffix is different than the standard .hex). >> >> Please comment. >> >> > OK ... The path, etc, is a pretty standard thing under Windows, so it's a > matter of preference. The target MCU might change ... but not for now. The > output includes an ASM file, right? What else should I look for? > Off the top of my head, for a multi-file project you would do: sdcc blinky.c -c --debug sdcc blinky_part2.c -c --debug sdcc main_lives_here.c -c --debug # Note that main_lives_here contains the main() function, and should be first in the list. All interrupt service routines need to be defined in this file as well. I just include the appropriate headers to do this. sdcc main_lives_here.rel blinky.rel blink_part2.rel -o amazing-blinker --debug Normally I let make do all the work. If you are on Windows, and plan to use make, I suggest downloading and using MinGW and MSYS. The use the msys verison of make. That way you'll be using GNU make with tons of helpful extensions. As a bonus, your makefiles will run under a bash prompt, which is far more powerful than a dos prompt. For each source file (eg blinky.c), you will have: blinky.adb A debugger file that I haven't ever needed to mess with. blinky.asm The assembler output version of the file- pre-linkage version. blinky.lst The assembler output and machine code all in one file--pre-linkage version. blinky.rel The object file. This is a text file. blinky.sym A big list of symbols allocated in the file and where they go. After linkage you get also: blinky.rst Basically the .lst file with addresses fixed up after linkage. If your output target is amazing-blinker, after linking you get these files as well: amazing-blinker An OMF51 file. from --debug switch amazing-blinker.cdb Another debugger file. amazing-blinker.ihx Intel hex file. amazing-blinker.map A listing of what is assigned where. Very useful to learn to read. amazing-blinker.mem A memory allocation overview. Easy to read, and important too. IIRC there's a something the User's Guide about the different files generated. Don't remember where. I hope this helps. --Mark Swayne |
From: Richard E. <ed...@id...> - 2008-08-29 22:41:04
|
All of this is going to help, once it's assimilated. Moreover, I suspect I'm not the only one who's been wondering about this stuff. I'm a seasoned man. All of my life, there have been things I didn't know. That's not likely to change any time soon. The things may change, though. regards, Richard Erlacher ----- Original Message ----- From: "Mark Swayne" <mar...@ch...> To: <sdc...@li...> Sent: Friday, August 29, 2008 3:50 PM Subject: Re: [Sdcc-user] Quickstart document, was: Virus in SDCC-2.8.0-setup.exe - MD5 etc tutorial > Richard Erlacher wrote: >> >>> 5. Providing SDCC was completely happy, the output you are looking for >>> is >>> in the same directory (C:\SW\Blinkey), named 'blinkey.ihx', and it is a >>> standard intelhex (note the suffix is different than the standard .hex). >>> >>> Please comment. >>> >>> >> OK ... The path, etc, is a pretty standard thing under Windows, so it's a >> matter of preference. The target MCU might change ... but not for now. >> The >> output includes an ASM file, right? What else should I look for? >> > Off the top of my head, for a multi-file project you would do: > > sdcc blinky.c -c --debug > sdcc blinky_part2.c -c --debug > sdcc main_lives_here.c -c --debug > > # Note that main_lives_here contains the main() function, and should be > first in the list. All interrupt service routines need to be defined in > this file as well. I just include the appropriate headers to do this. > > sdcc main_lives_here.rel blinky.rel blink_part2.rel -o amazing-blinker > --debug > > Normally I let make do all the work. If you are on Windows, and plan to > use make, I suggest downloading and using MinGW and MSYS. The use the > msys verison of make. That way you'll be using GNU make with tons of > helpful extensions. As a bonus, your makefiles will run under a bash > prompt, which is far more powerful than a dos prompt. > > For each source file (eg blinky.c), you will have: > > blinky.adb A debugger file that I haven't ever needed to mess with. > blinky.asm The assembler output version of the file- pre-linkage > version. > blinky.lst The assembler output and machine code all in one > file--pre-linkage version. > blinky.rel The object file. This is a text file. > blinky.sym A big list of symbols allocated in the file and where they > go. > > After linkage you get also: > blinky.rst Basically the .lst file with addresses fixed up after > linkage. > > If your output target is amazing-blinker, after linking you get these > files as well: > > amazing-blinker An OMF51 file. from --debug switch > amazing-blinker.cdb Another debugger file. > amazing-blinker.ihx Intel hex file. > amazing-blinker.map A listing of what is assigned where. Very useful to > learn to read. > amazing-blinker.mem A memory allocation overview. Easy to read, and > important too. > > IIRC there's a something the User's Guide about the different files > generated. Don't remember where. > > I hope this helps. > > --Mark Swayne > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the > world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user |
From: Jan W. <we...@ef...> - 2008-08-29 23:08:42
|
Richard, >Maybe a few words would be helpful about what makes one editor more >"suitable" than another, or what might make it less-suitable. A few >suggestions as to "convenient" features might be helpful in this context, >too. Well, this is not really SDCC-specific... I don't feel competent to answer this question either - as a notorious C-hater I don't use advanced function-header-collecting and similar functions of the "fat" IDEs. All I need is basic code indenting, decent syntax highlighting, ability to run external programs (i.e. upon F9 to run the compiler or a "script" (batch) of compiler-downloader) and good searching/bookmarking (unfortunately the latter is rare); and a fair price (recently, this has shrinked to the ultimate $0, as there are quite a lot of enthusiasts around writing this sort of stuff). Some examples are Notepad++, Programmer's Notepad, PSPad, and my favourite (although a bit strange and unfortunately mostly abandoned) is Crimson Editor (it's the only one I know which supports 2 language syntax highlight - e.g. C and asm - in a single file). An interesting option may be setedit, which is multi-platform and deliberately Borland-like; but also slightly different than the others, being text-based. >The >output includes an ASM file, right? What else should I look for? It's maybe not quite straighforwardly asm (and the assembler's syntax is non-intel-ish), but it's there, if you use the --debug switch. Under W9x, for me it was a challenge to find the --use-stdout switch as the "dosbox" there has no "scrollback" feature, and without this switch it's impossible to redirect the output into a file. This is not an issue under WXP as you can scroll back the "dosbox". But, basically, that's it. Try. Enjoy. Jan |
From: Richard E. <ed...@id...> - 2008-08-30 00:31:30
|
----- Original Message ----- From: "Jan Waclawek" <we...@ef...> To: <sdc...@li...> Sent: Friday, August 29, 2008 5:18 PM Subject: Re: [Sdcc-user] Quickstart document,was: Virus in SDCC-2.8.0-setup.exe - MD5 etc tutorial > Richard, > >>Maybe a few words would be helpful about what makes one editor more >>"suitable" than another, or what might make it less-suitable. A few >>suggestions as to "convenient" features might be helpful in this context, >>too. > > Well, this is not really SDCC-specific... > > I don't feel competent to answer this question either - as a notorious > C-hater I don't use advanced function-header-collecting and similar > functions of the "fat" IDEs. All I need is basic code indenting, decent > syntax highlighting, ability to run external programs (i.e. upon F9 to run > the compiler or a "script" (batch) of compiler-downloader) and good > searching/bookmarking (unfortunately the latter is rare); and a fair price > (recently, this has shrinked to the ultimate $0, as there are quite a lot > of enthusiasts around writing this sort of stuff). Some examples are > Notepad++, Programmer's Notepad, PSPad, and my favourite (although a bit > strange and unfortunately mostly abandoned) is Crimson Editor (it's the > only one I know which supports 2 language syntax highlight - e.g. C and > asm - in a single file). An interesting option may be setedit, which is > multi-platform and deliberately Borland-like; but also slightly different > than the others, being text-based. > Since MCU's don't use big programs, I'm not a HLL-lover either. What I want from an IDE is an easy way to move back and forth between editor, assembler, compiler, debugger, etc. All I want from the compiler is to be able to use the same high-level code for doing data manipulations whether the MCU is a PIC or an 'HC08, or whatever, including, of course, the 805x core. > >>The output includes an ASM file, right? >>What else should I look for? > > It's maybe not quite straighforwardly asm (and the assembler's syntax is > non-intel-ish), but it's there, if you use the --debug switch. > > Under W9x, for me it was a challenge to find the --use-stdout switch as > the "dosbox" there has no "scrollback" feature, and without this switch > it's impossible to redirect the output into a file. This is not an issue > under WXP as you can scroll back the "dosbox". > Couldn't you simply redirect the output from one program to a file, then use that file as input to the next program? I do this sort of thing all the time using batch files with the old DOS-based OrCAD products. I know that PALASM does it, too. > > But, basically, that's it. Try. Enjoy. > > Jan > > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the > world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user |
From: Jan W. <we...@ef...> - 2008-08-30 09:13:57
|
> > Under W9x, for me it was a challenge to find the --use-stdout switch as > > the "dosbox" there has no "scrollback" feature, and without this switch > > it's impossible to redirect the output into a file. This is not an issue > > under WXP as you can scroll back the "dosbox". > > > Couldn't you simply redirect the output from one program to a file, then use > that file as input to the next program? I do this sort of thing all the > time using batch files [...] Yes you can, as long as you use the mentioned --use-stdout switch (otherwise most/all of the output goes to stderr, which is trickier to redirect under WXP and next to impossible to redirect in W9x. Bothe stdout and stderr go to console if not redirected.). Jan |
From: Richard E. <ed...@id...> - 2008-08-30 16:19:19
|
Jan, Gee ... I'm not aware of a -stdout switch under DOS. Maybe I should get out the manual. I just go C:>FOO >BAR.SUF, whereupon the next executable takes BAR.SUF as an input file. If there's just a single executable, the output to the screen is redirected to a file using the same mechanism, and that allows me to peruse it at my leisure. regards, Richard Erlacher ----- Original Message ----- From: "Jan Waclawek" <we...@ef...> To: <sdc...@li...> Sent: Saturday, August 30, 2008 3:14 AM Subject: Re: [Sdcc-user] Quickstart document, was: Virus in SDCC-2.8.0-setup.exe - MD5 etc tutorial >> > Under W9x, for me it was a challenge to find the --use-stdout switch as >> > the "dosbox" there has no "scrollback" feature, and without this switch >> > it's impossible to redirect the output into a file. This is not an >> > issue >> > under WXP as you can scroll back the "dosbox". >> > >> Couldn't you simply redirect the output from one program to a file, then >> use >> that file as input to the next program? I do this sort of thing all the >> time using batch files [...] > > Yes you can, as long as you use the mentioned --use-stdout switch > (otherwise most/all of the output goes to stderr, which is trickier to > redirect under WXP and next to impossible to redirect in W9x. Bothe stdout > and stderr go to console if not redirected.). > > Jan > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the > world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user |
From: Jan W. <we...@ef...> - 2008-08-30 16:30:27
|
Richard, it's a switch you use when you invoke SDCC with intention to redirect its output to a file. If you type: C:>sdcc blinkey.c > blinkey.out all the output of sdcc will go to the console window, and blinkey.out will have size of 0 bytes. If you type C:>sdcc --use-stdout blinkey.c > blinkey.out the console remains empty and all the output of sdcc will go to blinkey.out. Please, give it a try. Jan ----- Original Message --------------- >Jan, > >Gee ... I'm not aware of a -stdout switch under DOS. Maybe I should get out >the manual. > >I just go C:>FOO >BAR.SUF, whereupon the next executable takes BAR.SUF as an >input file. If there's just a single executable, the output to the screen >is redirected to a file using the same mechanism, and that allows me to >peruse it at my leisure. |
From: Richard E. <ed...@id...> - 2008-08-30 16:37:14
|
Well, that's exactly the mechanism I mentioned ... I'm not surprised it has a name ... but -stdout ... ??? That sounds like *nix. regards, Richard Erlacher ----- Original Message ----- From: "Jan Waclawek" <we...@ef...> To: <sdc...@li...> Sent: Saturday, August 30, 2008 10:39 AM Subject: Re: [Sdcc-user] Quickstart document,was: Virus in SDCC-2.8.0-setup.exe - MD5 etc tutorial > Richard, > > it's a switch you use when you invoke SDCC with intention to redirect its > output to a file. > > If you type: > C:>sdcc blinkey.c > blinkey.out > all the output of sdcc will go to the console window, and blinkey.out will > have size of 0 bytes. > If you type > C:>sdcc --use-stdout blinkey.c > blinkey.out > the console remains empty and all the output of sdcc will go to > blinkey.out. > > Please, give it a try. > > Jan > > > > ----- Original Message --------------- >>Jan, >> >>Gee ... I'm not aware of a -stdout switch under DOS. Maybe I should get >>out >>the manual. >> >>I just go C:>FOO >BAR.SUF, whereupon the next executable takes BAR.SUF as >>an >>input file. If there's just a single executable, the output to the screen >>is redirected to a file using the same mechanism, and that allows me to >>peruse it at my leisure. > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the > world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user |
From: Richard E. <ed...@id...> - 2008-08-30 16:41:51
|
Well, that's exactly the mechanism I mentioned ... I'm not surprised it has a name ... but -stdout ... ??? That sounds like *nix. regards, Richard Erlacher ----- Original Message ----- From: "Jan Waclawek" <we...@ef...> To: <sdc...@li...> Sent: Saturday, August 30, 2008 10:39 AM Subject: Re: [Sdcc-user] Quickstart document,was: Virus in SDCC-2.8.0-setup.exe - MD5 etc tutorial > Richard, > > it's a switch you use when you invoke SDCC with intention to redirect its > output to a file. > > If you type: > C:>sdcc blinkey.c > blinkey.out > all the output of sdcc will go to the console window, and blinkey.out will > have size of 0 bytes. > If you type > C:>sdcc --use-stdout blinkey.c > blinkey.out > the console remains empty and all the output of sdcc will go to > blinkey.out. > > Please, give it a try. > > Jan > > > > ----- Original Message --------------- >>Jan, >> >>Gee ... I'm not aware of a -stdout switch under DOS. Maybe I should get >>out >>the manual. >> >>I just go C:>FOO >BAR.SUF, whereupon the next executable takes BAR.SUF as >>an >>input file. If there's just a single executable, the output to the screen >>is redirected to a file using the same mechanism, and that allows me to >>peruse it at my leisure. > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the > world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user |
From: Richard G. <ri...@re...> - 2008-08-30 18:36:59
|
stdout (stdin and stderr) are an integral part of stdio.h, so it's as much a C-ism as a Unix-ism. I don't know how the Windows environment would cope with this, but under Unix file-descriptor 0 is stdin, descriptor 1 is stdout, and 2 is stderr, and these are automatically opened before the execution of main() if one includes stdio.h. I should stress that I'm talking about PC-type processors now, rather than the SDCC device set - the underlying assumptions about the operating system don't exist for small devices, so stdio.h and its accompanying libraries would probably not be meaningful for a PIC or a Z80 or whatever. In Unix, suppose one were running a program called 'blinkey' - a nice example people seem to use... shell$ blinkey | more This would pipe the stdout from 'blinkey' through to stdin of 'more'. Anything blinkey wrote to stderr would appear on the screen, but if this was too much to cope with one could do this... shell$ blinkey 2> errors.txt The above means to redirect file descriptor 2 (stderr) to the errors.txt file. Similarly, the standard input can be pulled from a file, like this... shell$ blinkey < blinkey_input.txt And then one can get smart and combine these to do all kinds of crazy things! I *believe* Windows/DOS can do the standard input and output bits in similar fashion, but I have never had occasion to try it - I'm a dyed-in-the-wool Unix (Linux) nerd, you might gather. I don't know how Windows copes with descriptor 2 (stderr) if at all. On Saturday 30 August 2008 17:41:38 Richard Erlacher wrote: > Well, that's exactly the mechanism I mentioned ... I'm not surprised it has > a name ... but -stdout ... ??? That sounds like *nix. > > regards, > > Richard Erlacher > > ----- Original Message ----- <snip> -- Richard. PGP Key-id: 0x5AB3D350 A reactionary is a man whose political opinions always manage to keep up with yesterday. |
From: Richard E. <ed...@id...> - 2008-08-30 22:44:07
|
Yes, but 'C' is a Unix-ism, isn't it? ----- Original Message ----- From: "Richard Gray" <ri...@re...> To: <sdc...@li...> Sent: Saturday, August 30, 2008 12:36 PM Subject: Re: [Sdcc-user] Quickstart document > stdout (stdin and stderr) are an integral part of stdio.h, so it's as much > a > C-ism as a Unix-ism. > |
From: Art C. <aar...@bi...> - 2008-08-31 02:21:14
|
OK, it's a lot of years ago and the memory grows dim but IIRC C was used to rewrite the operating system that became Unix around '72 - '73 and had been developed for that reason. I _think_ the OS was already called UNIX (or maybe still UNICS) but it was certainly an assembler coded kernel with a couple of small apps like roff running on a PDP-11 until re-written in C with a small kernel of PDP assembler code at the hardware interface level. So C was really a PDP-ism since it was first written in assembler bootstraps fashion to run on that machine. Richard Erlacher wrote: > Yes, but 'C' is a Unix-ism, isn't it? > ----- Original Message ----- > From: "Richard Gray" <ri...@re...> > To: <sdc...@li...> > Sent: Saturday, August 30, 2008 12:36 PM > Subject: Re: [Sdcc-user] Quickstart document > > >> stdout (stdin and stderr) are an integral part of stdio.h, so it's as much >> a >> C-ism as a Unix-ism. >> > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user > |
From: Kevin B. <ke...@hy...> - 2008-08-31 21:48:49
|
Hi everybody, I've been following this thread for a while and thought I'd just chime in with some little tidbits I found while looking for a how-to guide. There appears to be a plug-in developed specifically for using SDCC with the Eclipse IDE, I can't vouch for its quality as I've never used it but here's its sourceforge URL: http://sourceforge.net/projects/eclipse-sdcc/ I also found this how-to install guide on the University of Colorado's website, again, I can't vouch for its correctness. http://ece-www.colorado.edu/~mcclurel/Installing_SDCC-Eclipse_2-28-2007_hand outs6.pdf I've never used these components and the SDCC plug-in hasn't been updated in a few years but maybe this plug in is something to look into to make getting started a little easier? Eg. 1. Install SDCC 2. Install Eclipse 3. Install CDT 4. Install the SDCC plug-in Just a few thoughts to keep the discussion running. Regards Kevin -----Original Message----- From: sdc...@li... [mailto:sdc...@li...] On Behalf Of Richard Gray Sent: Sunday, 31 August 2008 6:37 a.m. To: sdc...@li... Subject: Re: [Sdcc-user] Quickstart document stdout (stdin and stderr) are an integral part of stdio.h, so it's as much a C-ism as a Unix-ism. I don't know how the Windows environment would cope with this, but under Unix file-descriptor 0 is stdin, descriptor 1 is stdout, and 2 is stderr, and these are automatically opened before the execution of main() if one includes stdio.h. I should stress that I'm talking about PC-type processors now, rather than the SDCC device set - the underlying assumptions about the operating system don't exist for small devices, so stdio.h and its accompanying libraries would probably not be meaningful for a PIC or a Z80 or whatever. In Unix, suppose one were running a program called 'blinkey' - a nice example people seem to use... shell$ blinkey | more This would pipe the stdout from 'blinkey' through to stdin of 'more'. Anything blinkey wrote to stderr would appear on the screen, but if this was too much to cope with one could do this... shell$ blinkey 2> errors.txt The above means to redirect file descriptor 2 (stderr) to the errors.txt file. Similarly, the standard input can be pulled from a file, like this... shell$ blinkey < blinkey_input.txt And then one can get smart and combine these to do all kinds of crazy things! I *believe* Windows/DOS can do the standard input and output bits in similar fashion, but I have never had occasion to try it - I'm a dyed-in-the-wool Unix (Linux) nerd, you might gather. I don't know how Windows copes with descriptor 2 (stderr) if at all. On Saturday 30 August 2008 17:41:38 Richard Erlacher wrote: > Well, that's exactly the mechanism I mentioned ... I'm not surprised it has > a name ... but -stdout ... ??? That sounds like *nix. > > regards, > > Richard Erlacher > > ----- Original Message ----- <snip> -- Richard. PGP Key-id: 0x5AB3D350 A reactionary is a man whose political opinions always manage to keep up with yesterday. ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Sdcc-user mailing list Sdc...@li... https://lists.sourceforge.net/lists/listinfo/sdcc-user |
From: Maarten B. <sou...@ds...> - 2008-08-31 13:37:49
|
Richard(s), DOS and Windows are no different in this regard. stdin, stdout and stderr have been a part of it since at least DOS version 2.1 (I've never used an earlier one). And all this piping works in them too. Maarten > stdout (stdin and stderr) are an integral part of stdio.h, so it's as much a > C-ism as a Unix-ism. > > I don't know how the Windows environment would cope with this, but under Unix > file-descriptor 0 is stdin, descriptor 1 is stdout, and 2 is stderr, and > these are automatically opened before the execution of main() if one includes > stdio.h. I should stress that I'm talking about PC-type processors now, > rather than the SDCC device set - the underlying assumptions about the > operating system don't exist for small devices, so stdio.h and its > accompanying libraries would probably not be meaningful for a PIC or a Z80 or > whatever. > > In Unix, suppose one were running a program called 'blinkey' - a nice example > people seem to use... > > shell$ blinkey | more > > This would pipe the stdout from 'blinkey' through to stdin of 'more'. Anything > blinkey wrote to stderr would appear on the screen, but if this was too much > to cope with one could do this... > > shell$ blinkey 2> errors.txt > > The above means to redirect file descriptor 2 (stderr) to the errors.txt file. > > Similarly, the standard input can be pulled from a file, like this... > > shell$ blinkey < blinkey_input.txt > > And then one can get smart and combine these to do all kinds of crazy things! > > I *believe* Windows/DOS can do the standard input and output bits in similar > fashion, but I have never had occasion to try it - I'm a dyed-in-the-wool > Unix (Linux) nerd, you might gather. I don't know how Windows copes with > descriptor 2 (stderr) if at all. > > On Saturday 30 August 2008 17:41:38 Richard Erlacher wrote: > > Well, that's exactly the mechanism I mentioned ... I'm not surprised it has > > a name ... but -stdout ... ??? That sounds like *nix. > > > > regards, > > > > Richard Erlacher > > > > ----- Original Message ----- > <snip> > > -- > Richard. > PGP Key-id: 0x5AB3D350 > > A reactionary is a man whose political opinions always manage to keep > up with yesterday. |
From: Richard E. <ed...@id...> - 2008-08-31 14:07:21
|
Maarten, There's no question that this concept has existed since very early versions of DOS (1981), but I, personally, have never heard it referred to as such outside the 'C'/*nix context before. In fact, the notion of std-whichever existed under CP/M, too, as we had 'C' compilers there for several years before the PC became dominant in the industry. There was, under CP/M, even a feeble attempt (in '79 or so) at emulating a UNIX shell for CP/M. People, then, didn't discuss this in the same terms when programming in ASM, FORTRAN, BASIC, COBOL, ALGOL, PL/1, PL/M, PASCAL, LISP, or any of the other languages popular at the time. Since I came up through the microcomputer industry rather than minicomputers, where one was more likely to encounter 'C' and its friends, the syntax seems "unix-ish" to me. regards, Richard Erlacher ----- Original Message ----- From: "Maarten Brock" <sou...@ds...> To: <sdc...@li...> Sent: Sunday, August 31, 2008 7:37 AM Subject: Re: [Sdcc-user] Quickstart document > Richard(s), > > DOS and Windows are no different in this regard. stdin, > stdout and stderr have been a part of it since at least > DOS version 2.1 (I've never used an earlier one). And > all this piping works in them too. > > Maarten > >> stdout (stdin and stderr) are an integral part of stdio.h, so it's as >> much a >> C-ism as a Unix-ism. >> >> I don't know how the Windows environment would cope with this, but under >> Unix >> file-descriptor 0 is stdin, descriptor 1 is stdout, and 2 is stderr, and >> these are automatically opened before the execution of main() if one >> includes >> stdio.h. I should stress that I'm talking about PC-type processors now, >> rather than the SDCC device set - the underlying assumptions about the >> operating system don't exist for small devices, so stdio.h and its >> accompanying libraries would probably not be meaningful for a PIC or a >> Z80 or >> whatever. >> >> In Unix, suppose one were running a program called 'blinkey' - a nice >> example >> people seem to use... >> >> shell$ blinkey | more >> >> This would pipe the stdout from 'blinkey' through to stdin of 'more'. >> Anything >> blinkey wrote to stderr would appear on the screen, but if this was too >> much >> to cope with one could do this... >> >> shell$ blinkey 2> errors.txt >> >> The above means to redirect file descriptor 2 (stderr) to the errors.txt >> file. >> >> Similarly, the standard input can be pulled from a file, like this... >> >> shell$ blinkey < blinkey_input.txt >> >> And then one can get smart and combine these to do all kinds of crazy >> things! >> >> I *believe* Windows/DOS can do the standard input and output bits in >> similar >> fashion, but I have never had occasion to try it - I'm a dyed-in-the-wool >> Unix (Linux) nerd, you might gather. I don't know how Windows copes with >> descriptor 2 (stderr) if at all. >> >> On Saturday 30 August 2008 17:41:38 Richard Erlacher wrote: >> > Well, that's exactly the mechanism I mentioned ... I'm not surprised it >> > has >> > a name ... but -stdout ... ??? That sounds like *nix. >> > >> > regards, >> > >> > Richard Erlacher >> > >> > ----- Original Message ----- >> <snip> >> >> -- >> Richard. >> PGP Key-id: 0x5AB3D350 >> >> A reactionary is a man whose political opinions always manage to keep >> up with yesterday. > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the > world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user |
From: Jan W. <we...@ef...> - 2008-08-29 20:59:03
|
Richard, I answer the simulator-specific part separately. >I've looked for it, but haven't found one that operates as one might expect. >Perhaps its doc's need clarification. Are there any? I recall reading >something about a simulator and a link to a website that seemingly no longer >works. > C:\Program Files\SDCC\doc\usim\index.html is the starting point of the documentation, but you don't need to download anything. Simply run "C:\Program Files\SDCC\bin\s51.exe" and type "help". That might give you a rough feeling of what it is all about. >I always found simulators quite straightforward. The difficult part is >getting a complete characterization of whatever's to be simulated. >Approximations don't make a simulator work well. In this context, the >"trick" is to predefine the environment within which the simulator has to >function. Handwaves don't help, either. Some things have to be clearly >defined, at least in terms of inputs, outputs, and processes. I don't quite understand what do you mean by this. I think, a step-by-step quickstart example on a trivial "blinkey" program would help here, too; but I am not competent enough to make one. Jan Waclawek |
From: Richard E. <ed...@id...> - 2008-08-29 21:36:59
|
see below, please. regards, Richard Erlacher ----- Original Message ----- From: "Jan Waclawek" <we...@ef...> To: <sdc...@li...> Sent: Friday, August 29, 2008 3:08 PM Subject: Re: [Sdcc-user] Quickstart document,was: Virus in SDCC-2.8.0-setup.exe - MD5 etc tutorial > Richard, > > I answer the simulator-specific part separately. > >>I've looked for it, but haven't found one that operates as one might >>expect. >>Perhaps its doc's need clarification. Are there any? I recall reading >>something about a simulator and a link to a website that seemingly no >>longer >>works. >> > > C:\Program Files\SDCC\doc\usim\index.html is the starting point of the > documentation, but you don't need to download anything. > Simply run "C:\Program Files\SDCC\bin\s51.exe" and type "help". That might > give you a rough feeling of what it is all about. > >>I always found simulators quite straightforward. The difficult part is >>getting a complete characterization of whatever's to be simulated. >>Approximations don't make a simulator work well. In this context, the >>"trick" is to predefine the environment within which the simulator has to >>function. Handwaves don't help, either. Some things have to be clearly >>defined, at least in terms of inputs, outputs, and processes. > > I don't quite understand what do you mean by this. > There are times of the year when I have routinely have some time on my hands. A couple of years ago, I requested information from one of the 805x-clone makers about the specifics of their internal timing so I could implement a relatively precise, (timing-valid) simulator that allowed me to use scheduled event-relative stimuli to the MCU. though I've repeated my request, I'm still waiting. Things like the built-in timers and UART(s) that operate synchronously with the 12-ticks-per-system-clock model are easy to understand, as Intel, in this case, documented them, hence, are easy to simulate. In the case of one-clockers, particularly those that have programmable options as to how they treat relationship between system clock and that external timebase input, behave differently. If I want to obtain precise details about how the MCU interprets an event nn nanoseconds after the rising edge on X1, and when it sets this flag or that, I need detailed information from the manufacturer. Suppose I want to make the UART in MODE 0 function as a shift register, and not stop generating TxCk when a byte is assembled or disassembled. How can I do that if I don't know when it decides whether to generate a clock? How do I know when I have to read SBUF? How do I know when to clear the RI flag so it doesn't miss a clock? How do I determine whether I should even attempt do those things? So far, it's all a mystery, and any attempt at simulation would be a guess. As for the environment, the simulator can operate from a driver clock "event" or it can operate from "real" time. A schedule, in some implementations, implies "real" time, though the schedule actually is developed by a tool that interprets the schedule source and synthesizes the "real" time on which the schedule operates and from which it derives the required stimuli. This allows you to specify an oscillator as a loop, and a recurring event, similarly, as a periodic function. It also allows the insertion of random intervals in the event schedule, as you might want to do in order to "monte-carlo" your simulation in order to examine the effect of input timing variations. > > I think, a step-by-step quickstart example on a trivial "blinkey" program > would help here, too; but I am not competent enough to make one. > Right now, perhaps I'm not either. I'm not understanding on what you mean. > > Jan Waclawek > |
From: Jan W. <we...@ef...> - 2008-08-29 22:20:57
|
Richard, Although I am not competent to decide on this either, I don't think Daniel's simulator goes as far as peripherals timing (in ns). And, IMHO, there is not too much "buying drive" to make such a sophisticated simulator either. Some of the '51 simulations are done in the clock domain, most are done in the instruction cycle domain. Although I see the potential value of such a simulator; at the end of the day, when it comes to the nanosecond details, you need the real stuff anyway, don't you? Jan |
From: Richard E. <ed...@id...> - 2008-08-30 00:24:59
|
Jan, The level of effort required to develop simulator timing as opposed to cycle-by-cycle timing is not particularly great. It's all done by the computer, after all. It does slow down the simulation, of course, but since modern PC's execute code at 100x the MCU's rate, in may not make much difference whether that's 100x or 10x. The scheduler is another task, but also not difficult, and its output file is an input to the simulator. The problem with most cycle-by-cycle simulators is that they completely miss the mark when one is using a device like the Maxim/Dallas DS89C4x0's, in which you know, by now, that I have considerable interest, since firmware can control their execution rate and the length of an external bus cycle. It's deterministic, but beyond the ability of most simulators. The timing, whether in nanoseconds or in clock-ticks, is a simple calculation based on the simulator's timebase, which is virtual. However, if you want to determine how well a set of firmware synchronizes with an externally timed process, you have to have the ability to determine how the MCU responds to asynchronous stimuli. This affects interrupt response timing, and it affects built-in peripheral behavior. The underlying problem, of course, is that firmware has traditionally been generated by folks who saw programming as an art form, rather than an engineering practice, and seldom applied sound engineering principles to it. Therefore, they were happy with the cycle-by-cycle simulations, and simply guessed at whether the timing really worked. Sometimes it did, and sometimes it didn't. If it didn't, well ... back to the drawing board ... The amazing thing, so far, has been that they've gotten by with it. When engineers design the firmware, they use precise timing models and simulators based on them. Back in the early '80's we used precise timing models of 68000, 68010, 68012, and 68020, among others, together with precise models of memory, etc. Normally, one didn't have to do that. Today, even the PCB's are modeled. regards, Richard Erlacher ----- Original Message ----- From: "Jan Waclawek" <we...@ef...> To: <sdc...@li...> Sent: Friday, August 29, 2008 4:30 PM Subject: [Sdcc-user] ucsim, was: Quickstart document,was: Virus in SDCC-2.8.0-setup.exe - MD5 etc tutorial > Richard, > > Although I am not competent to decide on this either, I don't think > Daniel's simulator goes as far as peripherals timing (in ns). > > And, IMHO, there is not too much "buying drive" to make such a > sophisticated simulator either. Some of the '51 simulations are done in > the clock domain, most are done in the instruction cycle domain. > > Although I see the potential value of such a simulator; at the end of the > day, when it comes to the nanosecond details, you need the real stuff > anyway, don't you? > > Jan > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the > world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user |
From: Richard G. <ri...@re...> - 2008-08-31 12:40:40
|
On Saturday 30 August 2008 03:51:02 you wrote: <snip> > > Someone mentioned Code::Blocks earlier. I tried to use it a couple of > years ago, but when I joined the forum and began asking questions about > using it with SDCC, I was ridiculed, marginalized and laughed out of the > process by some of the major players in the program. They have > apparently deleted those older posts to the forum, so I can't prove it. > <snip> Proof is quite unecessary, belief meets reality right here. History has a habit of repeating itself. -- Richard. PGP Key-id: 0x5AB3D350 |
From: Bobby G. <bg...@fh...> - 2008-08-31 14:23:01
|
Richard Gray wrote: > On Saturday 30 August 2008 03:51:02 you wrote: > <snip> > >> Someone mentioned Code::Blocks earlier. I tried to use it a couple of >> years ago, but when I joined the forum and began asking questions about >> using it with SDCC, I was ridiculed, marginalized and laughed out of the >> process by some of the major players in the program. They have >> apparently deleted those older posts to the forum, so I can't prove it. >> >> > <snip> > > Proof is quite unecessary, belief meets reality right here. History has a > habit of repeating itself. > Failure to learn from our mistakes is a very bad habit, but addiction can be safely avoided by dealing with the facts. Diplomacy and compromise seek to avoid or conceal the facts. "Facts that are not frankly faced have a habit of stabbing us in the back." - Sir Harold Bowden Recognizing the recurring nature of history is the first step, and unfortunately the last for those who actively seek to perpetuate the process. Now if we wish to talk about Code::Blocks and SDCC, I downloaded and installed v8.02 yesterday. The first thing I looked for was the compiler settings, and discovered that all options are located on the 'Settings' menu, which was once the subject of frolicking laughter as I recall. Compiler and Debbuger settings is the third item. When I tried to use it before there were at least three dialogs for the compiler alone on different menus and they were all similar but different. I selected SDCC from the drop down list and set it as the default compiler. My major concern is the handling of projects which had serious problems before. I haven't tried to set up a project yet. There is now a CodeBlocks Manuel on the help menu. It looks good, but the proof invariably comes when you start looking for something very specific. A lot of help systems deal well with the obvious and intuitive, but finding specific detail is like working through a maze. I have never figured out why key word searches from the Index tab are sometimes limited to the index and excludes the text. Happily in this case a dialog pops up offering a range of topics to choose from. BTW, I found the evidence... http://forums.codeblocks.org/index.php/topic,1864.0.html Bobby |