View previous topic :: View next topic |
Author |
Message |
albertsm
Joined: 09 Apr 2004 Posts: 5913 Location: Holland
|
Posted: Mon Feb 08, 2021 12:30 pm Post subject: |
|
|
send the code to support.
we can update this topic with the conclusion.
and i can also send you the code where it is more clear than as7.
and also show how you want to modify the lib. _________________ Mark |
|
Back to top |
|
|
SZTRAD
Joined: 30 Dec 2019 Posts: 165
|
Posted: Mon Feb 08, 2021 12:49 pm Post subject: |
|
|
Calmly. You have my mail.
I used AS7 purely for hex code level simulation. It's terrible software, but firstly I need with him work and secondly there's probably nothing better about avr. |
|
Back to top |
|
|
MWS
Joined: 22 Aug 2009 Posts: 2262
|
Posted: Mon Feb 08, 2021 12:53 pm Post subject: |
|
|
SZTRAD wrote: | Be very careful of the word nonsense. |
As well I'm mildly careful, I had enough from your fantastic nonsense.
Quote: | I approached your game, although I don't like it either. |
It means something to you to tantalize, I do not care, but I react thereon.
Quote: | I'm not going to convince you. |
I am not free of mistakes, but in this matter I know exactly what I do.
Quote: | Start the simulation. |
I do not have to, I see it from the source and so should you, here's part of my post from yesterday:
MWS wrote: | The config-/init-code is executed as soon config-settings are changed, for example by rb_selectchannel(), rb_changepin(). |
Now look into your code and sub DigLedTest1, which is called eleven times, there you'll find:
Now compare my quote above from yesterday with your words:
Quote: | Hmm and it will be executed 11 times. What can it be? |
Surprise, surprise, what can it be? Maybe it is the function I have already mentioned among the ones calling config/init? Oops.
It would be better to read your opponents posts.
And 'opponent' actually describes it right, as you're extremely eager to prove your false position.
For me it's an effort writing theses posts, the reason I do it anyway is because I always think there may be a last change to make you understand.
For you it seems to mean more, maybe to prove yourself being still at the height of programming?
I feel not aversion against you, you pity me as you're so one-track.
Quote: | This is because the compiler assumes that the contents of IRAMs and constants can be overwritten. |
IRam denotes processor registers, the controller could not work, if these are not rewritten, in case this is undesired, processor registers can be saved.
Constants however are named this way because they are constant an can not be overwritten.
The calls to the config/init-block you did experience, happen one and only because the creator of this lib decided it and not because the compiler wants it that way.
Open the report and you'll find variables BOW__CUR_PORT, BOW__CUR_PIN, BOW__CUR_SIZE and BOW__CUR_ADR.
Any rb_xxx-function which requires a write to any of these variables will trigger the call to the config/init block, which will write the channel settings of RB0_, RB1_, a.s.o.
Any rb_xxx-function with read access only to these vars, also calls the lib, but solely rely on SRam data.
Think about the config/init-block as a library function which accordingly sets the variables BOW_xyz from a preset of channels.
Two of the BOW_xyz-vars are pointers, also for each channel a led-array is created.
Are you aware, that you used the command RB_SelectChannel 0 incorrectly?
It needs to be called one time, calling it every time the sub is executed makes no sense, as you never change the channel.
The lib-code however does not differentiate between meaningful and senseless use, it simply does as it is told.
Did it not raise your attention whilst dreaming your mirage of how the controller or compiler behaves, that you only got 11 calls to config/init, in contrary to the expected 22 ones?
I remind you to your words:
SZTRAD wrote: | Therefore, it performs a data recovery before each lib call. |
In your code you have two calls to the lib:
Code: | RB_SelectChannel 0
RB_FILL color(1) |
Two calls to lib at each for/next and sub-call should have given you 22 stops and calls to config/init, schouldn't it?
If you think about, and if you are able to free yourself a bit from your stubborn way of thinking, then and only then your world may start to become a sphere, instead of the disk you're living on in the moment.
Quote: | This is how all compilers work by reloading the constants stored in the program. |
Compilers may restore from constants if required, but what does it have to do with your false assumptions?
Quote: | Therefore, it performs a data recovery before each lib call. |
No, absolutely sure: NO.
As said: check again for your missing 11 of the 22 calls.
Quote: | That would end it, I don't mean to convince you of something you think works differently. |
You don't have to convince me, as I know how this works, while you only believe to know. Big difference.
If in your case reality mismatches belief, the only harm you do is to yourself. |
|
Back to top |
|
|
MWS
Joined: 22 Aug 2009 Posts: 2262
|
Posted: Mon Feb 08, 2021 1:23 pm Post subject: |
|
|
SZTRAD wrote: | I hate it when someone makes me an ox |
In this case you must dislike yourself.
What you seem not to understand is: a library is a collection of helper-subroutines, which encapsulate lib-calls into commands like Config xyz, or Print, or whatever else.
There isn't such a thing as lib-entry, execute all routines, lib-exit.
Instead user code is served by lib-calls whenever it is required and only to lib-routines and subroutines as required.
Some lib-routines may work on SRam only, others use constants and flash for a re-config.
Your statement of 'every lib-call re-inits' is simply false.
And Mark tries to save you becoming a bigger ox.
It's not even me, who want you to look like one.
But if you tell nonsense, do you think I cheer to this nonsense only because if I do not, it makes an ox out of yourself?
Beside, we're only discussing about a side note, the main thing of transferring the port's high byte into the lib requires to alter user code in a pretty ugly way AND requires to alter the lib.
This makes - compared to the lib's conditional compilation block - not the slightest sense.
The only smooth option would be that BOW__CUR_PORT becomes a word-var, this would then require to alter the compiler and the lib.
And for what?
Ask Mark how much time it takes for such a nonsense request.
So the whole discussion is moot and imho based on the fact that you have too much time. |
|
Back to top |
|
|
SZTRAD
Joined: 30 Dec 2019 Posts: 165
|
Posted: Mon Feb 08, 2021 1:50 pm Post subject: |
|
|
Like I said, I'm not going to argue.
Oddly, this code is also used only 11 times
Code: |
000000BF CLR R31 Clear Register
000000C0 LDS R30,0x0105 Load direct from data space
000000C2 LDS R18,0x0106 Load direct from data space
000000C4 MOV R19,R18 Copy register
000000C5 COM R19 One's complement
000000C6 RET Subroutine return |
Another argument? |
|
Back to top |
|
|
MWS
Joined: 22 Aug 2009 Posts: 2262
|
Posted: Mon Feb 08, 2021 3:11 pm Post subject: |
|
|
SZTRAD wrote: | Another argument? |
You still want some ?
Which type of argument do you want?
You have to answer still a ton of my old ones.
The shown disassembly is the code for which the discussion started, it's the routine BOW_LOAD_PORT_PIN, this routine is called from 3 more routines of the lib:
Code: | RB_Send
RB_CLEARStripe
RB_FillStripe |
Without following the asm-code, I'd say it's called from:
as this function needs to know the current Port and Pin to bang out serial stripe data.
The conditional compilation preceding BOW_LOAD_PORT_PIN resulted in:
as you've compiled for a non-XT/XM.
That's the point where you want to have a LDI R31, 0x06 for XMEGA or LDI R31, 0x04 for XTINY.
There's where a MOV R31, R27 would be of your special desire, if R27 would not have been destroyed by long already.
R27 is already void immediately after config, I wrote this already
Together with:
Code: | 000000C0 LDS R30,0x0105 |
it forms the Z-pointer address for indirect access to PORTx by opcodes LD/ST
0x0105 holds the address of pointer low byte BOW__CUR_PORT.
As you compile for M328 the address loaded in R30 at this moment for PORTB is 0x25.
Together with R31 they build the pointer to address 0x0025, which is usable with LD/ST
This:
Code: | 000000C2 LDS R18,0x0106 |
loads the pin-number and 0x0106 is the address of byte var BOW__CUR_PIN.
In R18 the port-pin is stored, in R19 it's complement, used as a mask.
Another argument? |
|
Back to top |
|
|
albertsm
Joined: 09 Apr 2004 Posts: 5913 Location: Holland
|
Posted: Tue Feb 09, 2021 1:05 pm Post subject: |
|
|
Ok, i had a discussion about the mean time with SZTRAD.
Because we both communicate in a language which is not out native language there are always some small misunderstanding.
In this case i think it simple:
- the TS came with a problem and sample
- this sample uses RB_SELECTCHANNEL in a loop while that is not required.
that is why i added this to the help:
It is NOT required to use RB_SELECTCHANNEL when the channel remains the same. So use it once and only when the channel changes.
- then SZTRAD noticed that the compiler sets up the right value with CONFIG RAINBOW. And of course he thought it would be better to keep the library simple and use the value used at the configuration.
- the problem with this is that when RB_SELECTCHANNEL is used as it is supposed to, this value get lost with all code that uses pointer X.
- a solution is to use another byte or to rewrite the lib and/or to pass the port or to store the high port address. that is of course preferred. but it also means re-testing with all platforms. so besides a note to possible change this it remains as it is for now.
i close this topic. if you want to discuss this further, do so on the VARIOUS forum. _________________ Mark |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You cannot download files in this forum
|
|