Difference between revisions of "Meeting 21-08-2013"

From MAGEEC
Jump to: navigation, search
m (Present: KIE, MG, AW, JB, JP, SC, SH)
m (Present: KIE, MG, AW, JB, JP, SC, SH)
Line 67: Line 67:
  
 
* <nowiki>[JP,SC,AW,KIE,SH] clarify database elements and make a final specification the necessary columns and entries.</nowiki>
 
* <nowiki>[JP,SC,AW,KIE,SH] clarify database elements and make a final specification the necessary columns and entries.</nowiki>
* <nowiki>[AW] migrate GDB interface to MI from RPI.</nowiki>
+
* <nowiki>[AW] migrate GDB interface to MI from RPC.</nowiki>
 
* <nowiki>[AW] migrate python to expect.</nowiki>
 
* <nowiki>[AW] migrate python to expect.</nowiki>
 
* <nowiki>[JB, AW, JP, SC] work on pitch and solution for the GDB interfaces</nowiki>
 
* <nowiki>[JB, AW, JP, SC] work on pitch and solution for the GDB interfaces</nowiki>

Revision as of 16:14, 21 August 2013

Meeting at Bristol: 21st August 2013

Present: KIE, MG, AW, JB, JP, SC, SH

  1. Technical items    - update on the interface (Simon C to lead)
    • Discussion of the results database in the framework:
      • Distinct databases for different compilers
      • Compilations options should include the source code
      • An entity relationship diagram would help map e.g. testID->runID
      • runID+testID will generate a unique key for top table
      • index is also a unique key.
      • One could be eliminated.
  •    - discuss data gather phase (Simon C, James, Ashley)
    • Top level framework gains specified flags (Q: how to select tests from them?)
    • Interface to GDB should be “MI” not RPC.
    • Heated discussion about best location for the power data to feed through into the GDB runners, and the most appropriate language for implementation (Boost python vs Tcl + C++)
      • Similarities to GDB regression.
      • Expect was discussed
        • Can solve timeout problem too
      • DejaGNU test suite is migrating to python
      • JB was concerned that our flow might not be accepted by the community.
  •    - demo of energy capture framework (Ashley)
    • Ashley gave demo of existing implementation
      • Good starts.
      • Monitor commands may be ignored.
      • Need to ensure that the framework is generic for platforms we have not yet used.
      • Expect may solve lots of coding work here.
      • Config file strategy is a good.   - instrumenting the Embecosm kit (James)
      • AVR first target
        • 8 bit and “different”
      • MAGEEC on SDCC compiler on ?8051?
        • Potential UoB group project in this area   - acceptance testing of initial framework and user flow
      • Embecosm guys to take away copy of kit to give feedback on the code base and current approach.
      • Initial acceptance of the current framework implementation to tie up Ashley's current efforts. No immediate requirement for porting to MI or Expect.
      • Tidy up with extra wiki pages, blog posts and video of the demo.
  • Moon's ML update
    • Been in contact with MILEPOST authors.
      • Felt that PCA was not a good approach – lost features
      • Decision trees were promoted for speed and simplicity by the other experts.
    • Support-vector models being explored.
    • How to feed the energy data into the framework – where does it come from initially? Current sample size too small to do decent learning.
  • 3. Public side    - Andrew's licensing and open data questions
    • Adopted CC BY-SA 3.0 for hardware.
    • Data sets to GPLv3
    • Open hardware logo (and license?!) on any new hardware adopted.
    • Prototype BEEBS web page (email sent about). Any comments welcomed.   - MAGEEC public mailing list — Working with open source embedded projects
    • We decided to allow external contributions, provided they are supplied under an identical license to the underlying project work.
    • Data contributions should be siloed by producer. 2. Preparation for quarterly review
    • Review on 4th --- Ashley will be away; Moon will be here.   - Simon C will take us through the steps    - review milestones, work packages, risk register    - we'll need a first cut at finance report and budgeting
      • Available flickr stream for photos


  • Could we work with open source embedded projects to mutual benefit? I.e. we help them increase their energy-efficiency and benefit from an exemplar use case. One possible candidate could be OpenEnergyMonitor(for their battery powered emonTX wireless sensor board). http://openenergymonitor.org/emon/
    • Was substantial enthusiasm for the general idea of working with related projects. The OpenEnergyMonitor does not look immediately compatible with our project goals, but we are willing to explore other candidates as well as this in some more detail.
  • New open mailing list @mageec.org
      • Use for technical discussions
  • mageec.org structure needs overhaul
    • home page should be description of project.
    • Indices should be moved. e.g Design->design overview not index.
  • Then after the MAGEEC meeting, I need to discuss 4. Latest versions of power and benchmark papers
    • Discussed and updates will be emailed.

Actions:

  • [JP,SC,AW,KIE,SH] clarify database elements and make a final specification the necessary columns and entries.
  • [AW] migrate GDB interface to MI from RPC.
  • [AW] migrate python to expect.
  • [JB, AW, JP, SC] work on pitch and solution for the GDB interfaces
  • [JP] look at SDCC compiler
  • [JP] get AVR working at Embecosm end
  • [AW] blog post on benchmarks used
  • [All] sign up for new mageec.org mailing list at: http://mageec.org/cgi-bin/mailman/listinfo/mageec
  • [AB,JB] restructure mageec.org navigation
  • [SH] write next blog post.
  • [SH] prepare project expenditure and forecast in line with reporting headings
  • [SC] exploitation plan to wiki
  • [JP] publish benchmark paper V1 on arXiv by Thursday evening.