Jump to content
mityeltu

Port Encapsulation... Union? Struct?

Recommended Posts

I am trying to encapsulate 2 ports from 18F2620 into a single variable. What I want to be able to do is something like the following pseudocode

 

variable ex_port = porta:portb // 16 bits of 2 ports in a single variable

for (z = 0, z<16, z++)

ex_port.z = 1

next z

 

what I'm trying to do is to sequence through both ports as well as to be able to address each individual port pin wihtout having to first address the individual port. I hope that makes sense.

 

Is there some way to bundle the ports together like this?

 

Since boostc does not support bitfields, this becomes pretty large if I used a structure of bytes.

I hope I'm not just making this way harder than it needs to be. Is there an easy way?

Share this post


Link to post
Share on other sites

Hi

 

The problem is not to join the 2 ports under a single 16 bit variable as long as the 2 ports have concecutive addresses in RAM, , like exemplified by richardc.

 

The real problem is beeing able to scan all the bits in a loop.

The dot (.) operator when applied to bit access has a serious limitation, it doesn't acept a variable for the bit number.

So you can access all 16 bits (x.0 to x.15) but you can't use the loop index to do it, only compile time constants.

 

Best regards

Jorge

Edited by JorgeF

Share this post


Link to post
Share on other sites
On 17/02/2017 at 9:23 PM, JorgeF said:

The dot (.) operator when applied to bit access has a serious limitation, it doesn't acept a variable for the bit number.

Hi Jorge, 

That's probably because there is no corresponding instruction at the assembly instruction level, only 'bsf' or 'bcf' with a constant.

Share this post


Link to post
Share on other sites

Hi

 

44 minutes ago, jartim said:

Hi Jorge, 

That's probably because there is no corresponding instruction at the assembly instruction level, only 'bsf' or 'bcf' with a constant.

 

If code can be generated to compute indexing of arrays, struct fields, ponters and so on, for sure it can also generate code to access a given bit in a byte or word from a variable.

My guess is that a piece of generic code to do that would be heavy and ineficient, so they choose to leave it to the programmer, to write optimized code for each use case.

 

Just my 2 cents....

 

 

Best regards

Jorge

 

 

Share this post


Link to post
Share on other sites

What would be useful would be a construct like this -

    struct sMyPortStruct
    {
        volatile unsigned char BasePortA @0x05;
        volatile unsigned char BasePortC @0x07;
    } MyPortStruct;

    for (unsigned char c = 0; c!= 16; c++)
    {
        MyPortStruct.c = 1;
    }

Although the compiler quite happily accepts this syntax, it ignores the fixed addresses and assigns the structure members to consecutive registers in RAM instead, so this doesn't work.  Also it would need some additional code inserted by the compiler to make sure you're addressing the correct member port. I suspect this could be done in C++, but there's no way to overload the '.' operator (overloaded operators aren't supported :( ) 

Share this post


Link to post
Share on other sites

Hi

 

Your codding seems a bit odd, to say the least.

Assigning independent addresses to the fields of a struct is against the basic semanthics of a struct.

I suspect the compiler is simply ignoring it and a warning is missing, maybe some inactive (disabled) warning.

In terms of assigning fixed addresses to variables, what you can do is to assign an address to a variable of type struct (MyPortStruct) but the internal organization  of the struct is out of control.

 

If the 2 port addresses are consecutive, you can place a 2 byte variable (int) on top of them and access the individual bits of that variable, anyhow, the BoostC compiler will not accept a variable bit index like in your for loop (another thread).

 

My solution to access computed individual bit ports is to use the loop counter to generate a bitmask and use a bitwase operation.

 

 

Best regards

Jorge

 

 

 

 

Share this post


Link to post
Share on other sites

Hi Jorge

I agree, the coding looks a bit odd as it stands; it wasn't meant to be an example of how to do it, rather an example of a possible way the compiler could implement a solution.  The syntax looks strange, but it's not breaking any of the compiler's rules or the C++ language rules.  

Having two structure members at non-consecutive addresses is quite acceptable, in fact many C-compilers do just by adding padding bytes between members when the target processor requires each member to be aligned on 16 or 32-bit boundaries.  My suggestion just tries to force the alignment rather than assume that the compiler will do it (it probably won't).  

As for the compiler not accepting a variable as a bit index, you're correct, but as you said -

Quote

"If code can be generated to compute indexing of arrays, struct fields, ponters and so on, for sure it can also generate code to access a given bit in a byte or word from a variable."

so I cannot see any reason why the compiler could not be modified to do this.

 

Rgds

Tim

Share this post


Link to post
Share on other sites

Hi

 

On 04/10/2017 at 9:55 AM, jartim said:

Hi Jorge

I agree, the coding looks a bit odd as it stands; it wasn't meant to be an example of how to do it, rather an example of a possible way the compiler could implement a solution.  The syntax looks strange, but it's not breaking any of the compiler's rules or the C++ language rules.  

Having two structure members at non-consecutive addresses is quite acceptable, in fact many C-compilers do just by adding padding bytes between members when the target processor requires each member to be aligned on 16 or 32-bit boundaries.  My suggestion just tries to force the alignment rather than assume that the compiler will do it (it probably won't).  

As for the compiler not accepting a variable as a bit index, you're correct, but as you said -

so I cannot see any reason why the compiler could not be modified to do this.

 

Rgds

Tim

Yes I wrote that, but I also worte...

On 20/09/2017 at 2:39 PM, JorgeF said:

....

My guess is that a piece of generic code to do that would be heavy and ineficient, so they choose to leave it to the programmer, to write optimized code for each use case.

....

And this comes from my assembly programming experience.

When it comes to 8 bit PICs, I have a lot more finished products written in ASM than in 'C'.

Bit scanning needs often surface whenever you have an array of sensors, a keyboard or even LED arrays like in 7 segment displays.

On all those situations, no matter how many tricks i come up with, the individual bit access ends up being more costly (instruction cycles and program memory) than bit mask based operations.

So my experience showed me that it can be done but its not worth the effort.

I don't se this as an universal truth, simply an 8 bit PIC specific (hardware architecture and instruction set) conclusion.

Give me a different microcontroller and I would, probably, end up with a different conclusion.

 

I also have a large experience in high level programming on desktop systems (C, C++, VB, Java, ...) and I happily port algorithms and code design accross different hardware platforms and operating systems. But programming an 8 bit PIC is a totally different ball game, there is no hardware abstraction at all.

 

The ball game also changes deeply when moving from 8bit PICs to 16bit PICs or to 32bit PICs. The platforms are so different that even using "C" or "C++" one needs to adjust the algorithms, data structures and even the whole conceptual approach to program design.

 

Just my 2 cents....

 

Best regards

Jorge

Edited by JorgeF
Clean empty lines at the end / underline main conclusion

Share this post


Link to post
Share on other sites

Your content will need to be approved by a moderator

Guest
You are commenting as a guest. If you have an account, please sign in.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoticons maximum are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×