is this routing possible or is Grace limited/broken?

bowerymarch,

Looking at the MSP430F2274 datasheet Table 24, the device would not allow you to configure the GPIO pin as both Analog configuration and input trigger at the same time. See the bottom note stating that the input pin trigger is also disabled when you enable the Analog configuration (ADC10AE0.y bits). The diagram also illustrates that the P2IN pin is disabled when ADC10AE0.y bit is enabled.

With that in mind, Grace configuration would not allow you to do so either in the GPIO view to re-configure it as a GPIO input pin while the analog is configured.

Regards,

William

Hi William,

Wow that's odd, I was looking at the MSP430F2274-EP data sheet (the actual part I'm using) and it doesn't have those figures marked as tables... I wonder what other differences there are between the two data sheets...

In any case, looking at the schematic above, it looks like you don't have to use the ADC10AEx to disable the digital stuff - it's optional.  Take a look at section  22.2.2.1  of the family manual also for more evidence of this.  Correct?

In any case that's P2.0, and Grace doesn't have a problem connecting that pin to OA0 and A0. 

Go back and read my post carefully.  I am trying to use P2.1 as a GPIO, NOT as an analog pin, but Grace won't let me.  I provided a project which shows this, if you try to set things as I posted you'll see that it won't work....

Regards,
Marc 

William Goh said:

Looking at your config file, you have both OA0O and A1 tied to P2.1. Grace checks if the GPIO resource is tied to either Ax or OAx. If it is connected to either of them, you have to disable both the OA0O and A1 before the handle is released to re-configure it to be used as a general purpose I/O.Even if you clear the ADC10AE.1 bit in the Power User Mode, it will get set again when you Refresh your configuration. This is an unfortunately side-effect from the OA module.

Ugh... so I want to get an interrupt from OA0O... how can I configure it then?  Or do I have to add manual code to work around what Grace hath wrought?

William Goh said:

As a workaround, you may have to explicitly disable the ADC10AE0.1 bit after Grace initialization to get a hold of the pin as an input pin.

So after the CSL_Init() function i can do that in my user code, and there's no other place Grace might reset it?

William Goh said:

I'll file an enhancement request for this as technically the ADC10 and OA GPIO functionality should be independent.

Please do! And review other false constraints in Grace...

btw - is this why I can't disable (uncheck) ADC10 input A1 (it comes back after a save....), or why setting the source to 21 and saving causes funny behavior (see above)?

thanks,
Marc 

If you take a look at the port pin schematics, you'll see that P2.0 is directly routed to OA0I0 and also directly routed to the input switch for ADC10 INCH0. No other configurations are needed on this MSP. However, setting ADC10AE0.0 disables the digital part (input and output and pullups) completely, to avoid influences. This functionality again is completely independent of the rotuing of the input signal to ADC10 and OA0I0.

My guess is that when GRACE was designed, the two operations were considered mutually exclusive while they aren't.
GRACE can only do a static configuration. It does not support if a pin changes its meaning dynamically at runtime, so it allows only one setting. If a port pin is used for one thing, all other functions on this pins are disabled. Reconfiguring a pin usage at runtime is not supported by GRACE.
In this special case, however, this logic fails, since both uses are available parallel. In theory, if you don't mind an influence by the input buffer, it would even be possible on P2.2 to use P2.2 as OA0I1 /A2/TA3CCI0B all three at the same time. (P2.0 has no digital input function)

You can configure the port pin with GRACE for one function, then for the other, and compare the two,so you'll get the necessary module configuration for both. Then use GRACE for configuring one option and add the necessary settings for the other one to your own (nto GRACE managed) code.

Jens-Michael Gross said:

My guess is that when GRACE was designed, the two operations were considered mutually exclusive while they aren't.

Considering the parts are older than the Grace app, I think a more likely scenario is that Grace wasn't sufficiently reviewed or tested before being released.

Jens-Michael Gross said:

In this special case, however, this logic fails, since both uses are available parallel.

This is not a special case.  The chip is designed to work this way.  One of the points of allowing the OA to be configured as comparator is to get an interrupt from it.

Jens-Michael Gross said:

You can configure the port pin with GRACE for one function, then for the other, and compare the two,so you'll get the necessary module configuration for both. Then use GRACE for configuring one option and add the necessary settings for the other one to your own (nto GRACE managed) code.

Try my example project, and re-read the thread, then you will realize that Grace isn't working right, AFAICT.

Regards,
Marc 

bowerymarc said:

Considering the parts are older than the Grace app, I think a more likely scenario is that Grace wasn't sufficiently reviewed or tested before being released.

bowerymarc said:

This is not a special case.  The chip is designed to work this way.

