usb firmware: rom unknown, no backslashes in #include

Logged In: YES
user_id=589052
Originator: NO

Hi Stefan,

for the "rom" keyword you could probably use either
an empty #define or a define to SDCCs equivalent.

I've not downloaded MCHPFSUSSB_Setup.zip and instead found:
http://www.nuxie1.com/Hackaday_Entry/Bootloader/system/usb/usbmmap.h
which I guess is near to your usbmmap.h.
The errors about the "duplicate union member" seem to be real
and related to:

typedef union _BD_STAT
{
byte _byte;
struct{
unsigned BC8:1;
unsigned BC9:1;
unsigned BSTALL:1; //Buffer Stall Enable
unsigned DTSEN:1; //Data Toggle Synch Enable
unsigned INCDIS:1; //Address Increment Disable
unsigned KEN:1; //BD Keep Enable
unsigned DTS:1; //Data Toggle Synch Value
unsigned UOWN:1; //USB Ownership
};
struct{
unsigned BC8:1;
unsigned BC9:1;
unsigned PID0:1;
unsigned PID1:1;
unsigned PID2:1;
unsigned PID3:1;
unsigned :1;
unsigned UOWN:1;
};
struct{
unsigned :2;
unsigned PID:4; //Packet Identifier
unsigned :2;
};
} BD_STAT; //Buffer Descriptor Status Register

If you'd f.e remove PID3:1; in the second struct the compiler
would have to choose whether UOWN would be bit 6 or bit 7 of the union.
To avoid this you should give the structs a name like:

struct{
unsigned BC8:1;
unsigned BC9:1;
unsigned BSTALL:1; //Buffer Stall Enable
unsigned DTSEN:1; //Data Toggle Synch Enable
unsigned INCDIS:1; //Address Increment Disable
unsigned KEN:1; //BD Keep Enable
unsigned DTS:1; //Data Toggle Synch Value
unsigned UOWN:1; //USB Ownership
} a;

Greetings,
Frieder

Logged In: YES
user_id=1902332
Originator: YES

You found the right file.
But where is the error with the unions/structs? Does the sdcc something wrong, or is the code (C standard) invalid?

What is the SDCCs equivalent to the (M18C) "rom" keyword?

Logged In: YES
user_id=568035
Originator: NO

SDCC accepts backslash "\" as path delimiters in the #include directive. You probably didn't specify the correct location of include files, so you received the "No such file or directory" error. Try to specify the path with slashes as path delimiters. If I'm right, then you'll gel the same error message. If I'm wrong, then let me know ;-)

Borut

Logged In: YES
user_id=1902332
Originator: YES

@borutr: You are wrong. As i described before replacing the \ with / works.
If you would do the steps I descibed, you will excatly see this in step 10. and 11.

@all: download the zip file (no costs, no registration required) and try it on your own, so many answers would be given to you and you see what the issues are which I descibed.

PIC controllers are from Microchip, and getting their C-frameworks work with sdcc is required for using sdcc for larger projects.
It is also required for me, until you have a framework for PICs which uses the USB and make e.g. a HID class device.
(perhaps USB functions should be shipped with sdcc (-libraries))

Logged In: YES
user_id=568035
Originator: NO

Sefan,

You are right that I'm wrong ;-)
The problem is that the first level include works, but the second and higher level include fails.

I'm still investigating the problem.

The workaround is to add -I. to the sdcc command line:

sdcc -mpic16 -p18f2550 -V -I/home/stefan/Entwicklung/PIC/Demo/ -I. -c main.c

