From LinksWiki

Contents 1 Sparta 1 Design Document 1.1 IO-Specifications 1.1.1 System-Level Inputs 1.1.2 System-Level Outputs 1.1.3 Communication Interfaces 1.1.4 Optional Interfaces 1.2 Component Selection 1.3 External Hardware Interfacing 1.4 Pin Mappings 1.5 Software 1.5.1 General Notes 1.5.2 Functionality Listing 1.5.3 Task and Priority Mappings 1.5.4 Function Prototypes and Dependencies 1.6 Key Links 2 To Do List

[edit] Sparta 1 Design Document

The Sparta1 Board is a design in progress, as a proposed replacement for the use of LEGO RCX modules in the EPADS 1 course at YCP. Intended to not only provide slight increases in functionality to the current program, the project is intended to allow the motivation of further discussion of more traditional ECE topics during the first semester, as well as serve as a test development board with low initial risk.

[edit] IO-Specifications

[edit] System-Level Inputs

• Single 9-12VDC Supply via Screw Terminals
  • May want to consider dual supply - something like a 9V battery with regulator for logic, and a battery harness for the motors, with separate grounds connected by a 39 Ohm resistor or so to minimize ground looping. This would require a re-design on how to handle the wall-based power supply however - share it, via jumpers, or some such?
• Buttons
  • System Reset
  • USB Reset
  • uP Erase
  • "Execute Program"
  • "Other" Button (e.g. change LCD display mode)
• Switches
  • Mains Power
• Sensors
  • 4 Analog Input Ports - Corresponding to those on the RCX

[edit] System-Level Outputs

• LCD Display - Proposed 16x2 LCD with backlight
• 4 Brushed DC Motor Output Ports (2 wires each) - Corresponding to those on the RCX
  • Approx 1A sustained load at 9V
  • Full H-Bridge functionality on each output port
• Speaker/Buzzer
• Status LEDs
  • Mains Power
  • "Program Executing"
  • Low Priority Heartbeat
  • High Priority Heartbeat
  • Error Code LEDs

[edit] Communication Interfaces

• Serial to LCD Display (Automatically handled)
• USB to PC (Upload)
• Serial to PC (Debug)

[edit] Optional Interfaces

• SPI for Accelerometer, etc.

[edit] Component Selection

The board will be fabbed out of standard 1/4Oz FR-4, double sided, and is expected to be approx 5" x 5" in size. It was discussed that a clean and understandable layout is more important than a tight board for increased understanding.

The primary processor will be an ARM7 processor, the AT91 SAM 7X256, and more specifically, likely the "Make Controller" from Makingthings.com. This allows us to avoid the use of SMT components (hopefully entirely). Things to check include the actual pin counts on the controller, as while the SAM7X has what we need, I need to make sure they're brought out to the edge of the design for mounting.

Motor driving could be simple L293 drivers, or something more advanced, such as the L6202 which is capable of much more current, and thermally limits itself. As a note, there are key distinctions to watch for drivers - the L293's don't have on board diodes (only the L293D's do) and in fact, the appboard actually uses SN754410 chips, which have diodes and provide the 1A. The L6202 sounds more appealing daily - and yet, is only a single full h-bridge per chip. I once saw an 18602 or some such that I should recheck as well...

Inputs are still up in the air. I'm uncertain whether or not to use op-amp input buffers or not. Update: To ensure high-impedance and controllable inputs, op-amps are a good idea

I'll need a USB Type-B socket to allow easy mating to the computer.

I'll be using screw terminals for the majority of connections - will these be removable, as per the make application board? Not certain at this time.

Input and output voltage ranges as well as regulated supplies are still up in the air. Worst-case, I'll be needing nearly 5A from the power system - but not all needs to be regulated. In particular, the 5V and 3.3V lines are important, but the high-end of the L293's is not. An adjustable regulator on each one would obviate the need for PWM, admittedly. Something to consider greatly, though the addition of 4 tunable pots may be a bit much.

The LCD targeted is currently sold by SparkFun, using the SparkFun serial LCD backpack. It's proven quite powerful so far, and easy to obtain. Mounting may be an issue.

Buttons may be simple, with no major specification.

The USB disconnect is still theoretical at this point, and a 4PST switch may be necessary to break connections reasonably. Safer yet would be one that was a 3PST switch, leaving the ground housing connected at all times.

The light sensors are by far the most detailed portion of this simple project. They require at least 5V supply, given for at least 2-3 ms (safe would be 4ms, no?) and then you remove supply and go to a 10kOhm pull up impedance. You wait 10 microseconds, and then read the voltage at the node, which will depend on the current being drawn into the phototransistor. Higher currents (brighter lights) will pull more current, resulting in a lower sensed voltage.

The touch sensors are simpler, and are just contact switches with an 800 ohm impedance in line with them. This not only limits short-circuit current (in case someone plugs one directly into a L293, for example), but still nicely overwhelms the pull-up resistor used in the light sensor configuration. Total voltage division would then be 800/10800 ohms, or 0.07 Vcc (0.37V @ 5Vcc or 0.66V @ 9Vcc).

[edit] External Hardware Interfacing

The motors will be driven by the SN754410 chips, with the use of extra external diodes still up in the air. I'll have to see how the SN754410 handles overcurrent during its high-Z mode, as that's the primary determining factor, really. If it doesn't need the extra diodes to handle motor flythrough during high-Z, I'll skip them.

The inputs will be buffered by op-amp buffers that will hopefully scale the input to a 3.3V max from the 5V operating state it runs at. The 5V supply for sensors will be a separate 7505 chip, which, while causing more noise, will give a separate point of failure should it over drive and short out. The 7505 will need derippling capacitors on it, and share the digital ground plane.

The input op-amps may well need to be inverting amps, if I want to scale from 5V to 3.3V, as non-inverting amps will push things into a gain greater than one no matter what. I've never used a non-full-rail op-amp for an inverting amp before - I believe I'll have to level shift some how to make it work smoothly - some sort of y = mx+b situation, where vout = -3.3/5 * vin + 1.65V or some such. A bit of off-screen math indicates that it works with R1 = 100K, R2 = 66K, and Vref = 1.99V. More generally, Vref = 5*R2/(R2+R1) and R2 = 3.3/5 * R1, and I pick R1 to choose my input impedance. This works out to a 5V in = 0V out and 0V in = 3.3V out. Thus, nicely inverting.

The TLV2375 is a 16-pin PDIP package with 4 channels of input amplification, and thermal shutdown. More generally, I require only two channels on each of two chips, so the 14-pin PDIP 2373 would work as well. If pins are an issue, the 8-pin 2372 would also work, but doesn't feature thermal shutdown.

To make the light sensors work, I need a 10K Ohm pull up to 5V resistor, and the ability to 'sometimes' drive the sensing node to 5V myself. I could use the chip itself, but I hate to use the chip directly, given the isolation we've managed so far. A 5V pull up driver seems so much more appropriate. Again, we could use motor drivers for this, but to get 4 enables, I'd need 2 complete chips. Driver chips? Tri-state buffer chips? Sadly, I'm not seeing what I need, so it seems like the SN754410 is the way to go. I'll get four drivers, with two enables, and since I'm doing synchronous reading, it's not an issue. Still, I think I'll use two chips to get four enables, to make sure I've got the software flexibility later in the game. All told, then, I'll have 4 SN754410's, and one-to-two TLV2375 chips on board, as well as caps and resistors.

[edit] Pin Mappings

Pin Mappings are defined in an Excel spreadsheet, located here: [1] This is by no means a final document, merely a starting point to evaluate pin numbers and assignments, ensuring that the device will be capable of the final goal.

Since excel is such a bear, it looks like I'll be doing this in raw text format, Sparta1PinMappings.

[edit] Software

[edit] General Notes

Software is developed in C, exploiting what code is available from the Makingthings API, as well as developing a more purposed API for use in the project, tentatively hidden behind "EPADS1.h". Students will not have access to the OS proper, and will instead execute all code in their own low-priority task, tentatively titled "my_Program". Communication between other tasks and my_Program should all be handled by EPADS1.h functions, with no direct semaphore or shared memory structures used without a wrapper.

[edit] Functionality Listing

• Update LCD display periodically
  • Display is 16x2 screen, with format as follows:
    • Top row indicates all four output states, with 3 chars +space for each motor. E.g. "+5 Brk -10 Cst" (Speed ranges from -10 through +10, with Brk and Cst replacing Zero.)
    • Bottom row indicates system state, as well as input sensor ports. E.g. "R 3.3 1.7 0 3.3"
  • Display update would likely be appropriate at 10 times - 20 times per second. (50ms - 100ms update frequency)
    • 32 chars in 50ms is a fast char. 1.5ms per char, or 0.195ms per bit (6400 baud, give or take, full speed)
    • May need update-based refresh, rather than full-screen - don't want to overdrive the onboard IC.
  • Will want to bump up UART baud rate and update the start/splash screen to say something like (Line1)" YCP Sparta1 vX.X"(Line2)"EPADS1 Controller"
  • Bonus Feature: API Command to send text to the bottom row of the screen for finite time before it returns to normal. During this time, the top line alternates between readouts. Meant to be a 'dumb fire' command, it'll display for some integer seconds before returning to normal.
• Scan buttons periodically (or interrupt?)
  • Most buttons aren't oft-read - but screen updates for things like "USB Disc" may be helpful. Low priority feature.
  • Only real important button is the "Run/Stop" button. Even a 5ms poll would be more than enough for this - still, to limit overheads, leaning towards interrupt on this line.
• Handle PWM for motors consistently - perhaps develop acceleration profile utilities?
  • PWM will likely be handled in software, using a FastTimer callback to handle each motor if possible.
  • Using software PWM allows much finer grained control of Brk and Cst states, etc.
  • General pattern will be assume t0, set all pins to drive state. Sort motor turn off deadlines, and set timer for earliest. At timer, change pins, and reset timer to next event. Repeat.
  • Acceleration profiles can be handled at a higher level of abstraction, I'd imagine - wrapping the softPWM subsystem.
    • Think " Motor1.LinearRamp(int target_PWM_duty, int ms_to_get_there) "
  • Target PWM frequency is currently 20Khz to get it out of human audio range. Need to check datasheet for motor drivers to verify, but doubt they'll be that slow.
• Provide interfaces to the sensor systems and provide 'lock' functionality to avoid sharing of inputs between types.
  • Sensing is a tough call - basic analog sensing is highly disparate in functionality. This is very much the design's weak point currently.
  • Many types of sensor to support:
    • Touch
      • Supported through a standard sensing voltage divider configuration. Nearly any pull resistor of 330 ohms or more would be fine.
    • Lego Light
      • Complex power-and-release setup. Need far more work into this. Imagining a subtask will handle these guys synchronously - charge them all, read them at once kind of thing, to limit overhead. Keep a running buffer of values, or retrieve only when queried? Not sure.
    • CdS Cell?
      • This one also requires a compensating resistor, but the value matters far more. Have to check our range of CdS cells to get the range of operation as wide as possible.
    • Rotation?
      • No idea on this one.
    • Simple Voltage
      • This would be a direct bypass of the pull up-down resistor.

• Provide beep-gen subsystem
  • Need asynchronous behaviour
  • Simple beeps of Beep.Now(note_t note, int Octave, int duration_ms), Beep.Queue(note_t, int Octave, int duration_ms), Beep.Song(note_t * song_array, int * duration_ms_array, int num_notes)
  • Need to limit current and voltage on output so as to limit volume. I really don't want these things loud. Very very annoying. May also want to restrict to octaves 2-6 or some such.

• Provide a debug communication channel to the external Serial port
  • Simple Debug channel, running at 'reasonable' speed - 56.7KBaud, for example.
  • Debug functions such as "Serial.Send(const char * const format, ...)" that'll take printf style formatting and send it along.
  • We want to make sure we've got a simple terminal app for them to read from as well.

• Update status LEDs consistently
  • Simple enough - 90% of updates to status LEDs can be handled in the appropriate functions
  • Also provide access to LEDs.SetALL(int LED0, int LED1, int LED2) and LED.SetLED(int which, int value) to watch debug values.

[edit] Task and Priority Mappings

It seems we've got a few simple tasks, and some handled merely be library calls:

• Things that get their own tasks
  • PWM timing (200Khz tick) (Consider a 15Khz PWM freq, with 10 steps, getting to a min 150Khz (6.6us) tick to save effort. That can free up CPU time significantly). - Lower than the main task, actually.
    • This task is very much the most significant task in terms of CPU time. Optimizing this into hardware etc is something to keep in mind. If each call is only 4us including overhead, that's 66% of the CPU time. (4us = 4000ns = 100 CPU cycles!)
    • Additionally, since we have at most four motors to drive, we have at most one turn on time and four turn-off times. This means we've got a 15Khz PWM period with 5 callbacks per period, for an average load of 75K callbacks per second. (down from the worst-case 150Khz callbacks above). This helps significantly, and implies that the PWM step size need not be an integer 10 step situation - regardless of the number of steps, we'll be able to time it. It's not like we're relying on the aliasing of 50 motors into 10 slots to help us out here.
    • For more, see Sparta1PWMSystem
  • The Beep subsystem (~30Khz tick) - Also very low priority
  • LCD updating (5ms tick) - Lower than PWM, I should think. This will be buffered to the UART, meaning we should get this done without trouble.
  • Read buttons (arbitrary, so thinking 5ms tick piggybacking) - This can be very low priority
  • High Priority heartbeat (100 ms on, 900ms off yellow)
  • Low Priority heartbeat (100 ms on, 900ms off green)

• Things that are synchronous with execution. It would seem that this thread has higher priority than all other background threads. NO!. Can't do that. Can't trust students to make this thing sleep often enough. Gonna have to have this be the lowest priority thread then. That means starvation prevention on the part of things like PWM.
  • Serial-to-PC
  • LED updates
  • Analog Sensor Reading (tentatively)

[edit] Function Prototypes and Dependencies

[edit] Key Links

• The Make Controller Likely the brains behind the project
• The SparkFun 16x2 Red LCD Likely the display screen
• Make Controller Schematics
• Make Firmware API
• Details of the slide-on screw terminal connectors we'll likely use
• FidelSparta1Notes - Fidel's Notes on the project

[edit] To Do List

• Draw Schematics
  • Requires generation of many library components in EagleCAD
    • Does not require standardizing on vendor/model at schematic level - only pins
• Develop Software Library
  • Almost no prerequisites to this step. Can be done in parallel.
• Test Uncertain Details
  • USB disconnect via switch?
  • Ability to use second UART?
  • Configuring pull-up enable on input pins? Can we alternate between High-Z input and pull-up input in software easily enough?
• Do Board Layout
  • Requires vendor specification for parts
  • Requires board foundry specific information