|
you're right, one can use asynchronous operations instead of threads. I tend to prefer threads as asynchronous operations seem more complex, but I do realize they can be a good choice, and have the advantage of saving on stack memory at the expense of some more code.
Also, when borrowing existing code in order to join a server and a client, I expect a thread-oriented approach would be easier to merge than an asynchronous one.
|
|
|
|
|
Luc Pattyn wrote: I expect a thread-oriented approach would be easier to merge than an asynchronous one.
It's just copy and paste. Here is a server/client example (last two code snippets), which you can join together in a single application. It wouldn't be very different with MFC's CAsyncSocket or QT's networking classes. I think the asynchronous networking model has is strengths with applications, where you want to focus on protocol an functionality and less on synchronisation and timing.
/M
|
|
|
|
|
yes, OK. Great link BTW.
|
|
|
|
|
As Luc says, why use sockets within a single application when you can just use a message queue, shared memory etc. However, since you are doing the implementation it is entirely your choice.
Just say 'NO' to evaluated arguments for diadic functions! Ash
|
|
|
|
|
thanks a lot. anyone has such example source code. can anyone send me here. only exchange the data. thanks a lot
|
|
|
|
|
zhiyuan16 wrote: anyone has such example source code. can anyone send me here.
What are your requirements? We know how you want to do it, but not what. Could you describe more detailed what it is you want to solve, for example if you have a practical application problem or experimenting with winsock, then it is much easier to recommend something.
|
|
|
|
|
i just want an example source code with 2 winsock can be run in one project. and can communicate each other.thanks
|
|
|
|
|
|
There are lots of sample winsock applications, both here on CodeProject and out where Google will find them. However there probably will not be many with both client and server code in the same app. As has been suggested more than once, you will need to take the code for both halves and put it together for your requirements.
Just say 'NO' to evaluated arguments for diadic functions! Ash
|
|
|
|
|
I have been using the following code to access individual bits of memory to use as bit fields for a white but I am not really sure how the heck it works. I now need some extended functionality and as I do not understand how it works I can not upgrade it myself.
struct bits {
uint8_t b0:1;
uint8_t b1:1;
uint8_t b2:1;
uint8_t b3:1;
uint8_t b4:1;
uint8_t b5:1;
uint8_t b6:1;
uint8_t b7:1;
} __attribute__((__packed__));
#define FMAN(ADDR,FLAG) ((*(volatile struct bits*)&ADDR).b##FLAG)
#define FIFO_EOF FMAN(0x20,1)
FIFO_EOF = 1;
expands to:
((*(volatile struct flags*)&_SFR_IO8(0x20)).b##1) = 1;
Theirs a few casts and pointers in their to make it confusing but Im going on an understanding that it is taking the value of the bits structure and applying the rusult to the memory location 0x20. I wish to upgrade this functionality by using c++ and some added structure so I could have a bitfeld access like below.
Memory location: 0x14000000
bitfield: RX0E, TX0E, RXB0E, TXB0E ..... etc
I would need to somehow initilize my custom bitfiled to the memory location easily so I can include it in my communications class. So in my code I would have the ability to set the entire bitfiled with one word or by individual bits.
COMMS->FLAGS = 0x90000000
COMMS->FLAGS->RX0E = 1;
if(COMMS->FLAGS->TXB0E)
Does that make since? I know its possible as all the source code I have poked around in for ARM based processors use this exact method but the implementations are closed source and I have never figured it out. I use GCC if you are wondering.
Anyone care to take a show at helping me figure out how it works and then how to get my desired results? Thanks!
|
|
|
|
|
a partial answer:
1.
FIFO_EOF = 1;
does not expand to:
((*(volatile struct flags*)&_SFR_IO8(0x20)).b##1) = 1;
it does expand to:
((*(volatile struct flags*)&_SFR_IO8(0x20)).b1) = 1;
as the ## operator inside macro's concatenates strings to yield new identifiers.
2.
you could have something like:
struct bits {
uint8_t RX0E:1;
uint8_t TX0E:1;
uint8_t RXB0E:1;
uint8_t TCB0R:1;
...
} __attribute__((__packed__));
but then of course there no longer is any b0, b1, ...
3.
you could have a union of both structs, then both ways of accessing bits are available.
|
|
|
|
|
Hi,
The C++ Standard Library provides various classes to deal with bit fields: std::bitset<size_t>[^] which is oriented to individual bit manipulation, and the specialized std::valarray<bool> and std::vector<bool>. You should consider using them instead of your C like constructs.
With all of them you can use placement new to allocate at a specific memory position.
cheers,
AR
When the wise (person) points at the moon the fool looks at the finger (Chinese proverb)
|
|
|
|
|
One cool thing about C++ is that you can keep doing hardware specific stuff in C style structures then add member functions to do the disgusting macro hackery and chicanery that you have to do to simplify your code. So for example if you've got a linear address for a 386 or later you can break it up in the same way as the processor does:
union linear_address_decoder
{
struct decoded
{
unsigned page_directory_entry_ : 10;
unsigned page_table_entry_ : 10;
unsigned offset_ : 10;
}
decoded_;
void *encoded_;
linear_address_decoder( void *p ) : encoded_( p ) {}
unsigned page_directory_entry() const
{
return decoded_.page_directory_entry_;
}
};
Anyway it sounds like you want to go the other way (assembling a value to be stored in memory) but the principle is the same:
- Declare a union of the bunch of bit fields you're interested in and a primitive type that fills the memory location you want to read/write it from
- Add a constructor that takes the component bits and sticks them in the bit fields
- Have a recovery function to write the assembled value somewhere in memory.
Hope that helps - if I'm not being clear drop us a line and I'll try and clarify things.
Cheers,
Ash
|
|
|
|
|
Thanks for the replies!
Luc: "you could have a union of both structs, then both ways of accessing bits are available" Could you give me an example of this union of two structures? I'm not sure how it would work as I would think each structure would have a different memory location.
Alain: "std::bitset<size_t>" I did not know of this capability. It is quite close to what I want and will be helpful while in visual studio but my GCC compiler does not have STL support only the standard set of c libraries. I'm going to take a look at how they implemented it and see if I can work with it but have not looked yet.
Aescleal: I have gone through some sites on placement specifically http://en.wikipedia.org/wiki/Placement_syntax[^] and It clearly states it does what I want and places something at a given memory location but nowhere in the examples do I see the new object being assigned to a specific location. Can you give me a breakdown on how you would place a 32bit value at memory location 0x14000000 using placement new?
Any other suggestions? I'm still poking code around unsuccessfully.
|
|
|
|
|
First off the code I presented had something similar to what Luc suggested. That works.
Placement new...
There is a problem using placement new with hardware and that's constructors. C++ objects are meant to be constructed in uninitialised memory. If you use placement new to overlay a particular memory location with an object the constructor will run and there's a chance the memory you're trying to overlay (i.e. interpret differently) will be modified. Over a set of device registers this might be interesting!
However the block of memory you're looking at has already been constructed - there's an object there it's just the compiler doens't know it. So instead of using placement new just cast the location to a pointer to the C++ representation of the raw memory.
A quick example would be something like the BIOS warmboot flag. You know where it is but it's been initialised when the computer boots. By the time any code you write gets control it's already been initialised. The warm_boot_control object is there, any program you write doesn't know what format it is.
So you declare a C++ class:
class warm_boot_flag
{
public:
void prepare_for_warm_boot();
void prepare_for_cold_boot();
private:
unsigned char flag_;
};
and you use it by:
warm_boot_flag *warm_boot_flag *warm_boot_flag_ptr( reinterpret_cast<warm_boot_flag *>( 0x472 ) );
and:
warm_boot_flag->prepare_for_warm_boot();
If, on the other hand, you were writing a BIOS and wanted to make sure the warmboot flag is set up properly, you could then use placement new as you'd want to make sure that the flag is constructed. You could use almost the same class:
class warm_boot_flag
{
public:
warm_boot_flag() { prepare_for_cold_boot(); }
void prepare_for_warm_boot();
void prepare_for_cold_boot();
private:
unsigned char flag_;
};
and you'd use it with placement new:
warm_boot_flag *warm_boot_pointer = new( (void *)(0x472) ) warm_boot_flag;
So in a nutshell if you're writing a component that requires initialising hardware, use placement new. If you're writing a component that's using a resource already set up use an old fashioned cast.
Cheers,
Ash
|
|
|
|
|
Thanks for that breakdown, no wonder I was having an issue with the first example Im still pretty bad when it comes to points to pointers and I get lost in whats data and whats an address.
So to access an already initialized piece of memory I use Type *Type *ptr(reinterpret_cast( location )); Creating a double pointer with the first layer being accessible to you but your changes flowing to the bottom layer in the cast? Hopefully thats right.
I have whipped up some code with the union structure (I forgot a unions members occupy the same memory location, duh so that was easy) I have tested it by using the code below and I can use printf to dump the flags and reg and it works perfectly. The problem with this is that I need to initialize every flag manually however the hardware address I am pointing to is all zeros by default so is it safe to ignore this??
#include <stdio.h>
typedef struct
{
unsigned RX0E:1;
unsigned TX0E:1;
unsigned RX1E:1;
unsigned TX1E:1;
unsigned RX2E:1;
unsigned TX2E:1;
unsigned EOFF:1;
unsigned FNEF:1;
} COMM;
typedef union
{
COMM flags;
unsigned reg;
} COMM_FR;
int main()
{
COMM_FR myflags = new( (void *)(0x1400000) ) COMM_FR;
myflags.flags.RX0E = 1;
myflags.reg = 0x2A;
return 0;
}
However when I change things around so the flags are initilized via a union constructor and make the flags a pointer it compiles without error but when run i get exception 6392.
#include <stdio.h>
typedef struct
{
unsigned RX0E:1;
unsigned TX0E:1;
unsigned RX1E:1;
unsigned TX1E:1;
unsigned RX2E:1;
unsigned TX2E:1;
unsigned EOFF:1;
unsigned FNEF:1;
} COMM;
typedef union
{
COMM *flags;
unsigned reg;
void COMM_FR()
{
flags->RX0E = 0;
flags->RX1E = 0;
flags->RX2E = 0;
flags->TX0E = 0;
flags->TX1E = 0;
flags->TX2E = 0;
flags->EOFF = 0;
flags->FNEF = 0;
reg = 0x00;
};
} COMM_FR;
int main()
{
COMM_FR *myflags = new( (void *)(0x1400000) ) COMM_FR;
myflags->flags->RX0E = 1;
myflags->reg = 0x2A;
return 0;
}
I would prefer to use the second example as the rest of my handling is done via -> and with a compiler that does not support auto-complete having combinations of -> and . member access is infuriating.
|
|
|
|
|
Ouch. Neither of your examples are going to work.
The first one won't because of this line...
COMM_FR myflags = new( (void *)(0x1400000) ) COMM_FR;
What this line says is: "Initialise an object of type COMM_FR at the specified location in memory. Create a completely new object of type COMM_FR and initialise it from the object you've just created."
You can see this by taking the address of COMM_FR - it's almost certainly not going to be 0x1400000.
The second won't work Flags is never going to be a pointer. It's a physical lump of memory, not the address of the memory. Here's how I'd have a go at writing the same sort of thing:
struct COMM
{
unsigned RX0E:1;
unsigned TX0E:1;
unsigned RX1E:1;
unsigned TX1E:1;
unsigned RX2E:1;
unsigned TX2E:1;
unsigned EOFF:1;
unsigned FNEF:1;
};
Quick note here: You don't need typedef so much in C++. Generally it's only used to simplify complex types.
union COMM_FR
{
COMM flags;
unsigned reg;
COMM_FR() : reg( 0x00 ) {}
};
You only need to initialise one "view" of the union in it's constructor. Constructors don't have a return type, even void. The comment about typedef applies as before.
Now you've got two ways of setting up access to your device... The first way is if you want to zero the register when you first use it - you have to invoke the constructor:
int main()
{
COMM_FR *myflags = new( (void *)(0x1400000) ) COMM_FR;
myflags->flags.RXOE = 1;
std::cout << std::hex << myflags->reg << std::endl;
}
The placement new invokes the constructor so the register will be written to implicitly before the line setting RXOE.
The second way is if something else has initialised the hardware and you're just using it:
int main()
{
COMM_FR *myflags = reinterpret_cast<COMM_FR *>( (void *)0x1400000 );
myflags->flags.RXOE = 1;
std::cout << std::hex << myflags->reg << std::endl;
}
This one doesn't execute the constructor at all, so the final result depends on what state the register is in before you set RXOE.
PS: Just noticed that Luc makes a good point about volatile. Make sure that anything that touches the bare metal is volatile or your cunning compiler will have a good go at eliminating writes if it doesn't change the visible effects of your program.
|
|
|
|
|
Well that works wonderfully!
I tried bother versions and can access the memory locations just as I wanted. Thanks!
I would really love it if I could access the flag names via a -> though to keep everything the same. I have written plugins for engines before that took several compiles because of variables setup like: Engine->PIO.LPT1->Data.D0 = 1; and when the implementation is hidden from the end uses how the heck are they suppose to know when to use a pointer or the . member of addressing?
|
|
|
|
|
union {
struct bits {
uint8_t b0:1;
uint8_t b1:1;
uint8_t b2:1;
uint8_t b3:1;
}
struct theSameBits {
uint8_t RX0E:1;
uint8_t TX0E:1;
uint8_t RXB0E:1;
uint8_t TXB0E:1;
}
}
would put both sets of bits at the same memory address, after all that is what unions are about.
Read the language specification!
BTW: you "answering" like that, to yourself, causes no signal being sent to whomever you want to read it, only a proper "reply" (not to your own message, hence the warning you've got) would send a mail notification.
|
|
|
|
|
Thanks for the info on the board, I didn't even know I replied to myself.
I only use union every few months and every time I need to google them over again as I forget what they do. I got it working in my latest post so I can access the bit field as a solid byte which is pretty easy when you rtfm lol.
Any ideas on why I am getting runtime errors but not compile time errors on my latest attempt using pointers?
|
|
|
|
|
I'm not following all the details in your thread.
I have two pieces of warning though about code snippets such as:
flags->RX0E = 0;
flags->RX1E = 0;
flags->RX2E = 0;
1.
if the object pointed to isn't marked volatile, the resulting code might not access the register at all until later. (read up on volatile if you're not familiar with it).
2.
assuming volatile got applied, three stores using "flags" would cause either:
- three times a read and a write to the register (read entire byte, adjust one bit, store new byte value);
- three bit operation instructions which some micro-controllers would object to for special registers; I don't know what your target is, nor whether Intel likes them or not.
Whatever is the case, it may turn out not to do what you want it to do.
My advice is:
- read the manual, about what is allowed/defined and what is forbidden/undefined;
- check the assembly instructions your source code results in.
- when those two don't match, adjust your source code.
In general, I tend to use a union with on the one hand the full register, on the other hand the individual bits or bitfields.
|
|
|
|
|
I will remember to mark things as volatile, I have had problems with them in the past when the compiler has optimized a register check right away and boy can they be hard to find sometimes.
I am aware that any change to the bits will require re-writing the whole byte but the processor is geared to handle full register writes in once cycle so I'm not worried. The main reason I am trying to get this set up is to allow a more natural peripheral configuration scheme as currently if you don't have the 1072page manual and the nemonics memorized you will never get anything to work. I wish to re-write things for easier access and properly document the usage.
|
|
|
|
|
I've seen all kinds of peripheral chips; for some, writing a bit causes something to happen, even when the value doesn't change. Others had bits with different semantics on read and write (e.g. on write the bit is an "interrupt enable", while on read it is an "interrupt received"), so you just can't simply write back what you have read before (which is what your flags->b3=0; might do to all 7 bits you think you are not touching).
|
|
|
|
|
True, I know on AVR's you write a 1 to the bit to clear an interrupt and if I read the register before the ISR is called that would be a problem. This could get quite difficult now...
How the heck to the people who write the header files for chips do these things then? For example here is some bus handling setup from an ARM:
RCC->APB1RSTR = 0x00000000;
RCC->APB2RSTR = 0x00000000;
RCC->AHBENR = 0x00000014;
RCC->APB2ENR = 0x00000000;
RCC->APB1ENR = 0x00000000;
RCC->CR |= 0x00000001;
RCC->CFGR &= 0xF8FF0000;
RCC->CR &= 0xFEF6FFFF;
RCC->CR &= 0xFFFBFFFF;
RCC->CFGR &= 0xFF80FFFF;
RCC->CIR = 0x00000000;
They must have a different implementation of how these registers get written as the RCC->CR |= 0x00000001; will cause errors like you say if any bit besides the first one is set. This would be alot easier if their was open source code to walk through and see exactly how changes effect the system.
My goal is to make these register assignments much easier to use. Instead of writing a 32bit value to the entire register or even ORing the bit you want changed in it would be better to have bit level access with the names available to make the code more readable.
For example if you want to enable the clock to timer1 you would write:
<br />
RCC->APB2ENR = 0x00000800<br />
but I want to add access like:
<br />
RCC->APB2ENR->TIM1EN = true;<br />
or better yet:
<br />
HW->Reset_Clock_Control->APB2_Bus_Enables->Timer_1 = true;<br />
I like the functionality in Eclipse IDE that shows the documentation of the thing you have intelisense popping up for you so when you type HW-> you given not only a list of available hardware settings but a description of them. My compiler does not do this but I can at least include documentation in the header and provide an open source file so people know what they heck is going on. as a 1072 page manual is annoying and if you search adobe usually freezes for a few minuets first.
|
|
|
|
|
1.
one can write a header file that contains:
- register addresses (relative to some base address);
- bit numbers, bit masks, bitfield masks
- structs, unions, typedefs
these are pretty much independent of the actual compiler.
2.
you can write executable code that manipulates the registers, based on such header files, AND on some assumptions about the compiler and micro-processor. Most often a vendor offers a free development environment (IDE, compiler, ...), header files and executable code, all working together. There is no guarantee that source code files (other than header files) will work well on another compiler, let alone another micro-processor + compiler combination.
3.
if you're lucky, the peripherals won't have nasty characteristics like the ones I described. Older ones typically do, as they tried to cram all functionality in a small number of (narrow) registers. Newer devices tend to have more registers, wider registers, and several unused bits, alleviating the need for design tricks.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
![Java | [Coffee]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/coffee.gif)
