Version 1.5.0 should not be used with newest compilers


+ Reply to Thread
Results 1 to 9 of 9
  1. #1
    Prolific Poster hadv215's Avatar
    Join Date
    Sep 2009
    Posts
    1,136
    Thumbs Up
    Received: 66
    Given: 26
    Total Downloaded
    3.61 GB

    0 Not allowed!

    Default Version 1.5.0 should not be used with newest compilers

    Hi All,

    Since Les has implemented a new USB stack in the newest versions of the compilers, version 1.5.0 will not do the job anymore.
    You can of course always manually change the descriptor, but please note that a number of included files have been changed, both in content and in name.

    The compiler now comes with an example HID_Descriptor.inc in PDS/Includes/Sources. The only safe way to work with this one is to copy it to your project directory, give it a meaningfull name and modify a number of values like VID, PID and packetsize.

    I will try to modify my wizard in such a way as that it will use this example as a base for generating a new descriptor.
    However, I'm a bit reluctant since a number of 'identifiers' may change over time and I don't really feel like updating my tool each time this happens.

    Regards
    Harm

Attention

This valuable resource relies upon the very small amount of revenue generated by displaying online advertisements to our visitors.

The advertisements we display are relevant to this web site and your browsing history

Please consider supporting us by disabling your ad blocker.


Note: Some users have reported issues related to ad-blockers rendering parts of this wesite unusable,
where possible we will rectify the issues to enable you to use this resource with adblocking enabled.

If you can, please report issues in the forum area WebSite / Forum Issues


