We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
xdata struct EEPROM {
unsigned int Last_Data; struct EEPROM *Node; };
struct EEPROM xdata * xdata p; p = (struct EEPROM xdata *)0x0FF6; if i will print the following statement printf("Size of p = %d",(unsigned int)sizeof(*p));
then it will shows the 5,but actually it should show the 4 bytes
Jay, We agree on almost all; the one area where we 'discuss' is about "a blanked satement" "use linked list" or "do not use linked list" is valid.
My contention is that in time critical applications and any REAL '51 app is, there is grave danger that someday in the future when the list grow you will have an 'unexpected" error. I can already hear "that will never happen" - famous last words. Why do I state "do not use linked list"? because the only valid use of a linked list is "sorted insert" and such as no place in the time critical device. It belongs at the final data (not event) processing device i.e. the PC at the end of the chain.
so, once more I have no problem, whatsoever, with linked lists on a microcontroller, but they have no place on a microprocessor. Of course, that assumes that this is not a case of misapplying a controller as a processor.
For your suggested use "more important records" I'd use a tag = no overhead.
Erik
But my previous example suggests that "sorted" could just mean divided into a few groups. For that same example, on a '51, I could create a linked list of a fixed maximum size (meaning we'll hold the last 1000 "events" or "data records" or whatever) that were generated. On each polling cycle, we can send a certain number of them and the master can go around round-robin requesting the list. If there are three "priority levels," then I just need to store the last element of each of the priority levels and I can insert into any of those points with no difference in time than tacking an item onto the end of the list. This is the sort of (admittedly contrived) application where linked lists really shine.
A tag does not have "no overhead." If you just tag each element with a priority, then when a request from the master comes in, you have to walk the list and first read out all the "highest priority" elements and continue doing that for each priority level until you've filled up a serial response. After that, since you probably still want to return items to the master in chronological order within their priorities, you'll need to go through and compact your array so that new items can be added at the end.
A method that would have no processing-time overhead would be to store a separate array for each priority level, but then you have to specify not only the maximum number of events that could occur in a given scan period(like the 1000 above), but rather then maximum of each type as well as the total.
Maybe you have access to the master node in which case you could design some smarter polling method, but maybe you don't.
We agree on almost all; the one area where we 'discuss' is about "a blanked satement" "use linked list" or "do not use linked list" is valid.
There, you are correct. I continue to believe that disallowing them for the '51 altogether is a bad idea, and I think it's a disservice to inexperienced people who read this forum to let them come away from this discussion with that impression.
-Jay
I agree that there may be some 'exotic' cases where a LL could be applied to the '51 even in a control app. That, however, should not be the first approach for the very reason that the "find the slot" is of indeterminate timing which is the bane of countless control apps.
I guess that I have not realized, till now, that my objection to LLs in a '51 app is due to just that. LLs are particularily bad in this respect since the user is 'responsible for' how indeterminate it is.
I agree that there may be some 'exotic' cases where a LL could be applied to the '51 even in a control app.
Thank you . . . that is all. :)