Jump to content

Unions: Porting Microchip Cdc To Sourceboost


Recommended Posts

Hi,

I'm trying to get a Sourceboost version of the Microchip CDC RS232 emulator going. Trying a couple of ways, this question is on porting the CDC source tree to Sourceboost.

 

In the various typedefs used by the Microchip code, there are unions defined similiar to this:

typedef union _CTRL_TRF_SETUP

{

/** Array for indirect addressing ****************************************/

struct

{

byte _byte[EP0_BUFF_SIZE];

};

 

/** Standard Device Requests *********************************************/

struct

{

byte bmRequestType;

byte bRequest;

word wValue;

word wIndex;

word wLength;

};

///and many more

Where different parts of the code will refer to the same piece of memory as either the array ._byte[] or .bmRequestType and so on. In memory bmRequestType would be the same as _byte[0].

 

This isn't quite what Sourceboost is expecting. It requires a name to the structure:

For example from usbdefs_ep0_buff.h

typedef union _CTRL_TRF_SETUP

{

/** Array for indirect addressing ****************************************/

struct

{

byte _byte[EP0_BUFF_SIZE];

} b;

 

/** Standard Device Requests *********************************************/

struct

{

byte bmRequestType;

byte bRequest;

word wValue;

word wIndex;

word wLength;

} request;

...etc

So an access to a variable of _CTRL_TRF_SETUP would be

avariable.b._byte[0] == avariable.request.bmRequestType

Source code will have to be modified to add the extra reference to the structure of the union you are referring to. I realise this is 'proper C' from K&R.

 

I can live with this...but it is a bit tedious. Is there no way to have sourceboost use the union without the reference??

 

Another question is on the bit fields eg (another part of the union above):

struct

{

unsigned Recipient:5; //Device,Interface,Endpoint,Other

unsigned RequestType:2; //Standard,Class,Vendor,Reserved

unsigned DataDir:1; //Host-to-device,Device-to-host

unsigned :8;

byte bFeature; //DEVICE_REMOTE_WAKEUP,ENDPOINT_HALT

unsigned :8;

unsigned :8;

unsigned :8;

unsigned :8;

unsigned :8;

} endpoint; //I've added the endpoint union structure reference here.

Now the unused or 'blank' definitions can easily be dealt with as

struct

{

unsigned Recipient:5; //Device,Interface,Endpoint,Other

unsigned RequestType:2; //Standard,Class,Vendor,Reserved

unsigned DataDir:1; //Host-to-device,Device-to-host

unsigned char n0;

byte bFeature; //DEVICE_REMOTE_WAKEUP,ENDPOINT_HALT

unsigned char n1;

unsigned char n2;

...... and so on

How to handle the bit fields? Will instances of code using these bit field references have to be re-written to use a whole unsigned char:

eg:

 

aVariable.Recipient = 0x03; //as it would have been called in PICC18

or aVariable.endpoint.Recipient = 0x03; //with union reference

be written with a declaration and all code instances as below:

struct

{

unsigned char RecipTypeDir; //combining all above bit fields

 

unsigned char n0;

byte bFeature; //DEVICE_REMOTE_WAKEUP,ENDPOINT_HALT

unsigned char n1;

....and the rest

} endpoint;

 

aVariable.ReciptTypeDir = (aVariable.ReciptTypeDir & 0x07) | (0x03<<3)

//mask old bits, and assign new ones

 

yuk.....any better ideas? Any handy macros or methods to catch and deal with lots of instances of these, or will I be doing a line by line port?

 

Phil

PS: I might have got my bits around the wrong way in the last example....but you get the drift.

Link to post
Share on other sites

Hi Phil,

 

I found the same problem with BoostC not catering for anonymous unions and structures. I have modified and compiled the Microchip sources for use with BoostC and the SourceBoost IDE. There is possibly a compiler bug too, I will see if I can produce a failing example for Dave or Pavel, it is connected with the byte and word typedefs and the BYTE and WORD unions / structures.

 

I have also sorted the bit field test and modifications where needed.

 

If you wish me to e-mail / pass you a copy of the modified sources, please let me know. I think I may be able to do so via the forum's personal message system? It may save you a monster of an edit!

 

Regards,

G

Link to post
Share on other sites
...I found the same problem with BoostC not catering for anonymous unions and structures...

 

BoostC doesn't support bit fields. It did not handle anonymous unions and structures but this problem has been fixed a few releases back. If this feature still doesn't work for you can you send us a simple project that demonstrates the problem. If there is one we'll try to fix it by the next release.

 

Regards,

Pavel

Link to post
Share on other sites
...I found the same problem with BoostC not catering for anonymous unions and structures...

 

BoostC doesn't support bit fields. It did not handle anonymous unions and structures but this problem has been fixed a few releases back. If this feature still doesn't work for you can you send us a simple project that demonstrates the problem. If there is one we'll try to fix it by the next release.

 

Regards,

Pavel

I will retry with a small example and post the code if I find problems.

 

Regards,

G

Link to post
Share on other sites
If you wish me to e-mail / pass you a copy of the modified sources, please let me know. I think I may be able to do so via the forum's personal message system?  It may save you a monster of an edit!

 

I looked at porting this code to source boost a few months ago. However after reading the terms and conditions of the Microchip licence agreement and pursuing it with Microchip I came to the conclusion it was not viable to do this to be able to share code with other forum members. Any attempt to share code with other team members in a usable way would be in violation of the Microchip licence agreement.

Link to post
Share on other sites

>I looked at porting this code to source boost a few months ago. However after reading >the terms and conditions of the Microchip licence agreement and pursuing it with >Microchip I came to the conclusion it was not viable to do this to be able to share code >with other forum members. Any attempt to share code with other team members in a >usable way would be in violation of the Microchip licence agreement.

 

Oh dear....well just a quick status report, we've made a lot of progress. Geoff has done an astounding job at getting the codebase to compile, sorting out issues like anonymous unions and the like. We've still got a ways to go with regards to function pointers and some mechanical stuff...but it's looking good. It'd be a pity not to be able to share it.

 

Phil

Link to post
Share on other sites
If you wish me to e-mail / pass you a copy of the modified sources, please let me know. I think I may be able to do so via the forum's personal message system?  It may save you a monster of an edit!

 

I looked at porting this code to source boost a few months ago. However after reading the terms and conditions of the Microchip licence agreement and pursuing it with Microchip I came to the conclusion it was not viable to do this to be able to share code with other forum members. Any attempt to share code with other team members in a usable way would be in violation of the Microchip licence agreement.

 

As Phil has said, "Oh Dear!". What a nuisance. I wonder if porting the code between compilers really is a problem?

Link to post
Share on other sites
If you wish me to e-mail / pass you a copy of the modified sources, please let me know. I think I may be able to do so via the forum's personal message system?  It may save you a monster of an edit!

 

I looked at porting this code to source boost a few months ago. However after reading the terms and conditions of the Microchip licence agreement and pursuing it with Microchip I came to the conclusion it was not viable to do this to be able to share code with other forum members. Any attempt to share code with other team members in a usable way would be in violation of the Microchip licence agreement.

 

As Phil has said, "Oh Dear!". What a nuisance. I wonder if porting the code between compilers really is a problem?

 

Read the licence agreement - the problem is not the porting it is the sharing of code. Effectively you are sharing code that is copyrighted (is owned by) a third party. The problem is solvable. CCS make available a ported version of the stack to their registered users however bundled into the package file is the Microchip licence agreement which must be accepted befoe the software will install.

Link to post
Share on other sites

>Read the licence agreement - the problem is not the porting it is the sharing of code. >Effectively you are sharing code that is copyrighted (is owned by) a third party. The >problem is solvable. CCS make available a ported version of the stack to their >registered users however bundled into the package file is the Microchip licence >agreement which must be accepted befoe the software will install.

>

Well any advice on making this all nice and legal much appreciated....perhaps an email from Pavel or Dave to Microchip?? Would love to make contribution a part of the sourceboost package, particularly if we can figure out how to compile it as a lib.

 

As an aside, could the Microchip CDC package get compiled using PICC18....then reused as a lib in Sourceboost.....that'd be another way of getting USB into Sourceboost.....or at least a set of instructions on compiling/library making and using from another compiler would be very handy. I've tried half heartedly to get the PICC18 CDC code going, but am stumbling on it's bootloader configuration...anyone done a PICC18 CDC compile for standalone/non bootloader use? What would I need to reconfigure, fuses certainly, but also execution startup/reset vectors etc.

 

Anyway the port is still chugging along. The codebase is now connecting to the host and there is some IRB exchanges, the device gets assigned a USB address...however is not going beyond the addressing stage to configuration.

 

A question to USB experts. After the device is addressed, how can I check if the configuration information is being transmitted...any ideas on a usb analyser that goes deep or other ways to check. I'm using USB Monitor from HDD and USB Trace from SysNucleus...but am not getting details from the device showing up on the trace....

Assuming the worst and that my microchip usb driver is not installed properly, will these packages show the device/config decriptors being transmitted before the driver or host sends the device into suspend? Does the device descriptor get transmitted, checked and rejected (if it doesn't match a usb driver) before config descriptor or do they go together even if the device will be rejected? I'm trying to guess if I am tranmitting the config/descriptor data, but because of some driver issue, maybe these analysers are not showing it. I'm guessing that they hook into the driver system a bit higher up than low level data tracing, if the driver doesn't load I would imagine in this case the high level hooks wouldn't work. Of course if I can't get the usb device to work properly...I can't tell if the driver will load properly....got a little chicken and egg situation at the moment.

 

 

Phil

Link to post
Share on other sites

Join the conversation

You are posting as a guest. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji 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...
×
×
  • Create New...