[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Newbie -- Accessing Hardware Ports



Don wrote:
> Okay, I have managed to get 'hello world' to work under both psim and 
> on a PPC2A using the ppcn_60x BSP.  Now I am trying to branch out and 
> exercise the board by flashing some LEDs.  Code snip looks something 
> like:
> 
> {
>     volatile unsigned8 *pLED_Control;
> 
>     pLED_Control = (unsigned8 *) 0x00000860;
> 
>     while(1)
>     {
>         *pLED_Control = 0x0F;
>         /**  wait loop  **/
>         *pLED_Control - 0x00;  /** LEDs should blink on & off  **/
>     }
> }
> 
> Unfortunately, nothing happens.  I have also tried reading some board 
> configuration locations (8-bit) and got back values that are no where 
> near what they should be.  
> 
> Now I have concluded the problem is one of the following, but have not 
> been able to find documentation to support or refute the position:
> 
> 1)  RTEMS does not allow direct manipulation of hardware ports via 
> pointers.  (But there has got to be a way around this as the COM port 
> works.)
> 

It does.

> 2)  That region of memory is being cached.  In which case I need to 
> figure out how to access the hardware registers to keep that region 
> from being cashed.
> 

See further down.

> 3)  I have screwed up basic C code.
> 

You did: the third line should be

   *pLED_Control = 0;

Changing '=' for '-' obviously makes this a NO-OP ;-)

> 4)  There is a board configuration problem.
> 
> Anybody willing to hazard a guess as to which is the most likely 
> problem?

Assuming that your original C-statement was correct and your
posting contains a typo:

5) It could be possible that your LED port is not mapped.

     a) where is your LED connected to: ISA, PCI or some ASIC
        mapping it to the PPC/CPU bus? In any case, the bridging
        device (PCI bridge, ISA bridge or the ASIC / memory controller)
        must have a mapping established so you can reach the LED address
        from the CPU bus.
     b) The MMU must have a mapping for the physical address (on the CPU
        bus) of the LED. The MMU subcomponent (BAT or page table)
        providing that mapping must be marked 'cache inhibited' and
        'guarded'.

Usually, a combination of firmware/monitor and RTEMS/BSP startup code
takes care of configuring the bridges and the MMU. Note that there are
special macros for accessing PCI or ISA space which you might want to 
use (if your LED happens to be on one of these busses).

HTH
-- Till

> 
> Thanks!!
> 
> Don
> 
> 
> www.dynamic-controls-inc.com
>