pulse counter using LPC1768 proving to very challenging

I have meaningful ISRs taking 400-600ns on a TMS320F2812 running at

150MHz. The entire executor engine of a dynamically reconfigurable waveform generation state sequencer completes in under 4us, with that time depending strongly on the number of possible transitions allowed per state, currently limited to 4.

The new TI Delfino at 300MHz could halve these times. The reason these processors can do this is because they have (albeit not particularly generous amounts, although the Delfino again improves this greatly) SRAM running at full processor speed, and a non-cached architecture.

What is critically important is interrupt latency and interrupt latency jitter. In my application, I use assembly language "pre-ISRs" above the non-critical ISRs which simply juggle a few interrupt enables, then very quickly re-enable interrupts. The main cause of interrupt latency jitter is C preamble code for each ISR takes quite a long time to complete. So if the main() code gets interrupted, the interrupt latency is about 100ns.

But if another low-priority interrupt is running when the highest priority real-time interrupt is triggered, then if I just leave it to the C compiler I have to wait for it to save full context, and run a bunch of silly little extra instructions, before having a chance to re-enable interrupts and let the high-priority one take over. That might extend the effective latency to 300ns. Hence, latency jitter.

By writing a pre-ISR in .asm, I can get interrupts re-enabled, restricted to just the more important ones, in just 3-4 instructions. Then the high-priority ISR can preempt the preamble codes of the low priority ISRs, greatly reducing latency jitter. I think the last time I measured, I could guarantee less than 200ns latency on the F2812.

Once past getting interrupts reenabled, the C compiler is good enough at writing the actual meat and potatoes ISR code.

I can't wait to get my hands on the Delfino. Being able to do serious work in a few 100s of ns is very much fun.

--
_____________________
Mr.CRC
 Click to see the full signature
Reply to
Mr.CRC
Loading thread data ...

I enjoyed reading the detailed overview. And it makes the point, again, among many other ways it can also be made.

As a side bar to just you, there are a few processor families where interrupt latency __jitter__ for internally generated interrupts (timers) is zero. Such interrupts are always synchronous with the clocking system (of course) and all instructions have the exact same execution time (1 cycle) and so interrupts are always entered on the same relative phase to the timer event. If you don't disable the system itself, of course. I've used this for an operating system with a jitter-free guarantee on starting sleeping processes using delta queues (where only one such process is allowed to sleep on the same timed event.)

Anyway, interesting overview. Enjoyed thinking a little about it. Makes me want to buckle down and design, build, and code up a personal arb-function gen for my desk. May do that.

Jon

Reply to
Jon Kirwan

Thanks Jon. I've mostly lurked here for over 12 years, and usually listen to your writings with great eagerness to learn something and am rarely disappointed.

Is that ARM families that can basically switch context in hardware, or some other device?

Hmm, looking at a few search results I sort of get it.

The recently produced Agilent 33522A I've gotten two of at work. In the past I was using Tek AFG3022. Unfortunately, the new Agilent is seriously bug ridden. They fixed it somewhat with a recent update, but still there are just embarrassing bugs. I would resign and go become a monk if I put out something like that. I was close to buying one for home, but I can't afford to put out my allowance funds for something screwey.

The nice thing about the 33522A if they ever get it to work is that it lets you choose an arbitrary sampling rate for arbs. Older generation ones like the Tek in this price range had fixed sampling rates, which seriously hampered usefulness if you wanted a precise or low frequency arbs. 33522A also has the ability to modulate many things with noise, and coolest of all is that the noise bandwidth is settable!

What I'd be tempted to do if I had the time or was retired (having a little one running amok is slowing me down to where a simple Nixie clock project takes 2 years just to make a PCB) is an audio range arb. with very high vertical precision output and very low distortion. That may be doable in a DSP as well, rather than needing an FPGA which would be my first consideration to implement anything serious. It would be cool to extend it into a full blown audio development instrument with analysis capabilities as well.

Weren't you one of the first people do code up a DDS on an AVR years ago?

