Newbie -- Accessing Hardware Ports

[Don]

Till,

Looked at youir previous message also.  Yup, the '-' was a case of 
being a typo in creating the message.  Unfortunatley, my development 
machine is not hooked up to this machine so cut 'n paste is a bit of a 
chore.  

Also, I got a response form another individual who pointed out the 
missing wait loop after the second write to the LED register.  Again a 
typo.

See my embedded comment regarding the PCI space issue.

Thanks!!

Don





> A followup to my previous message.
> 
> I just had a quick look at your BSP. It seems that the on-board 
> registers are attached to PCI_IO space starting at port 0.
> Hence, you should be able to access your LEDs using the
> 
> outport_byte(0x860, (unsigned char)VALUE)
> 
> macro who does the necessary address translation (and IO barrier 
> instruction [this is not strictly needed for your LED example]) for 
you.

----------------------------------------------------------
Interesting!  According to the PPC2A manual, the port address (0x0860) 
is in "system memory space" (0x00000000 to 0x7FFFFFFF) and under the 
heading of "PCI Address Range" it says "No PCI cycle".  Looks like 
there is a disconnect between the BSP and PPC2A documentation.  BUT, 
this gives me the clue I need to chase down the problem!!
-----------------------------------------------------------

> 
> -- Till
> 
> 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.)
> > 
> > 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.
> > 
> > 3)  I have screwed up basic C code.
> > 
> > 4)  There is a board configuration problem.
> > 
> > Anybody willing to hazard a guess as to which is the most likely 
> > problem?
> > 
> > Thanks!!
> > 
> > Don
> > 
> > 
> > www.dynamic-controls-inc.com
> > 
> 
> 
> 
>