In article <lne8sl$m5g$1@dont-email.me>, david.brown@hesbynett.no says... ......> And then archive a physical machine or two as well, just to be safe :-)Along with their disks and license paper copies and copies of copies Anything you archive or backup - software, compiler, OS, debuggers special hardware and even systems should always be at least 2 copies. Trying to rebuild a hardware platform because some tool or hardware will not work on new systems (e.g. ISA cards or code written for 286) is a nightmare know plenty of places with lots or archived hardware as you dont know if one will work when you need it or the parts are still available. Mind you lots of parts are obsolete these days within 3 to 24 months... -- Paul Carpenter | paul@pcserviceselectronics.co.uk <http://www.pcserviceselectronics.co.uk/> PC Services <http://www.pcserviceselectronics.co.uk/pi/> Raspberry Pi Add-ons <http://www.pcserviceselectronics.co.uk/fonts/> Timing Diagram Font <http://www.badweb.org.uk/> For those web sites you hate
filling remaining array elements with fixed value
Started by ●June 12, 2014
Reply by ●June 13, 20142014-06-13
Reply by ●June 13, 20142014-06-13
David Brown <david.brown@hesbynett.no> writes:> On 13/06/14 03:42, Don Y wrote: >> Hi Grant, >> >> On 6/12/2014 6:19 PM, Grant Edwards wrote: >>> On 2014-06-12, Don Y<this@is.not.me.com> wrote: >>>> On 6/12/2014 3:02 PM, Randy Yates wrote: >>>>> Grant Edwards<invalid@invalid.invalid> writes: >>>>>> On 2014-06-12, Randy Yates<yates@digitalsignallabs.com> wrote: >>>>>> >>>>>>> I go along with the others who suggested that you write some C/C++ >>>>>>> code >>>>>>> to generate this code. I've done that many times and it works well. >>>>>> >>>>>> I find it's usually _way_ faster to write a Python program to generate >>>>>> such things, but YMMV. >>>>> >>>>> Yeah, sure, python, perl, common lisp, scheme, erlang, c, c++, etc. - >>>>> pick yer' poison. >>>> >>>> Write it in the same language that you are compiling -- that way you >>>> *know* you have THAT tool available wherever you happen to maintain >>>> the codebase (instead of having to have *two* tools). >>> >>> I don't understand. If I'm writing in C for the '430, how does that >>> guarantee I have C for the development host? >> >> It doesn't guarantee that you have it for the host. But, neither >> does it guarantee that you have python, perl, sh, etc. for the host! >> What it *does* guarantee is that *you* will know how to write C >> for that host (more or less)! It doesn't guarantee that you will >> be able to write a perl script *if* you happened to have perl >> available to you on *that* host (e.g., none of my windows hosts >> have perl installed). >> > > I have written embedded C for 20 years - but I would not be confident > about using C on the host for something involving a lot of string > manipulation and formatting. It's a different skill set, even though it > is still C.What C programmer (embedded or otherwise) doesn't know how to use printf()?> And I know plenty of embedded programmers who have no idea > how to make a host-run C program at all.Wha..? You've GOT to be joking! I think there are 5th-graders who know how to take a C program from the net and get it compiled.> So no, you don't have such a guarantee. > > But I can give a guarantee* that a competent embedded C programmer will > pick up the basics of Python quickly, and write string manipulation and > formatting code faster than learning to write host C code for the same > job. And the resulting scripts will be cleaner, faster to develop, and > easier to maintain.Your statement is irrational. A competent C programmer already knows C. If one uses Python, you will need time for learning the language AND implementing the required formatting. I claim that a competent embedded C programmer will write such scripts more quickly in C than in Python, and that it is more sensible from a maintenance persperctive to keep everything in the same language. -- Randy Yates Digital Signal Labs http://www.digitalsignallabs.com
Reply by ●June 13, 20142014-06-13
On 13/06/14 14:41, Randy Yates wrote:> David Brown <david.brown@hesbynett.no> writes: > >> On 13/06/14 03:42, Don Y wrote: >>> Hi Grant, >>> >>> On 6/12/2014 6:19 PM, Grant Edwards wrote: >>>> On 2014-06-12, Don Y<this@is.not.me.com> wrote: >>>>> On 6/12/2014 3:02 PM, Randy Yates wrote: >>>>>> Grant Edwards<invalid@invalid.invalid> writes: >>>>>>> On 2014-06-12, Randy Yates<yates@digitalsignallabs.com> wrote: >>>>>>> >>>>>>>> I go along with the others who suggested that you write some C/C++ >>>>>>>> code >>>>>>>> to generate this code. I've done that many times and it works well. >>>>>>> >>>>>>> I find it's usually _way_ faster to write a Python program to generate >>>>>>> such things, but YMMV. >>>>>> >>>>>> Yeah, sure, python, perl, common lisp, scheme, erlang, c, c++, etc. - >>>>>> pick yer' poison. >>>>> >>>>> Write it in the same language that you are compiling -- that way you >>>>> *know* you have THAT tool available wherever you happen to maintain >>>>> the codebase (instead of having to have *two* tools). >>>> >>>> I don't understand. If I'm writing in C for the '430, how does that >>>> guarantee I have C for the development host? >>> >>> It doesn't guarantee that you have it for the host. But, neither >>> does it guarantee that you have python, perl, sh, etc. for the host! >>> What it *does* guarantee is that *you* will know how to write C >>> for that host (more or less)! It doesn't guarantee that you will >>> be able to write a perl script *if* you happened to have perl >>> available to you on *that* host (e.g., none of my windows hosts >>> have perl installed). >>> >> >> I have written embedded C for 20 years - but I would not be confident >> about using C on the host for something involving a lot of string >> manipulation and formatting. It's a different skill set, even though it >> is still C. > > What C programmer (embedded or otherwise) doesn't know how to use > printf()?Well, printf is pretty common. But typical tasks in a C program for Windows or Linux are very different from those on many embedded systems, especially small ones. I can count on one hand the number of times I have used "malloc" during my career - dynamic memory is very rare in small embedded systems (and when it is needed, it is often specialised functions rather than malloc/free), but very common in host C programs. If I wanted to do file I/O in C on a PC, I'd have to look up all the details - similarly if I wanted to do sorting or searching in strings. In Python, these sorts of things are simple and obvious.> >> And I know plenty of embedded programmers who have no idea >> how to make a host-run C program at all. > > Wha..? You've GOT to be joking! I think there are 5th-graders who know > how to take a C program from the net and get it compiled.I've met professional developers who get worried about installing new programs themselves, and who would flatly refuse to look at a command line. There is nothing particularly wrong with that. Using an unavoidable car analogy, it's like a taxi driver who takes his car to the workshop to change a lightbulb.> >> So no, you don't have such a guarantee. >> >> But I can give a guarantee* that a competent embedded C programmer will >> pick up the basics of Python quickly, and write string manipulation and >> formatting code faster than learning to write host C code for the same >> job. And the resulting scripts will be cleaner, faster to develop, and >> easier to maintain. > > Your statement is irrational. A competent C programmer already knows C.A "competent C programmer" knows /some/ parts of C (the language, the standard libraries, and common system libraries). An embedded C programmer knows about embedded C, a Windows C programmer knows Windows programming in C, and a Linix C programmer knows about Linux programming in C. There is plenty of overlap between these, but still plenty of differences. And just as experienced "big OS" programmers are often hopeless at embedded programming, experienced embedded programmers are often hopeless at PC programming.> If one uses Python, you will need time for learning the language AND > implementing the required formatting.Are you speaking from experience here? Most people consider Python as being very fast to pick up (as always, I am referring to the basics needed for simple scripts). And the context of this branch of discussion was, I believe, whether a non-Python programmer can easily maintain and modify an existing script, rather than writing from scratch.> > I claim that a competent embedded C programmer will write such scripts > more quickly in C than in Python, and that it is more sensible from a > maintenance persperctive to keep everything in the same language. >And I claim that the problems in question - developing embedded software and writing a script to generate some C code - are in such completely different domains that the best tools for the jobs will be different. When you are an expert with a hammer, you will manage to hammer a screw into the wall. But you would often be better off taking time to learn to use a screwdriver too.
Reply by ●June 13, 20142014-06-13
Hi Paul, On 6/13/2014 5:29 AM, Paul wrote:> In article<lne8sl$m5g$1@dont-email.me>, david.brown@hesbynett.no > says... > ....... >> And then archive a physical machine or two as well, just to be safe :-) > > Along with their disks and license paper copies and copies of copies > > Anything you archive or backup - software, compiler, OS, debuggers > special hardware and even systems should always be at least 2 copies. > > Trying to rebuild a hardware platform because some tool or hardware will > not work on new systems (e.g. ISA cards or code written for 286) is a > nightmare know plenty of places with lots or archived hardware as > you dont know if one will work when you need it or the parts are still > available.And there's the rub -- you don't *know* if you will be able to recreate the development (now "maintenance") environment. Yet, the requirement isn't that you *try* to support the product for X years (i.e., you *commit* to supporting it!). I've been lucky holding onto old bits of hardware, storing them in passive environments (SWMBO always gripes: "Why can't these things stay OUT IN THE GARAGE?"), having *need* to resurrect them with some frequency (*for* maintenance activities), etc. But, mothballing stuff and *hoping* isn't something to which I'd be happy making a financial commitment! You tend to discover something is "no longer available" only *after* you have a genuine NEED for it! (sort of like only discovering the batteries in the flashlight are dead when you *need* the flashlight!)> Mind you lots of parts are obsolete these days within 3 to 24 months...<frown> In several early projects, I made that assumption ("Heck, a few years from now, the product will be dead/updated simply because the client won't be *able* to buy these parts!"). I have been chagrined at how resourceful folks can be at keeping product lines alive -- despite the fact that genuine support (manufacturers) ended long ago! (esp for low volume, high dollar products!) The biggest worry (re: obsolescence) is *tools* and support thereof. Try calling a vendor for a "bug fix" 6 months from today. You'll be told to upgrade to *today's* version and then, *possibly*, your bug will be addressed. This is a huge incentive for having sources for your toolchain (e.g., FOSS -- but other options also exist) so *you* (or, someone you hire) can maintain it after the vendor stops (even the FOSS community doesn't support tools indefinitely! They are just as quick to suggest you "upgrade" before complaining about a bug).
Reply by ●June 13, 20142014-06-13
On 2014-06-13, Don Y <this@is.not.me.com> wrote:> On 6/12/2014 6:19 PM, Grant Edwards wrote: >> On 2014-06-12, Don Y<this@is.not.me.com> wrote: >> >>> Write it in the same language that you are compiling -- that way you >>> *know* you have THAT tool available wherever you happen to maintain >>> the codebase (instead of having to have *two* tools). >> >> I don't understand. If I'm writing in C for the '430, how does that >> guarantee I have C for the development host? > > It doesn't guarantee that you have it for the host.But that's what you wrote (and I quoted), isn't it? That if you're writing C for the '430, you'll always have a C compiler on the host to compile the source-generator? -- Grant Edwards grant.b.edwards Yow! But was he mature at enough last night at the gmail.com lesbian masquerade?
Reply by ●June 13, 20142014-06-13
On 2014-06-13, David Brown <david.brown@hesbynett.no> wrote:> I have written embedded C for 20 years - but I would not be confident > about using C on the host for something involving a lot of string > manipulation and formatting. It's a different skill set, even though it > is still C. And I know plenty of embedded programmers who have no idea > how to make a host-run C program at all. So no, you don't have such a > guarantee. > > But I can give a guarantee* that a competent embedded C programmer will > pick up the basics of Python quickly,10 minutes, max -- guaranteed[*]. Way faster that you can figure out what went wrong with your C string mainipulation even if you _have_ done it before. ;)> and write string manipulation and formatting code faster than > learning to write host C code for the same job. And the resulting > scripts will be cleaner, faster to develop, and easier to maintain. > > [*] My guarantee is, of course, worth the pixels it is written on![*] And you can back that up with the pixels mine is written on! -- Grant Edwards grant.b.edwards Yow! Give them RADAR-GUIDED at SKEE-BALL LANES and gmail.com VELVEETA BURRITOS!!
Reply by ●June 13, 20142014-06-13
On 2014-06-13, David Brown <david.brown@hesbynett.no> wrote:>>> for i in range(32) : >>> print "\t" >>> for i in range(32) : >>> print "0xff,", >>> print> That was just an easy example - specifically written to look like C > (it's not the way I would normally write it in Python).Oh good, I was hoping we'd get to this part: print ("0xff,"*32+ "\n") * 32 Or if you want it to be a little easier to read: line = "0xff," * 32 + "\n" print line * 32 -- Grant Edwards grant.b.edwards Yow! I invented skydiving at in 1989! gmail.com
Reply by ●June 13, 20142014-06-13
Hi Randy, On 6/13/2014 5:41 AM, Randy Yates wrote:> David Brown<david.brown@hesbynett.no> writes:[attrs elided]>>>>>>>> I go along with the others who suggested that you write some C/C++ >>>>>>>> code >>>>>>>> to generate this code. I've done that many times and it works well. >>>>>>> >>>>>>> I find it's usually _way_ faster to write a Python program to generate >>>>>>> such things, but YMMV. >>>>>> >>>>>> Yeah, sure, python, perl, common lisp, scheme, erlang, c, c++, etc. - >>>>>> pick yer' poison. >>>>> >>>>> Write it in the same language that you are compiling -- that way you >>>>> *know* you have THAT tool available wherever you happen to maintain >>>>> the codebase (instead of having to have *two* tools). >>>> >>>> I don't understand. If I'm writing in C for the '430, how does that >>>> guarantee I have C for the development host? >>> >>> It doesn't guarantee that you have it for the host. But, neither >>> does it guarantee that you have python, perl, sh, etc. for the host! >>> What it *does* guarantee is that *you* will know how to write C >>> for that host (more or less)! It doesn't guarantee that you will >>> be able to write a perl script *if* you happened to have perl >>> available to you on *that* host (e.g., none of my windows hosts >>> have perl installed). >> >> I have written embedded C for 20 years - but I would not be confident >> about using C on the host for something involving a lot of string >> manipulation and formatting. It's a different skill set, even though it >> is still C. > > What C programmer (embedded or otherwise) doesn't know how to use > printf()?Agreed. "Backing up" (driving in reverse) is a different skill set than driving forward -- yet, someone who advocated getting out of the car and *walking* (because he was more sure of his ability to do that) would leave me suspect: "And when are you going to LEARN to back up?">> And I know plenty of embedded programmers who have no idea >> how to make a host-run C program at all. > > Wha..? You've GOT to be joking! I think there are 5th-graders who know > how to take a C program from the net and get it compiled.But, they'll be able to "make" a host-run *python* program?>> So no, you don't have such a guarantee. >> >> But I can give a guarantee* that a competent embedded C programmer will >> pick up the basics of Python quickly, and write string manipulation and >> formatting code faster than learning to write host C code for the same >> job. And the resulting scripts will be cleaner, faster to develop, and >> easier to maintain. > > Your statement is irrational. A competent C programmer already knows C. > If one uses Python, you will need time for learning the language AND > implementing the required formatting.Why limit it to Python? Why not let the developer use whatever *he* thinks is appropriate for the task at hand? And, force everyone else in the organization to come up to speed with *his* choice of tools for *that* project? (of course, *he* will also have to come up to speed with the tools that his colleagues are using for *their* projects... "fair is fair") This was the siren's song that I fell for early on in my "independent" career -- picking the right tools FOR ME as I had no "arbitrary" constraints placed on me by "Corporate", development costs (at least those reflected in my monthly billing) were *very* obvious, etc. so why not pick the "most efficient" (for me) way to get the project "done"? Piece together whatever tools make sense (for *me*!) to get the job done... Ah, but now client -- running a MS shop -- grumbles because he doesn't have all those tools available that I do in my UNIX+MS shop! Do I try to be a religious zealot and convince him he *should* have them (from a purely technical argument)? "Gee, 5-10 years from now, you'll be able to get *some* of this stuff for free! There will be all these FOSS OS's available (in various levels of maturity) to choose from... why not get on the band-wagon *now*? MS is such a loser OS and, by association, anything that *runs* under it must be as well..." Look at some of the FOSS projects and the hodgepodge of tools they (somewhat arbitrarily) rely upon for proof of this. I.e., it's *fine* -- if you want to drink the koolade...> I claim that a competent embedded C programmer will write such scripts > more quickly in C than in Python, and that it is more sensible from a > maintenance persperctive to keep everything in the same language.Maybe others have better luck finding well rounded "coders" -- that are confident/competent writing code that typically runs in a desktop environment *and* an embedded one, in different languages, along with some familiarity with (embedded) hardware, etc. Should I write the "converter" for my text-to-phoneme algorithm in LISP as it is ideally suited for that task? Will someone down the road be able to change the input ruleset and *know* how to verify that the converter has accurately done its job? [I recall encountering gnuplot ports where the regression tests wouldn't pass. They would *run* to completion -- but, the resulting plots were obviously wrong! Unfortunately, the folks doing the port didn't understand what they were trying to "plot" so they were unable to determine that the plots were incorrect and, as such, teh *port* was flawed! "Gee, mathematical functions... you'd think folks would know what they all looked like!"] But, from my experience (and most of the grumbling I hear from my associates), finding someone who knows *a* language *well* is a significant challenge. Expecting him (her) *and* the rest of the staff tasked with reviewing his code to know *several* seems like a recipe for disaster. I can already see those folks nodding their heads at a design review (for fear of showing the shallowness of their knowledge of yet-another tool) instead of being able to actively criticize the implementation. How much more honest will they be with their abilities when tasked with *maintaining* it? *Especially* if the individual who built this multi-tool environment is "qualified"! ("Gee, he acts as if all of this stuff is 'obvious'; do I want to show my ignorance by questioning something he's done?") <shrug> I think folks have different experiences based on the environments in which they develop. I've learned to expect *less* flexibility in my environment rather than more (at least if I wanted to do less *rework*!) YMMV.
Reply by ●June 13, 20142014-06-13
On 13/06/14 16:35, Grant Edwards wrote:> On 2014-06-13, David Brown <david.brown@hesbynett.no> wrote: > >>>> for i in range(32) : >>>> print "\t" >>>> for i in range(32) : >>>> print "0xff,", >>>> print > >> That was just an easy example - specifically written to look like C >> (it's not the way I would normally write it in Python). > > Oh good, I was hoping we'd get to this part: > > print ("0xff,"*32+ "\n") * 32 > > Or if you want it to be a little easier to read: > > line = "0xff," * 32 + "\n" > print line * 32 >I usually prefer list comprehensions. (I've made the code a bit more general here). datalength = 1024 linelength = 32 # Take special values, pad with lots of 0xff, then truncate data = ([0x0a, 0x0b, 0x0c] + [0xff] * datalength)[:datalength] # Split data array into array of line chunks datablocks = [data[i : i + linelength] for i in range(0, len(data), linelength)] # Each line is formatted as a string lines = [", ".join(["0x%02x" % x for x in row]) for row in datablocks] # Put together the lines along with tabs, newlines, etc. output = "{\n\t" + ",\n\t".join(lines) + "\n};\n" # Display output (could also be written to a file) print output
Reply by ●June 13, 20142014-06-13
Hi Diego, On 6/12/2014 3:10 PM, blisca wrote:> Il 12/06/2014 22:53, Don Y ha scritto: >> On 6/12/2014 1:30 AM, blisca wrote: >>> Using Codewarrior,GNU i want to declare an array in program memory >>> like this: >>> >>> const unsigned char >>> my_array[8]={0xA,0xB,0xC,0xFF,0xFF,0xFF,0xFF,0xFF}; > > Lot of answers, > i will read all carefully > thanks againThink about what you are trying to *do* -- instead of the way you *currently* happen to be doing it. Then, think about what the compiler "expects" you to be doing. (languages tend to be written to facilitate certain types of activities). E.g., are you using uchar's as "small integers"? Or, are you, in fact, building "character strings"? (the latter can be tackled with other approaches). And, think of *why* your values are what they are. Is there anything that you want to *convey* (to the next person looking at your code) in their values? Any relationships that they should have to each other and to the program itself? (e.g., does every third value have to be "0x75"? Do they all have to be arranged in increasing order? etc.) And, how will the program behave if any of those relationships are violated? (e.g., if the values are intended to be presorted in ascending order, will your program choke if it encounters a value that is *smaller* than the value preceding it?) Ideally, you want to convey as much of these relationships to the next reader as possible -- to guide him in understanding and modifying your code. If you can have the compiler (or, another 'program'/tool that you wrote) enforce these relationships for you, then it aids in comprehension as well as protecting you from careless errors. For example, if the values had to be presorted in ascending order (recall, they are all *const* so they are not going to change after you compile it!), then you can write your code *knowing* this. I.e., value[i+1] - value[i] will NEVER be negative. If you know that no two consecutive values will ever be the same (can't be *guaranteed* for 1024 uchar's), then you can be confident that: result = something/(value[i+1] - value[i]); will NEVER signal a divide by zero error! But, these sorts of assumptions count on these characteristics of the data being *guaranteed*! I.e., if you "accidentally" specify two consecutive values having the same value, your code will *break*! (an argument for having some other tool "build" the data for you as *it* can make these guarantees -- assuming it is written correctly).
