Embedded systems, interrupt schemes

[blasthash]

Alright folks,

Let me try and describe this the best way possible - I dunno if this qualifies as a strict operating system, but I decided to post it here knowing that it deals with many of the very same concepts I work with when writing my operating system exploits (or failures... ha).

Recently (and being a college student), I've found myself on the development side of a rocketry project with some friends, so I've decided to go to work writing the avionics/guidance controls and systems for the hypothetical (and hopefully, someday real) designs we've all put on the table. After considering a whole bunch of different options, something told me to go with some variety of x86 CPU and FPGAs for peripherals, I/O, system control, communication, and what-not. The hardware aspects I can figure out, but the thing that this system needs to 100% be classifiable as is an interrupt-driven system.

Therefore, I've been working on creating a whole slew of interrupt schemes for how the various components that will be utilized in FPGA/logic hardware will interact with the code that the CPU itself is running. While I can come up with the priorities and handling and what-not myself, I was wondering how I will actually create the IDT/GDT entries, store them and then load the address. I was thinking of jumping the system into Protected Mode for the 32-bit and increased memory capabilities as well as the LIDT/LGDT instructions, but those require that I have formed tables that are ready to address to.

In essence, this doesn't feel as much like an operating system as much as "interrupt soup" with some background code running. The primary goal is that the system be 100% error-safe (that is, Div0 and other faults are protected against/recoverable from - just read about the Ariane 5 for why that needs to be) and that it can coordinate on regular intervals, most likely via timer modules in the FPGA hardware.

One of the reasons I want this system to be as flexible as possible with its interrupt handling is so I can revise the interrupt generation in hardware as needed and add different ones that come on truly exceptional events. For example, if the rocket starts flying horizontally or upside down, that might throw an exception that causes a predefined action to correct it irrespective of the normal control loops.

Apologies for not putting more explanation or thought into here; more was floating around my head earlier and as soon as I sat down to type it, out it went. I suppose one of the allures of developing a system like this is that this is true "blank-slate" - there will be no code on board this system when constructed that will execute before the system goes, no BIOS, so everything has to be done from scratch. I understand this is an oddity of a project, so I'll make beer a symbolic bounty if any of you can help me toward embedded greatness (or the single-board computer circus, whatever you prefer).

[alexfru]

There're CPU manuals from Intel and AMD. They describe how system stuff operates and how it has to be programmed. Download and read them.

[Octocontrabass]

After considering a whole bunch of different options, something told me to go with some variety of x86 CPU and FPGAs for peripherals, I/O, system control, communication, and what-not.

Are there any x86 CPUs available that could be easily fabricated into your custom design? Otherwise, you'd be better off looking at an ARM CPU.

I was wondering how I will actually create the IDT/GDT entries, store them and then load the address. I was thinking of jumping the system into Protected Mode for the 32-bit and increased memory capabilities as well as the LIDT/LGDT instructions, but those require that I have formed tables that are ready to address to.

Run your code from ROM, put the tables in the ROM. Easy. (Or, if ROM is too slow, copy the code and data to RAM before setting it all up and running. Also easy.)

In essence, this doesn't feel as much like an operating system as much as "interrupt soup" with some background code running.

That's because you're not writing an operating system, just a single embedded application. (The low cost of embedded CPUs means that many devices that don't need a whole operating system are running one anyway. A lot of routers nowadays are actually small computers running Linux.)

I suppose one of the allures of developing a system like this is that this is true "blank-slate" - there will be no code on board this system when constructed that will execute before the system goes, no BIOS, so everything has to be done from scratch.

You can do the same thing on most PC motherboards by replacing the BIOS ROM with one you've programmed yourself. (Of course, you'll need things like chipset manuals in order to write your code, so it may only be an option on really old motherboards.)

[SpyderTL]

If I were designing a rocket flight control unit, I'm not sure I would want the system to be interrupt driven.

There's a reason why commercial pilots have a door that they can close and lock while they are flying -- they want as few "interrupts" as possible.

I would think that you would want a "real-time" operating system, with a tight loop state machine with a very limited number of states, and guaranteed execution time. And you would want to "poll" all of your input and update your outputs on a regular basis. Having interrupts will effectively "randomize" your execution, so that you could get slightly different results on every flight (even if all of your inputs were identical).

the thing that this system needs to 100% be classifiable as is an interrupt-driven system.

Is there any particular reason you are wanting to use interrupts (or need to use interrupts)? Is this a school project?

[blasthash]

Are there any x86 CPUs available that could be easily fabricated into your custom design? Otherwise, you'd be better off looking at an ARM CPU.

I've considered using ARM cores, and the SAMA5D3 has been a real candidate due to its integration and low-power considerations. But I'll be damned if I can figure out how the peripheral interrupts map into the standard IRQ vector at 0x18 (the standard ARM IRQ vector). I can understand the gist of running a single interrupt, that is, place the peripheral ID number into the Source Select Register (AIC_SSR), and the vector address at the Source Vector Register (AIC_SVR), in which case upon an IRQ at 0x18, AIC_IVR will offload to PC. But past that and into multiple interrupts, it gets real hazy. I understand the x86 interrupt scheme quite well, I've just never dealt with actually writing ASM code from 0x0.

