1. Home
  2. Embedded Programming
  3. Linux + Control bus?

Linux + Control bus?

I think it's hard to ask for help when you are truly confused. I apologize = if this question is poorly worded, I don't have enough knowledge to phrase = it right.

I have carried out circuit analysis on PCBs with CPUs but never designed a = circuit that contained them, I am hoping to change this.

I know there are other lines on CPUs that are involved with a variety of si= gnalling but hopefully it's a safe statement to say that most are either ad= dress lines or digital bus lines.

My question is based on logic such as this:

If there was a CPU with 16 digital lines and 24 address lines and that CPU = was on a board that had two 16 bit memory devices. 8 of the 24 address line= s could be conceptually divided away to create a control bus. The control b= us could activate these devices and others one at a time by enabling them a= nd disabling them through tri-state logic.

If this is correct, I am wondering how Linux is used in the embedded world = were a designer will likely not use X86 and a PCI bus but rather their own = control bus? I am assuming that when Linux is compiled, certain configurati= ons are assumed and lines are allocated based on this. Is there a way to co= mpile Linux so that the number of address lines to access memory can be spe= cified? and lines to access other chips can be used as desired?

So just as an example. If there was a 32 bit CPU, could 16 bits be used to = address devices and 16+ lines be used to form a custom control bus that mig= ht control the state of numerous devices on the board?

Thanks for reading-Patrick

Reply to
Patrick
Loading thread data ...

I've been staring at my poorly worded question for a while. I think a bette= r way of phrasing this might have been:

How do operating systems divide hardware resources by address? Linux must a= ssume it is installed to some sort of memory and writes back to itself but = this would require knowledge of the address lines of the device it's loaded= on. Then in the embedded world it needs to access devices but how would it= know where they are, how is this specified?

Reply to
Patrick

way of phrasing this might have been:

assume it is installed to some sort of memory and writes back to itself but this would require knowledge of

needs to access devices but how would it know where they are, how is this specified?

The method you describe is quite common in both the embedded and non-embedded worlds for suitable devices. It's referred to as "memory mapping" the device, because its control port appears as if it were just a part of memory and is read and written as memory.

In the system I currently work on, we have an FPGA mapped into memory for instance, essentially forming a very large communications buffer for various purposes. (I work on the Linux side so don't ask me how the FPGA handles its side :-))

Even the good old 386 PC used memory mapping for several purposes, and the addresses of the control ports were well known, being a defined part of the IBM PC ISA architecture.

With Linux, specifically, you wouldn't use the data and address lines directly but would have some sort of memory controller chip to drive them. I think in fact that's likely to be true of any modern system whether Linux-based or bare metal, due to the needs to juggle timings, access and refresh. But for Linux it's essential as the kernel makes strong assumptions about being able to re-map and translate virtual memory addresses for various purposes.

How does the software know where the devices are mapped, then ? That's usually hard coded into a board-specific file that provides the addresses. Often it's as easy as a #define with the device base address, for commonly supported memory mapped devices. Some embedded Linux systems also make use of "Device-Tree" which is a structured hierarchical method of defining the devices that are part of a system. It's common on PowerPC and is starting to be used on ARM Linux.

Nick

--
"The Internet, a sort of ersatz counterfeit of real life"
	-- Janet Street-Porter, BBC2, 19th March 1996
Reply to
Nick Leverton

Hi Nick

Thank you for your excellent, detailed answer. I have several terms to search for now, to look for ways to do this.

Have a great day-Patrick

Reply to
Patrick

In addition to what Nick said, there is perhaps some confusion in how you are viewing memory mapping of peripherals.

One doesn't really use the address bus as "control" except in isolated instances, and then only in conjunction with whatever read and write strobes exist.

Usually what one does is one decodes part of the address bus into an enable signal; this enable signal, in conjunction with the read and write strobes and whatever remaining address bits are relevant go on to be used by the peripheral in question.

Most hardware peripherals are designed to be memory mapped, so they have data, address, and select strobe inputs.

Actually, most hardware peripherals these days are either already built into the microcontroller along with the microprocessor, or are programmed into an FPGA -- but when you go to connect up that FPGA, it'll talk to address, data, possibly enable, and certainly strobe.

--
Tim Wescott
Control system and signal processing consulting
www.wescottdesign.com
Reply to
Tim Wescott

Many thanks to you to Tim!

Reply to
Patrick

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.