[Tinyos-2.0wg] TinyOS 2.x WG/07.5.2006 Meeting Notes
Vlado Handziski
vlado.handziski at gmail.com
Thu Jul 6 13:22:35 PDT 2006
TinyOS 2.x WG/07.5.2006 Meeting Notes
------------------------------
Agenda
------------------------------
- beta2 status, net2 next steps
- Long-term toolchain maintenance (David G.)
- TEP review process/schedule (Alliance, David C.?)
- Serial communication (Vlado, from last week)
- Resource arbitration status/evaluation (Kevin)
- SID interfaces and HAL effects (Jan)
Participants
------------------------------
- Phil Levis
- David Gay
- Vlado Handziski (note taker)
- Kevin Klues
- Ben Greenstein
Next Meeting Agenda
------------------------------
- Moving TEPs out of draft
Discussion Notes
------------------------------
Phil:
- New RPMs were on the agenda...
- Kristin is going to do it for the beta
- net2 workshop at the end of the week. Goals: specification of
protocols, header fields, structures...
- discussion about tool-chain has been started on the list
David:
- I sent an email earlier...
- historically tools done by David and packaging by Kristin
- we need someone to take over tools and packaging since he and
Kristin are not available
- there is some interactions, needs cooperation
- we can split per platform: linux/cygwin
- tinyos tools are stable but someone needs to make small fixes
- Vlado raised the issue of the msp430 tools
Vlado:
- msp430 tools are ok, python changes should be updated for final
release
David:
- nesC has been maintained by him
- task is making package RPMs
- we need people available on short notice
- very responsive especially close to releases
- what about TU Berlin taking packaging for linux?
Vlado:
- we have done something similar for the eyesIFX kits under contract
from Infineon
- the infrastructure is there, last updates done in February when
contract ended
- we don't have any experience with windows/cygwin and we are not able
to take upon that task
- it can work only if we split the packaging per platform
- before we give a final agreement, we need to find a student wiling
to do it
Phil:
- what about testing platforms. Should the packager do the testing?
Vlado:
- platform guys should test it, they have the knowledge
Phil:
- some pretesting can be done, making sure this compiles for
platform...
- Kristin is not a developer so this was sometimes an issue.
David:
- is stable when you package it up
- so who can do cygwin?
David:
- will talk with AR about cygwin
- there are requests for windows distributions
- we have to keep this on our mind, but no one has volunteered to do
the work
Phil:
- next item is TEPs. We need to make a longer schedule for reviewing
TEPs to move them out of draft.
- start with 101, 102, 103 and move forward.
- what is a good rate?
David:
- one per week
Vlado:
- one per week if other items on the agenda, two can be done if not
David:
- we need to make clear that if someone is interested in a technical
issue in a TEP, he has to take part in the call
Phil:
- we need to agree on the technical issues.. the rest can be ...
- next week we talk 101/102
- depending if Jan is back
Phil:
- the alliance TEP has started to specify the review process for TEPs.
- once the chair decides it is ready, it goes to the Steering
Committee.
- they select a member that is not involved in the TEP development to
take the lead
- talked to David about that.
Phil:
- Vlado has raised an issue with the serial stack last week
Vlado:
- on double buffered platforms, the event for putDone is not the same
as "all data has been sent"
- we faced an issue when
Phil:
- Ben do you understand the issue?
- on msp430, double buffering, you get event when ready to take the
next byte, not when it is sent.
- So you can shutdown the UART before it is sent.
Ben:
- what are the solutions
Phil:
- separate events
- have split control
David:
- how to implement event when you have to loop?
Phil:
- No way to get event that signals that the queue is empty...
Vlado:
- export HAL level isEmpty
Phil:
- problem with HAL not being platform independent
Vlado:
- this is not a problem
Phil:
- What about dummy byte in stop
Vlado:
- other side has to take the garbage
Ben:
- what about timer?
David:
- split control in the HPL busy loop using a task
Vlado:
- this can happen also in normal operation
Phil:
- sending is fine, problem is interaction with power
David:
- knowing the transmission is done is useful
David:
- we can go with stop/stopDone in the midterm but we might not solve
this
David:
- how do you tell the HPL that you want this to be sent completely
David:
- what about split phase isEmpty
Phil:
- would need to send a task for platforms that don't have double
buffering
Vlado:
- we need to make distinction about the semantics
David:
- all serial comm, queues, makes this distinction
Phil:
- maybe we should talk over email
All:
- OK!
David:
- will check if ATmega if double buffered
- it is and has HW event for TX empty, msp430 does not, it has only a
flag
Phil:
- what is the status with the Resource?
Kevin:
- I said I will send a list, but this has not been done
- we here discussed a lot about the interfaces
- today we set down and went through the interfaces and came with a
solution
- the resource interface looks the same
-
Resource Controller changes not to have request or
ImmediateRequest<http://tinyos.stanford.edu:8000/ImmediateRequest>
- now granted goes without explicit request
- before, idle was signaled and the RC had to make explicit call
- now granted goes directly
- when he gets requested he decides if he releases or not
-
same happens for
ImmediateRequest<http://tinyos.stanford.edu:8000/ImmediateRequest>.
The PM will then release
Phil:
-
lets talk about
ImmediateRequest<http://tinyos.stanford.edu:8000/ImmediateRequest>.
- AR says not needed.
David:
- Henri is using it.
Kevin:
- I could not understand his code. He is not going back to request if
the first call fails
-
ImmediateRequest
<http://tinyos.stanford.edu:8000/ImmediateRequest>does not carry a lot
of overhead now
David:
- sounds like a good solution
Kevin:
- for evaluation we need to talk to Henri
David:
- goes to EPFL, can talk with him
Phil:
- it might be in the serial
All:
- and the radio
Phil:
- Kevin, can you write this up?
Kevin:
- yes
- no overhead if no PM
Phil:
- ADC/SID alignment issue
- problem when we want to use them at lower levels
- SID TEP requires values to be left shifted
- this is problematic at lower levels when we don't have the info
- solution: interface should not specify this
- sensor boards TEP will specify this
- HAL2 will use interfaces without this
- Jan looks to be fine with the decision
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.millennium.berkeley.edu/pipermail/tinyos-2.0wg/attachments/20060706/095ed659/attachment.html
More information about the Tinyos-2.0wg
mailing list