Framework for Synthesis of Host-Assisted Scripting Engines for Adaptive Embedded Systems

1. Framework for Synthesis of Host-AssistedScripting Engines for Adaptive Embedded Systems Jiwon Hahn, Qiang Xie, Pai Chou Center for Embedded Computer Systems, UC Irvine CODES+ISSS September 22, 2005 Rappit

2. Embedded Systems Host-involved Standalone GPS tracer Toy ATM Medical Device Embedded systems Sensor-net Set-top box Copier Printer Battery emulator Vending machine Disk drives Hybrid MP3 player Cell phones Digital camera PDA

3. Embedded Systems Programming • Current Methodology • Low-level programming (e.g., C, assembly) • Single processor, platform specific approach • Unchanged for decades! • Drawback • Time consuming on re-inventing low-level abstractions • eg., registers, timers, interrupts, I/O ports • Error prone • Requires frequent firmware update • Programming flash or burning EEPROM • In-field configuration unsupported • Not adequate for emerging large-scale, distributed, adaptive embedded systems

4. Our Solution: Scripting • High-level programming • Human readable • Utilize platform-independent APIs • Productivity gain • Interactivity • Easy communication between user and platform • Enables efficient test/debugging • Reconfigurability • No compilation or F/W update required • In-field configuration • Code size reduction • Scripts are usually x5 to x10 shorter than C code [Ousterhout] • Reduce memory size & cost, power

5. Enter bootloader mode Enter bootloader mode F/W coding F/W coding Compile Compile Erase Flash Load Program Verify Flash Erase Flash Load Program Verify Flash Erase Flash Load Program Verify Flash Execute Execute Restart Board Restart Board Enter bootloader mode Load script Load script Compile Restart Board Write script Write script Execute Execute Comparison of design flow • Traditional: 6-stage debugging cycle • Scripting: 3-stage debugging cycle Synthesize scripting engine (F/W)

6. Scripting vs. Runtime Overhead • Scripting for General Purpose Computers • Assume unlimited resources • Full feature scripting engine for convenience • Slower than system programming language • Scripting for Embedded Systems • Limited memory, CPU, power, … • Need scripting engine optimization • Host assist • Language subsetting • Library subsetting • Efficient memory usage • Scripting may be even faster than compiled code!

7. Outline • Related Work • Our Methodology • Code Synthesis • Runtime environment • Experimental Results • Conclusion • Future Work

8. Related Work * H: High level I: Interactivity R: Reconfigurability C: Code size PO: Performance overhead compared to compiled implementation

9. Overview of Rappit Runtime System Provide user one integrated environment of the host and target systems

10. Runtime Flow Comm Link Host Target Platform Platform Control msg (cmd) Command I/O Script Packetizer Depacketizer Scripting Engine Parser Msg Generator Platform Response Response I/O GUI msg (ack) Parser Depacketizer Packetizer Scripting Engine

11. Scripting Engine Optimization • Language Subsetting • Host Assist • Library Subsetting Host Parser/ Msg. gen. “print reg1” “0x4A0x01” • User friendly • Easy to parse at node • Efficient command representation (compact packet size and runtime repr.) MCU Full-Featured Component Library Customized Library RF Interrupts RF SPI ADC UART GPIO Interrupts UART GPIO ADC LCD Joystick Sensor1 Sensor2 Sensor1 Dataflash

12. Our Methodology System Description 1. Code Synthesis Flow Code Synthesizer 2. Runtime Flow Component Library Application Primitives GUI Host- Assisted Parser MCU Scripting Engine Script

13. I. Code Synthesis Input Application Description Communication Description Architecture Description Code Synthesis Component Library Interactive Language Output Binary Executable Host S/W (Parser, MsgGen, GUI, …) Target F/W (Scripting Engine, Native Routines, …) Compatible Message format Target System Host

14. I. Code Synthesis - Packet Format Examples • Command Packet Format • Response Packet Format Command Message Format Response Message Format

