|Version 5 (modified by atorf, 5 years ago)|
Changes and new features planned for toolbox release version 2.00
Communication functions (USB and BT) / handle concept
Current draft for handle-structure:
% generic info .OSName % String, 'Windows' or 'Linux' .OSValue % OS encoded as number: 1 = Win, 2 = Linux .ConnectionTypeName % String, 'USB' or 'Bluetooth' .ConnectionTypeValue % Type encoded as number: 1 = USB, 2 = BT % the actual handle .Handle % the actual handle value, datatype depends on OS and connection type % BT info known from the ini-file... .SerialPort % only valid for *-BT .BaudRate % only valid for Win-BT .DataBits % Win-BT, should we consider hardcoding this? .Timeout % Win-BT .SendSendPause % still needed for *-BT .SendReceivePause % ... % infos needed for BT, known from global vars inside BT_Send / Collect .LastSendTime % needed for the timers above to work .LastReceiveTime % ... % description of our NXT .NXTName % from the ini-file, or from the NXT retrieved? should match anyway .NXTMAC % maybe call it NXTID instead? Or Serial? Is it really a MAC? .KeepAliveInterval % could be read out from NXT, so we know when it will turn off % internal MOTOR state, previously one global var .NXTMOTOR_State % this is another whole struct! name might change % connections statistics, useful .BytesSent % status infos from here on: .BytesReceived % similar to Matlab's serial object .PacketsSent % just a counter .PacketsReceived % ... % some more additional handle information .CreationTime % just a gimmick? timestamp when connection was established .IsDefault % probably this is not needed
New lowlevel / helper functions
Needed for USB functions, returns payload length of a reply packet to a direct command — this isn't necessary for BT, since length information is encoded into the reply packet, but USB needs this information from somewhere else (i.e. this helper lookup).
Returns error description from error number, needed for Fantom (which in turn seems to use VISA, an USB instrument control framework / library)
Returns error description of last error that occured in libusb
Prototype file for libusb, something like a "DLL import header for MATLAB", generated from original C-header-file. Gets called from loadlibrary.
With new MATLAB 2008a, we get a "warning: protofile outdated". Are these prototype files MATLAB version dependent? Then we might have to regenerate them (using loadlibrary -mfilename) from the C-header-files. This would be a big disadvantage for m-proto-files, but the advantages on the other hand are: They load faster, are much more reliable, produce less warnings/errors, and are recommended anyway.
- dec2wordbytes.m / wordbytes2dec.m
Big performance improvement (factor 10?), important for USB with higher packet rates. Use profiler to improve even more: Instead of typecast we could (or even should?) use typecastc.
New sensor functions
- Generic OpenSensor and GetSensor functions?
Pros: Easier to use, more flexible, changing sensors doesn't result in changing so much code (i.e. GetSound? → GetLight? now stays GetSensor? → GetSensor?), smaller function-count, one powerful function.
Cons: More changes introduced, losing backwards compatibility (or do we keep the old functions, too?), one huge complex function to maintain, too variable input parameters?, unclear / varying output parameters (no strict expectable type)