Hi Daniel, FlashBridgeViewer can definitely be improved to at least twice as fast if some work is done on the software, and even faster if it is redeveloped. Maybe the best strategy to do this is to take the FlashBridge tinyos/java app templates and make a new copies of them so you can hack it and spin your own.
First let me explain how FlashBridgeViewer works right now so you understand what improvements can be made. In a single operation, FlashBridgeViewer only lets the computer request as much data from the flash as it can fit into the payload of one message. So say you type in <flashbridge> -read 0x0 0x6000 in the java app on the computer - the computer drives the operation, breaking up 0x0-0x6000 into many commands, each command requesting 20 bytes of data at a time. The first command the java app sends the mote is "read 20 bytes starting at 0x0" and the mote responds with those 20 bytes. Then its next message says "read 20 bytes starting at 0x14" and the mote pops back with the next 20 bytes ... and so on. As you can see, this is very inefficient. For every 20 bytes of useful data coming across, there are two 28-byte payload messages sent over serial. This ineffiency probably relates to the halting problem you're having. The computer is always much faster than the mote. What happens if the computer sends the next read command before the flash is ready to be read or before the mote is ready to handle another inbound message? The mote might ignore or drop the command, and the entire process fails because there's nothing in place to recover. To improve this particular issue, the java program should be setup to retry if it hasn't heard back from the mote after some timeout period. This would involve some simple thread wait(..) to retry commands on the java end. Although I don't have time to re-write FlashBridgeViewer, I have implemented a high speed, reliable serial data transfer. Unfortunately, it was written for a customer so I don't have the ability to hand it out to the open source community. But what I can do is explain how it works so you can take the ideas and build a version of it yourself if you want. First, the commands and the data packets should be separate structs/AM types. FlashBridgeViewer has one packet that is supposed to contain both the commands and the data - and that's inefficient because when we want to send only data, its sending empty useless command fields too. A data packet should contain one byte that tells the length of the valid data, and then the rest of the packet should be filled with data. The command packet can be whatever you want - something to hold the basic flash commands and their parameters. Next, the data transfer app on the mote should contain the logic to divide large blocks into many packets. As I explained, right now this is the computer's job. This does away with 2 packets transferred per 1 received packet of data, and will automatically double throughput. By typing in "-read 0x0 0x6000" on the computer, that single command should be the only thing sent to the mote, and then the mote should take over and stream off all of that data without using any kind of acknowledgements (no acks if serial is the only thing in play - of course, use acks if you're transferring data over the radio). Finally, if you're into changing the message payload size, feel free to do that but it's going to require some java hacking to all your java end to communicate with the mote. And obviously serial baud rate plays a huge part so if you can increase that, do. Hope that points you in the right direction, -David -----Original Message----- From: Daniel S. Menasche [mailto:[EMAIL PROTECTED] Sent: Thursday, November 16, 2006 7:47 PM To: [EMAIL PROTECTED] Subject: flashbridgeviewer Dear David, We have been using extensively the flashbridge viewer during the last month in order to implement some experiments with TinyNodes (we have also used flashbridge viewer with TMotes and the comments mentioned below also apply). Our experiments involve storage of data in the eeprom of the TinyNodes: an at45db chip. Flashbridge viewer is a really flexible and convenient component. Thanks for providing that. However, we are having some problems while reading data from the flash to the computer using the serial port and the Serial Forwarder. Flashbridge viewer sometimes halts. Besides, the throughput is really small! Maybe that's because the format of the packets that we use to transmit data among the nodes is the same as the format used to transmit data across the serial port (packets of 29 bytes). We use the following command to read data from the flash: java com.rincon.flashbridgeviewer.FlashViewer -read 0 0x6000 To sum up: this command takes a long time to perform its task and sometimes halts in the middle of the process (and then we need to restart the reading). Do you have any suggestion to improve the throughput and/or avoid the glitches in the reading process? Thanks a lot! Best regards, Daniel _______________________________________________ Tinyos-help mailing list [email protected] https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
