[Bug 1001872] New: TWR-ADCDAC-LTC hal support

[Bug 1001872] New: TWR-ADCDAC-LTC hal support

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001872

            Bug ID: 1001872
           Summary: TWR-ADCDAC-LTC hal support
           Product: eCos
           Version: CVS
            Target: freescale_twr_k70f120m (Freescale Kinetis TWR-K70F120M
                    board)
  Architecture/Host Cortex-M
                OS:
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: low
         Component: ADC
          Assignee: unassigned@bugs.ecos.sourceware.org
          Reporter: mjones@linear.com
                CC: ecos-bugs@ecos.sourceware.org

This patch add supports for the TWR-ADCDAC-LTC board for the K70F120M. It
should work on other versions if the driver is added to them as long as the
GPIOs use the same pins.

This patch is not ready for a commit, but it is fully working. I need some
feedback on a few things:

1) There are new calls in the io/adc package to support gain, polarity, and
mode, where mode is single vs. differential. The io/adc as is was designed for
ADCs internal to a target. All the existing ADC hal support has dummy functions
for these three new API.

2) The LTC ADC support requires use of SPI. This means the reading of values
was moved from the ISR to the DSR. The add sample routine in io/adc returns a
value that indicates the DSR is required. The origonal author of io/adc may or
may not want to change the defined return value to be more generic.

3) Timing is controlled by FTM or PDB at the users choice. PDB is also used for
internal ADCs of the kinetis (future). Someone may care about the impact on
adding future ADC support for the internal ADC. The code uses the interrupt and
should be compatible with future ADC support other than restrictions on the
clock rate that internal and external ADC rely on.

4) The driver was structured similar to the DSPI flash driver in terms of where
things we located in the tree. Someone with more experience may want to look at
the directory and CDL structure and see if it is ok.

5) I will eventually support the DACs on the LTC board, but want to keep it
seperate. I will probably make the DACs a simple poke API and will not use the
clocks. So releasing seperatly should be ok.

6) I have some example code if anyone has the LTC board and wants to play with
it.

7) There are new defines for PDB and FTM. Someone may want to look at these and
see if they are ok with them in terms of future use. I have printed them along
with a datasheet and verified every value, so they should be accurate.

8) There are some #defines in the code that enable/disable behavior. People may
want to remove these or control them with CDL. Looking for opinions.

In summary, even if you don't have a board, this could use a quick review by
those with knowledge of the io/adc and Kinetis support.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 1001872] TWR-ADCDAC-LTC hal support

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001872

--- Comment #2 from Mike Jones <mjones@linear.com> ---
Created attachment 2276
  --> http://bugs.ecos.sourceware.org/attachment.cgi?id=2276&action=edit
Ecos DB Patch

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 1001872] TWR-ADCDAC-LTC hal support

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001872

--- Comment #1 from Mike Jones <mjones@linear.com> ---
Created attachment 2275
  --> http://bugs.ecos.sourceware.org/attachment.cgi?id=2275&action=edit
Core Patch

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 1001872] TWR-ADCDAC-LTC hal support

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001872

Mike Jones <mjones@linear.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #2275|0                           |1
        is obsolete|                            |

--- Comment #3 from Mike Jones <mjones@linear.com> ---
Created attachment 2296
  --> http://bugs.ecos.sourceware.org/attachment.cgi?id=2296&action=edit
Core DAC/ADC

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 1001872] TWR-ADCDAC-LTC hal support

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001872

--- Comment #4 from Mike Jones <mjones@linear.com> ---
Created attachment 2297
  --> http://bugs.ecos.sourceware.org/attachment.cgi?id=2297&action=edit
Ecos DB for DAC/ADC

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 1001872] TWR-ADCDAC-LTC hal support

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001872

Mike Jones <mjones@linear.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #2276|0                           |1
        is obsolete|                            |

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 1001872] TWR-ADCDAC-LTC hal support

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001872

--- Comment #5 from Mike Jones <mjones@linear.com> ---
Created attachment 2298
  --> http://bugs.ecos.sourceware.org/attachment.cgi?id=2298&action=edit
ECM for Testing

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 1001872] TWR-ADCDAC-LTC hal support

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001872

Mike Jones <mjones@linear.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #2297|0                           |1
           is patch|                            |
   Attachment #2297|application/octet-stream    |text/plain
          mime type|                            |

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 1001872] TWR-ADCDAC-LTC hal support

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001872

--- Comment #6 from Mike Jones <mjones@linear.com> ---
Created attachment 2299
  --> http://bugs.ecos.sourceware.org/attachment.cgi?id=2299&action=edit