Ideally, I'd like this system to be quick, but I'm still working the math on how fast "quick" needs to be; something tells me pushing clocks past 100MHz or so will come down to bragging rights and ego more than utility. Ideally, this system could be serviced by a 133MHz Am5x86 in a QFP package with 8MB of SRAM, but I wouldn't be unwilling to move up to a Pentium 3/4 if need be and if I can find a justifiable reason to move to PCI bussing. I really don't want to move earlier than the 80486 and its derivatives for the actual implementation due to the increased latency of a discrete x87, but for conceptuals and verification I could work on something as simple as an 8086 with some modifications to the CPU side of the FPGA transaction scheme.

If I decide to go to the Pentium 4 lower-power varieties, it may be very well worth my while to consider the 64-bit Atom chipsets in terms of utility and TDP/consumption. I've considered developing hardware with the Centerton steppings before but got constricted between design path, cost and time. The Stellarton steppings (Atom E6xxTs) are 32-bit but feature an on-chip Altera FPGA so those might be considerations. The only difficulty with that route is that they are getting hard to find (they were discontinued awhile back, and only offered as an OEM device) and there isn't a whole lot of documentation on how one would configure the CPU's Siamese twin FPGA.

Run your code from ROM, put the tables in the ROM. Easy. (Or, if ROM is too slow, copy the code and data to RAM before setting it all up and running. Also easy.)

Restating the question better would most likely be - how do I declare (in section .data or what-not) the IDTs and GDTs and then load with the address? Is this a bunch of dw's or what not or is there a better scheme for how to deal with it? (That is, how do I allocate space for and fill the positions within the context of the ASM program?)

One thing I plan on doing is getting a look at the original IBM PC BIOS source in the service manuals. Granted, the 8086 allowed up to 256 IRQ/NMI entries starting from 0x0, I might get ideas about how to construct such code in assembly based on how IBM did it in the original PC BIOS.

You can do the same thing on most PC motherboards by replacing the BIOS ROM with one you've programmed yourself. (Of course, you'll need things like chipset manuals in order to write your code, so it may only be an option on really old motherboards.)

Yes, but this is difficult (as you yourself acknowledge) mainly for the sole purpose that
a) BIOS units nowadays rarely are generic EEPROMs/Flash units, and have custom pinouts; most use SPI but it would be difficult to find out how to wire up a new ROM/flash. If I could get my hands on two scrap Pentium mobos of the same variety, it wouldn't be too hard to lift the BIOS and southbridge and get the southbridge specs, manual trace from the boot lines to the BIOS positions. That's much too much work unless I'm dead certain that's the exact scheme I'll be building the guidance off of.
b) Conversely, the support chip/bridge selection back then was much more prolific and much more implementation-specific, and so there's a lot less information on the older devices than the newer Intel platform hubs and stuff of the like. Getting information on some TI-specific bridges was what killed my plan to make a Win-compatible 486DX2 SBC back in the day.

If I were designing a rocket flight control unit, I'm not sure I would want the system to be interrupt driven.

There's a reason why commercial pilots have a door that they can close and lock while they are flying -- they want as few "interrupts" as possible.

I would think that you would want a "real-time" operating system, with a tight loop state machine with a very limited number of states, and guaranteed execution time. And you would want to "poll" all of your input and update your outputs on a regular basis. Having interrupts will effectively "randomize" your execution, so that you could get slightly different results on every flight (even if all of your inputs were identical).

Is there any particular reason you are wanting to use interrupts (or need to use interrupts)? Is this a school project?

No particular reason for interrupt drive, as right now (even though my friend eventually wants to take this out of amateur/high-power rocketry and into commercial concerns) it rests as a personal project. My reason for using interrupt drive was that the interrupts pushing most of the action through would be timer-based, so SPI reads from an accelerometer or gyroscope, for example, would occur on an even interval with calculable execution time.

I suppose I could do the main guidance (that is, control the inclination according to a set path) in state-machine style, where interrupts would signal another condition that was unforeseen and needs immediate action (hey! that sounds like the definition of an interrupt -__- haha)

Saying that the system needs 100% interrupt drive was probably too much of an overstatement, as there is definitely code that should be running asynchronous to the interrupt servicing (that is, the main body of code ), such as data logging and communication and all those such things. The system does need to be very interrupt-friendly, though, as there will need to be a bunch of different circumstances for which the CPU can respond, such as aberrant inclination, hazardous conditions (too high a temperature near fuel assemblies, for example), change in guidance path, aborts, etc.

[Brendan]

Hi,

Recently (and being a college student), I've found myself on the development side of a rocketry project with some friends, so I've decided to go to work writing the avionics/guidance controls and systems for the hypothetical (and hopefully, someday real) designs we've all put on the table.

Does this mean that you need something capable of handling higher altitudes (e.g. with radiation hardening) and can't use normal ARM/80x86 CPUs?


Cheers,

Brendan

