From: Richard G. <ri...@re...> - 2008-08-27 17:49:59
|
md5sums, or sha1sum or whatever are a special type of checksum. In the past, a simple addition of all the byte values in any given file would give a simple total, and typically is/was used to distinguish EPROM contents/versions from one another. However, a simple checksum is not very robust, one bit dropped here and another added there can provide an identical checksum while two files are actually very different. So, cleverer checksum methods have since been devised where a single bit change in file in question can produce a radically different result, and thus it is much harder to produce two different files with the same MD5 checksum, for example, and maybe even impossible in many cases. If, by some miracle, one produced two files with an identical MD5 sum, it's almost beyond imagining that the SHA1 sums (a different algorithm) would be the same too. The upshot is that a file provided with a checksum is hard to tamper with undetected, unless the checksum is also adjusted, of course. MD5 etc are known as hash algorithms. md5sum etc are standard utilities on most unix/linux systems. I cannot speak for Windoze, but I kinda doubt MS can be bothered, but there are probably 3rd party versions available - if you can trust those! Examples (which might not mean much if you don't understand a unix command line)... bash# echo "Richard Erlacher" | md5sum 5d7a3bc8d9bbe8cbfdf2f53fe42f50f9 - The above 5d7a... number is the MD5 sum hash of "Richard Erlacher". Now make a tiny change... bash# echo "Richard erlacher" | md5sum f3c78f69a11aa4dd432ac3fe35eb976b - Notice that the tiniest change to the string makes a massive difference in the MD5 sum. The upshot of this is that an MD5 sum of a file is a great way of verifying if it has downloaded correctly - if the published MD5 doesn't match what you have downloaded, then there's a problem somewhere, because the files are different. A simple checksum might very well not detect defects or indeed deliberate alterations. I hope that helps! Let me know if I can explain further. On Wednesday 27 August 2008 18:07:37 Richard Erlacher wrote: > ----- Original Message ----- > From: "Frieder Ferlemann" <fri...@we...> > To: <sdc...@li...> > Sent: Thursday, August 21, 2008 10:18 AM > Subject: Re: [Sdcc-user] Virus in SDCC-2.8.0-setup.exe > > > Hi > > > > Richard Erlacher schrieb: > >> I don't know how this happened, but my CA virus scanner turned up a > >> virus (Win32FakeAV.CX) in SDCC-2.8.0-setup.exe. Forewarned is > >> forearmed. > > > > Checksums of sdcc-2.8.0-setup.exe as downloaded today from > > http://sourceforge.net/project/showfiles.php?group_id=599&package_id=2892 > >1&release_id=587999 are: > > > > md5sum sdcc-2.8.0-setup.exe > > bff1f75352a4897ee142a26a728c5e92 sdcc-2.8.0-setup.exe > > What's a md5sum? > > > sha1sum sdcc-2.8.0-setup.exe > > f804e0d149b96219ca39084024b9f0e8c3fa0e41 sdcc-2.8.0-setup.exe > > > > sha256sum sdcc-2.8.0-setup.exe > > fbb6ec3339d0b95759dcf57883fb912a2779dd198076760b9d52efc1b9e3ba62 > > sdcc-2.8.0-setup.exe > > What's a sha256sum? > > > Does that match the file you downloaded? > > How would I check it? Am I supposed to have those utilities? > > regards, > > Richard Erlacher > <snip> -- Richard. PGP Key-id: 0x5AB3D350 An authority is a person who can tell you more about something than you really care to know. |
From: Richard E. <ed...@id...> - 2008-08-28 04:25:45
|
Well, I'm just trying to answer Frieder's question(s). Until the doc on LINUX gets to where there are no more omissions of crucial words, ... like NOT ... I won't have time for it either. I've been trying to figure out how to get anything useful out of SDCC, but the instructions for Windows (Yes, I'm one of those ...)tell you how to build it, but say nothing about how to use it. Since I'm not a big HLL fan for code bodies smaller than, say 250K lines, I don't suffer as a result, but I would like to find a simulator that can actually simulate object code output from the assembler, that's bigger than 2 KB. I find that that JSIM program merely sits there and looks back at me, but otherwise does nothing, and the TSCONTROLS EMU8051 or whatever it's called can't be upgraded, since their website has disappeared. ... <sigh> ... I just reported that virus detection in the latest SDCC file set. My scanner seems to have found and removed it, but there are folks who may not be so lucky. I did understand that those programs are checksum/CRC verification tools. I'd just never seen 'em or heard of 'em before, nor do I know where they're to be found. regards, Richard Erlacher ----- Original Message ----- From: "Richard Gray" <ri...@re...> To: <sdc...@li...> Sent: Wednesday, August 27, 2008 11:49 AM Subject: Re: [Sdcc-user] Virus in SDCC-2.8.0-setup.exe - MD5 etc tutorial > md5sums, or sha1sum or whatever are a special type of checksum. In the > past, a > simple addition of all the byte values in any given file would give a > simple > total, and typically is/was used to distinguish EPROM contents/versions > from > one another. However, a simple checksum is not very robust, one bit > dropped > here and another added there can provide an identical checksum while two > files are actually very different. So, cleverer checksum methods have > since > been devised where a single bit change in file in question can produce a > radically different result, and thus it is much harder to produce two > different files with the same MD5 checksum, for example, and maybe even > impossible in many cases. If, by some miracle, one produced two files with > an > identical MD5 sum, it's almost beyond imagining that the SHA1 sums (a > different algorithm) would be the same too. The upshot is that a file > provided with a checksum is hard to tamper with undetected, unless the > checksum is also adjusted, of course. MD5 etc are known as hash > algorithms. > > md5sum etc are standard utilities on most unix/linux systems. I cannot > speak > for Windoze, but I kinda doubt MS can be bothered, but there are probably > 3rd > party versions available - if you can trust those! > > Examples (which might not mean much if you don't understand a unix command > line)... > > bash# echo "Richard Erlacher" | md5sum > 5d7a3bc8d9bbe8cbfdf2f53fe42f50f9 - > > The above 5d7a... number is the MD5 sum hash of "Richard Erlacher". > > Now make a tiny change... > > bash# echo "Richard erlacher" | md5sum > f3c78f69a11aa4dd432ac3fe35eb976b - > > Notice that the tiniest change to the string makes a massive difference in > the > MD5 sum. The upshot of this is that an MD5 sum of a file is a great way of > verifying if it has downloaded correctly - if the published MD5 doesn't > match > what you have downloaded, then there's a problem somewhere, because the > files > are different. A simple checksum might very well not detect defects or > indeed > deliberate alterations. > > I hope that helps! Let me know if I can explain further. > > On Wednesday 27 August 2008 18:07:37 Richard Erlacher wrote: >> ----- Original Message ----- >> From: "Frieder Ferlemann" <fri...@we...> >> To: <sdc...@li...> >> Sent: Thursday, August 21, 2008 10:18 AM >> Subject: Re: [Sdcc-user] Virus in SDCC-2.8.0-setup.exe >> >> > Hi >> > >> > Richard Erlacher schrieb: >> >> I don't know how this happened, but my CA virus scanner turned up a >> >> virus (Win32FakeAV.CX) in SDCC-2.8.0-setup.exe. Forewarned is >> >> forearmed. >> > >> > Checksums of sdcc-2.8.0-setup.exe as downloaded today from >> > http://sourceforge.net/project/showfiles.php?group_id=599&package_id=2892 >> >1&release_id=587999 are: >> > >> > md5sum sdcc-2.8.0-setup.exe >> > bff1f75352a4897ee142a26a728c5e92 sdcc-2.8.0-setup.exe >> >> What's a md5sum? >> >> > sha1sum sdcc-2.8.0-setup.exe >> > f804e0d149b96219ca39084024b9f0e8c3fa0e41 sdcc-2.8.0-setup.exe >> > >> > sha256sum sdcc-2.8.0-setup.exe >> > fbb6ec3339d0b95759dcf57883fb912a2779dd198076760b9d52efc1b9e3ba62 >> > sdcc-2.8.0-setup.exe >> >> What's a sha256sum? >> >> > Does that match the file you downloaded? >> >> How would I check it? Am I supposed to have those utilities? >> >> regards, >> >> Richard Erlacher >> > <snip> > > -- > Richard. > PGP Key-id: 0x5AB3D350 > > An authority is a person who can tell you more about something than you > really care to know. > > ------------------------------------------------------------------------- > 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: Frieder F. <fri...@we...> - 2008-08-28 09:24:53
|
Hi Richard, Richard Erlacher schrieb: > words, ... like NOT ... I won't have time for it either. I've been trying > to figure out how to get anything useful out of SDCC, but the instructions > for Windows (Yes, I'm one of those ...)tell you how to build it, but say > nothing about how to use it. I cannot follow you there. Don't f.e. sections: 2.7 Testing the SDCC Compiler 3.13 Inline Assembler Code 3.13.1 A Step by Step Introduction tell you (platform independently) how to use SDCC? Or are you looking for a C reference/textbook/tutorial and expect the SDCC manual to be one of these? > I just reported that virus detection in the latest SDCC file set. My > scanner seems to have found and removed it, but there are folks who may not > be so lucky. > > I did understand that those programs are checksum/CRC verification tools. > I'd just never seen 'em or heard of 'em before, nor do I know where they're > to be found. http://en.wikipedia.org/wiki/md5sum http://en.wikipedia.org/wiki/sha1sum Comparing just the md5sum (on a clean system) would be enough. Greetings, Frieder Richard Gray wrote: > md5sum etc are standard utilities on most unix/linux systems. I cannot speak > for Windoze, but I kinda doubt MS can be bothered, but there are probably > 3rd party versions available - if you can trust those! :) |
From: Richard E. <ed...@id...> - 2008-08-28 15:21:07
|
see below, please. regards, Richard Erlacher ----- Original Message ----- From: "Richard Gray" <ri...@re...> To: <sdc...@li...> Sent: Thursday, August 28, 2008 6:40 AM Subject: Re: [Sdcc-user] Virus in SDCC-2.8.0-setup.exe - MD5 etc tutorial > On Thursday 28 August 2008 12:52:37 Richard Erlacher wrote: >> see below, please. >> >> regards, >> >> Richard Erlacher > <snip> >> Not quite ... that is, not from the extremely basic level. For example >> ... >> Assume that I have code that runs in another environment and now I want >> to >> compile it into an executable for my MCU. I'm staring at a Windows >> Desktop >> ... now what? The <3.13.1 A Step by Step Introduction> refers to inline >> assembly language code. Maybe a few words about where to start would be >> a >> good thing. > > There is a PDF manual included in the distribution, and an HTML one too in > the > linux/unix distribution at least, but I wouldn't describe it as "step by > step", and is at best a nudge in the right direction. If you want a PDF > version I'll happily mail it to you if that would help? The manual does > describe how to create inline assembler, interrupt routines (including > NMI's), and other little gems. > That's true. There's a PDF version available, and Frieder referred to that. I have it, of course. It says little about how, under Windows, the directories are organized, though it does say, "the default directory for gcc-builds where include, library and documentation files are stored is now in /usr/local/share." Is that relevant? > > Much more can be learned from examining the supplied .h files (and example > files, in some cases) for the target architecture you're using. I've only > recently started using the Z80 (Z180 variant) target, and much of what > I've > learned is from experimentation. I started with the Z80 back when it was pup, in '76 or so. It wasn't my first CPU. Aside from a little fiddling with it under CP/M, I've never written any 'C' code for it. My work was all done in ASM. I don't use it any longer, however, as nobody's asked me to do that. I do use old Z80 hardware to stimulate systems under test, when it seems appropriate, though that's been a while, too. > I have found that except for the most > trivial programs, you will need to break your work down into separate > assembler sources and then assemble and link everything at the end. The > load > map file is absolutely invaluable and I would always urge anyone to > examine > it thoroughly, and even an examination of the emitted hex file wouldn't > hurt > either. > If it weren't for that admonition to "read the code" ... Everybody thinks their code is "self-documenting" though ... and it seldom is. 'C' programmers seem to pride themselves on how unreadable and impenetrable their coding style is, and while the originators of the language provided a mechanism for providing relevant and meaningful comments, it's used very little. The problem begins and ends with the fact that code should never precede a completed, approved, set in stone, set of documentation. It seldom does, which is why there are bugs ... er ... I mean ... undocumented features ... discovered in nearly any software set from time to time. Now, SDCC is a great concept if, for example, it's easy to integrate with an assembler, a linker, a simulator, a librarian, and all the other utilities that are helpful in developing code. I've taken a look at it at about annual intervals, and wish it were so. I just learned that the SiLabs environment (IDE) without which it's apparently a pain to use their MCU's, relies upon OMF files produced by SDCC tools, among others. That's why I'm taking another look. The small bits of code I usually prepare for the 805x-series (up to, say, 12k-15k lines of ASM) are generally monolithic, hence, don't require the linker, etc. Up to now, I've written code segments and de-loused them separately, since the things I do, though sometimes bigger than 8kB of object code, are seldom terribly complex. After that, I simply combine those portions of code as macros or as subroutines. > > As for C, Kernighan and Ritchie's ANSI C is probably regarded as the > defininitive reference. > > http://en.wikipedia.org/wiki/The_C_Programming_Language_(book) > Yes, I have a couple of versions of that, the printed versions, I mean. I used Turbo-C back when Borland was just starting up, and later in combination with Prolog. You can't escape K&R when learning 'C' even though it's no longer the standard. > -- > > ------------------------------------------------------------------------- |
From: Richard E. <ed...@id...> - 2008-08-28 11:52:46
|
see below, please. regards, Richard Erlacher ----- Original Message ----- From: "Frieder Ferlemann" <fri...@we...> To: <sdc...@li...> Sent: Thursday, August 28, 2008 3:24 AM Subject: Re: [Sdcc-user] Virus in SDCC-2.8.0-setup.exe - MD5 etc tutorial > Hi Richard, > > Richard Erlacher schrieb: >> words, ... like NOT ... I won't have time for it either. I've been >> trying >> to figure out how to get anything useful out of SDCC, but the >> instructions >> for Windows (Yes, I'm one of those ...)tell you how to build it, but say >> nothing about how to use it. > > I cannot follow you there. Don't f.e. sections: > 2.7 Testing the SDCC Compiler > 3.13 Inline Assembler Code > 3.13.1 A Step by Step Introduction > tell you (platform independently) how to use SDCC? > Not quite ... that is, not from the extremely basic level. For example ... Assume that I have code that runs in another environment and now I want to compile it into an executable for my MCU. I'm staring at a Windows Desktop ... now what? The <3.13.1 A Step by Step Introduction> refers to inline assembly language code. Maybe a few words about where to start would be a good thing. > > Or are you looking for a C reference/textbook/tutorial > and expect the SDCC manual to be one of these? > No ... those are widely available. I'd expect information on how to use THIS compiler/linker/assembler, etc. though. > >> I just reported that virus detection in the latest SDCC file set. My >> scanner seems to have found and removed it, but there are folks who may >> not >> be so lucky. >> >> I did understand that those programs are checksum/CRC verification tools. >> I'd just never seen 'em or heard of 'em before, nor do I know where >> they're >> to be found. > > http://en.wikipedia.org/wiki/md5sum > http://en.wikipedia.org/wiki/sha1sum > > Comparing just the md5sum (on a clean system) would be enough. > Well, that may, at least, lead to an answer to the question regarding the downloaded file set. A clean system is never a problem. I use removable (frame+tray) hard drives and always have at least one, for each system, that has never been present when attached to the internet or even the LAN. Sanitizing files acquired via the www is sometimes tricky, so they seldom see the "clean" drives. > > Greetings, > Frieder > Thanks for the comments, Frieder. I'm not complaining. I'm just lamenting that I've lost my way. Perhaps I'm looking for that trail of bread crumbs. Being oriented to ASM and macros rather than HLL's for small code body, I haven't made 'C' a priority for MCU development. However, as SiLabs, for example, has put its primary thrust into supporting the compilers (KEIL, SDCC) rather than ASM with its app-notes, etc, I'm taking another look. > > > Richard Gray wrote: > >> md5sum etc are standard utilities on most unix/linux systems. I cannot >> speak >> for Windoze, but I kinda doubt MS can be bothered, but there are probably >> 3rd party versions available - if you can trust those! > > :) > |
From: Richard G. <ri...@re...> - 2008-08-28 12:40:09
|
On Thursday 28 August 2008 12:52:37 Richard Erlacher wrote: > see below, please. > > regards, > > Richard Erlacher <snip> > Not quite ... that is, not from the extremely basic level. For example ... > Assume that I have code that runs in another environment and now I want to > compile it into an executable for my MCU. I'm staring at a Windows Desktop > ... now what? The <3.13.1 A Step by Step Introduction> refers to inline > assembly language code. Maybe a few words about where to start would be a > good thing. There is a PDF manual included in the distribution, and an HTML one too in the linux/unix distribution at least, but I wouldn't describe it as "step by step", and is at best a nudge in the right direction. If you want a PDF version I'll happily mail it to you if that would help? The manual does describe how to create inline assembler, interrupt routines (including NMI's), and other little gems. Much more can be learned from examining the supplied .h files (and example files, in some cases) for the target architecture you're using. I've only recently started using the Z80 (Z180 variant) target, and much of what I've learned is from experimentation. I have found that except for the most trivial programs, you will need to break your work down into separate assembler sources and then assemble and link everything at the end. The load map file is absolutely invaluable and I would always urge anyone to examine it thoroughly, and even an examination of the emitted hex file wouldn't hurt either. As for C, Kernighan and Ritchie's ANSI C is probably regarded as the defininitive reference. http://en.wikipedia.org/wiki/The_C_Programming_Language_(book) -- Richard. PGP Key-id: 0x5AB3D350 In 1914, the first crossword puzzle was printed in a newspaper. The creator received $4000 down ... and $3000 across. |
From: Juges, D. <Did...@cr...> - 2008-08-29 13:10:47
|
Richard, Since you mention Silabs, I assume you have tried the SDCC compiler from within the Silabs IDE. It is a very easy setup and seems to work well. I have done a simple project starting from scratch and all went just like it did with my old compiler (Keil-based Franklin). However, like you, I would be hard pressed to use SDCC outside the Silabs environment. Good thing I do not have the need at the moment :-) TI does have some useful app notes about SDCC, in order to facilitate its usage with their MSC1210 processor. They do not have an IDE, so you may find useful info for your case. You may want to look at those. I have found a fairly detailled app-note/procedure to recompile SDCC with floating point support under Windows/cygwin, even though I have just read it and not used it myself. It may be for an older version of SDCC, I do not have it on this computer at the moment. If you have a hard time finding it, let me know. Didier -----Original Message----- From: sdc...@li... [mailto:sdc...@li...] On Behalf Of Richard Erlacher Sent: Thursday, August 28, 2008 6:53 AM To: sdc...@li... Subject: Re: [Sdcc-user] Virus in SDCC-2.8.0-setup.exe - MD5 etc tutorial see below, please. regards, Richard Erlacher ----- Original Message ----- From: "Frieder Ferlemann" <fri...@we...> To: <sdc...@li...> Sent: Thursday, August 28, 2008 3:24 AM Subject: Re: [Sdcc-user] Virus in SDCC-2.8.0-setup.exe - MD5 etc tutorial > Hi Richard, > > Richard Erlacher schrieb: >> words, ... like NOT ... I won't have time for it either. I've been >> trying to figure out how to get anything useful out of SDCC, but the >> instructions for Windows (Yes, I'm one of those ...)tell you how to >> build it, but say nothing about how to use it. > > I cannot follow you there. Don't f.e. sections: > 2.7 Testing the SDCC Compiler > 3.13 Inline Assembler Code > 3.13.1 A Step by Step Introduction > tell you (platform independently) how to use SDCC? > Not quite ... that is, not from the extremely basic level. For example ... Assume that I have code that runs in another environment and now I want to compile it into an executable for my MCU. I'm staring at a Windows Desktop ... now what? The <3.13.1 A Step by Step Introduction> refers to inline assembly language code. Maybe a few words about where to start would be a good thing. > > Or are you looking for a C reference/textbook/tutorial and expect the > SDCC manual to be one of these? > No ... those are widely available. I'd expect information on how to use THIS compiler/linker/assembler, etc. though. > >> I just reported that virus detection in the latest SDCC file set. My >> scanner seems to have found and removed it, but there are folks who >> may not be so lucky. >> >> I did understand that those programs are checksum/CRC verification tools. >> I'd just never seen 'em or heard of 'em before, nor do I know where >> they're to be found. > > http://en.wikipedia.org/wiki/md5sum > http://en.wikipedia.org/wiki/sha1sum > > Comparing just the md5sum (on a clean system) would be enough. > Well, that may, at least, lead to an answer to the question regarding the downloaded file set. A clean system is never a problem. I use removable (frame+tray) hard drives and always have at least one, for each system, that has never been present when attached to the internet or even the LAN. Sanitizing files acquired via the www is sometimes tricky, so they seldom see the "clean" drives. > > Greetings, > Frieder > Thanks for the comments, Frieder. I'm not complaining. I'm just lamenting that I've lost my way. Perhaps I'm looking for that trail of bread crumbs. Being oriented to ASM and macros rather than HLL's for small code body, I haven't made 'C' a priority for MCU development. However, as SiLabs, for example, has put its primary thrust into supporting the compilers (KEIL, SDCC) rather than ASM with its app-notes, etc, I'm taking another look. > > > Richard Gray wrote: > >> md5sum etc are standard utilities on most unix/linux systems. I >> cannot speak for Windoze, but I kinda doubt MS can be bothered, but >> there are probably 3rd party versions available - if you can trust >> those! > > :) > ------------------------------------------------------------------------- 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-29 16:32:13
|
Didier , Well ... No ... I've not attempted to use the SiLabs IDE. I'm still looking for doc's on what it's supposed to do, etc. I'll "get around to it." I'm interested in a more generalized procedure not wedded to a given manufacturer's tools, at least for the moment. I understand your comment. I believe, as well, that one would be hard-pressed to use the SiLabs IDE without SDCC or KEIL. Up to now, I've had the impression that the SDCC tools work from the command line in a Windows environment. There's an IDE called MIDE, which presents an editor, 2-kB-range-limited simulator (by TS Controls), and, perhaps, (I've not attempted to do anything further) a means for hooking into the SDCC compiler, which would have some potential, but for the limitation on the simulator. The TS Controls website is apparently gone ... and so is the opportunity to upgrade to a "full" simulator. That's moot anyway, as what's necessary is a simulator for the specifics of the MCU that's the target. An IDE is a separate issue. more below ... regards, Richard Erlacher ----- Original Message ----- From: "Juges, Didier" <Did...@cr...> To: <sdc...@li...> Sent: Friday, August 29, 2008 7:10 AM Subject: Re: [Sdcc-user] Virus in SDCC-2.8.0-setup.exe - MD5 etc tutorial > Richard, > > Since you mention Silabs, I assume you have tried the SDCC compiler from > within the Silabs IDE. Not a safe assumption. I try to read the doc's in order to learn what's supposed to happen before I "try" things. So far I've found about one paragraph that describes this, fewer than 100 words. >It is a very easy setup and seems to work well. I have done a simple >project starting from scratch and all went just like it did with my old >compiler (Keil-based Franklin). However, like you, I would be hard pressed >to use SDCC outside the Silabs environment. Good thing I do not have the >need at the moment :-) > > TI does have some useful app notes about SDCC, in order to facilitate its > usage with their MSC1210 processor. They do not have an IDE, so you may > find useful info for your case. > You may want to look at those. I have found a fairly detailed > app-note/procedure to recompile SDCC with floating point support under > > Windows/cygwin, even though I have just read it and not used it myself. It > may be for an older version of SDCC, I do not have it on this > computer > at the moment. If you have a hard time finding it, let me know. > > Didier > Yes, Windows users expect to see some sort of integrated development environment. Not being a Windows programmer, or interested in becoming one, I have no idea what would be required for such a thing. I doubt it would be difficult to generate in a simple, command-line-based approach. If one used DOS-based tools, the code size could be held down, and if one wrote the IDE from a DOS-based position, it would probably be straightforward, at least in contrast with what would be required for Windows. > > -----Original Message----- > From: sdc...@li... > [mailto:sdc...@li...] On Behalf Of Richard > Erlacher > Sent: Thursday, August 28, 2008 6:53 AM > To: sdc...@li... > Subject: Re: [Sdcc-user] Virus in SDCC-2.8.0-setup.exe - MD5 etc tutorial > > see below, please. > > regards, > > Richard Erlacher > ----- Original Message ----- > From: "Frieder Ferlemann" <fri...@we...> > To: <sdc...@li...> > Sent: Thursday, August 28, 2008 3:24 AM > Subject: Re: [Sdcc-user] Virus in SDCC-2.8.0-setup.exe - MD5 etc tutorial > > >> Hi Richard, >> >> Richard Erlacher schrieb: >>> words, ... like NOT ... I won't have time for it either. I've been >>> trying to figure out how to get anything useful out of SDCC, but the >>> instructions for Windows (Yes, I'm one of those ...)tell you how to >>> build it, but say nothing about how to use it. >> >> I cannot follow you there. Don't f.e. sections: >> 2.7 Testing the SDCC Compiler >> 3.13 Inline Assembler Code >> 3.13.1 A Step by Step Introduction >> tell you (platform independently) how to use SDCC? >> > Not quite ... that is, not from the extremely basic level. For example > ... > Assume that I have code that runs in another environment and now I want to > compile it into an executable for my MCU. I'm staring at a Windows > Desktop ... now what? The <3.13.1 A Step by Step Introduction> refers to > inline assembly language code. Maybe a few words about where to start > would be a good thing. >> >> Or are you looking for a C reference/textbook/tutorial and expect the >> SDCC manual to be one of these? >> > No ... those are widely available. I'd expect information on how to use > THIS compiler/linker/assembler, etc. though. >> >>> I just reported that virus detection in the latest SDCC file set. My >>> scanner seems to have found and removed it, but there are folks who >>> may not be so lucky. >>> >>> I did understand that those programs are checksum/CRC verification >>> tools. >>> I'd just never seen 'em or heard of 'em before, nor do I know where >>> they're to be found. >> >> http://en.wikipedia.org/wiki/md5sum >> http://en.wikipedia.org/wiki/sha1sum >> >> Comparing just the md5sum (on a clean system) would be enough. >> > Well, that may, at least, lead to an answer to the question regarding the > downloaded file set. A clean system is never a problem. I use removable > (frame+tray) hard drives and always have at least one, for each system, > that has never been present when attached to the internet or even the LAN. > Sanitizing files acquired via the www is sometimes tricky, so they seldom > see the "clean" drives. >> >> Greetings, >> Frieder >> > Thanks for the comments, Frieder. I'm not complaining. I'm just > lamenting that I've lost my way. Perhaps I'm looking for that trail of > bread crumbs. > Being oriented to ASM and macros rather than HLL's for small code body, I > haven't made 'C' a priority for MCU development. However, as SiLabs, for > example, has put its primary thrust into supporting the compilers (KEIL, > SDCC) rather than ASM with its app-notes, etc, I'm taking another look. >> >> >> Richard Gray wrote: >> >>> md5sum etc are standard utilities on most unix/linux systems. I >>> cannot speak for Windoze, but I kinda doubt MS can be bothered, but >>> there are probably 3rd party versions available - if you can trust >>> those! >> >> :) >> > > > ------------------------------------------------------------------------- > 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 > > ------------------------------------------------------------------------- > 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: Juges, D. <Did...@cr...> - 2008-08-29 19:14:12
|
Richard, Previous to SDCC (and still for most work-related projects) I use the old Franklin compiler, which was a variation (under licence) of the Keil compiler, circa 1985 or so. Nothing like an old, trusty compiler :-) It is a DOS based tool, and like the current Keil (!) has limitations on filenames and directory path (which have to be DOS-compliant, with no space in them). I was surprised to find out that the current Keil compiler, at $5,000 a seat, still has these limitations. For the Silabs related projects, I use the Franklin compiler from within the IDE with the Keil settings, but for the TI MSC1210 projects, I use a free make utility (DMAKE) and the Franklin compiler from the Windows command line. I suspect it would be easy to use the SDCC compiler with the same makefiles, but I have not tried, since all I do at the moment is with the Silabs chips, and the Silabs IDE is OK for what I do. I do very little assembly and I have not used a simulator, so my experience in that regard is limited. I have started a Wiki on the SDCC tools, for my own and my friends benefit primarily, but it is public: http://www.ko4bb.com/dokuwiki/doku.php?id=tools_for_the_silabs_and_other_8051_micro_controllers You are welcome to visit and/or add your piece :-) Didier -----Original Message----- From: sdc...@li... [mailto:sdc...@li...] On Behalf Of Richard Erlacher Sent: Friday, August 29, 2008 11:32 AM To: sdc...@li... Subject: Re: [Sdcc-user] Virus in SDCC-2.8.0-setup.exe - MD5 etc tutorial Didier , Well ... No ... I've not attempted to use the SiLabs IDE. I'm still looking for doc's on what it's supposed to do, etc. I'll "get around to it." I'm interested in a more generalized procedure not wedded to a given manufacturer's tools, at least for the moment. I understand your comment. I believe, as well, that one would be hard-pressed to use the SiLabs IDE without SDCC or KEIL. Up to now, I've had the impression that the SDCC tools work from the command line in a Windows environment. There's an IDE called MIDE, which presents an editor, 2-kB-range-limited simulator (by TS Controls), and, perhaps, (I've not attempted to do anything further) a means for hooking into the SDCC compiler, which would have some potential, but for the limitation on the simulator. The TS Controls website is apparently gone ... and so is the opportunity to upgrade to a "full" simulator. That's moot anyway, as what's necessary is a simulator for the specifics of the MCU that's the target. An IDE is a separate issue. more below ... regards, Richard Erlacher |
From: Maarten B. <sou...@ds...> - 2008-08-28 18:15:50
|
Hi Richard, > Now, SDCC is a great concept if, for example, it's easy to integrate with an > assembler, a linker, a simulator, a librarian, and all the other utilities > that are helpful in developing code. SDCC for the 8051 only works with the assembler and linker that come with it, sorry. It needs a separate assembler and linker and AFAIK there is no other free/open source option available. > I just learned that the SiLabs > environment (IDE) without which it's apparently a pain to use their MCU's, > relies upon OMF files produced by SDCC tools, among others. That's why I'm > taking another look. The small bits of code I usually prepare for the > 805x-series (up to, say, 12k-15k lines of ASM) are generally monolithic, > hence, don't require the linker, etc. Up to now, I've written code segments > and de-loused them separately, since the things I do, though sometimes > bigger than 8kB of object code, are seldom terribly complex. After that, I > simply combine those portions of code as macros or as subroutines. Unfortunately the assembler that comes with SDCC does not support macros. But the assembler/linker combination can also output OMF files without being called by SDCC. And thus the SiLabs IDE can download and debug the output. The SiLabs IDE can download only HEX- files (which have no debug information) and OMF-files (which do). If your favourite assembler (with or without linker) can generate OMF files, the IDE should be able to load and debug them. The only real issue I can think of would be the endianness for displaying multibyte variables. Both big-endian and little-endian are supported so choose a compiler setting with compatible endianness. Hope this helps, Maarten Brock |
From: Bobby G. <bg...@fh...> - 2008-08-28 20:16:39
|
Hello All, As a beginner (I've written one real C application), using SDCC with an Atmel 8051 micro on an XP machine, I can certainly empathize with Richard. While the advice in these exchanges is helpful, It doesn't address the question of better documentation. It is in fact as I see it, an admission that the documentation is inadequate. Further, it suggests that nothing is going to be done about it. Bobby Garner Maarten Brock wrote: > Hi Richard, > > >> Now, SDCC is a great concept if, for example, it's easy to integrate with an >> assembler, a linker, a simulator, a librarian, and all the other utilities >> that are helpful in developing code. >> > > SDCC for the 8051 only works with the assembler and linker that come > with it, sorry. It needs a separate assembler and linker and AFAIK > there is no other free/open source option available. > > >> I just learned that the SiLabs >> environment (IDE) without which it's apparently a pain to use their MCU's, >> relies upon OMF files produced by SDCC tools, among others. That's why I'm >> taking another look. The small bits of code I usually prepare for the >> 805x-series (up to, say, 12k-15k lines of ASM) are generally monolithic, >> hence, don't require the linker, etc. Up to now, I've written code segments >> and de-loused them separately, since the things I do, though sometimes >> bigger than 8kB of object code, are seldom terribly complex. After that, I >> simply combine those portions of code as macros or as subroutines. >> > > Unfortunately the assembler that comes with SDCC does not support > macros. But the assembler/linker combination can also output OMF > files without being called by SDCC. And thus the SiLabs IDE can > download and debug the output. The SiLabs IDE can download only HEX- > files (which have no debug information) and OMF-files (which do). If > your favourite assembler (with or without linker) can generate OMF > files, the IDE should be able to load and debug them. The only real > issue I can think of would be the endianness for displaying > multibyte variables. Both big-endian and little-endian are supported > so choose a compiler setting with compatible endianness. > > Hope this helps, > Maarten Brock > > ------------------------------------------------------------------------- > 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-28 20:38:26
|
Thanks, Maarten, that's good to know. I've been using a macro assembler that came with an earlier version of SDCC, or, perhaps (I don't recall), was simply pointed to by one of the related sites. It has a good help file which has saved me many an error, and it's part of the "MIDE" package, which includes a simulator and claims to hook up in some way to SDCC. That may be why I made some possibly unwarranted assumptions about its relationship to SDCC. regards, Richard Erlacher ----- Original Message ----- From: "Maarten Brock" <sou...@ds...> To: <sdc...@li...> Sent: Thursday, August 28, 2008 12:15 PM Subject: Re: [Sdcc-user] Virus in SDCC-2.8.0-setup.exe - MD5 etc tutorial > Hi Richard, > >> Now, SDCC is a great concept if, for example, it's easy to integrate with >> an >> assembler, a linker, a simulator, a librarian, and all the other >> utilities >> that are helpful in developing code. > > SDCC for the 8051 only works with the assembler and linker that come > with it, sorry. It needs a separate assembler and linker and AFAIK > there is no other free/open source option available. > >> I just learned that the SiLabs >> environment (IDE) without which it's apparently a pain to use their >> MCU's, >> relies upon OMF files produced by SDCC tools, among others. That's why >> I'm >> taking another look. The small bits of code I usually prepare for the >> 805x-series (up to, say, 12k-15k lines of ASM) are generally monolithic, >> hence, don't require the linker, etc. Up to now, I've written code >> segments >> and de-loused them separately, since the things I do, though sometimes >> bigger than 8kB of object code, are seldom terribly complex. After that, >> I >> simply combine those portions of code as macros or as subroutines. > > Unfortunately the assembler that comes with SDCC does not support > macros. That's not a big deal, since the macros can be substituted/pasted into the code using an editor command, if necessary. >But the assembler/linker combination can also output OMF > files without being called by SDCC, and the SiLabs IDE can thus > download and debug the output. The SiLabs IDE can download only HEX- > files (which have no debug information) and OMF-files (which do). If > your favourite assembler (with or without linker) can generate OMF > files, the IDE should be able to load and debug them. The only real > issue I can think of would be the endianness for displaying > multibyte variables. Both big-endian and little-endian are supported > so choose a compiler setting with compatible endianness. > > Hope this helps, > Maarten Brock > > ------------------------------------------------------------------------- > 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-28 21:09:36
|
Bobby, I suspected I wasn't the only one who experienced this documentation shortfall. I've seen lots of software projects go this way over the years, and it starts with the coder/designer sitting down and coding something, then figuring out what he's created. If he "gets around to it" then a document is generated, though it may or may not reflect what's been coded. Most of the time, it reflects how it was coded and not so much why, and seldom does it actually reflect design goals that the coder had in mind when setting about to write the product. When I last looked at portions of LINUX, I was surprised to find code that had drivers containing comments from versions numbered below 1.0, yet the code, back in the mid-'90's was released at version 13.-something. Those comments should have been deleted when the code was changed ... <sigh> ... and, hopefully, replaced with something relevant. When I stopped writing code for a living, which was before the advent of 'C' and Pascal (Nobody remembers that, do they?) as the popular learning vehicles, folks who wrote programs for a living tended to work from an objective specification that had been "approved" by the people paying for the work. If the resulting work product didn't pretty precisely match the objective specification, the programmer lost his job and, since nearly everyone engaged in that sort of work at the time knew each other, that meant he'd have trouble finding work thereafter, aside, perhaps, from waiting tables or washing dishes. Today, everyone seems to know more about 'C' than I, though they seldom document their code properly, or even sufficiently to make it readable, and that's why much of the software we see is so large, complex, and often faulty. Over the years, I have become moderately proficient at writing documentation, among other things, 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. I can't document what I don't know. Now, I'm like most other folks, in that I have to keep the wolf from the door, and that requires me to do other things, mostly involving things others want me to do, from time to time. I have very little time for hobby projects, and, sadly, my alligator mouth often overloads my hummingbird "other end" when it comes to promising freebies to people I encounter along the way, which doesn't help with my time budget. 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, as I made writing simulations my primary area of academic interest back in the '60's when I was in college. The documentation of SDCC must come first, though, if I'm to do anything along those lines. regards, Richard Erlacher ----- Original Message ----- From: Bobby Garner To: sou...@ds... ; sdc...@li... Sent: Thursday, August 28, 2008 2:16 PM Subject: Re: [Sdcc-user] Virus in SDCC-2.8.0-setup.exe - MD5 etc tutorial Hello All, As a beginner (I've written one real C application), using SDCC with an Atmel 8051 micro on an XP machine, I can certainly empathize with Richard. While the advice in these exchanges is helpful, It doesn't address the question of better documentation. It is in fact as I see it, an admission that the documentation is inadequate. Further, it suggests that nothing is going to be done about it. Bobby Garner Maarten Brock wrote: Hi Richard, Now, SDCC is a great concept if, for example, it's easy to integrate with an assembler, a linker, a simulator, a librarian, and all the other utilities that are helpful in developing code. SDCC for the 8051 only works with the assembler and linker that come with it, sorry. It needs a separate assembler and linker and AFAIK there is no other free/open source option available. I just learned that the SiLabs environment (IDE) without which it's apparently a pain to use their MCU's, relies upon OMF files produced by SDCC tools, among others. That's why I'm taking another look. The small bits of code I usually prepare for the 805x-series (up to, say, 12k-15k lines of ASM) are generally monolithic, hence, don't require the linker, etc. Up to now, I've written code segments and de-loused them separately, since the things I do, though sometimes bigger than 8kB of object code, are seldom terribly complex. After that, I simply combine those portions of code as macros or as subroutines. Unfortunately the assembler that comes with SDCC does not support macros. But the assembler/linker combination can also output OMF files without being called by SDCC. And thus the SiLabs IDE can download and debug the output. The SiLabs IDE can download only HEX- files (which have no debug information) and OMF-files (which do). If your favourite assembler (with or without linker) can generate OMF files, the IDE should be able to load and debug them. The only real issue I can think of would be the endianness for displaying multibyte variables. Both big-endian and little-endian are supported so choose a compiler setting with compatible endianness. Hope this helps, Maarten Brock ------------------------------------------------------------------------- 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 ------------------------------------------------------------------------------ ------------------------------------------------------------------------- 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-28 21:14:03
|
While I'm sympathetic to the cries of inadequate (or sometimes just plain wrong) documentation, I think this needs to be met with more understanding. The Open Source development community is comprised of some rather clever people that are prepared to sit and write useful software in their spare time for free and for nothing. People that write software are notoriously reluctant to sit and write documentation because, well, they just don't like doing it. Unfortunately, this places some pressure upon would-be users to provide some input of their own, which is to examine the source code for themselves and learn by experimentation - it's those same people that might later decide to contribute with documentation, worked examples "howto" guides and so-on, should they wish to join this very generous community themselves. Unfortunately people have come to expect a professional finish (which it does get eventually) from people who are toiling away in their spare time, and this is a bit unrealistic. I don't admonish anyone to look at source code, rather exhort them to in the hope that they themselves might be able to contribute to the project one day. Projects like SDCC are going to be niche projects with only a limited number of people able to contribute, and I've no doubt these people have day-jobs too. Bigger projects, like Open Office and Linux tend to be much better documented and better generally because of the comparatively large number of people behind them, and indeed through sponsorship - Linus Torvalds develops and maintains Linux for a living, for example. If enough money could be raked together to sponsor someone, or a group, to develop and maintain SDCC then we would no-doubt see superb developments in a much shorter timescale; but this is probably an unlikely turn of events. Then again, maybe if someone wants to try and persuade, say, Microchip Inc that it's in their interests to sponsor the development of the PIC forks of SDCC, then who knows? Even then, wrangling with companies over sponsorship is time away from the project coal-face, and many programmers would find this tedious. There is a quite nice C compiler for PICs from some Australian outfit, I think, (I cannot remember the name) but this will cost you around £400 (GBP 400), and the documentation is good and I found the simulator and cut-down teaser version very good when I last tried it; but I don't want to cough-up £400 or so for the full-blown product for projects that I write for free to help people out. For myself, I don't want to be forced to use Windows, so SDCC is great if you're a Linux user, which I am, exclusively. When I've written some worthwhile stuff for the Z80/Z180 fork, I'll offer it as example code specifically to help others, and no-doubt I could make some amendments to the manual too. So, I'm suggesting that if you can do better then please feel free to do so. Constructive criticism and bug reports are great too. When you're an Open Source user you're also a developer, in however modest a way that might be. Complaining, well... A last word for Windows users (apart from to try and wean yourselves off it!), try searching your file system for z180.h - once you have found this you will have found the general area of includes and libraries and such. /usr refers to a Unix/Linux file system and the Windows setup is probably different. -- Richard. PGP Key-id: 0x5AB3D350 |
From: Richard E. <ed...@id...> - 2008-08-28 23:16:12
|
Richard, That's all very true. That's also one of the things that holds open-source projects, software and hardware, back, and, often causes them to fall into relative disuse until someone not-so-open-source gloms onto them and reworks them into a commercial product. The commercialization of LINUX is one example. What's a common thread among all open-source projects is that the core precedes the documentation, hence, the documentation is difficult because the authors of the core product must, having worked long months and years of spare time, which they probably enjoyed to greater or lesser extent, certainly don't want to write documentation after the fact. It's very difficult to document your work after it's been "completed." That's why it's important to get the doc's done BEFORE the coding is started. When you're finished coding, then, you have something against which to test, not just "try out" your work to see how well you've done, what you've missed, etc. It's easy, too, to get wrapped up in an open-source project when you just jump in and start doing what you want, though it doesn't always lead where you intended to go. Now, I've offered to work up a User Guide, provided, of course, that I can find the information necessary in order to become a user. If that involves reading the code, then it had best be thoroughly documented code ... you see where this leads? I appreciate that the folks who are maintaining SDCC have their hands full dealing with problems and occasional "critters" that come up. I also know that those same people are not likely to find time to document SDCC, nor would they be likely to want to do that. I know that I'm presently unable to make use of SDCC. I also know that if I find out how to use it, I'd be in a much better position to produce useful documentation than if not. Is there anyone else who's better equipped with the energy and willingness to do this? I hope so. If I have to figure out how to use SDCC from poring over the code listings, I'll probably skip it and continue using assembly language. I'm comfortable with that. After all, sifting through the code is about a 10 k-hour investment, and that would be necessary to perform a < 1000-hour task. BTW, I'm not a Windows lover. I use it because it's just about impossible to buy a computer without it, aside from a MacIntosh, which I like even less. I'm a devoted user of DOS, at least for "useful work" since I can rely on that. With Windows, which is useful for compatibility with the rest of the world, and yes I know about the open-source tools that are "equivalent," all bets are off. I guess what I'm doing is complaining ... but I'm complaining that that's all I can do. regards, Richard Erlacher ----- Original Message ----- From: "Richard Gray" <ri...@re...> To: <sdc...@li...> Sent: Thursday, August 28, 2008 3:13 PM Subject: [Sdcc-user] Poor documentation & open source generally > While I'm sympathetic to the cries of inadequate (or sometimes just plain > wrong) > documentation, I think this needs to be met with more understanding. > The Open Source development community is comprised of some rather clever > people that are prepared to sit and write useful software in their spare > time for > free and for nothing. People that write software are notoriously reluctant > to sit > and write documentation because, well, they just don't like doing it. > Unfortunately, this places some pressure upon would-be users to provide > some input of their own, which is to examine the source code for > themselves > and learn by experimentation - it's those same people that might later > decide > to contribute with documentation, worked examples "howto" guides and > so-on, > should they wish to join this very generous community themselves. > Unfortunately people have come to expect a professional finish (which it > does > get eventually) from people who are toiling away in their spare time, and > this > is a bit unrealistic. I don't admonish anyone to look at source code, > rather > exhort them to in the hope that they themselves might be able to > contribute > to the project one day. > Projects like SDCC are going to be niche projects with only a limited > number > of people able to contribute, and I've no doubt these people have day-jobs > too. > Bigger projects, like Open Office and Linux tend to be much better > documented > and better generally because of the comparatively large number of people > behind > them, and indeed through sponsorship - Linus Torvalds develops and > maintains > Linux for a living, for example. If enough money could be raked together > to > sponsor someone, or a group, to develop and maintain SDCC then we would > no-doubt see superb developments in a much shorter timescale; but this is > probably > an unlikely turn of events. > Then again, maybe if someone wants to try and persuade, say, Microchip Inc > that > it's in their interests to sponsor the development of the PIC forks of > SDCC, then > who knows? Even then, wrangling with companies over sponsorship is time > away > from the project coal-face, and many pro-grammers would find this tedious. > There > is a quite nice C compiler for PICs from some Australian outfit, I think, > (I cannot > remember the name) but this will cost you around £400 (GBP 400), and the > docu- > mentation is good and I found the simulator and cut-down teaser version > very good > when I last tried it; but I don't want to cough-up £400 or so for the > full-blown product > for projects that I write for free to help people out. For myself, I don't > want to be f > orced to use Windows, so SDCC is great if you're a Linux user, which I am, > exclusively. > When I've written some worthwhile stuff for the Z80/Z180 fork, I'll offer > it as > example code specifically to help others, and no-doubt I could make some > amendments to the manual too. > So, I'm suggesting that if you can do better then please feel free to do > so. Constructive > criticism and bug reports are great too. When you're an Open Source user > you're also > a developer, in however modest a way that might be. Complaining, well... > A last word for Windows users (apart from to try and wean yourselves off > it!), try > searching your file system for z180.h - once you have found this you will > have found > the general area of includes and libraries and such. /usr refers to a > Unix/Linux file > system and the Windows setup is probably different. -- Richard. PGP Key-id: 0x5AB3D350** > > > |
From: Richard G. <ri...@re...> - 2008-08-29 00:51:54
|
Hi, er, Richard - apparently we have an uncommon name, so it's doubly weird to be writing to my namesake! I completely agree that the methodology (such as it is) used in Open Source projects leaves a lot to be desired; but it seems to me that despite many imperfections the Open Source movement is producing some remarkably useful stuff which is incredibly enabling and exciting, in a nerdy sort of way. The fact that one's code is released into the wild and subject to critical peer review is an incredible concentrator, and software types being what they are tend to find they cannot just leave something alone knowing that there are rough edges that can be shaved off. It seems to me that the most productive way ahead is to play to our strengths whilst being mindful of our weaknesses. This is all very well, but what does this mean in practice, to us? I have a project (Z180-based) which is to furnish an access control system for a local Buddhist Centre, bizarrely. I'm not doing this for any other reasons except that I have the know-how and gear to do it, it will help my friends and it interests me. To make this happen, I'm going to develop some code, in C (assembler being too clunky for my taste, although I understand it well enough). Because I'm a devout Linux user, using SDCC is a natural choice and will give me a great deal of practical experience, at least with the Z80 fork. I'll keep a diary and from time-to-time I'll post an account of what I've been doing, and hopefully this will give you a punt in the right direction with a manual revamp. In the short-term, I suggest you write a noddy program and see what happens - I'll post mine shortly if it helps get you going (and I'll have to tidy it up as well!)? I have an interest in the various PIC forks too, but I do not propose to devote any time to these just yet, useful as the PIC series are. I have some existing code written for a 16F84A [?], I wonder... I do think that there's a fairly fundamental problem with SDCC under Windows, and that is that the Windows build is something of a grudging concession. Everything about SDCC, as far as I can see, is geared towards Unix/Linux where C and the development of C programs is completely natural, and a native C compiler is standard. Any kind of development environment is an add-on for Windows with varying degrees of discomfort to go with it. Microsoft is notoriously unhelpful in disclosing the internals of Windows, and this has made it difficult for anyone to develop anything for it, and much is owed to reverse-engineering, which is no way to run a railroad really. I daresay that some poor bugger had to fork-out for the C compiler with which the SDCC cross-compilers, assemblers, linkers and so-on were built with originally, under Windows. If you have a spare partition on one of your Windows machines, then you could install a Linux distribution on it and have a dual-boot setup (I have a laptop configured this way - you need about 7GB free). I have another solution you might like to consider, but please contact me off-list about it... ooer. ;-) On Friday 29 August 2008 00:16:03 Richard Erlacher wrote: > Richard, > > That's all very true. > <snip> -- Richard. PGP Key-id: 0x5AB3D350 For some reason, this fortune reminds everyone of Marvin Zelkowitz. |
From: Borut R. <bor...@si...> - 2008-08-29 05:56:10
|
Just in front: I'm not a Windows lover, I just use it for my daily work. I'm developing on (and for) both Windows and Linux. My goal is not to enforce anybody (even myself) to use one or the other OS. My goal is to have a possibility use the same tools on any OS, so that it doesn't matter which OS I'm using. And the open source movement is following the same direction, for example Firefox, Open Office, Apache, MySQL, (even GNOME and KDE) ..., just to name some of projects which are not OS dependent Richard Gray wrote: > I do think that there's a fairly fundamental problem with SDCC under Windows, > and that is that the Windows build is something of a grudging concession. > There is nothing special about SDCC on Windows: you have install sdcc-2.8.0-setup.exe <http://downloads.sourceforge.net/sdcc/sdcc-2.8.0-setup.exe?modtime=1206870651&big_mirror=0> from http://downloads.sourceforge.net/sdcc/sdcc-2.8.0-setup.exe?modtime=1206870651&big_mirror=0 and voila, you can use it in the same way you can use it on Linux. The locations of include and lib directories are different from ones on Linux, but this doesn't hurt, since the SDCC compiler knows where to search header files and libraries. > Everything about SDCC, as far as I can see, is geared towards Unix/Linux > where C and the development of C programs is completely natural, and a native > C compiler is standard. I think that development in SDCC (and of SDCC) is equally "natural" on both platforms. Official SDCC build on Windows is compiled by gcc + mingw, which is "native" C compiler for Windows: it produces a Windows native code. > Any kind of development environment is an add-on for > Windows with varying degrees of discomfort to go with it. Microsoft is > notoriously unhelpful in disclosing the internals of Windows, and this has > made it difficult for anyone to develop anything for it, and much is owed to > reverse-engineering, which is no way to run a railroad really. I daresay that > some poor bugger had to fork-out for the C compiler with which the SDCC > cross-compilers, assemblers, linkers and so-on were built with originally, > under Windows. > There are IDEs which integrate well with SDCC. > If you have a spare partition on one of your Windows machines, then you could > install a Linux distribution on it and have a dual-boot setup (I have a > laptop configured this way - you need about 7GB free). I have another > solution you might like to consider, but please contact me off-list about > it... ooer. ;-) > By using MSYS http://www.mingw.org/wiki/msys or CygWin http://www.cygwin.com/ you can have complete *nix environment (shell & utilities) on Windows. Borut |
From: Dave M. <mc...@ne...> - 2008-08-29 05:28:54
|
On Aug 28, 2008, at 7:16 PM, Richard Erlacher wrote: > BTW, I'm not a Windows lover. I use it because it's just about > impossible > to buy a computer without it, Good heavens. If you choose to buy your computers at Wal*Mart, you'll get the Wal*Mart of operating systems...Windows. Further...why would anyone EVER trust and use a preinstalled operating system? Drives get wiped when they walk through my front door. -Dave -- Dave McGuire Port Charlotte, FL |
From: Bobby G. <bg...@fh...> - 2008-08-30 02:51:24
|
Richard (Gray), I have no doubt that you mean well, but there is a certain and unmistakable tone of arrogance in your closing remarks, which in my opinion, negates everything which preceded them. You allege that I am a developer by vertue of the fact that I am a user. if so, then why can not my remarks be consider constructive criticism? Why did you view my comments as a complaint rather that constructive criticism? Why do you demand that I jump through some other hoop? Why is this not a suitable forum? Of course, I /feel free /to "do better", but it is an incontrovertible fact that we (all of us) are working under a certain economic duress, and in my personal case, I cannot justify laying out $5,000 for "better". Being a beginner programmer, I am unqualified to jump in and contribute to the cause. However, I do feel qualified (having been engaged in electronics repair/design and manufacturing since 1958) to point out some of the problems which I have encountered, and which may not be so apparent to those who are so /qualified/. It is exceedingly unfortunate in my opinion, that my experience is of no value to you, and so easily written off. I assume that you speak for the larger group of active developers, and that too would be consistent with my experience. 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. I understand that the Opensource community is composed of volunteers, but since when did volunteering for something demand anything less then ones very best? Maybe this is the best. As good as it gets? It so happens that I'm more knowledgeable of Opensource, than I am of microcontrollers and the software to make them function properly. Public Journalism is a first cousin of Opensource, and thats something I can claim some degree of competence in since I am the owner and publisher of www.congregator.net. Someone mentioned how some Opensource software such as Openoffice.org is far more better documented. From those comments, and in the context in which they were made, it is easily assumed that the Opensource community takes full credit for that marvelous achievement. However, leave it to some nutcase like me to point out, in this context, that Openoffice.org was wholly designed and fully developed by paid professional programmers working under the direction of Sun Microsystems. Please, let us deal only with reality and the facts! Bobby Garner Richard Gray wrote: > While I'm sympathetic to the cries of inadequate (or sometimes just plain > wrong) documentation, I think this needs to be met with more understanding. > > The Open Source development community is comprised of some rather clever > people that are prepared to sit and write useful software in their spare time > for free and for nothing. People that write software are notoriously > reluctant to sit and write documentation because, well, they just don't like > doing it. Unfortunately, this places some pressure upon would-be users to > provide some input of their own, which is to examine the source code for > themselves and learn by experimentation - it's those same people that might > later decide to contribute with documentation, worked examples "howto" guides > and so-on, should they wish to join this very generous community themselves. > Unfortunately people have come to expect a professional finish (which it does > get eventually) from people who are toiling away in their spare time, and > this is a bit unrealistic. I don't admonish anyone to look at source code, > rather exhort them to in the hope that they themselves might be able to > contribute to the project one day. > > Projects like SDCC are going to be niche projects with only a limited number > of people able to contribute, and I've no doubt these people have day-jobs > too. Bigger projects, like Open Office and Linux tend to be much better > documented and better generally because of the comparatively large number of > people behind them, and indeed through sponsorship - Linus Torvalds develops > and maintains Linux for a living, for example. If enough money could be raked > together to sponsor someone, or a group, to develop and maintain SDCC then we > would no-doubt see superb developments in a much shorter timescale; but this > is probably an unlikely turn of events. > > Then again, maybe if someone wants to try and persuade, say, Microchip Inc > that it's in their interests to sponsor the development of the PIC forks of > SDCC, then who knows? Even then, wrangling with companies over sponsorship is > time away from the project coal-face, and many programmers would find this > tedious. There is a quite nice C compiler for PICs from some Australian > outfit, I think, (I cannot remember the name) but this will cost you around > £400 (GBP 400), and the documentation is good and I found the simulator and > cut-down teaser version very good when I last tried it; but I don't want to > cough-up £400 or so for the full-blown product for projects that I write for > free to help people out. For myself, I don't want to be forced to use > Windows, so SDCC is great if you're a Linux user, which I am, exclusively. > When I've written some worthwhile stuff for the Z80/Z180 fork, I'll offer it > as example code specifically to help others, and no-doubt I could make some > amendments to the manual too. > > So, I'm suggesting that if you can do better then please feel free to do so. > Constructive criticism and bug reports are great too. When you're an Open > Source user you're also a developer, in however modest a way that might be. > Complaining, well... > > A last word for Windows users (apart from to try and wean yourselves off it!), > try searching your file system for z180.h - once you have found this you will > have found the general area of includes and libraries and such. /usr refers > to a Unix/Linux file system and the Windows setup is probably different. > > |
From: Art C. <aar...@bi...> - 2008-08-30 05:53:00
|
Bobby Garner wrote: > > 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. Try it again - I suspect it has improved a lot since then and hopefully the few idiots around have grown up a bit since then. I've had good success with Code::Blocks v8.02 compiling both avr-gcc and sdcc (Z80) source for a few projects including a FreeRTOS based app on an ATMega128. Just stick to project specific make files, set C::B to use the custom makefile and it works like a charm. With care it even works with 'foreign' simulators. > I understand that the Opensource community is composed of volunteers, > but since when did volunteering for something demand anything less then > ones very best? Maybe this is the best. As good as it gets? Nope - we can do better (and I _should_ know having picked up one or two of those guvmnt certificates telling everyone how I'm such a wonderful volunteer!) > Someone mentioned how some Opensource software such as Openoffice.org is > far more better documented. From those comments, and in the context in > which they were made, it is easily assumed that the Opensource community > takes full credit for that marvelous achievement. > > However, leave it to some nutcase like me to point out, in this context, > that Openoffice.org was wholly designed and fully developed by paid > professional programmers working under the direction of Sun Microsystems. No question - OpenOffice is NOT representative of the Opensource community or of volunteer effort. > Please, let us deal only with reality and the facts! > > Bobby Garner |
From: Richard E. <ed...@id...> - 2008-08-30 05:36:58
|
Bobby, Don't assume the "complaints" remark Richard Gray made was targeted exclusively at you. Everyone knows that if nobody complains, nobody will fix what's broken, or even recognize that it is. Complaints are useful, but they do have to be brought out in a spirit of collegiality rather than simple and narrow criticism. I bitch about things all the time, and there are plenty of folks who probably think I'm just a whiner. However, I try not to whine about stuff that can't be fixed, or shouldn't be, I don't think the "complaints" remark was targeted at any one specific source. There are plenty of sources. My real complaint is that open-source community programmers often believe they can do the part of a task that they like doing and leave the rest, documentation, for example, to someone else. Some of them think they can be sloppy, so long as their work product functions. I believe they're wrong, but not everyone agrees with me. Go figure ... regards, Richard Erlacher ----- Original Message ----- From: Bobby Garner To: sdc...@li... ; Richard Gray Sent: Friday, August 29, 2008 8:51 PM Subject: Re: [Sdcc-user] Poor documentation & open source generally Richard (Gray), I have no doubt that you mean well, but there is a certain and unmistakable tone of arrogance in your closing remarks, which in my opinion, negates everything which preceded them. You allege that I am a developer by vertue of the fact that I am a user. if so, then why can not my remarks be consider constructive criticism? Why did you view my comments as a complaint rather that constructive criticism? Why do you demand that I jump through some other hoop? Why is this not a suitable forum? Of course, I feel free to "do better", but it is an incontrovertible fact that we (all of us) are working under a certain economic duress, and in my personal case, I cannot justify laying out $5,000 for "better". Being a beginner programmer, I am unqualified to jump in and contribute to the cause. However, I do feel qualified (having been engaged in electronics repair/design and manufacturing since 1958) to point out some of the problems which I have encountered, and which may not be so apparent to those who are so qualified. It is exceedingly unfortunate in my opinion, that my experience is of no value to you, and so easily written off. I assume that you speak for the larger group of active developers, and that too would be consistent with my experience. 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. I understand that the Opensource community is composed of volunteers, but since when did volunteering for something demand anything less then ones very best? Maybe this is the best. As good as it gets? It so happens that I'm more knowledgeable of Opensource, than I am of microcontrollers and the software to make them function properly. Public Journalism is a first cousin of Opensource, and thats something I can claim some degree of competence in since I am the owner and publisher of www.congregator.net. Someone mentioned how some Opensource software such as Openoffice.org is far more better documented. From those comments, and in the context in which they were made, it is easily assumed that the Opensource community takes full credit for that marvelous achievement. However, leave it to some nutcase like me to point out, in this context, that Openoffice.org was wholly designed and fully developed by paid professional programmers working under the direction of Sun Microsystems. Please, let us deal only with reality and the facts! Bobby Garner Richard Gray wrote: While I'm sympathetic to the cries of inadequate (or sometimes just plain wrong) documentation, I think this needs to be met with more understanding. The Open Source development community is comprised of some rather clever people that are prepared to sit and write useful software in their spare time for free and for nothing. People that write software are notoriously reluctant to sit and write documentation because, well, they just don't like doing it. Unfortunately, this places some pressure upon would-be users to provide some input of their own, which is to examine the source code for themselves and learn by experimentation - it's those same people that might later decide to contribute with documentation, worked examples "howto" guides and so-on, should they wish to join this very generous community themselves. Unfortunately people have come to expect a professional finish (which it does get eventually) from people who are toiling away in their spare time, and this is a bit unrealistic. I don't admonish anyone to look at source code, rather exhort them to in the hope that they themselves might be able to contribute to the project one day. Projects like SDCC are going to be niche projects with only a limited number of people able to contribute, and I've no doubt these people have day-jobs too. Bigger projects, like Open Office and Linux tend to be much better documented and better generally because of the comparatively large number of people behind them, and indeed through sponsorship - Linus Torvalds develops and maintains Linux for a living, for example. If enough money could be raked together to sponsor someone, or a group, to develop and maintain SDCC then we would no-doubt see superb developments in a much shorter timescale; but this is probably an unlikely turn of events. Then again, maybe if someone wants to try and persuade, say, Microchip Inc that it's in their interests to sponsor the development of the PIC forks of SDCC, then who knows? Even then, wrangling with companies over sponsorship is time away from the project coal-face, and many programmers would find this tedious. There is a quite nice C compiler for PICs from some Australian outfit, I think, (I cannot remember the name) but this will cost you around £400 (GBP 400), and the documentation is good and I found the simulator and cut-down teaser version very good when I last tried it; but I don't want to cough-up £400 or so for the full-blown product for projects that I write for free to help people out. For myself, I don't want to be forced to use Windows, so SDCC is great if you're a Linux user, which I am, exclusively. When I've written some worthwhile stuff for the Z80/Z180 fork, I'll offer it as example code specifically to help others, and no-doubt I could make some amendments to the manual too. So, I'm suggesting that if you can do better then please feel free to do so. Constructive criticism and bug reports are great too. When you're an Open Source user you're also a developer, in however modest a way that might be. Complaining, well... A last word for Windows users (apart from to try and wean yourselves off it!), try searching your file system for z180.h - once you have found this you will have found the general area of includes and libraries and such. /usr refers to a Unix/Linux file system and the Windows setup is probably different. ------------------------------------------------------------------------------ ------------------------------------------------------------------------- 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 08:44:11
|
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. 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. 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...) > 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). Jan Waclawek |
From: Daniel D. <dr...@ma...> - 2008-08-29 12:58:40
|
On Fri, 29 Aug 2008, Jan Waclawek wrote: > 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 Excuse me, but I should say that I wrote that simulator for myself, it was intended to be used by myself, human... Daniel |
From: Jan W. <we...@ef...> - 2008-08-29 13:22:28
|
Daniel, OK the wording was a bit strong, I apologize. On the other hand, as a common user, spoiled by windowey clickey programs, I somehow cannot get to like a simulator where for each single step I have to type "step" and hit enter, and then type in a bunch of other commands to find out, what has happened. You seem to know that as there are very nice pictures in the documentation of what you say there is a discontinued version. Otherwise, it's a very fine simulator and I know it's a lot of work you put into that, just the ease of use is more important for me than the other features which are important for you or for the SDCC developers. Szep napot! Jan Waclawek >> 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 > >Excuse me, but I should say that I wrote that simulator for myself, it >was intended to be used by myself, human... |
From: Daniel D. <dr...@ma...> - 2008-08-29 15:32:55
|
On Fri, 29 Aug 2008, Jan Waclawek wrote: > OK the wording was a bit strong, I apologize. That's OK, no problem. Sometimes GUI is more important but sometimes CLI can be usefull too. > Otherwise, it's a very fine simulator and I know it's a lot of work > you put into that, just the ease of use is more important for me > than the other features which are important for you or for the SDCC As you know it was developed as a special tool for my work so it was very good for me. It's not a general "best_for_everybody" tool so it is very possible that it doesn't fit for most users. I'm sorry for that but I can't help. Anybody can develop a better tool for her/himself (as I did), or pick a better one (there are a lot). 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. 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... > Szep napot! Neked is:) Daniel |