This is the mail archive of the
mailing list for the eCos project.
[Bug 1001872] TWR-ADCDAC-LTC hal support
- From: bugzilla-daemon at bugs dot ecos dot sourceware dot org
- To: ecos-bugs at ecos dot sourceware dot org
- Date: Sun, 30 Jun 2013 19:16:13 +0000
- Subject: [Bug 1001872] TWR-ADCDAC-LTC hal support
- Auto-submitted: auto-generated
- References: <bug-1001872-13 at http dot bugs dot ecos dot sourceware dot org/>
Please do not reply to this email, use the link below.
--- Comment #8 from Mike Jones <email@example.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.