Question about sbit definitions

Andrew,

I was planning to do that indirection only once on a vendor request and then after that the port address remains the same for the entire duration. Where as adding an IF condition would be checked almost every write to that port address.

Also writing to both the pins could cause some side affect as those port pins are mapped to a different pin in the FPGA on that condition.

I have atleast 5 different pins that need to change during the program execution and they all execute atleast 40,000 times during the intialization. Our application now takes about 5 sec to initialize and the customers are complaining already and after this IF condtion I am seeing it atleast 10 mins which is not acceptable.

Please throw some other alternatives? . Please...

Andrew,

I was planning to do that indirection only once on a vendor request and then after that the port address remains the same for the entire duration. Where as adding an IF condition would be checked almost every write to that port address.

Also writing to both the pins could cause some side affect as those port pins are mapped to a different pin in the FPGA on that condition.

I have atleast 5 different pins that need to change during the program execution and they all execute atleast 40,000 times during the intialization. Our application now takes about 5 sec to initialize and the customers are complaining already and after this IF condtion I am seeing it atleast 10 mins which is not acceptable.

Please throw some other alternatives? . Please...

Our application now takes about 5 sec to initialize and the customers are complaining already
Just stencil "Microsoft Windows" on the box and they will think it is fast :)

Please throw some other alternatives? . Please...
redo the hardware to change the pins (so that alternate pins are on same port and such), then you can do things like this:

instead of sbit p0.0 alternating with sbit p0.1 you can do P0 |= raplph; where ralph can be set to 1 or 2 for the alternation..

Erik

To dredge up an ancient forgotten evil: self-modifying code.

If you have von Neumann memory (that is, you can write to your program store), and know the address of the instruction that accesses the pin, you can overwrite the byte that contains the bit address so that the instruction fetches from different bits.

If you do such a thing, I'd recommend writing the fetching routine in assembly so that you can exactly control the instruction sequence. You'll also need giant screaming comments that the source you see is not the code that actually gets run, with a reference to place that changes it.

ah .... one other possibility

put the whole kit and kaboodle into a aubroutine using pin a. Then make a copy, rename it and change globally pin a to pin b. then it is a simple matter of

if (ralph)
{
funca();
}
else
{
funcb():
}

Erik

My funca() is huge and making a copy to create funcb() may not fit in the internal RAM as I think it has only 8K bytes of space.

RAM??? what are you talking about, in a '51 the code is in ROM/PROM?Flash.

Erik

If you mistyped and mean ROM, get a device with more, stepping up from e.g. 8k to 16 k will cost you only pennies.

Erik

"I was planning to do that indirection only once"

Eh??

If you use indirect addressing, then the indirection overhead happens every time you use the indirect address - even if the address is fixed at startup!

Remember - you originally said:
"I tried doing &JTAG_TDO = &ALT_JTAG_TDO and that raised a compiled error"

"Also writing to both the pins could cause some side affect as those port pins are mapped to a different pin in the FPGA on that condition."

Aha! So this is in an FGPA?!

Surely, then, it is a simple matter to provide a "hardware" gate in the FPGA that will switch between JTAG_TDO and ALT_JTAG_TDO?!

The address is fixed at startup and then based on a vendor request it is set to a new one and it will stay way for rest of the program life. After the indirection happens in the vendor request I wll then just use the JTAG_TDO to read and write values in a different function.

The driver (common) I am developing will be used by both the hardware that is shipped already to the customers and in our next generation hardware. So it is mandatory to handle this in software without asking for any changes in the hardware for backward compatibility reasons.

So it is mandatory to handle this in software without asking for any changes in the hardware for backward compatibility reasons.
yeah, yeah, have heard that one before - are you management?

1) you evidently must reprogram the uC, what hinders a reprogram of the FPGA.
2) whatever "is mandatory to handle" you cant' make the '51 grow new instructions.
3) you never answered "may not fit in the internal RAM" --- "RAM??? what are you talking about, in a '51 the code is in ROM/PROM?Flash."

Erik

Sorry, that was a typo'. It is Internal RAM and not ROM.

now you absolutotally lose me.

You post "RAM"
I ask "did you mean ROM"
You post "Sorry, that was a typo'. It is Internal RAM and not ROM."

To stop all confusion, please post
"My code is in ROM"
or
"My code is in RAM"

and a followup question
Is the uC socketed?

Erik

also, how about answering 1)

OOPS. My code is in ROM.

I dont understand your question

"Is the uC socketed?"