[Tinyos-2.0wg] TinyOS 2.x WG/07.5.2006 Meeting Notes
Ben Greenstein
bengreenstein at gmail.com
Thu Jul 6 15:54:42 PDT 2006
Vlado,
Would you like to start a discussion on your proposed serial communication
enhancements?
Ben
On 7/6/06, Vlado Handziski <vlado.handziski at gmail.com> wrote:
>
> 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
>
>
> _______________________________________________
> Tinyos-2.0wg mailing list
> Tinyos-2.0wg at Mail.Millennium.Berkeley.EDU
> https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-2.0wg
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.millennium.berkeley.edu/pipermail/tinyos-2.0wg/attachments/20060706/e30bbe4d/attachment.htm
More information about the Tinyos-2.0wg
mailing list