ADC Buffer

[drdoug]

One of the cool features I found in the PIC32 was the ADC buffer. In looking at the IDE it looks like you are using the familiar method of going to get a sample and hanging out till its ready.
It might be nice to implement a feature in the setup where you simply check the buffer which is continually updated while you do other things in the program.
Obviously there are many advanced features like this with the ADC section alone, but I thought I would share that observation with you which I am using.
It looks to be another nice product.
GOOD WORK.

[p.erasmus]

I agree with drdoug

as said before the PIC 32 is a high level device which will be used in high level applications
we need the compiler to support the advance features such as Fifo read and writes /adc interrupt DMA that we can free
the cpu from waiting for single actions to take place
this is very important if we want to have the compiler in a state which it can be used with high level applications

Regards
Peter

[zristic]

We are considering that option anytime someone complains and we always conclude the same: there are so many register/bit variations for PICs available that the amount of work needed for the feature exceeds the amount available we have for a release.

It is on our list anyway, but I do not know when we are going to work on it at all.

[p.erasmus]

Zristic

Yes I understand your posion and When I mention these topics it is not meant to be for this current release
no person can expect it from you to have all these functionality in the very first release !
however I do think that it can be implemented step by step !! it should be the end goal for the compiler !!

Regards
Peter

[drdoug]

In reality it is a trade off between ease of use and functionality.
The advantage I have found with mE products is the ease of use.
Even the Microchip solution for setting up the registers is often clunky.
I think the best thing that mE can do is make the registers easy to get to and set up their libraries to make maximum use of the available uC features.
I thought the ADC buffer idea (and the other peripherals are full of buffers as well) would help to take advantage of the chips power (which p.erasmus said better than me).

[p.erasmus]

drdoug

I agree with you 100% it is of no use if you use a power full micro and you limit it by the manner you
use the the periherals it is essential that you use the advance features of the peripherals and by doing so
you free up the cpu to to other tasks ,I can not imagine that any development engineer would use a PIC32
in a low level application ,it will be used in high level applications that needs lots of CPU power
it is so that a programmer can use the compiler to write his own drivers to use these advance features
but then as you correctly said, that miss the point of mE compilers as being user friendly and speed up
development time .

Regards
Peter

[LGR]

I've been away for a while. Things have certainly grown.

My take on this is that the PIC32 peripherals are unique enough to require certain libraries that are unique to the PIC32, and can't be portable to other families. This is going to be a problem, and I think these things are logical candidates for user projects. Another (simple) example would be the PIC32 RTCC module. It's not realistic to expect mE to furnish these kinds of things, and if your situation allows it, it would be good if people could go off and develop these things and then donate the code. That's the only way these obscure features are ever going to get support in a reasonable amount of time.

The mE team needs to keep the focus on the core functionality. That's my opinion, anyway.

[Muntari]

Hi everyone,
First, great work to ME team, I appreciate your compilers and have purchased a number of them, so what I am about to say is to be taken in a positive light......
My take on things is that the PIC32 range warrants its own subset of hardware libraries for not just the ADC but comparators, DMA and the like. I agree that the PIC32 compiler should have the same feel about it as the rest of the ME compiler family BUT not to the extent that I have to build my own hardware libraries to effectively use peripherals with ALL of their features..... I have had to do this with a number of hardware pieces , like the ADC because the ME version is just way to slow...(I get why that is the case however). What I want to see from the ME team is a compiler that will not only be easy to use (and it is) but also a compiler that has fast and fully feastured libraries to suit the PIC32, after all if I have a PIC32 , that is what I want libraries for, not a complier that restricts library functions and efficency because it has to be complient across ALL MPU ranges.
ME have a chance to place the PIC32 compiler right up there at number 1, please don't restrict library functions!!

That's my take anyway.

Keep up the great work ME!

cheers

Muntari

[p.erasmus]