Anyway, someone did that, and it inspired me to do something a little different, instead of trying the tightest inner loop for highest sampling rate, I went for low frequencies, but with an 8-digit LED display, with 5 frequency digits, and 3 phase shift digits for 1 degree phase setting.

I think it was a dual channel too. My interest was in making psychadelic doodles with a laser and closed-loop scanner mirrors, laser show style.

I got that to a working stage then threw it in a drawer. Then I did something more sophisticated with the TMS320F2812, but with no UI.

Then that went in the drawer. Ultimately I'll use the F2812 to make a full blown laser show. I really prefer to just goof off with eye candy toys. Only at work do I do serious stuff.

--
_____________________
Mr.CRC
 Click to see the full signature
Reply to
Mr.CRC

Thanks. I don't usually have a lot to say, anymore, though.

With the move towards large memory systems and 32-bit cpus with FP and memory mgmt systems capable of runing Linux on a chip, "embedded" has blurred to the point where you can't tell the difference between a Microsoft MSDN developer, a Linux guru, and an embedded micro coder, anymore.

The Windows CE coder seems to imagine they are doing embedded work. So does the Linux coder. .NET can run embedded, in fact, though anyone familiar with its details must realize just how abstracted that environment is. Technically, yes, I suppose it's true that porting code from a workstation to run on an "embedded device" using .NET, for example, might still meet some people's definitions. A lot of the discussions here seem to be at that level now. Although I do .NET coding and have my paid-up annual MSDN subscription, it's dull stuff to me.

I think of embedded to be about the skills required by us and where they __differ__ from hosted environment development skill sets. When a job requires familiarity more than just one language and requires familiarity with how compilers compile code, with assembly, with linker semantics and how to modify their control files for some desired result, as well as broad acquaintances with physics, numerical methods, signal processing, optics, and certainly electronic design, then we find more of these differences. When it requires less of these differences from workstation development skills, it is less about the "embedded" I know and love.

Times are changing and the relative mix of skills found amongst the embedded programmer body are shifting with the capabilities being offered in todays tools. Entire operating systems are ported over by people I do consider to be well healed embedded programmers, but then just used lock-stock- and-barrel by those who know little about what took place and don't care to know and who just use the usual workstation tools without knowing much difference, at all.

That's a different thing to me. So I write less, today. I haven't changed, but the audience has.

Some other. For one example, the now "mature" or "older" ADSP-21xx Family from Analog Devices is the example I had coded that delta queue for.

It's a very simple, easy to operate, precision tool. I first read about the idea from Douglas Comer's first book on XINU.

I think I'd focus on an audio range device, as well. But I'm pretty sure I'd just make it a toy and not something professional. There is so much more "work" involved in making something ready for others to use and although I find some of that enjoyable, I don't find all of it to be so. And I'd be looking more for my own hobbyist pleasure, self-test, and education than anything else.

I looked over some of what you write elsewhere and I wish I had your experiences with lasers, too. Lots of potential fun there, both for me and for students I like to teach at times.

By the way, I've also got a lot of "stuff in drawers." And I definitely get it about just goofing off with toys. Work is work, but on my own I don't want the burden of having to do all the extra stuff needed to productize. I'd rather play.

Jon

Reply to
Jon Kirwan

The "one-liner" description of "embedded systems" that I use to try to give folks (e.g., at a dinner party) an idea of what I do is: "something that is quite obviously a computer (inside) but doesn't look/act like a 'computer'" (assuming that they will relate "desktop PC" to the term "computer"). It's easy to give them examples of all of these systems that they've interacted with in the past 24 hours:

- your ATM

- the gas station experience

- the ECU that runs your automobile

- the *mouse* (!) attached to your PC (yup, there's a computer inside!)

- your sewing machine

- your TV

- the modem that connects your PC to the internet

- your cell phone

- your iPod etc.

I.e., it is easy to *quickly* overwhelm them with a list of things that they take for granted without even resorting to more esoteric applications (e.g., the photo-radar detectors around town; the traffic light controller; the machine that weighs and labels the meats you purchase at the butcher/grocer)

I summarize by saying "I make *things*".

To folks in the Industry, I describe embedded systems as "software that comes with a warranty" (*think* about it!)

Reply to
Don Y

I don't look at it from the outside. I look at it from the processes involved in performing the work and the skills and talents those entail. It's not about usage. It's about what is required by the craft.

Making a table from a shipped kit that requires assembly using a provided wrench and screwdriver, with everything already cut, pre-assembled and dismantled before shipping, and nicely varnished as well is indeed a table in the end and the end user, in fact, "made it." However, someone who does all the design, taking into account structure, form, use, available tools, fasteners, and skills, and then cuts each piece after careful measurement and strategy beforehand, and then does all the treatments and so on before getting to assembly, also "made it." Yet the shared backgrounds, skills, talented are completely lacking here.

To me it is about the shared life's experience and knowledge, skills and interests, depth and breadth, tools and so on that are involved in the shaping that count. It's who we are, not what we make, that makes us "embedded programmers."

When the things themselves change -- for example, when the making of furniture goes from hand-selection of grain and quality and orientation and colors and hand-crafted use of a wide variety of odd styled chisels of every manner and kind, to make a piece that will last 200 years (I have many such pieces, by the way, which are in perfect condition today) through all manner of humidty and temperature.... to using

30-yr old doug fir softwood stapled together with plastic and staples and some cheesy metalwork slapped onto the outside without any real idea of how these things get used over the years in the end (as happens to be the huge difference between old "roll top" desks and the new crap that could only be said to be copied out of some catalog, by comparison)... well, I just cannot call them the same kind of craft anymore.

Things have changed. And they have.

It's not for the bad. In many ways, the changing face of it makes it more accessible to many who otherwise could never have laid hands to the work before. People who couldn't have readily fathomed what it takes to write their own O/S on the fly, don't need to do so. They don't even need to understand them very well. In fact, they can downright abuse them and often come up, ignorantly, with something that "works" well enough to get the job done even though they don't even know they didn't use the tools well, at all. The tools are that good and readily available. But it also means that they have no idea what a thunk is, or a coroutine, or how c++ manages to mechanically achieve its inheritance rules, or what a stack unwind actually is and does.

It's a slightly different world coding for embedded Linux. So we don't share that much between us.

Embedded to me is about the skills and shared backgrounds we share as a community. Not products with warranties.

Jon

Reply to
Jon Kirwan

But the requirements change as the craft evolves! Do you want to dope your own silicon? Do you prefer using a "pocket assembler" in lieu of a HLL compiler?

What's wrong with that? If it results in more people having *tables*...

Or, if it frees them up to work on something *else* that they couldn't have had time to do, otherwise (because of the the countless hours/weeks that they would have spent designing, measuring, selecting wood grains, etc.)?

I.e., how much *didn't* get done, previously, because we were screwing around with 6 character, uppercase symbols in our code instead of writing things more expressively?

They are redirected to other purposes.

One of the first products I was involved with was a LORAN-C position plotter. Feed it time-difference coordinates and it charts your progress, on paper, in real time. Anywhere on the globe.

Hardware:

- 8085 (did that max out at fosc of 6MHz or 4?)

- 2 timer/counters

- 12KB ROM

- 256 bytes RAM

- two unipolar stepper motor drives (low power, nothing fancy)

- 2x6 digit PGD display

I.e., you could almost do this with a PIC, today.

The code -- complex for that time -- would:

- gather incoming TD's

- fit them to the appropriate "chains" based on GRI

- convert hyperbolic coordinates to lat-lon

- compensate for oblateness of Earth

- translate to a scaled Mercator projection

- drive X&Y motors to bring the pen to that position

- lather, rinse, repeat

Today, tackling this project would be a 4-6 *week* effort instead of the many man-years that went into it.

Builds would take *seconds* instead of half an hour of listening to an 8" floppy grinding away -- followed by

2 *hours* of EPROM burning. You'd be able to step through your code "at your desk" instead of burning EPROMs and probing for signatures with a 'scope.

I don't see how evolution in tools or device capabilities changes that. To me, the differences *are* in what we make. You use an autopilot differently than a "word processor" (that some desktop programmer created). The consequences of the autopilot's failure can be more significant, and immediate. A Therac hiccups and it *cooks* someone.

Users are more *engaged* with "devices" than "computers". They become integrated in their lives. Sitting down at "your PC" is an entirely different experience than cooking your dinner in the microwave; or, making a call on your cell phone; or driving to work; etc.

The "warranty" aspect, to me, speaks to the mindset differences between the two product worlds. People

*expect* (yes, EXPECT!) the software on their PC to crash. They *don't* expect -- nor are they tolerant of -- the software *in* their microwave to crash! And, if the latter occurs, they expect to be compensated for it ("I want a new microwave. One that *works*!").

So, would you prefer to spend weeks or months building that hand-crafted desk? Or, would you prefer to assemble it from a kit and spend the rest of your time building a unique set of windchimes (that no one else will ever have)?

I am thrilled at the opportunities these changes have given me to move my art into different areas. If I was still relying on that "pocket assembler", I'd never have time to even *imagine* the other devices that I could create let alone actually create them!

Or, the time to spend *commenting* on how "things have changed" :>

Reply to
Don Y

Indeed that is so. But it isn't just that there are new tools in town. It's also that _more_ people can participate at a much wider variety of skill levels. I'm not complaining about it. Just noting it.

I have done that. Were you aware of a Bell Labs kit to do just that, put out in the mid 1960's?? (I've done it since, with my own home-brew oven, as well, made with a nickel plated, water cooled chamber and halogen lamps. Long story there, too.)

