Rainbow INstruction difficulty on the XTiny 402

SZTRAD · Joined: 30 Dec 2019 Posts: 165

Mark
wouldn't it be better to use the R27 register if you already have the argument there and leave the decision to the main program according to the set processor?
Wouldn't it be possible to write it like this?
Original

MWS · Joined: 22 Aug 2009 Posts: 2262

SZTRAD · Joined: 30 Dec 2019 Posts: 165

Try it for all rows of processors and you will see that it will work. I understand why the driver is written as it is. I'm just saying how to do it automatically.
This is nothing against the original solver of the controller. I am based on the operation of config rainbow settings and its writing in flash memory.

MWS · Joined: 22 Aug 2009 Posts: 2262

SZTRAD · Joined: 30 Dec 2019 Posts: 165

When translating, Mark stores the upper part of the address in the R27 register (note the last line). According to the simulator, the config routine is called before each entry into the library, so formally there is nothing to stop you from using it. Or am I wrong? I'm an old man and I can knit.

albertsm · Joined: 09 Apr 2004 Posts: 5921 Location: Holland

I did not wrote the original lib, it was made my Galahat from the German bascom forum.
I did however made a variant based on his work which is integrated with bascom.
I also added a variant for the rgb leds with an additional white led.

I understand what you mean : when the code is called, the registers can be set. But it saves code to do it this way.
And like MWS mentioned : when this lib was there there was no support for xmega and xtiny did not even exist.
So xmega was added with a directive.
I understand your point. when checking mega X/DA/DB i will check if the ports have yet another offset. And see if it makes sense.
Also some normal AVR ports have high IO address and there the code will fail too. So it makes sense to move that part of the code from the lib to the caller code in the compiler.

SZTRAD · Joined: 30 Dec 2019 Posts: 165

OK
The new series currently uses addresses identical to xtiny
RS

albertsm · Joined: 09 Apr 2004 Posts: 5921 Location: Holland

In the caller code rb init procedure XH is set. But this register is later used and trashed so it can not be used.
And this init code is only done once.
of course there are many alternatives. like using an extra byte to store this info. but that would take more flash.
and sram could be used to store such info but that is a waste of memory imo.
i had a look but i think the effort required is not worth it. after all it takes new testing for all platforms with hardware. the only benefit would be to support ports of normal avr on an extended address.

when using 1 port it would be simpler but some use multiple ports with multiple pins. i have seen projects with many leds. btw the channels were increased to 16. i see the help did not reflect this.

MWS · Joined: 22 Aug 2009 Posts: 2262

A bit more universal port addressing.
Already some EQUs in the lib, let these follow:

MWS · Joined: 22 Aug 2009 Posts: 2262

SZTRAD · Joined: 30 Dec 2019 Posts: 165

MWS do you really think I don't know this?
Thank you for the MWS alert, but Mark's compiler works as it should. This means that it performs initialization again before each call to lib because it works with RAM.
If I hadn't tried it, I wouldn't have asked.
I asked I got an answer. I don't like when something has to change in libraries. It is terribly bad to look for mistakes when the interviewer has a different library than me.
For Mark.
you don't have to change anything, the information is already stored in flash memory.
That listing is made from the real contents of the memory using a paper compiler.
As I wrote above, I have already received an answer.

MWS · Joined: 22 Aug 2009 Posts: 2262

SZTRAD · Joined: 30 Dec 2019 Posts: 165

You use sharp words. Be very careful of the word nonsense.
I approached your game, although I don't like it either. Once decided, one does not intend to accept another person's opinion (based on trial). You're wrong, but I'm not going to convince you.
I'll take the original JC software. I'll use a modified library from Mark.
Load the resulting .hex code into AtmelStudio 7. Start the simulation.
According to you, the loading block should be executed 1. Hmm and it will be executed 11 times. What can it be? This is because the compiler assumes that the contents of IRAMs and constants can be overwritten. Therefore, it performs a data recovery before each lib call. This is how all compilers work by reloading the constants stored in the program. And it's the right function.
I tried again. That would end it, I don't mean to convince you of something you think works differently.

albertsm · Joined: 09 Apr 2004 Posts: 5921 Location: Holland

I am a bit confused about the whole discussion.
But here are the facts :
- BOW_LOAD_PORT_PIN is called from RB_SEND, RB_CLEARStripe,RB_FILLStripe
- BOW_LOAD_PORT_PIN need to set the Z pointer to the port address.
- the compiler does not store word address for the port but a single byte. that because the code originated from the normal AVR decade with ports on a normal IO address
- this makes it required to set the MSB of the port address to the right value. which was always 0. But for xmega it is 6 and xtiny it is 4.
- as part of the config rainbow there is a table created with the port and pin info. it also contains code to set the used ports to the right state. and it contains code RB_PININIT which is called from RB_Change_pin. this code also takes into account the platform thus loads R27 with the proper value.

now we could store this R27 into an additional byte from SRAM. and use that in BOW_LOAD_PIN.
But the conditional code that sets the port with LDI works equal well and does not take sram.

The X register is trashed by many code. so we can not rely on that.
IMO the only way to do it is to use sram. either i do not understand the original problem, discussion, or ?
But when someone see a possibility to make it simpler and to move the code out of the lib without using sram, let me know with a sample.
I must admit that it is long time ago i worked on this lib and i might overlook something.

the code should however work with code like this :
do
rbsend
waitms 100
r26=0 'simulate other user code that destroy X pointer
r27=0
loop

SZTRAD · Joined: 30 Dec 2019 Posts: 165

Mark
I understand your attitude and your words. Can I post all the decompiled code here and show you what's going on? I don't like doing this, this doesn't belong in the discussion. The method of translation is your property and the layout of the resulting code is too.
I hate it when someone makes me an ox
You refresh the loading of constants before each entry into the library code. For atmega you negate the MSB port in R27, for xmega you save in R27 06h, for xtinny analogously 04h.
I asked if you could use anything more. I take the argument that you still have a problem for the above reasons. Nothing against it. But it is a simple fact that the part of the codes I gave in the previous post is always run. Coincidentally, R27 is not used in the library, but port constants are only called once in the library. It was an idea after examining the resulting code, and I see no reason for the invectives.