Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFE: tos-diagprint - decoding printf and diag messages in python #259

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

mcerveny
Copy link
Contributor

tos-diagprint program displays "printf" (see PrintfC.nc, AM_PRINTF_MSG=0x64)
and "diag" (see DiagMsgC.nc, AM_DIAG_MSG=0xB1) messages
(like PrintfMsg.java + DiagMsg.java).

tos-diagprint program displays "printf" (see PrintfC.nc, AM_PRINTF_MSG=0x64)
and "diag" (see DiagMsgC.nc, AM_DIAG_MSG=0xB1) messages
(like PrintfMsg.java + DiagMsg.java).
@gnawali
Copy link
Member

gnawali commented Apr 1, 2014

Should we keep this file updated:
https://github.com/tinyos/tinyos-main/blob/master/doc/txt/tep135.txt

with these message ids?

@andrasbiro
Copy link
Member

The most basic apps are using AM ids from the reserved pool (e.g. RadioCountToLeds: 6). But it would be great to actually have some reserved/free pool, I had bugs because of this. But this probably deserves a new ticket.

@mcerveny I like this tool, but could you add the support of the usual "-comm " argument?

@mcerveny
Copy link
Contributor Author

mcerveny commented Apr 1, 2014

The arguments are analyzed in https://github.com/tinyos/tinyos-main/blob/master/support/sdk/python/tos.py#L436. The same syntax (without -comm and encoded connectivity in argv[1]) is used in tos-deluge.

@andrasbiro
Copy link
Member

Oh, I didn't realize, so it's based on tos.py. I'm not sure if it's a good idea to add more dependency to it: The "other" SDK seems to be the official, as far as I know, tos.py only used by deluge.

@mcerveny
Copy link
Contributor Author

mcerveny commented Apr 2, 2014

Hello.

On Wed, 2 Apr 2014, András Bíró wrote:

Oh, I didn't realize, so it's based on tos.py. I'm not sure if it's a good idea to add more dependency to it: The "other" SDK
seems to be the official, as far as I know, tos.py only used by deluge.

Hmmm.

  1. tos.py - synchronous call "read()", SDK is easy to use
  2. "other" == tinyos/message/MoteIF.py ? - callback "read()", SDK is designed to work with mig/nescc-mig and "serialforwarders" (sf)

Is there some documentation for (official) python SDK ?
Should tos-deluge be reprogrammed to "other" SDK (and tos.py removed) ?

M.C>

@andrasbiro
Copy link
Member

These are very good questions. Having two SDKs for the same language is confusing, one of them should be at least marked as deprecated, but the best thing would be to remove it.
If we have to choose from them, I would choose the MoteIF.py based, because it supports mig, and uses mostly the same naming as the java SDK, which is the best known.
No, I don't think there's any documentation - tinyos is not really good in that :)

But I'm not really familiar with python, I just did some stuff in it for fun. So there might be very good reasons to remove the MoteIF based SDK, and add mig support to tos.py, I don't know.

@phil-levis
Copy link
Contributor

Python always was a bit of an undocumented step-child, for Deluge support. mig support is pretty critical. Serial forwarders end up being pretty important if you want to do IP-based communication/forwarding.

I think the basic idea was that tos.py was for Deluge and tools, while MoteIF was for applications. Not sure what we should do here...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants