Yup. There is also the case of people starting off with this sort of assumption -- then *forgetting* it. Or, forgetting to reevaluate the consequences. Then, wondering why they are "suddenly" seeing bizarre system behaviors that "don't make sense" from an examination of the code...
Exactly. *Not* just picking up some "component" and dropping it in place because it *looks* like it SHOULD do the job.
Note that this sort of stack only needs to have *predictable* behavior in those environments. That doesn't mean that it has to "work" there. E.g., my network speakers have really slim stacks (i.e., big chunks omitted to get them down into a tiny resource footprint) but they will survive "exposed" without "crashing" or being exploitable. Put them in a more benign environment and they will easily outperform a "full" stack. They "work" in each case. But, "work better" in the environment for which they were designed.
Unfortunately, I think many aren't really aware/qualified to understand what can go wrong "on the wire" and "in the stack". This is a consequence of "black box" *thinking* (i.e., "I don't need to understand how it works, just how to *use* it...")
Everyone (?) knows that a second order equation will yield up its roots with:
[sorry, sticking to ASCII makes this harder to visualize than it should be :> Hopefully I didn't munge the parens! Or, the *signs*!!]
However, *blindly* applying the quadratic formula (in a computing environment) will, eventually, lead you astray with certain "types" of curves. E.g., understanding this leads to a more appropriate use of:
as fitting to the curve in question. The difference, of course, is *understanding* the solution instead of just blindly *applying* it! (a tiny bit more work but a far more "accurate" result!)
Is this any good AAMOI ? Has anyone here used it for real and can tell me how stable and usable it is ?
Also, I am thinking of using the Olimex ARM-USB-TINY-H for ST ARM Cortex M3 device development, has anyone any experience with this setup ?
Are there any ARM Cortex M3 forums that are well frequented and not specific to any particular manufacturer ? I like c.a.e. but it's a bit low-volume atm and I wonder if there is anywhere out there where all the big kn0bs hang out in ARM terms ?
Connected TVs, "smart" phones, decoder set-top boxes, routers, etc have *WAY* more RAM than that; typically /hundreds/ of megabytes, up to 1 gigabyte (!) for the Galaxy S3. RAM prices have reached an all-time low, at 4-8 euros per GB.
Phones and STBs can easily be upgraded in the field (TVs too, but consumers may not feel comfortable doing it).
And DoS, and spoofing, and hijacking.
FTR, lwip can be configured that way too.
You sound like someone who enjoys reinventing the wheel again and again (and again). In my opinion, the main strength of open-source software is to free developers from /continuously/ solving the same problems (what a waste of human brain-power).
How many GB are you going to put in your refrigerator? Freezer? Washing machine? Dryer? Bluetooth earpiece? Household thermostat? Irrigation system? Furnace? Range/stove? Telephone? Multimedia system remote control? Toaster?
Where do you think all those IPv6 addresses are GOING??? Do you really think consumers will be excited about the UNNECESSARY ADDED COSTS of "megabytes" of RAM just so their microwave oven can "know" the right defrost cycle for a 12 pound turkey? Or, so their washing machine can inform them when the wash cycle is complete??
We've already seen how wonderfully unsolicited updates work! You've never encountered a problem where your machine "broke" after a SOLICITED update? "Gee, Bob, the TV was working yesterday! Honest, I didn't *touch* it! And don't go blaming the kids for this, either!!"
It doesn't have to continue to heat the house when under attack. Or prevent the items in the freezer from thawing (because it was commanded to raise the temperature setpoint to 10C). Or ensure that the plants in the yard keep getting watered despite any "schedule/weather updates" from external services ("Gee, is it Summer out there? Should I be watering more often? Or, less? I sure wish I knew... but, someone is pinging the hell out of my interface and I can't seem to get any useful information...")
Look at *where* the filtering happens. If you harvest a packet, you have incurred cost. If you can discard it *in* the driver, you haven't.
I believe in coming up with the right solution for the problem.
Do you use long longs for all your "numbers"? Heck, you can represent 1, 35099, 68736, 5003876555, etc. ALL as long longs! Why bother with byte_t's, shorts, ints, longs and long longs when you could just use long longs for ALL of them!!! Why REINVENT all the arithmetic operations for each of these different data type sizes?!
Hmmm... we'll have problems with floating point values, though. OK, so we;ll use long *doubles* for all out numeric needs! Why bother with integer data types, floats, doubles *and* long doubles if we can just handle them all with long doubles?! Why REINVENT all the math LIBRARIES to support each of these types? Why burden printf with having to know which size argument it is dealing with? "Numbers are numbers", right?
Of cource, we also haev to worry about numbers that can't be accurately expressed in those representations. So, maybe we should adopt the use of a *rational* data type. I.e., typedef struct { long double numerator; long double denominator; } rational_t; And, of course, that won't handle complex numbers so we need a complex_rational_t as well...
Look at all the REINVENTING that we've been able to AVOID! After all, memory is cheap! Put a few GB in your toaster so you can implement: turn_on_heating_element(); sleep( (rational) (5.0L, 1.0L) ); turn_off_heating_element(); eject_toast(); beep(); with those nice CONSISTENT numeric types! :>
Do you have ONE sort() routine in your toolbox? Heck, sort is sort is sort. Why REINVENT such a trivial facility? Just throw more CPU cycles/memory at "whatever" algorithm you settle on and live with that! Of course, you will have to make sure your sort() is completely parameterized so you can sort arbitrary objects -- not just "numbers" (which we have already decided will be complex_rational_t's) or "strings" (which should all be of variable length -- do we do LR alpha sorts? What if we're sorting some numerical strings? Do we add a SWITCH to sort right justified??) Look at how much we'll *save* by not reinventing specialized sort()'s! :>
And, we surely don't need gets(), fgets(), getchar(), fgetc(), getc(), UNgetc(), scanf(), sscanf(), fscanf(), etc. Let's just settle on *one* so we don't REINVENT any of the same (and incompatible) mechanisms.
Nor, different window managers, operating systems, "computers", mice, etc. Choice is bad. One size fits ALL! Need a pocket calculator? Carry a laptop! Need a pencil and pad of paper? Put your desk on wheels!! :-/
We'll take a VOTE next Tuesday and rid ourselves of all this UNNECESSARY duplication!
People often mistake *code* reuse with *design* reuse. The thought that cobbling some existing (hopefully *working*) code into a new project somehow cuts a corner. Sure! If you are making essentially the same *thing* as that for which the code was originally created! (is your washing machine essentially the same as your STB?? Or your furnace? Granted, they each might have a network connection -- but, are their roles and needs *that* similar that they would benefit from the same network stack as that used in your PC??? REGARDLESS OF IT'S SOFTWARE COST??)
The real gains are in reusing *designs*, not *code*. Approaching similar problems in similar ways.
Reusing *code* assumes the code works, you *understand* it sufficiently to *know* that it addresses your problem domain adequately and that you will be able to *maintain* it (what good is developing a product "overnight" if you have to answer the first customer complaint with, "Gee, I'll post a message on the forum and hope someone
*there* can tell me what's going wrong..."). This is how product counterfeiters often falter -- when something goes wrong, they haven't the knowledge of how to *fix* it (because they've COPIED instead of ENGINEERED).
[It's also a great way to *thwart* counterfeiters by designing your product to "break" if subtly altered!]
Reinventing for the sake of reinventing is a non-starter. Blindly *reusing* is even worse!
I am are working with the coocox IDE and found it pretty good and reliable. Our project is an autopilot system for RC models. After a year of development it's in production.
While there are other compatible interfaces, colinkex is the safe bet for the coocox IDE. I had some trouble with others, worked with a version and failed with the next edition.
--------------------------------------- Posted through
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.