I said that the group's interests have moved away from my own over the years. That's true. I _also_ believe that as the processors used and tools applied increasingly look more like traditional, hosted programming environments found on workstations, to that degree it also is less and less a differentiating feature. Taken to its limit, there will be no difference in embedded development and any other and no point in choosing to use the adjective anymore.

The group here has had this debate here. Long threads about it. I'm not changing any of the position I took a decade back about any of this. It's the same stand today. What makes embedded development "embedded" to me are how the skills and tools are differentiated from workstation development. That's the main point. It's not about the end product.

If a washing machine uses Windows 7 Ultimate and Microsoft writes the .NET objects used to do the hardware interfacing at a low level and then provides abstraction objects to the programmer, then this particular washing machine programmer is no more an embedded programmer -- even though it is a washing machine -- than would be any other .NET Windows 7 Ultimate programmer dragging and dropping a few objects onto a form.

Others have instinctively asked the questions you have asked. But I have considered them and don't agree with them once I thought more on it. It's not a useful dividing line. Sorry, but that's the end of it for me. What _is_ useful to know are the types of experiences, talents, and backgrounds required to _do_ development for some sphere. And in that sense, embedded has real meaning the way I apply it. It has almost no useful meaning the way you seem to suggest.

I'll stop here. There's more to this, but I didn't want to go too far. If you are interested, I've posted on this topic before and with more of my views on it exposed. Still available in google, I'm sure.

Jon

Reply to
Jon Kirwan

Your welcome.

I can relate. I prefer bit banging, writing ISRs, that sort of thing. Though drivers can get a little tiresome. I figure if it doesn't need an oscilloscope to debug and verify, it's not my kind of "embedded." Perhaps I just prefer any excuse to use an oscilloscope!

I've cringed at the mere sight of ".NET" since its inception. I also hated Java since I first heard of it.

We had a guy at work who thought "embedded" meant installing Linux on a SBC and programming it. It is "embedded" in a sense, but not quite the sense that it seems we would pretty much agree upon.

Well I don't think the need for the more EE skill side of the trade will go away. The changes probably amount to an overall improvement, since more people can access more technology and tools. That still a benefit even if some of them don't become master craftsmen. There's a place for developers with a cursory, high level undertanding. Think of Arduino and kinetic skulptors, for ex. If they can get something to just "work" then the world is a better place.

At first I thought Arduino was stupid. "I can work with a bare AVR, what do I need that for?" I thought. Then I realized that if it makes more people play with microcontrollers, it is good. Now I'm even curious to check it out and see if it can spare me some time on my next

