summaryrefslogtreecommitdiff
path: root/decoders/maxim_ds28ea00
AgeCommit message (Collapse)Author
2014-03-10Probes, optional probes and annotations now take a tuple.Bert Vermeulen
Annotation entries also consist of a tuple, not a list.
2014-03-10Remove unused probes and optionsBert Vermeulen
2014-01-28All PDs: Consistent naming/case for annotation shortnames/IDs.Uwe Hermann
2014-01-28All PDs: Drop unneeded comments.Uwe Hermann
The single comment re-stating the PD's name / description / purpose in each pd.py file is not really needed, that info is available in the Decoder class' attributes already.
2014-01-28All PDs: Improve/fix descriptions.Uwe Hermann
2013-11-27Automate protocol decoder installation.Bert Vermeulen
This automatically figures out the files to install for each protocol decoder, without involving autotools. All python files (filenames ending in .py) are always installed. If a protocol decoder requires installation of a non-python file, a small file called 'config' can be created in that protocol decoder's directory, with the following content: # comments are ok extra-install vendorlist.txt commands.txt
2013-11-15Drop obsolete report() method.Bert Vermeulen
2013-11-15Use the new Decoder.register() APIBert Vermeulen
2013-10-30The start() method no longer takes a metadata parameterBert Vermeulen
2013-04-23GPL headers: Use correct project name.Uwe Hermann
2013-01-01Small cosmetic/consistency fixes in the PDs.Uwe Hermann
2012-11-24All PDs: Name the files pd.py consistently.Uwe Hermann
The Python module name is determined by the directory name (e.g. dcf77), the *.py file names in that directory don't matter and can be kept consistent.
2012-07-21srd: maxim_ds28ea00: Factor out putx(), small fixes.Uwe Hermann
2012-07-21srd: maxim_ds28ea00: Cosmetics, cleanups.Uwe Hermann
2012-07-21srd: maxim_ds28ea00: Fix to only handle DS28EA00.Uwe Hermann
2012-07-21srd: Rename onewire_transport to maxim_ds28ea00.Uwe Hermann
It doesn't make sense to have one "generic" onewire_transport PD, as this layer is very much device-specific and such a generic PD would have to contain an accumulation of all possible features and commands and handling code of all existing (now and in the future) 1-Wire devices, which is neither possible nor useful nor elegant. There are (for example) 1-Wire thermometers, RTCs, EEPROMs, special-purpose security chips with passwords/keys, battery monitoring chips, and many many others. They all have a different set of features, commands and command codes, RAM areas/sizes/partitioning/contents, protocols, and so on. Thus, the layering for 1-Wire PD stacks should look like this: onewire_link -> onewire_network -> <specificdevice> Examples: onewire_link -> onewire_network -> maxim_ds28ea00 (special thermometer) onewire_link -> onewire_network -> maxim_ds2431 (1kbit EEPROM) onewire_link -> onewire_network -> maxim_ds2417 (RTC) onewire_link -> onewire_network -> maxim_ds2762 (battery monitor) onewire_link -> onewire_network -> maxim_ds1961s (SHA-1 eCash iButton) and so on... So, renaming onewire_transport to maxim_ds28ea00. The non-DS28EA00 specific code will be dropped and/or moved to other PDs on top of onewire_network later.