filling remaining array elements with fixed value

should have been (assuming 100 [sic]): const unsigned char my_array[100]={

should have been: , TEN_FFS, TEN_FFS, TEN_FFS, TEN_FFS, (else you have 110 initializers for a 100 element array)

#define HUN_FFS TEN_FFS, TEN_FFS, TEN_FFS, TEN_FFS, TEN_FFS, \ TEN_FFS, TEN_FFS, TEN_FFS, TEN_FFS, TEN_FFS

const unsigned char my_array[1000]={ 0xA, 0xB, 0xC, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, TEN_FFS, TEN_FFS, TEN_FFS, TEN_FFS, TEN_FFS, TEN_FFS, TEN_FFS, TEN_FFS, TEN_FFS, HUN_FFS, HUN_FFS, HUN_FFS, HUN_FFS, \ HUN_FFS, HUN_FFS, HUN_FFS, HUN_FFS, HUN_FFS };

I think you can claim this is just two ADDITIONAL lines (or even *one* if you want to get creative!)

Reply to
Don Y
Loading thread data ...

hamilton schreef op 13-Jun-14 7:21 AM:> On 6/12/2014 11:20 PM, hamilton wrote: >> On 6/12/2014 3:24 AM, Wouter van Ooijen wrote: >>>> #define TEN_FFS 0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF >>>> const unsigned char my_array[8]={ >>>> 0xA, 0xB, 0xC, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF >>>> TEN_FFS, TEN_FFS, TEN_FFS, TEN_FFS, TEN_FFS, >>>> TEN_FFS, TEN_FFS, TEN_FFS, TEN_FFS, TEN_FFS >>>> }; >>>> #undefine TEN_FFS >>> >>> I misread, you want 1000, not 100, but that requires only two more >>> lines ;) >>> >> Don't you mean 200 more lines !! > sorry, 20 lines >

You think too linear. Learn to think recursive.

#define TEN_FFS 0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF #define H_FFS TEN_FFS,TEN_FFS,TEN_FFS,TEN_FFS,TEN_FFS,\ TEN_FFS,TEN_FFS,TEN_FFS,TEN_FFS,TEN_FFS const unsigned char my_array[8]={ 0xA, 0xB, 0xC, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF H_FFS,H_FFS,H_FFS,H_FFS,H_FFS,H_FFS,H_FFS,H_FFS,H_FFS,H_FFS }; #undefine TEN_FFS #undefine H_FFS

Wouter

Reply to
Wouter van Ooijen

It's not overkill, it's increasingly common practice. I have a few projects for which the tools are all installed in a VirtualBox virtual machine and run from there. The VB machine can then be snapshotted and archived. If the build "machine" is Linux rather than Windows, it's possible to be even more efficient using lightweight virtual machines (chroot jail, openvz, or now docker) - the "machine" for archiving can be just a few 100 MB's of files.

Reply to
David Brown

I would recommend a few things here. First, consider using raw hard disk images rather than specific formats and containers - the tools for working with raw images will always be around (a loopback mount in Linux is usually all you need). Most hypervisors and virtual machines can work with that.

Secondly, aim to use KVM on Linux as your hypervisor. I haven't used it myself - I use either VirtualBox for full emulation or OpenVZ for lightweight emulation. But KVM can emulate a lot more than other systems. While it is most efficient when the target and the host cpu are the same, KVM can handle a mismatch, using QEMU as a cpu emulator when necessary. If Intel goes bankrupt and your 2040 machine runs on PowerPC chips, KVM will let you run your x86 virtual machine images.

Also, KVM is entirely open source. You won't have to face vendors in 20 years time asking for old licenses for their old products - you can archive Linux and KVM (it is in the kernel, but there are usermode tools as well) as both source code and installable media, and rebuild machines in the future.

And do as much as you possibly can with open source software - both on the hosts and inside the virtual machines.

And then archive a physical machine or two as well, just to be safe :-)

Reply to
David Brown

On many systems, you only need /one/ word and a letter - "gcc", then answer "y" to the prompt asking if you want to install it.

But Grant does have a point, which could be relevant if developers don't have root (or sudo) access to their own machines, and are given minimal installs.

Reply to
David Brown

What you say is all true - but small Python scripts are usually very easy to follow for beginners, once someone else has written the original. I introduced Python to some of our other C embedded developers that way - and none have found it challenging to maintain or modify the generating scripts even though they had not seen Python before. /Mastering/ Python takes time (if it is even possible to "master" such a large programming language and library), but little scripts to generate code like this are easy.

for i in range(32) : print "\t" for i in range(32) : print "0xff,", print

That gives you 1024 "0xff, " for cutting and pasting into the code. Tidy up by hand to add the special values.

Any C programmer who thinks that is difficult to follow has a problem.

And it is not /that/ hard to add the special values to the Python, and make it generate an output file directly, so that the script can be run from make.

Reply to
David Brown

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, 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!

Reply to
David Brown

That might be correct. But I would also say that any C programmer who writes code for embedded systems is not able to write the equivalent to your Python script in C for the host should be stopped from writing any code.

--
Reinhardt
Reply to
Reinhardt Behm

That was just an easy example - specifically written to look like C (it's not the way I would normally write it in Python). When you have to generate values, parse inputs, sorting stuff, make more complex formatting, etc., you appreciate the flexibility of a higher level language. Rather than piles of strcat, strcpy, sscanf, sprintf, along with memory management of buffers, you can use Python to write much shorter and simpler code. Yes, a C programmer /could/ write that stuff in C (even if he is used to embedded C without malloc and printf) - but it is much easier and faster in interactive Python than code-compile-debug cycles with C.

It is up to each development group how they handle this sort of stuff, of course. My point is merely that Python is an excellent choice of language for small scripts and helper programs, it is easy to learn (at least to that level), and is almost always better suited than host C code for such purposes.

Reply to
David Brown

I did not put down Python. I have not use it yet. But in comparable situations I have also used other languages for such tasks. For example REXX when my host system was OS/2. Well today I use C++ together with Qt on the host and often also on larger embedded systems. This makes many things likewise as easy.

--
Reinhardt
Reply to
Reinhardt Behm

In article , snipped-for-privacy@hesbynett.no says... ......

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 
    PC Services 
 Click to see the full signature
Reply to
Paul

What C programmer (embedded or otherwise) doesn't know how to use printf()?

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.

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 
 Click to see the full signature
Reply to
Randy Yates

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.

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.

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.

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.

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 to
David Brown

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!)

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 to
Don Y

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 
 Click to see the full signature
Reply to
Grant Edwards

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 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 
 Click to see the full signature
Reply to
Grant Edwards

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! 
 Click to see the full signature
Reply to
Grant Edwards

[attrs elided]

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?"

But, they'll be able to "make" a host-run *python* program?

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...

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?")

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 to
Don Y

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 to
David Brown

Think 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).

Reply to
Don Y

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.