8-bit project.

Oh that one. I was close to trying that out once. I actually would have preferred to use ADI processors for what I use the TI C2000 for, but at the time ADI had nothing like a "digital signal controller" with DSP speed and microcontroller peripherals. Blackfin has closed the gap a little, but it's still not what you'd pick to interface quadrature encoders and run MOSFET SMPS front-ends.

But TI assembly language is an ugly thing. It's not that bad if you can figure out the syntax and work with it enough to keep it memorized, which I haven't, because the docs are all language lawyer style when what is needed is more simple examples.

With ADI, at least for SHARC which I looked at a bit, assembly is a breeze.

Well I've a tidbit from you again. Thanks.

[edit]

Once it blurs into legalities, regulations, and injection molded die making, I start to run for cover. Probably better that I have a 9-5 job then.

Yeah, well the lasers and my silly Chemistry degree cost me a lot of time that I sometimes wish I had spent on getting a proper EE degree.

Have a good Father's Day, whether or not your a father!

--
_____________________
Mr.CRC
 Click to see the full signature
Reply to
Mr.CRC

I don't always require an oscilloscope or an MSO, but just being threatened that I might need one is what makes it all the more fun for me. Without at least the threat present, it's certain to be boring.

If you don't need to read datasheets, study peripheral operation, read schematics, consider sensor/transducer physics, do some laplace and partial fractions, look over voltage thresholds and current limits, scan over compiler output in assembly or machine code, set up that HP 54645D with both 8-lead probes in hand just in case, and figure out how to modify a linker control file, and all in the same project, then it isn't embedded work... much.

No, it grows. But the size of the pyramid of programmers grows exponentially larger still. So it remains a dwindling proportion of the conversation here despite the truth of what you say.

Agreed. I think this is very good, that computers have moved from when I first worked on building my own. What I did caused me to get written up in a large spread, with pictures, in the local newspaper. It was _that_ unusual, I guess. I don't know who ratted me out at the time. But the news people showed up, one day, all the same. To have the case where one can get a TI Launchpad send to you for $4.30, with cables and a crystal and two cpus, and connectors and the rest... no shipping charges... well, what can one say? It's a great time, indeed!!

I am glad for all this. And I'm glad others might be interested in them for any reason of their own, at all.

I just used a Launchpad to create a parallel port to USB "printer device" that can be used as a parallel port printer and it saves files automatically on the PC, instead. Had to add a DB25, some wire and a few resistors and one cap, is all. Oh, and a tiny piece of vector board. So yes, I get your point here.

I used a TI 'C40 quite a while back, but when I was actively also using the ADSP-21xx. I have to say it was night and day between the two. I had TI support on the phone because the hardware timing I was getting was 11 clocks for a cached bit of code that according to their docs should have taken 7 clocks. They NEVER were able to explain the timing of the bit of source code I sent them. Even after 3 weeks of their working on it and comparing it to their docs about register clashes and so on. Never did resolve the issue to my satisfaction. By comparison, the ADSP-21xx worked _exactly_ as the docs said. Always. Exactly. Never a question about them. The assembly (up to 3 instructions per cycle) was nice, too.

I know.

It's a book worth reading through. Very clear, very easy, and it stimulates the imagination well.

Hehe.

I did as much chemistry as I wanted to do -- mostly explosives as a kid. Mercury fulminate was my absolute fave

-- the reaction before the crystals settle out is a mad scientist's exothermic, boiling, vaporous dream. And what you get after, or better still after filtering and precipitation with glacial acetic acid, was also a lot of fun too. I did rocket fuels, explosives, fireworks, smoke bombs, and pretty much anything "thermodynamic." Luckily also learned enough extra to stay alive while doing that at home. Still have picric acid, chlorates and perchlorates, and a few other goodies laying about here. They used to ship that to

