[En-Nut-Discussion] STM32F103 - ADC

Achim achim_muc1971 at gmx.de
Tue May 7 11:20:40 CEST 2013


what´s the stud of the ADC implement ion for STM32?
I´ve modified the configuration files. Afterwards ADC 1,2 is active in the
qnutconf common device section, but the adc-files are not added to the
make-file and not compiled.

Can anybody help?


On 07.05.13 10:20, "Harald Kipp" <harald.kipp at egnite.de> wrote:

>Hi Ulrich,
>To stop this threadjacking, I'm opening a new topic.
>On 06.05.2013 14:00, Ulrich Prinz wrote:
>> In many cases NutOS just returns -1 in case of error and then leaves
>> it to the user to find the right variables to query for detailed error
>> information.
>For good reasons, see below.
>> There are some traps with using this rule:
>> You need to limit the maximum byte count to a value that guarantees to
>> be less then the negative roll over value caused by bit-width of your
>> return variable. For ARM 32 bits and Cortex 16 bits are fine as you
>> will not send a block of more than 32767 bytes through I2C in one
>> transfer. But with 8 bit platforms you need to declare return values
>> as int (preciesly int16_t) or limit transfer to 127 bytes in one
>> transfer.
>I cannot follow. What I understood is:
>Per C standard, an int is defined as the "natural size" of the target,
>but not less than 16 bits. When checking for positive or negative
>results only, returning an int will allow 32k-1 on 8-bit and 2G-1 on
>32-bit targets. In other words, half of the available address space. I
>never had any problems with this limitation.
>External C function never return less than an int. This is required,
>because functions may be called without explicitly defining a prototype,
>in which case an int is assumed.
>Therefore, returning an 8-bit value on 8-bit targets doesn't save any
>code. Furthermore, returning less bits than an int will often add more
>code to targets with larger word sizes, because any upper bytes of the
>result need to be cleared.
>My conclusion is: Returning an int will naturally fit 90% of the all
>functions. However, throughout Nut/OS development lifetime I'm
>discovering newly added external functions defining smaller return
>values than an int.
>Do I miss something?

More information about the En-Nut-Discussion mailing list