This solves only the first level of your problems :-(

Borut

Logged In: YES
user_id=568035
Originator: NO

Actually the -I. option is not only workaround but the proper solution, since all include paths (also those in subdirectories) are relative to the directory where main.c is located. (BTW: replacing backslashes with slashes doesn't change anything.)

The error:
usb_compile_time_validation.h:46: error: token "\" is not valid in preprocessor expressions
is caused by double backslash in usb_compile_time_validation.h, line 46. Replace it with a single backslash and the error will go away.

Other errors are consequence of differences between C18 and sdcc compiler.

Borut

Logged In: YES
user_id=568035
Originator: NO

OK, now I found out why you have to replace backslashes with slashes: you are compiling on Linux, while I'm on Windows.

sdcpp (which is derived from gcc prepocessor) doesn't support backslashes in a path in the #include command on Linux, but it supports them on Windows.

I'm not sure if this has to be changed, since I think that the portable code should always use slashes, even on Windows platforms. I would like to hear other opinions before the final decision.

Borut

Logged In: YES
user_id=888171
Originator: NO

I vote to keep it as is. Backslashes should be accepted on Windows but need not be accepted on Linux or any other unix-like OS. But I would also like to hear from one of the Linux-based developers.

Logged In: YES
user_id=1902332
Originator: YES

I vote for max. compatibility like backslashes should work.

I do not like backslashes and I do not use them on Windows and Linux, but I have to use orginal code from Microchip (there are backslashes) because of USB-functionality of my PIC18F2550.

The OS under which I create code is does not matter, the M18C runs under Windows with MPLAB and under Linux with piklab. So the code I write is portable between the OSs. Piklab also supports the sdcc.

How do you use USB with sdcc?

Logged In: YES
user_id=589052
Originator: NO

I vote to keep it as is, too. But emit warnings.

As it is now many application notes or code on public sites
do not compile out of the box on Unix.
(and the people developing them on Windows had been given no hint).

Instead of trying to fix that "halfway" in SDCC I'd prefer that:

SDCC should warn when Microsoft's "embrace and extend" directory
separator '\' is used.
('\' as a separator is pretty un C'ish anyway.)

About the "halfway" above:
1) if some kind of "lazy filename matching" is tried then other
trouble lies ahead, f.e. does:
#include "abc\ def"
use the file " def" in the directory "abc" or the file "abc\ def"?

2) allowing '\' as a directory separator alone would not be sufficient.
Differences in upper and lower casings of filenames
would have to be ignored too.
And this can lead to very hard to find bugs:

Say there is a bug in some header file x51y15a.h which comes
with the distribution (or another file which is in an include path).
Then you place a fixed or otherwise changed version
named x51y15A.h into the source directory. And in all but one file
where you include x51y15a.h. In one file you include x51y15A.h.
Then you pass your code to a colleague...
(chances are your colleague would have preferred a compile time error
over a possibly subtle runtime problem).

(The warning itself should be as gentle as can be)

Feature request [ 1506882 ] "warning on file name case mismatch"
http://sourceforge.net/tracker/index.php?func=detail&aid=1506882&group_id=599&atid=350599 is related

Logged In: YES
user_id=245280
Originator: NO

re: "PIC controllers are from Microchip, and getting their C-frameworks work
with sdcc is required for using sdcc for larger projects.
It is also required for me, until you have a framework for PICs which uses
the USB and make e.g. a HID class device.
(perhaps USB functions should be shipped with sdcc (-libraries))"

No. You shouldn't expect SDCC to change to match C18. Directory separators are the least of the issues between C18 and SDCC. The big things that are breaking are compiler specific and different choices were made (e.g., "rom" keyword). Even if you got that keyword fixed, you would then have to grapple with the different ways that pointers work in the two compilers.

Note that if you want a HID device that compiles under SDCC you should go download one. There are quite a few available. For example I wrote one based on the Microchip USB framework that is available from Nuts & Volts magazine. Look for USB.zip in http://www.nutsvolts.com/downloads.php, or directly from http://www.nutsvolts.com/media-files/113/USB.zip. It is under LGPL so you can use it as you please. I haven't tried recompiling under a recent build of SDCC, but it shouldn't be too big a task.

Logged In: YES
user_id=568035
Originator: NO

I don't see any reason to keep it open, so I'm closing it.

Borut

Logged In: YES
user_id=888171
Originator: NO

I agree that there is no bug here, but I do see an RFE for a warning when using a backslash in the include instruction. Still it might be better to keep this one closed and open a proper RFE for that particular purpose.