16 yr old kids, though the picric acid had to go by train. I know. I was one and they Boulevard Labs in Chicago shipped to me, regularly! Organics I got into a little. Enough to get some of the basic terms down so that I could read and draw things when asked, but nothing much more than that. I know what a hydroxy ketone is defined as and I can draw out a diagram for 1-Chloro-3,5-dinitro-4-hydroxybenzene if asked, for example. But that's about it. Although there is logic to organic naming, there is enough memorization of various specialized words to bother me. Inorganics is easier in that sense.

Thanks. You too. And yes, I've 3. All in their mid 20's now.

Jon

Reply to
Jon Kirwan

Jon Kirwan wrote: By comparison, the ADSP-21xx worked _exactly_

That one was intriguing. I was several pages into the manual before I realized that the sample code I was reading wasn't BASIC. Never wound up working with one, though. There was an ADSP-2105 at the other end of the product from me, once.

Mel.

Reply to
Mel

The ADSP-2105 was their "value line" part. Cheap at $5, memory serving. I used them. I also have an ISA board system with one installed on it where you can download code and play a bit. I did most of my work on an ADSP-2111. A somewhat higher priced spread than the 2105. I liked them a lot. Learned some things from the books that ADI produced for them, as well.

Jon

Reply to
Jon Kirwan

Holy smokes I can't believe you mentioned that Bell Labs kit. It was to make a silicon solar cell, and my dad and I worked through it when I was about 12. I remember actually being able to see a change in the visual properties at the edge of the wafer which was possibly evidence of the doped junction.

My dad and I built the furnace with fire bricks and *asbestos panels* that you could freely purchase in a hardware store.

We got our wafer Ni plated, but never could get any evidence of current production. It was a lot of fun though.

--
_____________________
Mr.CRC
 Click to see the full signature
Reply to
Mr.CRC

It's amazing to find another who knew about the kit!! It's still available, I think. At least, I had some contact a few years ago with the husband/wife pair who bought up the rights for the Bell Labs kits. I should see if they are still alive and kicking.

Jon

Reply to
Jon Kirwan

I disagree. Because the type of application and demands of the "user environment/experience" differ greatly in the two worlds.

As I said, a user interacts with a "device" (thing) differently than with a "computer" (desktop application). Everything about how and where he uses it is different. When you use a desktop application, you are (typically) investing much more effort

*trying* to use it as *you* intend. OTOH, when you use a *device*, the interface wants to be intuitive, second-nature, unobtrusive, etc.

You don't have some (arbitrary) set of "user interface guidelines" imposed by (e.g.) MS to adopt (ah, yes... we must support a 'cut' operation... and this must be initiated with these magic keystrokes...). Rather, you design the interface to fit the application and *environment* in which you expect the device to be operated.

You don't think in terms of long, drawn out "operational sequences" (create alpha channel from mask, darken, multiply, flood fill) but, rather, simple, short-lived exchanges. (consider an automobile: the most "involved" driving activity is probably parallel parking?)

Likewise, you know the user is far less forgiving of any "misunderstandings" (or, *gasp*, screwups!) on your part. When you turn the steering wheel left, the car had *better* turn left! By contrast, in the desktop world, the user expects problems interacting with the application (either because of a lack of familiarity with its intricacies, bugs in the application or whatever)

Look at the design and interaction you experience when using an iPod (or other "portable media player") vs. a desktop media player experience. Which is friendlier? More intuitive?

The desktop player's "controls" probably "make sense" -- to the developer and to the user -- yet they are nowhere near as intuitive and unobtrusive as the portable media player.