I have to build my own hardware libraries to effectively use peripherals with ALL of their features..... I have had to do this with a number of hardware pieces , like the ADC because the ME version is just way to slow...(I get why that is the case however). What I want to see from the ME team is a compiler that will not only be easy to use (and it is) but also a compiler that has fast and fully feastured libraries to suit the PIC32, after all if I have a PIC32 , that is what I want libraries for, not a complier that restricts library functions and efficency because it has to be complient across ALL MPU ranges.

I had to do the same for my dsPICBasic compiler and the C compiler and at the moment I still can not use the mE compilers for FOC motor controls as there is no support for the Hardware MAC
(I am not able to program the ASM for the MAC ) and because C30 had built in support for MAC, I still use the C30 and the dsPIC compilers I just have as toys ,
the concerning thing is that mE hear abnd acknowledge that we need these support function but it is were it stays.

ME have a chance to place the PIC32 compiler right up there at number 1, please don't restrict library functions!!

This is the point I have been trying to make over the last 4 months of PIC32 development asking for things as MAC support.Q15 library ,floating point library ect,
it is of now use if the higher level of performance microcontrollers are limit by the capability of the compiler then we can stay with C32 ,again In my opinion
mikro is targeting the Hobbiest and the multi media market were the high level of compiler is not necessary and sell as many licences as possible ,However
with a higher level compiler they will get even more sales as more people will have chance to make a decision between mE,C32 and the HighTech compiler.
I also think now is the time to take such a decision as it is early in the development cycle of the PIC32.
I must also express that I am not saying that all of this should be done at once but set or show a clear direction they are going with the PIC32 compiler
and implement the functions step by step.

There is an old saying in the Engineering world
if you want to play with the big dogs, you can not afford pee like a puppy !!

I have purched a licence for each and every Basic and C compiler from mikro and I think that they have the potential to be in the top class of compilers however
I just get the impression they do not want to be there, they want to support and sell as much as possible to the Hobbiest and therefore the compilers are know as hobby compilers!

mikroE all of this I am saying in a very postive light !

[mileta.miletic]

We will implement DSP library with MAC support and Q15 library, but I can't promise that it will be done for the release.

[p.erasmus]

@mileta.miletic

We will implement DSP library with MAC support and Q15 library, but I can't promise that it will be done for the release.

Thank you for comfirming this !!
As said before nobody expect this all to happen for the official release ! we are quite happy to see with each new release some implementations
that is all ,Rome was not build in one day ,We know this

Regards
Peter

[zristic]

This week we have the staff meeting concerning the new libraries page. The things are moving and we can expect the results this spring.

[p.erasmus]

This week we have the staff meeting concerning the new libraries page. The things are moving and we can expect the results this spring.

Zristic

Thank you this sounds very good.
Once the mE Compiler supports these things the MC C compilers supports ,We will switch our people over to mikroC compilers and then we will only use 2 types of C compilers
for the normal applications the mE compilers (microchip devices) and the HighTec for Infineon TRICORE (Engine applications & Safety Applications).


Regards
Peter

[rmteo]

Once the mE Compiler supports these things the MC C compilers supports ,We will switch our people over to mikroC compilers and then we will only use 2 types of C compilers for the normal applications the mE compilers (microchip devices) and the HighTec for Infineon TRICORE (Engine applications & Safety Applications).

Regards
Peter

Peter,

How would you go about ensuring compliance with the MISRA-C:2004 standard? Thanks.

[p.erasmus]

How would you go about ensuring compliance with the MISRA-C:2004 standard? Thanks.

Well this problem we have with the MC compilers as well ! therefore we use the microchip devices in applications which the MISRA standard is not enforced
such as infontainment,DASH displays ect and you will noticed that I mentioned TRICORE for Engine and safety applications were the
application code is strict MISRA enforced and some other Standards ,The TRICORE Compilers such as TASKING and HIGHTEC are fully MISRA C
Standard and does MISRA C Code checking to the standard during compilation :

We also produce a lot of Off Road Vehicle applications for which MISRA is not enforced !!