[Octocontrabass]

Restating the question better would most likely be - how do I declare (in section .data or what-not) the IDTs and GDTs and then load with the address? Is this a bunch of dw's or what not or is there a better scheme for how to deal with it? (That is, how do I allocate space for and fill the positions within the context of the ASM program?)

That's exactly how you'd do it, especially since the assembler can do all of the address calculations for you.

a) BIOS units nowadays rarely are generic EEPROMs/Flash units, and have custom pinouts; most use SPI but it would be difficult to find out how to wire up a new ROM/flash.

Citation needed? Every motherboard I have ever seen uses a standard ROM chip of some type. Really old boards use DIP EPROM or EEPROM, more recent boards use PLCC Flash ROM, and really new boards use SO SPI Flash ROM. DIP and PLCC ROMs are usually in a socket, which makes them easy to remove and rewrite.

If I could get my hands on two scrap Pentium mobos of the same variety, it wouldn't be too hard to lift the BIOS and southbridge and get the southbridge specs, manual trace from the boot lines to the BIOS positions. That's much too much work unless I'm dead certain that's the exact scheme I'll be building the guidance off of.

There might be a reference schematic in the chipset datasheet. Motherboard designers tend to follow those pretty closely, from what I've seen.

[blasthash]

Hi,

Recently (and being a college student), I've found myself on the development side of a rocketry project with some friends, so I've decided to go to work writing the avionics/guidance controls and systems for the hypothetical (and hopefully, someday real) designs we've all put on the table.

Does this mean that you need something capable of handling higher altitudes (e.g. with radiation hardening) and can't use normal ARM/80x86 CPUs?


Cheers,

Brendan

I don't think so, at least not for the first few iterations. I don't think our first few rockets will get to any sort of altitude where that really becomes an issue, and if I have my wants and can have enough leeway with weight concerns it'll be shielded pretty heavily with impact casings and what-not.

The systems that I implement in the FPGA (and eventually, if I decide to move the entire system into complex logic) can be made more fault-tolerant. I've read several abstracts dealing with how to do so - most rely on making each logic module in the design triple-redundant and imparting a smaller core to decide between the three results. Essentially, it's a majority-wins sort of system - a corruption on one of the logic modules due to transients will be rendered null by the voting component of the other two modules.

The other reason I haven't really considered moving to rad-hard systems is due to expense. Those devices are filthy expensive.

As far as reliability in other areas, one thing I'd ideally implement is dual-head and dual-I/O systems; that is, two independent CPUs and two independent FPGAs, where one pair is "off", but in hot-standby mode. This will be easier than it seems. Via the PROCHOT#/THERMTRIP# pins and other routes, one can determine if the core has been shutdown. If the core shuts down, it releases a master line that continually holds the slave into reset, and the slave then takes control of the bus.

By making the system at least in part interrupt-driven, the safety element is increased - if the main timer polls the cores once every 100ms, the farthest "out-of-date" the slave core is after coming online will be 100ms.

Things to ponder.

[blasthash]

Would the ORG keyword be a good use for this task?

Citation needed? Every motherboard I have ever seen uses a standard ROM chip of some type. Really old boards use DIP EPROM or EEPROM, more recent boards use PLCC Flash ROM, and really new boards use SO SPI Flash ROM. DIP and PLCC ROMs are usually in a socket, which makes them easy to remove and rewrite.

I know first-hand from projects with old 68k Macintosh boards that they used standard-pinout mask ROM in many cases, and I definitely know about the E/EPROM. However, I've never been adventurous enough to scratch the BIOS sticker off a chip (the label manufacturers usually apply to their BIOS devices) and see if it fits a standard pinout.

I have tried looking for BIOS device datasheets, and the information isn't easily found. Knowing that sort of difficulty, I would be hesitant about saying that it would be the standard, typical PLCC/SOIC pinouts for SPI devices. That being said, I wouldn't cry too much if I blew one while trying to test it.

There might be a reference schematic in the chipset datasheet. Motherboard designers tend to follow those pretty closely, from what I've seen.

Yes, and the good thing is that Intel has gotten to be very open with many of their chipset references. I think a lot of them will even explain bus architecture down to the timing. What I'll probably end up going with for this design is a P3 (SL3KJ/SL3DW) where the bridge chipset is an FPGA. That way, I get everything accomplished using the least number of BGAs as possible.

[Octocontrabass]

Would the ORG keyword be a good use for this task?

That really depends on how you decide to do things.

I have tried looking for BIOS device datasheets, and the information isn't easily found.

That's because the vast majority of motherboards use (or are compatible with) standard EEPROM chips. I doubt any manufacturer would want to go through the expense of using a custom-pinout EEPROM in their motherboards.

What I'll probably end up going with for this design is a P3 (SL3KJ/SL3DW) where the bridge chipset is an FPGA. That way, I get everything accomplished using the least number of BGAs as possible.

If you're going to design your own chipset, you get to decide what type of ROM it works with. (And while you're at it, you also get to throw away all of that PC compatibility garbage. You weren't planning on running Windows XP on it, were you?)