[IMO, this is where most of apple's products fall down, big time!]

That starts to sound elitist. As if only a person who has developed his own film can call himself a photographer. You may *lament* the fact that others can now *simply* do things that were, previously, signs of supreme accomplishment in the field. But, that doesn't make them any less so.

So, if *I* were to write that .NET program, it, *somehow* makes it an embedded program? (whereas it wasn't when *he* did so? Even though, chances are, *he* will get the .NET program "more correct" than I?)

I've a friend from school who has *probably* more "embedded devices" in use than most people I know. I wouldn't trust him to design a voltage divider -- or even solder two wires together without *also* putting a wire nut on them! He could easily have been designing compilers or writing desktop applications had he not "started" by writing code for "computers that don't look like computers". And, I suspect he could just as easily transition to that world if he had the interest -- despite his "embedded" (?) background.

Reply to
Don Y

I disagree, as well. What binds us is our experiences and knowledge of tools and practices. Who we _are_. Not end use. I think we are talking cross-purposes, though. I know you get it. I think we are just talking across each others' bow, so to speak. I'm talking about what it is to be a tool developer not a tool user.

That's probably my fault. Bad writing. But it's not.

I have a great deal of respect for Windows programmers, for example. I am one, as I have been programming nationally- sold Windows programs since about Windows 3.0 (learned on Win286 and Win386.) I'm working on such a product this very year, in fact. So I'm not talking about lofting embedded coders above Windows coders. That would be crazy.

I just happen to know, quite well, that "who I have been" as a Windows programmer is quite a lot different than "who I have been" as an embedded programmer. I include both types of people inside me and reject neither of them. But I simply see within me two different skill sets and talents arranged in different priority arrangements, when wearing one hat or another. The embedded side requires a far wider range of skills, but not a "better" range. There is no "better."

I readily admit I _prefer_ the embedded side of work. That's personal. If you feel that is elitist, I can't help that.

Why would I care, Don? Doesn't matter to me that others have their interests and desires, different from mine.

But to use your example, that doesn't mean that a person who owns a camera and doesn't know anything about developing film will be someone that a film developer necessarily lumps into their own social group. If you imagine conflating these two things into the same mush, I guess I then understand your confusion about where I'm coming from.

I don't mean to be abrupt about it, but it is obvious to me this way you write here isn't a useful way to divide things.

Put simply, if I wanted to waste my precious reading and responding time on Windows and Linux programming issues, I'd go find a Windows or Linux group. They already have plenty of places, in fact, for a wide variety of special interests in their own categories.

In any case, I like your discussions here. They sing to me and I understand them pretty well and enjoy the issues brought out by them. Just so you know.

You miss my point. This is why we are talking at cross purposes. As I just wrote, I __like__ reading your posts. That won't change at all just because you write a .NET program. Cripes, __I__ write .NET programs, for gosh sake. I like to think that I'm still an embedded programmer. My soul doesn't change.

I enjoy the kinds of challenges, and seeing the kinds of interesting solutions to them, that deeply embedded development entails. That's why I'm here. Those challenges often bring people with similar interests together. I like that fact. To the degree that this group changes its discussions towards .NET or Linux development, to that degree I will read less and participate less.

Not because I don't do that development work -- I do -- but because my personal interests lay elsewhere. And not because I mean to judge it harshly -- I don't. But I don't define myself as a Windows programmer, despite the fact that I've now 25 years of such experience mixed within 38 years of embedded experience. I don't define myself as a Linux developer, despite having been involved with Unix since the v6 kernel days (mid to late 1970s.) I prefer my embedded side, love that aspect, what to share it with others. The rest is part of who I am, too, but it's not what I enjoy as much.

If you wrote a .NET program, it would still be a .NET program and wouldn't rely upon the kinds of shared experiences I like listening to. That doesn't take away from the fact that you and I _do_ still have shared experiences and interests. And that comes out in your posts here. It will, regardless.

Again, I'll stop here. I think we are talking at cross purposes and it won't help anything to beat an already dead horse.

Jon

Reply to
Jon Kirwan

No, that's the problem! I keep rephrasing *my* points and yours in an attempt to come up with something that I can "relate to" as an aid (to me) to understanding the distinction you're trying to make.

And, obviously, I keep missing the mark. :-/

[this was an excellent phrase -- I willhave to remember it!]

I'm assuming this, also, isn't the "differentiating factor" that you're using between embedded/desktop so I won't go into that, here...

[snip]

I'd really like to understand the point(s) you're making. If you can be patient with me, to that end, I'd like to continue this (in private). Watch your inbox (though I may not get to it today as I have a tree to cut down -- on someone else's property! :> )

[of course, if you're tired of it, feel free to click "delete" :> ]

Thx,

--don

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.