| ??? 05/16/10 15:35 Modified: 05/16/10 15:38 Read: times |
#175937 - why would that be impossible? Responding to: ???'s previous message |
Erik Malund said:
The size of the .cdb seems right, but a .omf (the one with no extension from SDCC) that is smaller than the .hex (.ihx from SDCC) is impossible. Why would that be impossible? How did you come to that conclusion? What makes you believe it is not "full"? OMF is a binary format, whereas intelhex, as you know, is ASCII, inflating the size significantly. I assume a pure binary of your experiment would come out somewhere around 2-3kB. .cdb is the native SDCC debug format, which is ASCII and rather sparse. Erik Malund said:
why it comes out w/o extension Well, a design choice... :-) How do you perform the compilation/linking cycle? Do you use a makefile? Or .bat? You could add a rename command to fix this after the compilation finishes into both. I presume you need the omf to be read into some other tool, the SiLabs stuff, I guess? Isn't there some guide to that tool how to use it with SDCC? Erik Malund said:
and why .hex is .ihx Another design choice... Maybe to push you to try to reformat it to a more conventional style before you use it? As it is after linking, the addresses of its lines are not in consecutive order, and that is known to throw apart certain programming tools. There's an utility called packihx included with SDCC, it is a common practice to perform something like packihx main.ihx > main.hex after compilation. A few months ago I reported here on a small project, a "snake" game on a 16x2 LCD module, which was written in SDCC. You might perhaps look at its makefile for some inspiration - nothing special there, though. Erik Malund said:
PS how can something with such a major defect even be considered a release. Who does the testing? Most of the testing - other than the developers testing themselves the changes they've just made - consists of an automated daily compilation and simulation run of a suite of small "regression test" programs. And, there is no formal process to assess the expectations of potential users, AFAIK. It would be hard to do that, given the number of developers and given that most (all) of them do this as a hobby, besides regular job. AFAIK there are no full-time-paid developers on SDCC nor massive corporate funding as gcc enjoys for example. I understand your frustration, but believe me that most SDCC users are used to/expect more spartan treatment than those who are used to the commercial tools. So they don't complain; and it also means that the developers don't know what would be the proper treatment of potential new users, what would they really need to get them started. I am not saying that you get what you payed for, I hate that saying, it is not fair, even if there's some truth in it. Maybe if you would write more on your particular setup and what the application is all about and how exactly do you intend to achieve your goals etc., others might come up with suggestions and, who knows, maybe even improved tools. JW |
