At this time when the two of you are active here, can I get an answer to the following which I have sougtht an answer to for some time both through support and this forum. Is there - or will there be - a means of allowing a struct to cross a 64k boundary. The code generated by the compiler does 16 bit math so members in the second page are erroneously accessed. This is for address calculation, not actual access since my system has a "flash page" port and a "read flash" function that set that port. Note" I am NOT talking of "placing in any 64k page", I AM talking about accessing a member of a struct that happen to be in the following 64k page. PLEASE no words about banks, I am not using it since 99.99% of the run time my program is happy in 64k code and data. Erik
I think we have this answer already on: http://www.keil.com/support/docs/2800.htm It should work this way also on the classic 8051. In case that I am wrong, just provide your programming example. Reinhard
In case that I am wrong, just provide your programming example. I will try it when time permits (other thigs are sizzling right now) and come back with a programming example if it does not work. Thanx, Erik
You may define objects in assembly language (using HDATA or HCONST segments). I want to stick to the small model because the project is barely fast enough with a Silabs f122 at 100MHz when processing the 99.99% of the time stuff. Thus I can not handle any added overhead for this part of the code. How do I combine processing SRAM and code at full blast and then accessing HDATA once in a while. Erik
Banking has zero overhead when you don't explicitly invoke it. Only the pointers declared "far" (or generic that happen to be far) are going to cause the libraries to poke the bank registers. Memory space-specific pointers will continue to work as they do when the banking checkbox in uVision is off. Far access to your mass storage won't significantly impact the size or speed of the rest of the code if coded properly. Take a look in XBANKING.A51. The code is pretty straightforward. There are some special-case tweaks you could make to run faster -- setting the bank register once for a block of accesses, for example -- but it's reasonably efficient. Or perhaps you might consider something with a little more horsepower. 8051s aren't the best solution for all problems, particularly when your problems involve processing speed and shuffling large amounts of data.
Drew, I DO NOT WANT BANKING, do I need to make it clearer!!!! OK, I DO NOT WANT BANKING I DO NOT NEED BANKING, do I need to make it clearer!!!! OK, I DO NOT NEED BANKING THIS IS NOT ABOUT BANKING, do I need to make it clearer!!!! OK, THIS IS NOT ABOUT BANKING How do you, with banking, have a struct that start in one bank and end in another, That is PAGING, NOT BANKING. The overhead I refer to is the (possible) overhead if I need to use the HUGE model or any such in order to access HDATA or will the calculations of offsets then, in all cases, be more than 16 bit. Or perhaps you might consider something with a little more horsepower. 8051s aren't the best solution for all problems, particularly when your problems involve processing speed and shuffling large amounts of data. I agree totally; however, in this unique case a lot of legacy code must be used for TTM reasons. I am, however, a little bit considering to make the next with a LPC2xxx when this generation is out the door and the time to market pressure is gone. The reason for this thread is that I will need to make the PC people that make the input data file (which is a memory image of a bunch of structs) jump through hoops (they claim) if no struct can cross a 64k boundary. Struct size is not a problem, none will be even close to 64k in size. Erik
/////////////////////////////////////////////////////////////////////////// // // EXAMPLE.C // // try HDATA // typedef struct { unsigned char SGaddr1 ; // 485 address of first sign this type unsigned char SGaddr2 ; // 485 address of 2nd sign this type unsigned char SGaddr3 ; // 485 address of 3rd sign this type unsigned char SGaddr4 ; // 485 address of 4th sign this type unsigned char SGfPage ; // flash page for data unsigned short SGfAddr ; // flash addr for data } ACTIVE_SIGNS; extern ACTIVE_SIGNS hdata from_here; extern ACTIVE_SIGNS xdata to_here; void TryIt(void) { to_here.SGaddr4 = from_here.SGaddr4; }
"what's wrong" If you think that 'hdata' is a keyword then that would be what is wrong. I can't tell you what would be right, unfortunately, but I suspect it may have something to do with 'far' and 'HDATA segments'.
I got hdata from the appnote Reinhard referred to Erik
View all questions in Keil forum