• About PSAS
• Get Involved!
• Schedule
• Projects
• Presentations
• Mailing lists
• Contact us

• Teams
  • Airframe
  • Avionics
  • Communications
  • Ground
  • Payload
  • Propulsion
  • Rocket Science
  • Safety
  • Software
  • Uncertainty
  • Regulation
  • PSU Student Club

Attending: Tim, Andrew, Glenn, Sarah, Jacob, Bart, Jamey (various other software team people).

Microcontroller Summary

Last Friday, Glenn and Sarah met to complete the ARM microcontroller comparision sheet. They thought that the Atmel 100 pin CAN and USB chip was the obvious choice, since the CAN chips didn't have a 64 pin version.

However, Andrew reminded them that they missed the STMicro chips. The chips are 64 pins, and can have either USB or CAN. Tim says the USB and CAN pins are the same, so they could easily be swapped out. We also looked at a GPS front end board that had a 100 pin ARM chip and realized that a 100 pin package is just too big. The board needed four layers to handle the 100 pins.

Since the 64 pin STM microntrollers were looking to be the best candidates, we needed to decide whether to choose a USB only or a CAN only microcontroller.

Communications Bus Discussion

(Basic rehash of older discussion.)

Bart's points about CAN:

• bandwidth is an issue - we're currently using at least 40% of CAN's 1Mbps bandwidth, which limits what new things we can add to the rocket.
• no kernel-level specification

Bart's points about USB:

• complex
• fast
• we aren't going to be using a lot of the bandwidth, so we won't be pushing the specification.

Andrew's worries about USB:

• latency - if the bus goes down, how long will it take to enumerate the nodes?

With CAN, we'll be redefining a higher level of abstraction over the CAN hardware. With USB, the upper layer is already there.

What about starting with USB?

Andrew worries that picking a good physical layer for USB could take time. Bart pointed out that we don't need the PHY for testing. It was proposed that we make room on the schematic for the PHY, but just use a jumper for the first prototype boards. Glenn proposed that we use a mini-A USB connector for the prototype boards, since the normal connector might be too big.

If we actually start using the USB nodes, we'll have to create an adaptor (or perhaps an active node) to connect a normal USB cable to our special locking connectors on the nodes. We'll also have to get a "wall wart" to convert house current to the 19V the nodes require.

It was proposed (and accepted) that we do a schematic for both CAN and USB layouts, but only fab the USB board at first. The software team can test the USB node front end, and if it doesn't work out, we still have the CAN layout.

Misc

STM has source code for USB.

Philips' 64 pin CAN microcontroller doesn't have the same footprint as STMicro's 64 pin microcontroller.

Action Items

Get the STMicroelectronics parts in the ARMs spread sheet.

Carefully go through the STM microcontroller data sheets. Look for show stoppers and things that are obviously broken. Also be on the look out for vague sections--these may indicate weaknesses in the design. Look for things we're giving up by not choosing another part.

Specifically look for:

• fast flash
• the process type (e.g. 0.1u process)
• power consumption
• Serial boot (also known as UART boot, ROM boot, and boot loader)
• wait states on the memory (1 wait state means you lose one clock cycle)
• PLL
• real time clock
• has eCos been ported to it?
• drivers
• software tools support (and what license is it under)
• internal interrupt handling

There should be a critique of this microcontroller on the wiki by next Wednesday.