You're on a good track, but you deleted the wrong file. You should replace
libtoscomm.so. If you compiled and installed tinyos-tools from source, just
run "sudo tos-install-jni". Or you can do it by hand: Search the compiled
file and copy it to "tos-locate-jre --jni"
Another trick I usually use is the c based serialforwarder ("sf"), which
never had this limitation.And naturally, this will be included in the upcoming release. But still, if you have a bit of time, use serialactivemessage. Printf is mostly designed for debug, not for data download. Andris On Thu, Sep 4, 2014 at 9:52 AM, Ugo Maria Colesanti < colesa...@dis.uniroma1.it> wrote: > Wow, I was not aware that uart could handle that kind of speeds, I tried > even 1Mbps and still works... that's cool :) > On that point I have one question: > I just installed the more recent tinyos-main and compiled the tools > folder, but the java PrintfClient still doesn't support speeds over > 230400bps (it gives me "TOSComm JNI library runtime error: baud_to_enum, > bad baud rate"). However, if I go in > tools/tinyos/jni/serial/NativeSerial_linux.cpp which seems to be the file > that generates this error, greater speeds are enumerated. I removed > tools/tinyos/java/tinyos.jar just to be sure it was taking all files from > the compiled sources and not from jar, but it still continues to give me > the same error... any hints? > I managed to make the PrintfClient to work using the c version of serial > forwarder and binding the java PrintfClient on it. > > Ugo > > > 2014-09-01 13:28 GMT+02:00 András Bíró <andras.b...@ucmote.com>: > > Hi Guys, >> >> Fastserial doesn't provide faster communication, it's just using much >> less blocking (atomic) segments, so it doesn't mess up important >> interrupts. This is very useful when you want to use it as a really fast >> basestation. You can turn it on with the fastserial extra (e.g. "make iris >> fastserial"). >> >> You can also try to increase baudrate with the PLATFORM_BAUDRATE constant >> in the makefile. I'm not sure about the telosb, but the ucmotes usually >> works well with "CFLAGS+=-DPLATFORM_BAUDRATE=500000U", probably even better >> than with 115200, because the RFA1's clock generator can generate round >> numbers better than "traditional" badrates with the integral oscillator. >> >> I never really used the flash with serial dumping, but I used radio >> downloading a lot (again, on ucmotes, but probably every stm25p based mote >> is similar): Flash was always significantly slower than the radio, which >> works at theoratical 250kb/s rate, but it has at least 10% overhead, >> probably more. >> >> Your original problem was with printf: You don't know if it finished the >> communication, or not. On top of that, I think printf does the numbers to >> ascii conversion on mote. With AM, you eliminate the conversion overhead, >> and you know you can send the next message when you received the sendDone >> event. >> >> So, long story short: use AM, I don't think you'll need anything else. >> But you probably want to add a sequence number or address to every package, >> so you can check for data loss. If there is data loss, you'll also need >> some kind of ack (probably AM's ack is trustable on serial as well, but I'm >> not sure). Don't forget to turn off every other serial communication (e.g. >> debug printfs). >> >> Using the UART directly can work, but it's a bad idea: You'll probably >> need framing, escaping, CRC, and so on: You'll end up with a new serial >> stack, which is very similar to the current. >> >> Oh and one more thing: The default maximum payload is 28 byte. This is >> mostly because RAM: every message_t allocates 28B+overhead. On serial, the >> overhead is around 10B, so basicly you have about 25% overhead, which is a >> lot. You can increase it with the constant TOSH_DATA_LENGTH. I think the >> physical maximum on radio is 114B (the maximum message length is 127B, but >> you have headers and footers). It's unlimited on serial, but usually 100 or >> 110 is a good value. >> >> Andras Biro >> http://ucmote.com >> >> >> >> On Mon, Sep 1, 2014 at 11:39 AM, Ugo Maria Colesanti < >> colesa...@dis.uniroma1.it> wrote: >> >>> I think you will manage to do everything with the standard serialAM >>> stack, but just in case, have a look to tos/lib/fastserial which should be >>> a more efficient serial interface than the standard one (i never used it). >>> It should support both, ucmini and telosb. >>> I think it can be re-wired to serialAM. You can also consider to write >>> raw bytes directly on the uart without the serialAM stack ahead. >>> Bye, >>> >>> >>> Ugo >>> >>> >>> 2014-09-01 11:24 GMT+02:00 Alessandro Sivieri < >>> alessandro.sivi...@gmail.com>: >>> >>> >>>> On Mon, Sep 1, 2014 at 11:08 AM, Ugo Maria Colesanti < >>>> colesa...@dis.uniroma1.it> wrote: >>>> >>>>> How big is your flash? What hardware are you using? >>>> >>>> >>>> I'm using the telosb and the ucmini, the former with 1MB flash and the >>>> latter with 2MB. I think I will try the active message this week and see >>>> how it goes. >>>> >>>> >>>> >>>> -- >>>> Sivieri Alessandro >>>> alessandro.sivi...@gmail.com >>>> http://sivieri.wordpress.com/ >>>> >>> >>> >>> _______________________________________________ >>> Tinyos-help mailing list >>> Tinyos-help@millennium.berkeley.edu >>> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help >>> >> >> >
_______________________________________________ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
