DSO-150 not supported #1
Comments
|
I want to do the same : having an open source firmware on my DSO-150. |
|
I'm about ready to upload to hardware to see if I can get anything to work this weekend. If I don't hear back from the ardyesp I just create a new branch... |
|
I just forked the project as the original contributor has gone silent. |
|
I had a deep look. But there is another problem : the "startSampling" function takes 3 seconds. I imagine the capture should be done by interrupt in a rolling buffer ? I got an email this morning from JYE saying that they will open the firmware source early in May, except for the capture part that will be supplied as a library. So I'd say we should wait a little while, see the source code from JYE Tech. What do you think ? |
|
Couldn't stop myself to have a look in ADC capabilities of STM32F103. Maybe you already know that, but there is an ADC mode by DMA with interrupt. Basically, the ADC conversion is done while the CPU can do something else. That's for sure what should be used. I programmed a test and it's as fast as 1 value per micro-second. Not bad. It's not possible to open issue on your fork. Is that intentional ? I saw some questions in pinout.xlsx. VSENSEL1 & 2 : on DSO 138 there are input so the display can be updated, writing the correct value in the bottom left corner. On DSO 150 SENSEL1,2,3 are output to set U2 U3. AMPSEL on DSO 150 is PB12 which is also connected to j9 as "spare IO". So I guess it does nothing. |
|
Yea, I saw the FW from JYE-Tech for the DSO-138... Not too impressed and hard to work with... Especially if some of it is a library. No reason not to have a fully open source version.
Yea, totally agree. DMA is the way to go. (And using the sample interval to control the timebase…).
Not really. Need to figure out GitHub a little bit more ;-)
Yea, figured that out.
It’s used during the calibration process when assembling DSO-150. As it has two front-ends for low range/high range it generates a 3.3V or 0.1 V signal to calibrate the two stages (done manually…) so it’s not used afterwards. I think they just turn the test-wave output on and set ampsel to input weakly pulled low…. |
|
I tried the "enable IRQ when screen is idle" but it was very slow. I didn't
dig in the source to see if enable an IRQ can only be writing a word
somewhere on an IO port. And if you enable IRQ when the line is alreaday
active, you don't have an IRQ. So I needed to enable IRQ AND check for
buttons. There is so much screen access that I eventually remove IRQ.
But that was just test and I may have missed something. Hopefully we'll be
able to see in JYE source.
I'll be awfully busy in April, May and beginning of June. I probably won't
program/test/prototyping on that until then.
…On Mon, Apr 3, 2017 at 9:27 PM, michar71 ***@***.***> wrote:
Yea, I saw the FW from JYE-Tech for the DSO-138... Not too impressed and
hard to work with... Especially if some of it is a library. No reason not
to have a fully open source version.
(Arduino project is not the best option either. Need to see if all the
library and STM32 stuff can be easily pulled into PlatformIO....)
Couldn't stop myself to have a look in ADC capabilities of STM32F103.
Maybe you already >know that, but there is an ADC mode by DMA with
interrupt. Basically, the ADC conversion is >done while the CPU can do
something else. That's for sure what should be used. I >programmed a test
and it's as fast as 1 value per micro-second. Not bad.
So, if we replace the function startSampling by a DMA version and just
wait for it to complete, >it'll be way faster. Around 2ms for 2048 samples
instead of my current 3 seconds.
Yea, totally agree. DMA is the way to go. (And using the sample interval
to control the timebase…).
But not entirly sure if that gives you a reliable timebase or just a "grab
next sample when ADC is ready" which might introduce too much variance for
the samples.... There is also the digital line capturing that we would
loose unless we find a trick to do it in parallel. (Might use the IRQ from
the ADC to capture the digital data whenever the ADC has new data. No idea
if that works in parallel with the DMA...)
For “slow” sampling rates I’d also prefer to have some sort of Rolling
FIFO acquisition (Let’s say you only want to sample every 200mS, it should
just add it to the end of the buffer so it “rolls” through the screen….
Maybe just add a "high capture rate" specific option that only captures
analog channel at max speed....
It's not possible to open issue on your fork. Is that intentional ?
Not really. Need to figure out GitHub a little bit more ;-)
I think I’ve a better solution to deal with the encoder/button issue on
the display lines, I’ll try to fix that first and the open it up for bug
reports. If I can figure out how...
A better solution "seems" to be to use IRQ's but only enable them when the
display is idle. Still looses fast encoder movements but at least not that
bad. There's a Quadrature decoder in the F103 but we can't use that with
the lines muxed....
(There are a bunch of other bugs/annoyances/issues and missing features so
I need to get that into the system too…)
I saw some questions in pinout.xlsx.
VSENSEL1 & 2 : on DSO 138 there are input so the display can be updated,
writing the correct >value in the bottom left corner. On DSO 150
SENSEL1,2,3 are output to set U2 U3.
Yea, figured that out.
AMPSEL on DSO 150 is PB12 which is also connected to j9 as "spare IO". So
I guess it does >nothing.
It’s used during the calibration process when assembling DSO-150. As it
has two front-ends for low range/high range it generates a 3.3V or 0.1 V
signal to calibrate the two stages (done manually…) so it’s not used
afterwards. I think they just turn the test-wave output on and set ampsel
to input weakly pulled low….
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#1 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AC822f86ryzltel8hnXrmlguOO-j8cQ4ks5rsUgbgaJpZM4Mpuws>
.
|
|
I'm just using Arduinos attachInterrupt/detachInterrupt function but I'm bracketing the whole screen access functions in display.ino. Probably more dead-time for the button/encoder but less overhead. Pretty sure I can optimize that a lot by just setting the IRQ enable bits directly... I don't think JYE-Tech does anything different, the encoder works not that great in DSO150 original FW either.... I've just started a real work project on STM32F103 so at least I've good reason to read the dev-guide at work ;-) Check if you can now open issues in my repository, I'd like to move the conversation over to there.... |
|
Speaking of STM32 ADCs, they can be used in interleaved mode, see https://www.tablix.org/~avian/blog/archives/2013/10/interleaved_adc_mode_on_stm32f1/ |
|
Sorry for long delay in responding to this; seems like you all are making progress. I am not familiar with DSO-150, but it also seems to be based on same STM32F103. For development, you can get a barebone "blue pill" boards and try out the firmware on it. In the current implementation, ADC is not operated in the interleaved mode, because of the need to support two ADC channels. Factory firmware does that, and that is how it achieves 10us timebase (0.5 us/sample). DLO-138 gets 1us/sample in the fine tuned assembler loop. I am not able to actively support any development on it yet. Thanks. |
Well, not so much an issue, more like a fact ;-)
Just got myself a DSO-150 which seems to be the successor to the DSO-138 and though "Wouldn't it be nice if it would be open source so I could add some features..." and found your project.
Hardware looks very similar with some advancements like:
Your project already covers 80% so I'll see if I can get the code working on the DSO-150 and add config options to global.h...
Unfortunately the pinout used for the STM32 seems to differ in some areas so I'll try to document that first...
If I can sort out Github and get the STM programmer going I should be able to make some progress. (Oh, and I need to crack open the DSO-150 again...Bummer...)
Michael
(Sorry for filing this as an issue, there improbably a clever way to send a message... somewhere...)
The text was updated successfully, but these errors were encountered: