498

Proposals, Sitsang

Proposals

• The big problems were:– Perspective

• You know a lot about what you are doing. Don’t assume the reader does too.

• Provide a high-level overview of the system from a technical viewpoint.

– A diagram can be really handy. – Indication of interface can be useful too (CAN or whatever)

• One group had a glossary, not a bad idea.

– Organization• Have an outline. Make it clear to the reader you have a

structure so they can find stuff.• This is especially true for the executive summary.

Proposal • (Problems continued)

– Consistent level of detail• Lots of detail on some parts with none on others was fairly

common.• More details somewhere is fine, but let the reader know why.

– Writing• Keep the sentence structure simple. • Do a good job proof-reading.• Use consistant terms

– Eg. It is either a “system” or a “subsystem”

– Executive Summaries• Often missed major points. • Make a list of the 3-5 things you want to get across and be

sure you do that. • Be organized here. Depending on the nature of the proposal

no one may read past this if it sucks.

Proposal

• Good stuff– 2 groups covered information in a level of

detail that I could understand their projects well.

• Other group never gave me a high-level picture.

– 2 groups had good solid technical writing• Other had complex sentence structure and related

grammar errors.

Project Deadlines

• 10/10– Today

• 10/19– Milestone 1

• All “proof of concept” stuff done. You should have all of your hardware.

• 11/9– Milestone 2

• Project should be working on the breadboard. Maybe a few glitches or additional features to add

• 12/5– Formal Demo to class (suit, tie etc.)

• 12/7– Design expo

• 12/12– Project report

Sitsang

• Admin– Lab will be up by Thursday night.– Will be due by Nov 14th

– Second lab will be due by Dec 1st, up by Oct 24th

Sitsang: What is it?

• It is a StrongARM based board with tons of I/O (Ethernet, USB, joystick, buttons, accelerometer, color touch-screen LCD, Flash memory, CF socket, etc.)

• It runs Linux by default.

• It comes with qpe as the windowing enviornment.

Sitsang: What will we do with it?

• We’ll have you:– Install a bootloader– Install a file system (to flash)– Install an OS (to flash)– Write programs that directly use the Unix

device interface• Frame buffer, LCD backlight, accelerometer.

– Modify the OS drivers• Lab 2, will involve changing the OS.

Issues for lab 1

• Protocols, wires and more– There are two bootloaders for the board

• Redboot is simple, works, and what comes with the board.• Uboot is more complex and powerful, but doesn’t work

entirely.– There is a lab 0 you can look at if you want to mess with the

bootloader.

– We will simply install the pre-built Redboot bootloader.

• You use a program called Jflash (from Intel) over a parallel port to JTAG interface.

• Not fast.

Bootloader

• Once you have the bootloader installed you can talk to it via a serial interface– Again to JTAG.– Still not fast, but good enough for command-

line interface.

• Works just like any other command line interface

Redboot commands

• fconfig – Prompts you for information like

• Bootscript• Local and server IP address• GDB connection port

– For doing remote debugging

• Etc.

Redboot commands: load

• Copies into SDRAM from over the network.– load [-r] [-v] [-h <host>]

[-m <tftp|xmodem|ymodem>][-b <base address>] <file name>

– -r indicates raw data (not sure what no –r would be!)– -m specifies protocol– -b where to start putting it– <file name> what file to get– -h specifies host to get it from.

• Uses fconfig host by default.

Redboot commands: load (continued)

• We use tftp (trivial file transfer protocol).– CAEN doesn’t support this, so we have our own linux

machine serving the needed files.– You CAN upload to our server too.

• Of course, CAEN doesn’t support a client either…

• The Sitsang seems to have problems with our network.– It _often_ drops the transfer. I had to try a fair

number of times to get it to work.– -v gives you a good hint if things are going to work or

not.– Found changing ports helped oddly.

Redboot comands:fis commands

• Init – put flash into an initialized state

• List– display current usage of flash

• Unlock– unlock a section of flash memory

• Erase– erase a section of flash memory

• Create– create a new section in flash memory

• Load– load a section of flash memory into SDRAM

• Go– Jump to a specific address to continue execution

Redboot commands:fis command arguments

• Many of the sub-commands use the same flags. Common flags are listed below:– -b

• Specify an address in SDRAM

– -f • Specify a flash memory address

– -l• Length of data to modify

• Many of the fis commands are really slow (hey, you’re talking to flash!)

Examples:

• fis unlock -l 0x02800000 -f 0x00200000 – Unlock 0x200000 bytes of memory– Takes a while (1 minute?)

• fis create JFFS2 -b 0xa0200000 -l 0x02800000 -f 0x00200000 – Copy 0x200000 bytes of memory into flash– Takes a long while.

You will…

• Need to use the bootloader to – Download the file system & kernel

• “load” using tftp

– Write them to flash• Via the fis commands

– Start linux• The first time this takes a LONG time.• Just wait.

So you’ve got linux…

• Now we can start the real part of the lab.– It is helpful to do the previous stuff because:

• It removes some of the magic • If you need to change the file system or (more likely) linux

you can.• You have a slightly better understanding as to what’s going

on.

– We want to finish writing a simple game.• Uses the accelerometer as input• Plays game on the board.• We provide a working version so you can see what it is to do.

Linux devices

• /dev/**** contains a bunch of devices on any linux system.– /dev/ttyS0 is the serial port, etc.

• In general when you read from a device it supplies you with a bunch of data.– For example, our accelerometer will dump an X and a

Y value, each 32 bits. So you get 64 bits.– You can open the file for reading and grab stuff that

way.• Ideally you dump it into a data structure you can deal with.

#include<stdio.h>#include<fcntl.h>

main(int argc, char * argv[]){ int i=0; struct me { unsigned int x; unsigned int y; } tmp; int fd; fd=open("/dev/acce", O_RDONLY); read(fd, &tmp, sizeof(struct me)); printf("X=%u, Y=%u\n",tmp.x, tmp.y); close(fd); //close device file}

But it gets worse.

• Sometimes you have to deal with VERY complex data structures.

#include<linux/fb.h>#include<fcntl.h>#include<stropts.h>#include<sys/ioctl.h>#include<stdio.h>main(){ struct fb_fix_screeninfo fb_f;

if(ioctl(fb,FBIOGET_FSCREENINFO,&fb_f) <0) { printf("OPPS: No fixed screen info\n"); exit(1); } printf("ID String: %s\n",fb_f.id); printf(" Length of frame buffer mem %u\n",fb_f.smem_len); ...

Figuring this stuff out is hard

• You need to find the right include file – There is also often documentation somewhere.

• For the frame buffer, you need a way to read and write the memory– We use a function called mmap.– It basically lets you have access to certain I/O

registers (big ones for fb).– Handles all of the timing and related magic for you.