libsigrokdecode.git - libsigrokdecode

Age	Commit message (Collapse)	Author
2014-04-15	All PDs: Bump api_version to 2.	Uwe Hermann
	Older libsigrokdecode versions are no longer able to use the current versions of the PDs (various changes in syntax etc).
2014-03-12	Various PDs: Drop currently unsupported probes in stacked PDs.	Uwe Hermann
	At the moment we don't yet support PDs which take both input from another PD (which they're stacked on top of) and from one or more logic inputs/pins. This will be supported later on, and at that time we'll bring back these changes.
2014-03-10	Probes, optional probes and annotations now take a tuple.	Bert Vermeulen
	Annotation entries also consist of a tuple, not a list.
2014-03-10	Remove unused probes and options	Bert Vermeulen

2014-01-28	All PDs: Consistent naming/case for annotation shortnames/IDs.	Uwe Hermann

2014-01-28	All 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-28	All PDs: Improve/fix descriptions.	Uwe Hermann

2013-11-27	Automate 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-15	Drop obsolete report() method.	Bert Vermeulen

2013-11-15	Use the new Decoder.register() API	Bert Vermeulen

2013-10-30	The start() method no longer takes a metadata parameter	Bert Vermeulen

2013-04-23	GPL headers: Use correct project name.	Uwe Hermann

2013-01-01	Small cosmetic/consistency fixes in the PDs.	Uwe Hermann

2012-11-24	All 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-21	srd: maxim_ds28ea00: Factor out putx(), small fixes.	Uwe Hermann

2012-07-21	srd: maxim_ds28ea00: Cosmetics, cleanups.	Uwe Hermann

2012-07-21	srd: maxim_ds28ea00: Fix to only handle DS28EA00.	Uwe Hermann

2012-07-21	srd: 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.