Code used for testing

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 1001872] TWR-ADCDAC-LTC hal support

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001872

--- Comment #7 from Mike Jones <mjones@linear.com> ---
Created attachment 2300
  --> http://bugs.ecos.sourceware.org/attachment.cgi?id=2300&action=edit
Wiring use for testing

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 1001872] TWR-ADCDAC-LTC hal support

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001872

--- Comment #8 from Mike Jones <mjones@linear.com> ---
This new set of patches and files completely support the DACs and ADCs on the
TWR-ADCDAC-LTC. The testing was done by driving the ADC inputs with DAC
outputs. Some ADC bugs were fixed in the process. Mainly it was the need to
deal with the fact that reading a value is always one SPI after transaction the
one that initiates the conversion. These ADCs have a MUX, and it requires one
SPI transaction to change the MUX and start the conversion, and then the value
is read on the next SPI transaction. The code works by iterating through the
active channels. The timer chosen, FTM or PDB, triggers one measurement each
event. This means if using 8 channels, the sample rate of an individual channel
is 1/8th the rate. Unlike a built in ADC, these devices cannot sample all
inputs at the same time.

This version has:

- Generic DAC support modeled on the Generic ADC support. You feed the buffer
with data and it is output based on a clock.

- DAC support for the TWR board.

- SGML files for the generic DAC support and the two LTC DACs and two LTC ADCs.

- ChangeLog files.

- Test code for the Generic DAC, but I am not sure how to compile and run it.
Also, it is very dependent on the ecc file, wires, etc. So its usefulness is
limited in my opinion.

- No compile warnings when using both DAC or ADC. However, in a few cases, like
disabling one of two ADC/DAC there are a few warnings. This could be a little
cleaner, mainly to reduce the size of the object code. I think other ADC
devices have some of this. I don't have time for a while to look into all the
ways the user can make the code bigger by changing the ecc settings.

- There is always room for code improvements. I am sure there a few ways to
make the code just a little faster. Over time I might do some of that. For now,
it is reasonable and I believe the behavior is bug free.

Previous suggests on things for other people to look at still apply. I believe
this version is fully working. With the picture of the wiring and my test code
and ecm anyone with this board should be able to duplicate my test results.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 1001872] New: TWR-ADCDAC-LTC hal support

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001872

            Bug ID: 1001872
           Summary: TWR-ADCDAC-LTC hal support
           Product: eCos
           Version: CVS
            Target: freescale_twr_k70f120m (Freescale Kinetis TWR-K70F120M
                    board)
  Architecture/Host Cortex-M
                OS:
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: low
         Component: ADC
          Assignee: unassigned@bugs.ecos.sourceware.org
          Reporter: mjones@linear.com
                CC: ecos-bugs@ecos.sourceware.org

This patch add supports for the TWR-ADCDAC-LTC board for the K70F120M. It
should work on other versions if the driver is added to them as long as the
GPIOs use the same pins.

This patch is not ready for a commit, but it is fully working. I need some
feedback on a few things:

1) There are new calls in the io/adc package to support gain, polarity, and
mode, where mode is single vs. differential. The io/adc as is was designed for
ADCs internal to a target. All the existing ADC hal support has dummy functions
for these three new API.

2) The LTC ADC support requires use of SPI. This means the reading of values
was moved from the ISR to the DSR. The add sample routine in io/adc returns a
value that indicates the DSR is required. The origonal author of io/adc may or
may not want to change the defined return value to be more generic.

3) Timing is controlled by FTM or PDB at the users choice. PDB is also used for
internal ADCs of the kinetis (future). Someone may care about the impact on
adding future ADC support for the internal ADC. The code uses the interrupt and
should be compatible with future ADC support other than restrictions on the
clock rate that internal and external ADC rely on.

4) The driver was structured similar to the DSPI flash driver in terms of where
things we located in the tree. Someone with more experience may want to look at
the directory and CDL structure and see if it is ok.

5) I will eventually support the DACs on the LTC board, but want to keep it
seperate. I will probably make the DACs a simple poke API and will not use the
clocks. So releasing seperatly should be ok.

6) I have some example code if anyone has the LTC board and wants to play with
it.

7) There are new defines for PDB and FTM. Someone may want to look at these and
see if they are ok with them in terms of future use. I have printed them along
with a datasheet and verified every value, so they should be accurate.

8) There are some #defines in the code that enable/disable behavior. People may
want to remove these or control them with CDL. Looking for opinions.

In summary, even if you don't have a board, this could use a quick review by
those with knowledge of the io/adc and Kinetis support.

-- 
You are receiving this mail because:
You are the assignee for the bug.