Timothy J. Weber wrote:
>> To be honest, I'm just going off the ads I see in DDJ and similar
>> publications, and the internet. I don't know how it compares to Python,
>> since I don't generally use Python.
>
> Ah!  I'm a bit skeptical that buzz = availability, though I agree
> there's probably some correlation.

Well, for one, C# includes a serial port object as a standard component. :) 
But also, when I was looking for certain libraries/gadgets in preparation 
for a project, I found more C# stuff. As far as reports go, for example, 
add-ons for Delphi are available, but seem to be somewhat outdated. I 
realize this is a very subjective assessment, based on anecdotal evidence.

>>> Well, then what header does the UART library include to find the
>>> constants that matter to it (and only it)?
>>
>> I would put them in uart.h. Or, perhaps, I don't understand your 
>> question?
>
> I think I meant "the constants that matter to it, but that are provided
> by the project and not the library."
>
> In general, utility modules need to get some information, often about
> pin assignments or maybe buffer sizes, number of peripherals to use,
> whatever.  So uart.c (e.g.) needs to include those from somewhere.  If
> the project modifies its shared copy of uart.h, then a later SVN Update
> will require merging, which is annoying.  If the project simply says
> "Hey, you have to define UART_PIN somewhere, and I'll try including
> something called main.h, whatever that is", it could work but seems a
> little messy.
>
> So I list the things uart.c needs defined by the project in a separate
> uart-consts.h file, that the project duplicates and owns, and that is
> included by either uart.c or uart.h.  SVN Update won't require merges,
> because this is committed to the project, not to the reuse library.  But
> it contains boilerplate defines and comments describing what's needed.

OK, I see now. I agree that project-specific definitions and constants 
shouldn't be in uart.h. However, I solve the problem with an Initializer 
object that I mentioned before.

The way I look at it, ideally it shouldn't be Uart's responsibility knowing 
about the environment it is being used in -- in order not to violate the 
principles of loose coupling and tight cohesion. Someone else should set up 
its pin assignments, buffer sizes, put a value in its baud rate register, 
etc.

Main.h doesn't seem like an appropriate place for this code. So, the code 
goes inside the Initializer object, which is project-specific. Once the 
program starts up, main.c calls a procedure called 
Initializer_InitializeAll(), which in turn calls (for example):

    p_InitializeAdc()
    p_InitializeUart()
    p_InitializeI2c()

...which are private functions inside the initializer.c module, and change 
from project to project. p_InitializeUart would then call functions inside 
the Uart module, such as Uart_SetBaudRate(), Uart_SetTxBufferSize(), etc, as 
well as take care of the pin assignments.

I hope this makes sense.

Vitaliy 

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist