You are right, Mike.
Following your advice, I have successfully compiled the test application
"Blink" for Deluge. Just sharing with the community, here is what I did:
1. Clone the git repository using command "git clone git://
hinrg.cs.jhu.edu/git/mike/tinyos-2.x.git" (I failed to get this to work
through my university's proxy though)
2. Put the repository in /opt
3. Back up the following files:
- /opt/tinyos-2.x/tos/lib/net/Deluge/extra/micaz/TOSBoot_platform.h
- /opt/tinyos-2.x/tos/lib/net/Deluge/extra/avr/InternalFlashC.nc
- /opt/tinyos-2.x/tos/lib/net/Deluge/extra/mica2/NetProg_platform.h
- /opt/tinyos-2.x/tos/platforms/mica/sim/PlatformC.nc
- /opt/tinyos-2.x/tos/platforms/mica/sim/MeasureClockC.nc
4. Replace the above files with the files from
http://yee.wei.law.googlepages.com/deluge-tossim-patch.zip. The following
is some explanation why steps 3 and 4 are necessary:
- TOSBoot_platform.h contains the macro SPM_PAGESIZE which for some
reason, the build process does not know how to substitute the
proper value
for. The proper value of SPM_PAGESIZE for MICAz is 256.
- InternalFlashC.nc and NetProg_platform.h access MICAz's EEPROM
directly, so some code needs to be commented out using #ifndef TOSSIM
directives.
- PlatformC.nc only provides the calibrateMicro() command and not the
entire Atm128Calibrate interface, which is for some reason required by
Deluge.
- MeasureClockC.nc does not originally provide the whole
Atm128Calibrate interface and has to be modified to do so.
The above four steps are all that is required.
2009/3/24 Chieh-Jan (Mike) Liang <[email protected]>
> It depends on what you really want to simulate. Deluge is a combination of
> two components: A network protocol that disseminate objects, and a
> bootloader that loads the received objects. The internal flash is needed by
> the bootloader, but not necessarily the network protocol.
>
> Mike
>
>
> On Mar 23, 2009, at 6:54 AM, Yee Wei Law wrote:
>
> I found the root of the problem.
>> • /opt/tinyos-2.x/tos/lib/net/Deluge/extra/mica2/NetProg_platform.h
>> calls the hardware specific function wdt_enable() directly.
>> • /opt/tinyos-2.x/tos/lib/net/Deluge/extra/avr/InternalFlashC.nc
>> calls the hardware specific functions eeprom_is_read(), eeprom_write_byte(),
>> and eeprom_read_byte() directly.
>> There are no TOSSIM-equivalent implementations of these functions. Hence,
>> TOSSIM support for DelugeT2 remains unavailable.
>>
>>
>>
>> 2009/3/23 Yee Wei Law <[email protected]>
>> Hi Mike,
>>
>> Thanks very much for your help. I have downloaded the code from your git
>> repository. Although the application Block (apps/tests/storage/Block)
>> compiles successfully, I am still having several problems with Blink
>> (apps/tests/deluge/Blink). The most serious problem of all is the following:
>>
>> /usr/include/unistd.h:238: conflicting types for `intptr_t'
>> /usr/avr/include/stdint.h:142: previous declaration of `intptr_t'
>> In file included from /opt/tinyos-2.x/tos/chips/at45db/sim/At45dbC.nc:43,
>>
>> The file /usr/include/unistd.h is included by TOSSIM whereas the file
>> /usr/avr/include/stdint.h is included by tos/chips/at45db/sim/At45dbP.nc.
>> What I haven't figured out is why this is not a problem for Block, but is a
>> problem for Blink.
>>
>> Might you have an idea?
>>
>> Best regards,
>> Yee Wei
>>
>> 2009/3/20 Chieh-Jan (Mike) Liang <[email protected]>
>>
>> The TOSSIM I have in my GIT repository might be helpful to you. Here is
>> what I sent to the mailing list a while ago,
>> http://mail.millennium.berkeley.edu/pipermail/tinyos-help/2008-December/037688.html
>>
>> Mike
>>
>>
>> On Mar 18, 2009, at 10:49 PM, Yee Wei Law wrote:
>>
>> Hi Razvan,
>>
>> Continuing this thread from last year, I have spent some time finding a
>> way to simulate DelugeT2 on TOSSIM. My understanding is there are two main
>> difficulties: (1) the storage, (2) the radio. The following summarizes my
>> (unsuccessful) experience so far:
>>
>> The storage
>> The make rule for TOSSIM is in $TOSROOT/support/make/sim.extra, which does
>> not depend on the target 'build_storage', hence the storage-related files
>> are never generated. This is easy to solve:
>> • First, do a "make micaz" to have the storage-related files
>> generated, and copy all the files (which most importantly include the header
>> file StorageVolumes.h) from build/micaz to simbuild/micaz
>> • Replace the value of SPM_PAGESIZE in
>> $TOSROOT/extra/micaz/TOSBoot_platform.h with 256 (the value "256" can be
>> gleaned from the generated file build/micaz/app.c)
>> • Modify the file BlockStorageManager/BlockStorageManagerC.nc to use
>> FakeBlockReaderC and FakeBlockWriterC instead of BlockStorageC
>> The radio
>> This is where I got stuck. The file extra/NetProgC.nc uses CC2420Config
>> explicitly, what should we use to substitute for CC2420Config?
>>
>> Thank you.
>>
>> Regards,
>> Yee Wei
>>
>> 2008/8/27 Razvan Musaloiu-E. <[email protected]>
>> Hi!
>>
>> On Tue, 26 Aug 2008, Ning "Martin" Xu wrote:
>>
>> > Hi all,
>> >
>> > I wonder if there's any support for external flash memory content
>> > simulation with Tossim for MicaZ motes in TinyOS 2.x. Would somebody
>> > give me some instructions on this? Thank you.
>>
>> I'm not aware of any Tossim support for storage but you can try to use the
>> FakeBlockReaderC and FakeBlockWriterC from tos/lib/net/Deluge to avoid
>> using the real storage.
>>
>> --
>> Razvan ME
>> _______________________________________________
>> Tinyos-help mailing list
>> [email protected]
>> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
>>
>> _______________________________________________
>> Tinyos-help mailing list
>> [email protected]
>> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
>>
>>
>>
>> _______________________________________________
>> Tinyos-help mailing list
>> [email protected]
>> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
>>
>
>
_______________________________________________
Tinyos-help mailing list
[email protected]
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