However, if you hadn't answered my post so fast, I had deleted it, as it was rather superfluous. I forgot to refresh the page before answering (it was opened in the browser for hours), so I did only see your initial post. When some minutes later I discovered that there were already other replies, you already wrote your answer, so I was unable to delete it.

Jens-Michael Gross said:

If a tool si designed for a generic handling of known and unknown past anfd future parts, some generic logic algorithms must be developed and implemented if the tool shall be of any help.

Sorry, I think you're making it bigger than it is.  Chips existed with particular functionality.  Test Grace against existing functionality.  If it's not sufficient, fix it.  Not that hard.

Jens-Michael Gross said:

Usually you have one pin, one function.

Not really... can't think of any processors that I've dealt with since the days of 40 pin DIPs that dont have pin muxes.

Jens-Michael Gross said:

Without 400 independent hand-tweaked sets of code.

Hopefully it's not a big pile of code, that would be a serious design error.  Should be files or resources (data sets) which spell out constraints and functionality.  

Jens-Michael Gross said:

Personally, I don't llike GRACE,a sit moves the field of MSP programming from 'design an efficient and optimal applicaiton for your microcontroller' to a 'click your application together' task. With naturally less than optimal results. It may attract more customers and may lower the coding skill requirements for newcomers, but at the same time lowers the quality of the produced applications.

Some people do all their programming with EMACS too :)  You can do everything in EMACS that you can in Eclipse.

Take a look at Freescale's ProcessorExpert for another example.  These are productivity enhancers.  They reduce 'dumb bugs' or they should.  Reduce or eliminate having to cross-reference half a dozen documents to divine hardware dependencies (like partially populated pin muxes)  Grace is getting there... this latest generation is behaving itself way better.

Jens-Michael Gross said:

However, if you hadn't answered my post so fast, I had deleted it, as it was rather superfluous.

Lesson for both of us :)

I'm going back to work...

Regards,
Marc 

bowerymarc said:

Sorry, I think you're making it bigger than it is.  Chips existed with particular functionality.  Test Grace against existing functionality.  If it's not sufficient, fix it.  Not that hard.

Doing it this way would mean writing one independent program for each chip, grouping them under a common UI.

The only sane approach for a project that will support a yet unknown number of devices is to generate a basic strategy, sort of an intelligent script interpreter, and just add the proper 'script' for each processor.
And while designing this interpreter, some 'special cases' weren't recognized. Mos tlikely because the first devices supported didn't exhibit them.

Sure, after the issue was detected, the engine needs to be changed to support them. But this is NOT a case of insufficient testing and poor quality control.It' sjsut that nobody though that you would come along and do this specific thing that's only possible on this specific device.

bowerymarc said:

Usually you have one pin, one function.

Not really... can't think of any processors that I've dealt with since the days of 40 pin DIPs that dont have pin muxes.[/quote] GRACE is for MSP onlys, not for any processors you've dealt with. So other processors were not part of the considderations when planning the software. And the planning stage most certainly has taken place long before the first revision of GRACE was released. And latest MSPs have been released.

And on MSPs, you usually have GPIO funcitonality and optionally one module input and one module output function and maybe an analog function. Not two inputs and two outputs and additionally analog functionality.

bowerymarc said:

Without 400 independent hand-tweaked sets of code.

Hopefully it's not a big pile of code, that would be a serious design error.  Should be files or resources (data sets) which spell out constraints and functionality.  [/quote]That's what I was talkign about. And how do you thing the data sets which spill out resources are handled? Well, not by an AI that reconfigures itself if new and previously unknown constraints are coming up in the provided data sets.
But rather by an interpreter/parser which simply wasn't designed for this special case. And needs to be extended to support it, now that it's known.

I've doen a lot of software (and hardware) projects. Including OS design. And I don't say I'm 'makign it bigger than it is'. I'm pretty sure it is ratehr bigger than I could make it in a forum post. Quite a complex project with lots of internal logic to write.

bowerymarc said:

Some people do all their programming with EMACS too :)  You can do everything in EMACS that you can in Eclipse.

Neither one writes the code for you. I too prefer a fine-tip soldering iron over a hot nail when it comes to stuffign my PCBs, but neither one helps me designing the PCB. So this emacs/eclipse comparison really doesn't fit.
(and BTW: even with eclipse, some people fail to perform even the simplest basic C++ tasks and ask for help here)

If you don't know how to find your destination without a navigator, you shouldn't try to drive a car with one. Even if it's convenient and helpful to have one available.

bowerymarc said:

I'm going back to work...

Me too. Vacation has ended and lots of things piled up on the desk.

rats, i just realized IHBT!

bowerymarc said:

rats, i just realized IHBT!