Thank you for your attention.

  • #2
    Prolific Poster hadv215's Avatar
    Join Date
    Sep 2009
    Posts
    1,136
    Thumbs Up
    Received: 66
    Given: 26
    Total Downloaded
    3.61 GB

    0 Not allowed!

    Default Re: Version 1.5.0 should not be used with newest compilers

    Anybody at all interested in a version that will work with 3.5.6.0 and possibly newer?

  • Attention

    This valuable resource relies upon the very small amount of revenue generated by displaying online advertisements to our visitors.

    The advertisements we display are relevant to this web site and your browsing history

    Please consider supporting us by disabling your ad blocker.


    Note: Some users have reported issues related to ad-blockers rendering parts of this wesite unusable,
    where possible we will rectify the issues to enable you to use this resource with adblocking enabled.

    If you can, please report issues in the forum area WebSite / Forum Issues


    Thank you for your attention.

  • #3
    Prolific Poster John Drew's Avatar
    Join Date
    Feb 2002
    Posts
    2,836
    Thumbs Up
    Received: 90
    Given: 34
    Total Downloaded
    4.60 GB

    0 Not allowed!

    Default Re: Version 1.5.0 should not be used with newest compilers

    Interested but on the not for a while list here Harm.
    John

  • Attention

    This valuable resource relies upon the very small amount of revenue generated by displaying online advertisements to our visitors.

    The advertisements we display are relevant to this web site and your browsing history

    Please consider supporting us by disabling your ad blocker.


    Note: Some users have reported issues related to ad-blockers rendering parts of this wesite unusable,
    where possible we will rectify the issues to enable you to use this resource with adblocking enabled.

    If you can, please report issues in the forum area WebSite / Forum Issues


    Thank you for your attention.

  • #4
    jdaniels
    Guest jdaniels's Avatar

    0 Not allowed!

    Default Re: Version 1.5.0 should not be used with newest compilers

    I am very interested, I was using your previous version.

    Thanks
    John

  • Attention

    This valuable resource relies upon the very small amount of revenue generated by displaying online advertisements to our visitors.

    The advertisements we display are relevant to this web site and your browsing history

    Please consider supporting us by disabling your ad blocker.


    Note: Some users have reported issues related to ad-blockers rendering parts of this wesite unusable,
    where possible we will rectify the issues to enable you to use this resource with adblocking enabled.

    If you can, please report issues in the forum area WebSite / Forum Issues


    Thank you for your attention.

  • #5
    Prolific Poster towlerg's Avatar
    Join Date
    Mar 2012
    Posts
    2,268
    Thumbs Up
    Received: 77
    Given: 182
    Total Downloaded
    5.30 GB

    0 Not allowed!

    Default Re: Version 1.5.0 should not be used with newest compilers

    Absolutely, anything that makes to new USB stack more accessable. Yes please.

  • Attention

    This valuable resource relies upon the very small amount of revenue generated by displaying online advertisements to our visitors.

    The advertisements we display are relevant to this web site and your browsing history

    Please consider supporting us by disabling your ad blocker.


    Note: Some users have reported issues related to ad-blockers rendering parts of this wesite unusable,
    where possible we will rectify the issues to enable you to use this resource with adblocking enabled.

    If you can, please report issues in the forum area WebSite / Forum Issues


    Thank you for your attention.

  • #6
    Prolific Poster hadv215's Avatar
    Join Date
    Sep 2009
    Posts
    1,136
    Thumbs Up
    Received: 66
    Given: 26
    Total Downloaded
    3.61 GB

    0 Not allowed!

    Default Re: Version 1.5.0 should not be used with newest compilers

    Okay, some interest exists, good to hear.

    At the moment I have 3.5.6.1 installed on one of my machines and find an example HID_descriptor.inc in PDS/Includes/Sources.
    This is a famous one, it stems from years ago and is based an a very early example of a demo app built by Jan Axelson (it's still USB 1.10).

    If you take a look at this file you'll notice that in line 37 the file USB_HID.inc is included. This file itself includes USB_Dev.inc which in it's turn includes USB_MemAlloc.inc.
    And there are other things to notice:
    - lines 1 and 2 contain preprocessor statements that are used by the compiler, line 197 also contains one, but it does not have a name in it.
    - a number of tables contain the constants cUSB_DESCRIPTOR_DEVICE, cUSB_DESCRIPTOR_CONFIGURATION, cDSC_HID, cUSB_DESCRIPTOR_ENDPOINT, cUSB_DESCRIPTOR_STRING. Although these constants are defined in USB_Dev.inc, they are not specific for the compiler because they're defined by the USB organisation.

    Now the first two observations make me a bit carefull because they may be changed with a new version of the compiler.
    The third can be overcome easily by replacing these constants with their values since they are not depending on the compiler.

    The first is, in my opinion, the most serious.
    First it's the question of architecture and the role of device description file. A description file should never contain code, not even by means of an include.
    The descriptor file should be what the USB organisation says it should be. Nothing more, nothing less.
    Description and code should be separate and not depending on each other.

    Second it's the question of maintenance.
    The fact that code is included makes the descriptor file dependant of the compiler version and possible (probable?) changes in the future.
    You don't want that because it would mean that to recompile a source for whatever reason you'd first have to update the descriptor file.

    So the best I can do is generate a new descriptor based on this example with as little compiler dependencies as possible.
    But it means you will be stuck with
    - the preprocessor statements
    - the code include
    For these I can offer solutions by means of extra settings in the program, read on start of execution and saved when changed at the end of execution.
    At the moment I'm considering the following:
    - Preprocessor statements:
    -- include preprocessor statements yes/no
    -- if yes:
    --- name of the define you want included. This will be defaulted to '_HID_DESC_INC_' as in the current version.
    - Included files:
    -- include .inc files yes/no
    -- if yes: multiple files may be included and for each file a choice can be made if it is included at the top or at the bottom of the descriptor.
    --- Top would mean directly after the line containing "Goto _DescriptorMain_"
    --- Bottom would mean directly after the line containing "_DescriptorMain_"

    It also means the tool should never overwrite an existing .bas with the same name-part as the descriptor (since it may just be updating the descriptor). Note that if you start this tool from JohnG's famous FuseConfigurator no skeleton .bas file would be created anyway, that only happens if you start the tool in stand-alone mode.

    What is your opinion on this?
    Anything I forgot/overlooked?
    Possible improvements?

    Suggestion for Les (if he's following this thread): add a 'Declare USB_HID (= 1)' and 'Declare USB_CDC (= 1)' to the compiler so we don't keep stuck with a descriptor that isn't a pure descriptor. I love the new implementation and I am baffled by what you came up with, but it can be improved.

    Regards,
    Harm

  • Attention

    This valuable resource relies upon the very small amount of revenue generated by displaying online advertisements to our visitors.

    The advertisements we display are relevant to this web site and your browsing history

    Please consider supporting us by disabling your ad blocker.


    Note: Some users have reported issues related to ad-blockers rendering parts of this wesite unusable,
    where possible we will rectify the issues to enable you to use this resource with adblocking enabled.

    If you can, please report issues in the forum area WebSite / Forum Issues


    Thank you for your attention.

  • #7
    Prolific Poster hadv215's Avatar
    Join Date
    Sep 2009
    Posts
    1,136
    Thumbs Up
    Received: 66
    Given: 26
    Total Downloaded
    3.61 GB

    0 Not allowed!

    Default Re: Version 1.5.0 should not be used with newest compilers

    Well, response was very low to say the least.
    Sometimes I wonder...

    Anyway, I've updated my wizard to reflect the situation as per 3.5.6.0.
    But...when trying to access the file server my browser gives a time-out..
    So, if anybody is in a hurry, please let me know & we'll find a way to supply you with the latest version.
    It's too big for most mail systems though (2.9 MB).

    Regards,
    Harm

  • Attention

    This valuable resource relies upon the very small amount of revenue generated by displaying online advertisements to our visitors.

    The advertisements we display are relevant to this web site and your browsing history

    Please consider supporting us by disabling your ad blocker.


    Note: Some users have reported issues related to ad-blockers rendering parts of this wesite unusable,
    where possible we will rectify the issues to enable you to use this resource with adblocking enabled.

    If you can, please report issues in the forum area WebSite / Forum Issues


    Thank you for your attention.

  • #8
    Fanatical Contributor top204's Avatar
    Join Date
    Feb 2002
    Posts
    3,465
    Thumbs Up
    Received: 305
    Given: 145
    Total Downloaded
    1.99 GB

    0 Not allowed!

    Default Re: Version 1.5.0 should not be used with newest compilers

    A description file should never contain code, not even by means of an include.
    The descriptor file should be what the USB organisation says it should be. Nothing more, nothing less.
    Nonsense... All descriptor files created in C contain code. Just look at the #include directives at the top of the file. These are linking in libraries.

    Taken from the Microchip USB stack's descriptor .h file:

    #include "./USB/usb.h"
    #include "./USB/usb_function_cdc.h"

    A descriptor in an embedded stack IS itself code.

    Text based descriptors are in the realm of PCs, or devices running an operating system.

    I can assure you that the USB code will not be changed in the future. I've added mechanisms that allow a user to create USB routines, so the compiler's built-in routines do not need to change.

    However, thanks for the wizard Harm. I'm sure it will be welcomed by those who use it.
    Last edited by top204; 19th December 2013 at 17:13.

  • Attention

    This valuable resource relies upon the very small amount of revenue generated by displaying online advertisements to our visitors.

    The advertisements we display are relevant to this web site and your browsing history

    Please consider supporting us by disabling your ad blocker.


    Note: Some users have reported issues related to ad-blockers rendering parts of this wesite unusable,
    where possible we will rectify the issues to enable you to use this resource with adblocking enabled.

    If you can, please report issues in the forum area WebSite / Forum Issues


    Thank you for your attention.

  • #9
    Prolific Poster hadv215's Avatar
    Join Date
    Sep 2009
    Posts
    1,136
    Thumbs Up
    Received: 66
    Given: 26
    Total Downloaded
    3.61 GB

    0 Not allowed!

    Default Re: Version 1.5.0 should not be used with newest compilers

    The fact that descriptors created in C contain code does not convince me one bit, I try to avoid writing in C for a lot of reasons.
    Same for the argument that MC does it too.
    The only thing I do is look at the definition of a descriptor file, e.g. in the famous books by Jan Axelson.

    But let me refrase my statement : A descriptor file should not contain code, but it may include files as long as the names of those files are stable.
    The reason I'm so pertinent on this is the question of maintenance.
    If the implementation changes, it should be possible to update a project without having to change the descriptor (unless of course there are user specific reasons to change the descriptor).

    I'm happy about your assurance that the USB code will not be changed in the future.
    Although I do not quite understand which mechanisms allowing users to create USB routines you refer to.
    Could you please explain this, because you make me very curious.

    The tool, as you may know, is more than just a descriptor wizard, it also supports in setting some of the fuses to valid values for USB (this is harder than modifying an existing descriptor by hand).

    By the way, is there a remote chance that you will support USB (even OTG) in future versions of the newest compiler in the family?

    Regards
    Harm

  • Attention

    This valuable resource relies upon the very small amount of revenue generated by displaying online advertisements to our visitors.

    The advertisements we display are relevant to this web site and your browsing history

    Please consider supporting us by disabling your ad blocker.


    Note: Some users have reported issues related to ad-blockers rendering parts of this wesite unusable,
    where possible we will rectify the issues to enable you to use this resource with adblocking enabled.

    If you can, please report issues in the forum area WebSite / Forum Issues


    Thank you for your attention.

    Thread Information

    Users Browsing this Thread

    There are currently 1 users browsing this thread. (0 members and 1 guests)

       

    Similar Threads

    1. Replies: 0
      Last Post: 30th June 2016, 16:51
    2. Replies: 1
      Last Post: 11th April 2016, 23:28
    3. [SOLVED !] P-ICD and newest Compiler Beta
      By Michael_L in forum In Circuit Debugger
      Replies: 1
      Last Post: 17th July 2008, 09:34

    Tags for this Thread

    Posting Permissions

    • You may not post new threads
    • You may not post replies
    • You may not post attachments
    • You may not edit your posts