First, giving the exact error message (copy it verbatium from the output of the toolchain) would have been helpful.
On Wed, Mar 13, 2013 at 10:09 AM, [email protected] <[email protected]>wrote: > Hello, > > I am trying to obtain something similar to how the timers are > implemented, a number of generic modules and a central module that can > communicate with them with commands/events. > > My central module should > be a generic module with a parameter, always instantiated using > uniqueCount, so that only one instance is actually created. > That isn't how generics work. If you define a module as generic you have to instantiated it using the "new" keyword. What that actually does is create an instance (each is numbered starting with 0) that effectively duplicates the code. Generic is essentially a glorified macro if you are familar with the concept of a "macro". > This module > should provide a parametrized interface to wire the many generic > modules to it. > You don't want a generic. Rather you want a central module that provides a paramerterized interface and each client has its own unique client id that is the "port" into the module. No generic involved. > > My problem is that with my wiring, I can seem to call > commands, but when I try to signal events, the compiler claims that the > event is not connected (but with the same wiring calling the command > works). > This is occuring because you haven't defined the default for TestInterface. Since TestInterface includes an event and TestInterface is paramterized ([uint8_t]) you have to tell nesc what to do with all 256 possible wirings into this interface. When you actually wire in that is an explicit wiring and nesc knows what code to generate for that. But it doesn't know for all the other cases. Unless you provide a default clause. see below. > > I did a minimal application as a proof of concept, so I have > an interface that defines one command and one signal: > > interface > TestInterface { > command uint8_t call_test(uint8_t p); > event > uint8_t event_test(uint8_t p); > } > > Then i have one module that uses the > interface, which is meant to be instantiated many times: I'm pretty sure that you don't want this generic but is what you want to be paramerterized. > generic module > UserC() { > uses interface TestInterface; > uses interface Boot; > > uses interface Leds; > } > > implementation { > uint8_t last; > > > event uint8_t TestInterface.event_test(uint8_t p) { > last = p; > > return 0; > } > > event void Boot.booted() { > uint8_t > r = call TestInterface.call_test(0); > if (r == last) { > > call Leds.set(0); > } > } > } > > And the > central module, provides the interface > Not generic. The problem with generic is when you do a "new", you don't have a way of remembering what the instance is called. So unless you use the reference immediately (via the "as" clause in the "component" statement) you have no way of capturing the name. > generic module ProviderC(uint8_t max) { > provides interface TestInterface as TestInterface[uint8_t num]; > uses interface Leds; > } > > implementation { > command uint8_t TestInterface.call_test[uint8_t num](uint8_t p) { > static uint8_t l = 0; > > call Leds.set(l++); > signal TestInterface.event_test[num](l); > return l; > } > * default event void TestInterface.event_test[num]() { }; * * * > } > > In the end I have some > wiring to make it stick together > > configuration TestAppC {} > > implementation { > components LedsC; > components MainC; > > > components new UserC() as U0; > components new UserC() as U1; > > > components new ProviderC(0) as P0; > > P0.Leds -> LedsC; > P0. > TestInterface[0] <- U0.TestInterface; > P0.TestInterface[1] <- U1. > TestInterface; > > > U0.Boot -> MainC; > U0.Leds -> LedsC; > > > > U1.Boot -> MainC; > U1.Leds -> LedsC; > } > > > Could someone tell me > what is wrong with my code? > Thanks > > > Invita i tuoi amici e Tiscali ti premia! Il consiglio di un amico vale più > di uno spot in TV. Per ogni nuovo abbonato 30 € di premio per te e per lui! > Un amico al mese e parli e navighi sempre gratis: > http://freelosophy.tiscali.it/ > > _______________________________________________ > Tinyos-help mailing list > [email protected] > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help -- Eric B. Decker Senior (over 50 :-) Researcher
_______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
