Just encode the opcodes as hexadecimal values. This makes for better
readability when mapping the communication dump with the sigma to the
code.
Signed-off-by: Marek Vasut <marex@denx.de>
Pull out the code which switches Sigma from the FPGA programming mode
into Logic-Analyzer mode into separate function. Also, given the reply
is only ever 3-byte long, do not allocate 32 byte big buffer, but only
a 3-byte long one.
Signed-off-by: Marek Vasut <marex@denx.de>
Move the sigma_fw_2_bitbang() function closer to the upload_firmware()
function so there's not such a horrible mess in the file.
Signed-off-by: Marek Vasut <marex@denx.de>
Rework the bit2bitbang function. Remarkable changes are:
- The function was renamed to sigma_fw_2_bitbang()
- We use glib function calls to work with the file
- We mmap the file containing firmware instead of opening the file
and then reading it into a buffer.
- The magic firmware transformation is now type-safe.
- Documentation and comments were added where applicable.
Signed-off-by: Marek Vasut <marex@denx.de>
Remove all those if ((ret = foo(bar)) < 0) constructs from upload_firmware()
function. This is just a confusing programming practice, kill it. While at it,
replace all the uses of &devc->ftdic with plain ftdic , which is defined at
the begining.
Signed-off-by: Marek Vasut <marex@denx.de>
The code silently assumed the firmware path can be no longer than 128 bytes.
This doesn't scale. This patch fixes it in such a way that it completely
rips out the run-time computation of firmware path and instead replaces it
with compile-time computation. It's true this makes the library grow by a
couple bytes, but makes the code cleaner.
Signed-off-by: Marek Vasut <marex@denx.de>
Rework the pre-firmware-upload FPGA initialization sequence so it matches
the documentation. Also, since this sequence is documented in a separate
section, wrap it into separate function.
Signed-off-by: Marek Vasut <marex@denx.de>
The NUM_CHANNELS macro is inflexible, since in 100MHz and 200MHz modes
we don't support 16 channels. Moreover, it's only used to limit the size
of array of channel labels, which can be done in much cleaner way.
Signed-off-by: Marek Vasut <marex@denx.de>
Add comments to the sampling rate table explaining how the frequencies
are selected and where do those numbers come from.
Signed-off-by: Marek Vasut <marex@denx.de>
(files in hardware/, input/, and output/ don't need this since none of
those directories contain API stuff and are thus not included in the
list of input files for Doxygen at all).
This driver has been unmaintained for years, and was never good code
to begin with. It's also questionable whether it was ever useful,
particularly with the demo driver now supporting various analog
signalling.
This somewhat naively copies whatever it gets into the output, regardless
of how many channels are in there, or which ones are enabled. Not sure
what the best way to deal with that is, but for now you have to feed it
a channel setup the Chronovu software can read.
hardware/fx2lafw/protocol.c: In function 'fx2lafw_command_start_acquisition':
hardware/fx2lafw/protocol.c:113:7: warning: 'cmd.flags' may be used uninitialized in this function [-Wmaybe-uninitialized]
(cmd.flags & CMD_START_FLAGS_CLK_48MHZ) ? "48" : "30");
^
Marek Vasut
Bert Vermeulen
Uwe Hermann
Martin Ling
Aurelien Jacobs