Hmm... still having issues:
- I did the tos-install-jni and it no longer says that it does not find
toscomm, but the baud error is still there.
- I made a make clean and make again inside the jni folder and it created
new libtoscomm.so
- I manually copied libtoscomm.so inside the jre path (and removed the old
one that was there) but nothing, still it does not recognize 500000 as a
valid baudrate.
Another strange thing, if a use make install inside jni, it copies the
libtoscomm.so and libgetenv.so in /usr/local/lib/tinyos/ is it the normal
default behavior?
Ugo
2014-09-04 12:48 GMT+02:00 András Bíró <andras.b...@ucmote.com>:
> 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
