Download - ppt slides
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.