What is CCS up to?

[drolleman]

It has been a long time since CCS has come out with significant new features. I would upgrade if there is something to buy. Have they lost that creative feeling? so what is going on there?

David

[temtronic]

Maybe they just need some 'input' as to what features you'd like to have. I have to admit I'm an 'old school' guy, don't need any bells or whistles, just solid performance that I can count on. That's probably why I'm still using XP, MPLAB8v86 and only use 3 or 4 PICs for projects using PCM 4point something....

Jay

[asmboy]

MY feeling is that CCS has it's plate full trying to
create smooth interfaces for new PIC features.

I wish they would think up a creative slick
INTERACTIVE application to:

1- generate useful code for modules like the CLC
2-Simplify/check PPS choices based on a provided PIC model

I do like all the intrinsics they have given me so far- just wishing for
easier interfaces for new PIC features as they are released.

[Gabriel]

For me the "hardest" thing is to get the oscillator settings right on newer chips..... so many options sometimes getting that first blink takes more than it should.

Maybe a quick osc. setup as part of the wizard?

And also, with the growing popularity of IOT, A SIMPLE stack?
Seems by now that should be water under the bridge but getting a PIC online without external Internet chips is basically imposible.
Chips like the ESP8266 or any GPRS modem have super simple interfaces... why cant we get that here? 5 or 6 functions and BOOM, im online.

G.
_________________
CCS PCM 5.078 & CCS PCH 5.093

[drolleman]

I too am old school, but I believe that coasting is dangerous. Look at DEC they are now gone. IBM has always maintained new development, that is why they are still around and healthy.

I would like otg usb, as I don't do any 232 anymore.

Even though there are free compilers for pic32 porting a ccs version would be great, and I would willing to pay for. I have built many libraries for 16 / 18 / 24 /33 pic that are not device dependent. it would be nice to have the pic32 option.

keep the ideas running, so ccs gets the wish list from its users.

David

[Ttelmah]

The one thing that is badly lagging the features, is the manual.
Some 25% of the questions here actually come down to either the manual not being comprehensive any more, and/or the examples being incomplete or lacking. The CLC is a 'classic' example of this.
They need in a sense to shift to using something akin to the 'old' Unix Man interface, which then allows sections to be added indexed and updated, without actually having to re-author the manual as a whole. Then descriptive sections could be added to give comprehensive documentation of some features.

There have been a lot of new features appearing, and the manual is becoming increasingly inadequate.

Some features have only been 'worked out' by users playing, or even scanning the text sections in the program files themselves to get the correct syntax. Doesn't encourage new users....

[SherpaDoug]

I agree, the manual is where I wish they would put more effort. I imagine it is difficult to keep up with the features of the new chips. But the older features could use more explanation.
_________________
The search for better is endless. Instead simply find very good and get the job done.

[gpsmikey]

[newguy]

The manual/documentation is an issue, I agree. I don't see why CCS doesn't post a "latest" version of the manual here - one each for v3, v4 and v5. That alone might tempt more legacy customers into upgrading and might pay for the cost of doing so in the first place.

Myself, I tend to stick with what I know (I think we're all guilty of that) and so far I'm pretty well versed with the particular PIC peripherals that I regularly use and the associated CCS code. That said, I do remember times when I've decided to use something new only to discover that the documentation wasn't up to par.

The latest thing I've had the pleasure (and pain) to play with was the CCS easyApp (or whatever it's called). The PIC driver code seemed straightforward, but as soon as I started to expand on the examples I quickly started discovering some weird behaviour. CCS support was great and quickly pointed out what was wrong, and to their credit the necessary changes were documented, but not obviously. I would assume that simply to save time answering questions that have already been documented would be an impetus to improve the documentation.

I do really like the idea of the easyApp, and I have a pet project that would benefit from it immensely, but I did discover a fair number of bugs in the short time that I did play with their easyApp kit. That makes me a little leery to dive in, but later this year I probably will take the plunge anyway.

[Ttelmah]

Their current manuals are available as PDF's in the download part of their site. Doesn't require an ID to get them.

The problem is that these are just not working any more, in terms of documenting the actual features. Try to find 'how' to use a peripheral on the chip, and you will probably end up here, rather than finding an answer in the manual. Even for existing peripherals, some parts of manual entries have been lost, new features/functions added, and documentation gets less and less complete.

If I was doing a 'little list', it'd be:

1) A real update to the manuals. internal indexing, so you can search on keywords, find the functions for each peripheral, with examples for each mode.
2) Basic USB OTG code. Selectable support for an MSD slave, and for HID. This would cover 99% of OTG applications, and at the same time keep the driver size small.
3) Tidy up the recent changes to error reporting. They have (correctly) added a warning, for pointers to different types - sensible warning, but you should then be able to use a 'void *' as a type that automatically bypasses the warning. Currently best solution is to disable this warning. Casting, which should be OK, currently costs (unnecessarily) an extra data move.
4) A poster asked about multiple search windows in the IDE. Easy to do, and a useful feature. I'd like a more flexible approach to 'files'. I'd like to be able to have multiple 'source sections', so (for instance), you could compartmentalise into 'USB source', 'serial source' etc., without having to actually use MCU's which is the only way currently to get this.

[Fulturition]

[RF_Developer]

I don't want extra "features". I want the features that are there to work, and stay working. I want stability and reliability and a guarantee of forward compatibility wherever possible: i.e. that code developed now will compile and run the same in the future without change, or that where change is unavoidable, its clearly indicated/flagged/automatically ported/whatever.

I am already having considerable difficulty selling the idea of continued use of CCS C to my management. There are considerable restrictions that limit serious use in production environments. Yes, CCS have implemented build numbers and output file relocation during the life of version 5, both features I specifically requested, but hey, why weren't they in there from the start? Or at least in V3? I've also requested some sort of integration in to version control systems, to no avail so far :-(

I want the documentation to be completely overhauled: corrected, brought up to date and in parts, reorganised to make it clearer. It has evolved somewhat haphazardly, some entries lagging far behind the hardware and compiler support.

Controversially, I would actually support the removal of USB support, at least if full-featured, reliable support with known and well-defined memory and performance impact was not provided. Half-hearted support where users are not clear about the implications of its use is in many ways worse than none at all. A lot of the requests for help we see here are directly cause by the USB support, often due to it not being used properly.

On the flip-side, I would prefer to see far better and native CCS TCP/IP support, rather than very occasional CCS ports of old Microchip stacks.

I'd like to see a more coherent strategy on examples/drivers. If they are drivers then there really should be some way of easily integrating more than one into a project. If they are examples then they need to make it clear that users are expected to have to do some work, to use them in their own projects. I don't necessarily expect MORE examples or drivers, just more usable ones.

[temtronic]

I agree the manual/drivers 'update' would be great ! My head spins though at the daunting, near impossible task though. A complete 'rewrite' would involve thousands of manhours by staff well versed in USING the compiler as opposed to some 'tech writer' transposing scribbles from coders. The same goes for the drivers. Yes, it'd be nice to see them all,'nice and neat' using similar coding formats but over 2+ decades , I assume there's been a few 'hires and fires' at CCS. How anyone. let alone a company can stay focussed in a filed that changes DAILY is beyond me. To their credit they do try to keep up,but I could see needing a staff of 20 techs JUST to 'update ' the drivers for 3-4 years. It's all in the details, common coding style(whose ? ),even program names would need a 'commitee decision !
Another factor may be that the 'current' generation of coders never saw assembler,especially from the 70s, where EVERY line had a comment and memory consisted of just a few thousand ferrite beads.'Bloatware' IS the standard these days and with super fast brains, no one 'sees' how bad code has become.
As for example programs ,like USB, perhaps 'one of the regulars' would post and donate their code? Yes, I 'm aware of your time involved, client confidentiality, etc. but I think CCS would appreciate the help,or at least the offer!

Jay

[Ttelmah]

That is the key point about using something like the Man structure. The manual could then evolve. On Unix in the past, when I wrote new functions that were then adopted, we added the Man pages for them, so that all users in future could use these functions and have documentation of them. Clones of some of these still exist in Linux now.
If the structure was sensible, people could submit improved sections for the manual, and it could evolve. What would be needed, was a set of support 'tools' to allow display, cross-referencing, and indexing, and a method (via say an extra branch in the forum), by which sections could be submitted.
Then the existing manual could be fed into the tools (hopefully giving improved indexing), all new functions could use the new enhanced format, and slowly the older manual could be upgraded by CCS, with the help of user submissions as well.

[Gabriel]

.... dare I suggest: how about filling in the driver gaps with our own drivers?

There is a lot of knowledge and experience here.... CCS could tap into that if "we" let them....
Polishing a user based driver rather than starting from scratch could speed up the process.

I hope the Native TCP/IP stack gets traction.

G.
_________________
CCS PCM 5.078 & CCS PCH 5.093