Skip to main content
Topic: Question about Jawi's SUMP client (Read 16379 times) previous topic - next topic

Question about Jawi's SUMP client

I'm using Jawi's SUMP client to test the firmware for the Logic Shrimp v2.b I've written. However, when viewing the captured data in Jawi's client, and after analyzing the serial communication, I noticed that the client provides a(n incorrect) divider calculated for a 100MHz base clock, instead of the correct divider calculated for the selected base clock given by the "device.clockspeed" property. I would like to know whether is this the correct behavior of the client (and thus I need to recalculate the correct divider in the PIC firmware) or is there a bug in the client software (is the "device.clockspeed" property ignored?). Or maybe am I doing something wrong? I'm posting a copy of the profile I've created for the Logic Shrimp v1.2b

Code: [Select]
# Configuration for the Lobster profile

# The short (single word) type of the device described in this profile
device.type = LOBSTER
# A longer description of the device
device.description = Lobster
# The device interface, SERIAL only
device.interface = SERIAL
# The device's native clockspeed, in Hertz.
device.clockspeed = 20000000
# Whether or not double-data-rate is supported by the device (also known as the "demux"-mode).
device.supports_ddr = false
# Supported sample rates in Hertz, separated by comma's
device.samplerates = 20000000, 10000000, 5000000, 2000000, 1000000
# What capture clocks are supported
device.captureclock = INTERNAL
# The supported capture sizes, in bytes
# The sample delay (before/after) does not work when recording 256KB of data. This is not working properly in the current version of the client. For now the maximum capture size is 128KB.
#device.capturesizes = 262144, 131072, 65536, 32768, 16384, 8192, 4096, 2048, 1024
device.capturesizes = 131072, 65536, 32768, 16384, 8192, 4096, 2048, 1024
# Whether or not the noise filter is supported
device.feature.noisefilter = false
# Whether or not Run-Length encoding is supported
device.feature.rle = false
# Whether or not a testing mode is supported
device.feature.testmode = false
# Whether or not triggers are supported
device.feature.triggers = true
# The number of trigger stages
device.trigger.stages = 1
# Whether or not "complex" triggers are supported
device.trigger.complex = false

# The total number of channels usable for capturing
device.channel.count = 4
# The number of channels groups, together with the channel count determines the channels per group
device.channel.groups = 1
# Whether the capture size is limited by the enabled channel groups
device.capturesize.bound = false
# Which numbering does the device support
device.channel.numberingschemes = DEFAULT

# Is a delay after opening the port and device detection needed? (0 = no delay, >0 = delay in milliseconds)
device.open.portdelay = 0
# The receive timeout for the device (in milliseconds, 100 = default, <=0 = no timeout)
device.receive.timeout = 100
# Does the device need a high or low DTR-line to operate correctly? (high = true, low = false)
device.open.portdtr = false
# Which metadata keys correspond to this device profile? Value is a comma-separated list of (double quoted) names...
device.metadata.keys = "LogicShrimpV2b"

# In which order are samples sent back from the device? false = last sample first, true = first sample first
device.samples.reverseOrder = true

###EOF###

Thanks in advance,

M.

Re: Question about Jawi's SUMP client

Reply #1
This information is very helpful for me, I like it, thank you ~ ~

Re: Question about Jawi's SUMP client

Reply #2
Yes, that is/was a bug in my client. The upcoming 0.9.7 release of my client will add an additional option in the device profile to allow a different clock for the divider calculation. You can give the first RC a spin if you like...
when good software is not an alternative...

Re: Question about Jawi's SUMP client

Reply #3
Thanks for the info! I will certainly give the RC1 a try.

Re: Question about Jawi's SUMP client

Reply #4
it keeps getting better and better! I've officially started using your client exclusively, I just spent the last couple days troubleshooting some SPI output from the AVR8 Soft Processor core project and your client didn't miss a beat