Proposal for register validation technique

Hello all,
    We've started speaking about validating the specification of the register 
set for the NOUR project.  Right now no one has stepped forward who has
previous experience with bluetooth firmware, so I'm proposing a technique for
simulating the radio in software and helping us to get started working on the
algorithms and organization for firmware based on this register set.
    The BlueZ project for Linux (http://bluez.sf.net) provides something called
hciemu that can be used for testing.  hciemu effectively creates "virtual" hci
interfaces.  These interfaces communicate with each other by passing around
messages at the granularity of HCI events.  It allows a way to experiment with
and test the upper layers of their stack without having physical devices
present.  My proposal is to extend this existing work to create a NOURemu
device that can be used with BlueZ.
    The NOURemu device would accept HCI events from the upper layers of BlueZ
and run the request through our firmware.  Two or more NOURemu devices could 
then communicate with each other by exchanging data at the level of register
updates.  I haven't yet worked out any of the specifics such as how to
represent information exchanged between the two devices, or if the radio link
should be simulated or emulated, or if the 'firmware' in the emulated device
should run through a CPU simulator for the microprocessor we choose to use in
the design.  If there is interest in this idea those are points I think we can
work through in the implementation.
    Significant points I think support organizing like this:

- It gives us a method for immediately starting to move forward with work, we 
  already have the specification of the register set and access to the existing
  work in BlueZ.
- It allows us to start development of the algorithms needed for the firmware
  in a very 'friendly' environment.
- We can incrementally implement the emulation layer.  We start out with hciemu
  devices and start working in subsets of the registers controlling functions
  we're interested in testing.  The hci transport is used for the stuff we
  don't have implemented yet, and we can test subsections while still having a 
  fully functional emulation environment.
- By involving a working implementation for the upper layers of the protocol
  stack we hopefully can avoid oversights in the host side of the integration.

At present this is the best idea I've come up with to help Jamil get validation
for the excellent work he's done on the specification so far.  I would be happy
to take the lead in starting the device emulation project if we think that it
would provide a good technique for advancing.

Comments?  Concerns?  Criticism?  Let me know.
                                                  Mike

---------------------------------------------------------------------
To unsubscribe, e-mail: nour-unsubscribe-bZJqt4gKw0dwc45b+y0WwMLKnirKmNT7@public.gmane.org
For additional commands, e-mail: [email protected]
Handasa Arabia, http://www.handasarabia.org