15. II. Runtime Environment Host MCU Msg Gen. Parser Packetizer/ Dispatcher Packetizer/ Depacketizer Scripting Engine packet IDE Cmd prompt GUI Component Library Admission Controller Packet Manager Native Routines command response

16. II. Runtime Environment – Scripting Examples • Interactive port setting >> PORTA[2] = 1; PORTA[2] = 0 # toggle clock >> PORTA[1] = 1 # set port A pin 1 >> PORTA[0] # read input pin 0 >> PORTA[2] = 1; PORTA[2] = 0 # toggle clock >> PORTA[0] # read input pin 1 • System configuration >> mcu.sysclock = 1 MHz # set system clock speed >> uart.baudrate = 9600 bps # set baudrate for UART >> rf.power = -5 db # set RF tx power >> rf.speed = 1 Mbps # set RF throughput >> rf.config # query the configuration {’payload’: 1, ’power’: -5, ’speed’: 1000000, ’channel’: 100, ’mode’: ’TX’} • Scheduling >> every(50 ms, ’sample’) >> stop(’sample’)

17. Experimental Setup I • Atmel ATmega169 • 8-bit MCU @ 8MHz, 512B EEPROM, 1KB SRAM, 16KB program flash • Connected to dataflash, speaker, sensors, joystick, LCD • USART serial link at 9600 baud • AVR Butterfly board AVR Butterfly w/ Wireless module AVR Butterfly

18. Experimental Setup II • HC12 Controller in Mini-FDPM • FreeScale16-bit MC9S12NE64 • 16KB RAM, 64KB program flash • SPI, I2C, GPIO, ADC • Built-in Ethernet Mini-FDPM HC12 Host Computer Ethernet

19. Metrics and Modality • Observation Metrics • Execution Modality

20. Experimental Results - Code Size • Experiment • Test code included 100 cmds, 9 instruction types • Same subroutines and packet handlers used • Code size observed from compiled code and memory map • Result • Scripting engine is a thin layer • Rappit achieves big reduction in application code size

21. Experimental Results - Execution Speed • Experiment • Relative comparison by setting host timer with same conditions • Same experiment repeated several times • 3 different applications • Result • Batch mode scripting can be faster than native! • Same pattern observed in other experiments • Observed up to 25.7% speed-up • Memory access could be the key

22. Summary of Results • Code size reduction • Performance overhead components analysis 1: fast 2: tolerable 3: slow (bottleneck)

23. Conclusion • Scripted the embedded systems • High-level programming • Interactivity • Reconfigurability • Code size reduction • Overcame scripting overhead • Host assistance • Script subsetting • Library subsetting • Effective memory usage • Synthesis • Systematic generation of scripting environment

24. Future Work • More dynamic scheme • Allow new native code to be added • Mapping to richer set of syntax • Eg., http to allow access as web device • Memory management in the target • Set evaluation order to reduce memory usage • Parser optimization • Parsing simplicity vs. expressiveness

25. Thank you!

26. Backup Slides

27. Code Size of Each Rappit Components

28. Goals of Embedded Systems Fast development cycle High Adaptability Low power Embedded System Goals Low cost Small size High performance (speed)

29. I. Code Synthesis • Input: system description script # example: pin mapping for an RF module mcu = MCU(ATmega169) # instantiate an atmega169 MCU import RF # load a transceiver module rf = RF(nRF2401) # instantiate nRF2401 transceiver rf.CS = mcu.PORTB[0] # connect the chip select pin rf.CE = mcu.PORTB[1] # connect the chip enable pin rf.DR1 = mcu.PORTB[2] # connect the data ready pin rf.CLK1 = mcu.PORTF[1] # connect the clock pin rf.DOUT1 = mcu.PORTF[2] # connect the data pin • Output: Rappit software for host, firmware for the target platform

30. I. Code Synthesis • Command Format • Machine-efficient representation of a command • Application-specific • Pain to reinvent for each application • Need auxiliary code to handle each command format • Automatic Command Format definition • Synthesizer generates the command format • Coherent between host and target • End user syntax parsed and mapped to command format in the host parser • Command format interpreted by the target scripting engine