DSO-150 not supported
michar71 opened this issue · 10 comments
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:
- Integrated Rotary Encoder (And still 4 switches)
- Analog board separated from digital board
- more range selectors on the analog frontend
- Separate analog frontons for different input ranges
- External eprom (Not sure why they needed that...)
- Spare Header with 6 digital I/O's
- Dual amplitude test signal (0.1/3.3V used for dual fronted calibration...)
- No USB connector :-(
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...)
I want to do the same : having an open source firmware on my DSO-150.
I can compile and program and run. Unfortunately, the screen stays white, on a DSO138 as well as a DSO 150.
I'm about ready to upload to hardware to see if I can get anything to work this weekend.
I've a real scope so I can check if there is any difference between original FW and open source version if display doesn't work. (There's some trickyness going on with the buttons/encoder on the DSO-150 as it shares the data lines with the display which makes it impossible to use IRQ's so I'll need to work around that somehow...)
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.
Fork is working for DSO-150 (Work in progress...)
I had a deep look.
I found out about data lines shared with the screen before I saw your post. I lost some time...
What I've tried is : in CS_IDLE I call a checkButtons method that put the PB0-7 in input mode and read GPIOB->regs->IDR. It's working not too bad. Missing some button press but not that much.
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.
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.
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.
(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….
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.