Dave's looked at the yellow FNIRSI-5012H 100MHz bandwidth 500MS/s.Yes, I know he looked at that, that's what I mentioned in parenthesies.
your link doesn't work.Weird. I clicked it and it worked, let me link another one. This one should also be from the official firnis store on ali:
also interested in this tablet o'scope. does any body got hand on this o'scope???
The main hardware is probably the same garbage as the little one. If you want a tablet oscope don't waste your money and get a micsig.
Original Poster's link worked for me.
If they had a 4 channel version of this it would be the perfect cheap automotive scope. I don't have the need for anything mobile, but being battery operated would be awesome because then I would be isolated from mains. Even if it operates at half it's claimed bandwidth it would be worth it (to me).
Original Poster's link worked for me.Don't mistake an oscilloscope like this with an oscilloscope suitable to use with mains! This oscilloscope has no protection against touching live parts at all so it is not suitable to use as a floating oscilloscope. You'll need to use a CAT rated differential probe anyway to probe anything connected to mains.
If they had a 4 channel version of this it would be the perfect cheap automotive scope. I don't have the need for anything mobile, but being battery operated would be awesome because then I would be isolated from mains. Even if it operates at half it's claimed bandwidth it would be worth it (to me).
4：Vertical sensitivity: 50 mV/div ~ 500 V/div
Mine hasnt come in yet with all this disrupted mail stuff, so I cant test anything yet, hopefully Kosmic will have further updates soon.
Hi!
Did anyone check if it was capable of 100Mhz? Or where its limit is?
Hi all.
I got one of these to test out. Results so far are OK-ish – i.e. it does work.
- My unit is way out on vertical accuracy, yielding around 212 mVpp for a 200 mVpp 1 kHz square wave. Specification is 2%, which seems optimistic, but 6% high is fairly poor.
- No way to store or restore setups, and fairly limited measurement options.
- I am not sure if it is set to a sinc mode or not – no setting for this.
- Waveform capture is two horizontal screens wide, so you can shift the window that much. No hold-off or other such niceties.
I have an oscilloscope calibrator here at work, so give some suggestions as to what I should verify and I will try to get it sorted.
Cool. I don't expect it to be perfect at this price point but is there anything you'd say was a deal breaker?
How's the touch screen? Good update rate? How easy it is to set horizontal/vertical scale? Does it crash and need rebooting?
Are you "This is OK...", or "What a pile of garbage!"?
That wouldn't worry me at all. "About 200mV" is fine.
(and yeah, 2% is never going to happen with an 8-bit ADC on a device like this)
Sooooo annoying if it doesn't power on to a known state (preferably the same as power-off).
It will be obvious if it doesn't have it: Zoom in on a rising edge and look for Gibbs phenomenon, ie. a sinc will show ringing before the signal starts to rise.
The main thing at this price point is being able to see wiggly lines on screen properly and not have any deal-breaking fails/annoyances.
I'd go to the extremes of horizontal scale and see how badly it aliases high/low frequencies. See if you can get it to display correct-looking waves with completely wrong frequencies.
How good is the FFT? I have a cheapo device with an awesome FFT (much better than the FFT on low end Rigols/Siglents).
FFT included in attachments. It seems viable for simple requirements. Update rate is fast.
Attachments:
Pic 1: 200 mVpp @ 1 kHz (centred)
Pic 2: 200 mVpp @ 100 kHz (centred)
Pic 3: 3 Vpp @ 50 kHz sine (centred) – horizontal jitter roughly ± 0.1 div
Pic 4: 3 Vpp @ 50 kHz sine (centred) – trigger shifted low
Pic 5: 3 Vpp @ 50 kHz sine (centred) – trigger shifted high
Pic 6 & 7: 3 Vpp @ 50 MHz sine (centred) – amplitude ~2.3<->2.5 Vpp
Pic 8: 3 Vpp @ 10 MHz sine (centred) – stable amplitude (becomes significantly unstable around 20 MHz)
Pic 9: 3 Vpp @ 10 Hz sine (centred) – roll mode (automatic - cannot be selected)
Pic 10: 3 Vpp @ 50 kHz sine (centred) – aliased signal (AUTO SET not used, but shows aliasing is possible)
Pic 11: 200 mVpp @ 1 kHz (centred) – FFT
Pic 12-14: 20 Vpp @ 1 kHz (centred) – FFT, shifting horizontal scale
Definitely something weird in the FFT.
How do you adjust the horizontal/vertical? Does it use gestures like pinch-zoom, etc.?
What are your thoughts about ease of use of the interface, especially compared to traditional knob and button layouts? Simpler? Confusing?
More or fewer steps to accomplish intent?
How useful is the manual for experienced? For noobs?
Would it be possible to test it with higher frequency square waves, e.g. 10-100MHz?
the manual appears to claim that you need to use the 10x probe setting to achieve the claimed bandwidth.
Jitter starts getting significant past 10 MHz for sine waves, so the triggering is a bit dubious.
the manual appears to claim that you need to use the 10x probe setting to achieve the claimed bandwidth.That's true on all 'scopes.
Jitter starts getting significant past 10 MHz for sine waves, so the triggering is a bit dubious.This is much more worrying. 10Mhz is in the "Arduino range".
So its amplitude rolloff is not consistent through the V/div ranges and BNC cable connection produces different results ? :-//the manual appears to claim that you need to use the 10x probe setting to achieve the claimed bandwidth.That's true on all 'scopes.
Not with an oscilloscope calibrator. Or at least I have not found this to ever be the case.
The bandwidth is determined using direct connection from an Active Head. (Usually 3 Vpp @ 50 kHz as reference level, so I did that here, but didn't bother to adjust for an accurate 3 Vpp reference indication because this isn't really a 'performance' instrument, so meh...)
So this instrument seems a bit odd, if it only functions correctly with the probe.Jitter starts getting significant past 10 MHz for sine waves, so the triggering is a bit dubious.This is much more worrying. 10Mhz is in the "Arduino range".There isn't a lot in the front end. A gradual deterioration in stability seems to occur, somewhere past 10 MHz for a sine wave. Because this starts at 50 mV/div, perhaps it would perform better with a higher amplitude than 3 Vpp.
Sounds like it's still a toy scope, not a serious instrument, and the bandwidth is still a lie. As expected.Is the Hantek linked below a less enough of a "toy" to be worth $70 more?
So its amplitude rolloff is not consistent through the V/div ranges and BNC cable connection produces different results ? :-//
Cool, thanks for your checks and the GUI looks not too bad but shame it's not a real 100 MHz scope.So its amplitude rolloff is not consistent through the V/div ranges and BNC cable connection produces different results ? :-//
It appears to be a weird hybrid / fast logger design to me, repurposed through software to give 'scope-like functionality.
My positive takes are: it is cheap, claimed to handle 400 Vpeak directly (yeah... I could check, but...), responsive UI, makes taking screen / waveform captures easy (but limited options if you want to do anything on the device), and it does yield a sensible(ish) trace up to 50 MHz+.
Negative: not really a handheld 'scope, IMO.
I think it is more of a "basic 'scope" / pretty inaccurate DMM hybrid. (And I suspect it's really a data logger.)
Should you buy it?
Well, will it do what you would want it for? Should be useful to quickly probe something before cranking up the real 'scope, as an alternative to the cheaper not-quite 'scopes, or for certain 'niche' uses. I intend on adding it to my gear for the Airsoft club, where it could be handy to check for battery/motor type faults where a DMM doesn't tell you enough.
Sounds like it's still a toy scope, not a serious instrument, and the bandwidth is still a lie. As expected.
Sounds like it's still a toy scope, not a serious instrument, and the bandwidth is still a lie. As expected.
Anybody could have told you that just from the price, no need to read the thread or get snobbish over it.
Every measuring/diagnostic device has its best uses and limitations and requires significant user familiarity with its best useage, quirks and anomalies.
Sounds like it's still a toy scope, not a serious instrument, and the bandwidth is still a lie. As expected.
Anybody could have told you that just from the price, no need to read the thread or get snobbish over it.
....until then I'd rather people with limited budgets not waste that money.
Especially with the guy performing all the tests being way too happy with a fairly expensive toy scope.
I'd rather people with limited budgets not waste that money
At this price level you can't really go wrong. Worst case you end up with a portable scope you can use on the road. Someone else made the suggestion for the 60% more expensive Hantek but at that point you better save more money and buy a real (entry level) oscilloscope. But I agree this FNIRSI-1013D portable scope's price is at the tipping point where you have to consider spending around $450 on a real entry level oscilloscope or spend $130 and get by for a couple of years.Sounds like it's still a toy scope, not a serious instrument, and the bandwidth is still a lie. As expected.
Anybody could have told you that just from the price, no need to read the thread or get snobbish over it.
Yea. Multiple people bought one because they thought it'd be the same thing as the last one. I think multiple people thought it was going to be something more because of the form factor change. If you'd read the thread you'd see that I had. It's also not me getting snobbish I'm summarizing for people who don't know better. They see all the screenshots and won't know what to make of it. Especially with the guy performing all the tests being way too happy with a fairly expensive toy scope. Maybe someone will do like ataradov did with the smaller one and write new firmware for it but until then I'd rather people with limited budgets not waste that money.
I look at it this way: Different scopes for different folks.
Not everyone has the same need for the same degree of stability required for their diverse applications.I look at it this way: Different scopes for different folks.
Beginners usually don't have enough knowledge to determine what would be useful but a stable trigger and working measurements are usually a baseline.
working measurements are usually a baseline.
Especially with the guy performing all the tests being way too happy with a fairly expensive toy scope.
(Special usage to please maginnovision. :D Now who can tell which 'toy' is at fault? :-DD)
As far as I can tell there is nothing about this that is a substantial upgrade over their last iteration which was bad enough a forum member wrote his own firmware for it. It had plenty of issues and this one seems to as well.
Apparently I can't even get people to agree on a baseline so I recommend everyone go out and buy one. It'll be my new newbie scope recommendation since everyone is saying I'm just a negative nancy.
eg. Why do the height of the peaks on the square wave in that image alternate tall/short? Are the tall ones harmonics and the short ones aliases? I don't know the source of the signal in that video and the horizontal axis has no scale.
Can the measurement cursors be used on the FFT? Is there any control of the FFT horizontal scale or does it simply follow the horizontal timebase? :-//
I'd love to have one to play with for a couple of hours.
Here there is a small alternation of high and low peak, but this is due to the FFT. If the frequency matches exactly one of the main frequency of the FFT, you have a high isolated peak. If you are further from one of the FFT harmonics, yoiu have a smaller, but broader peak.
So the peak is shorter because it's "smeared" across two pixels...In some sense, yes. But it is already in the mathematical FFT of the signal, not only in the display.
Does the horizontal scale of the FFT change when you change the timebase of the 'scope? It would be good to zoom in on the first few harmonics.
I just received my ADS1013D from Banggood.
I consider it as a very valuable piece of equipment, and a real oscilloscope with a huge advantage over
my previous oscilloscopes [bold added] ( I have many anchor boats and a recent rigol 1054Z)
You will have access only to the beginning part ( which is what you asked for).
Certainly not on par with your Rigol 1054Z, right?
What will be the circumstances/types of testing with your new ADS1013D that you would not use the Rigol for?
(https://www.tequipment.net/Rigol/DS1054Z/Digital-Oscilloscopes/)
@nctnicoThat IS category 1.
There is also the category of tools
4) Cheap, not full featured, but fulfill your needs.
Certainly not on par with your Rigol 1054Z, right? https://www.tequipment.net/Rigol/DS1054Z/Digital-Oscilloscopes/ (https://www.tequipment.net/Rigol/DS1054Z/Digital-Oscilloscopes/)No, the Rigol is far superior in performance from what I have measured
What will be the circumstances/types of testing with your new ADS1013D that you would not use the Rigol for?
@nctnicoThat IS category 1.
There is also the category of tools
4) Cheap, not full featured, but fulfills your needs.
Well, after considerable consternating and other assorted deliberations, I went with the Hantek 5072P. http://www.hantek.com/en/productdetail_97.html (http://www.hantek.com/en/productdetail_97.html)
My own interest in this "toy" is more because of form factor and portability than its measuring ability.
The FFT function seems very dubious to me. I am not sure how they're deriving it, but the weird 'foldback' artefacts it produced (shown in my screen-grabs) are spurious.
If that's important to you, then this is probably not suitable. More testing would be required to figure out what it is doing, and the limitations.
There is no labels on the ADS1013D, and the scales are difficult to adjust. It can only be used marginally.
It's a 'basic' instrument.
A modern 'real' oscilloscope (Siglent and Rigol are probably fine low-cost options) is a better bet if you want a more flexible instrument.
Siglent make hand-held 'scopes, too, if that is a requirement.
Yes we all know the low cost Rigol FFT is poor but an equivalent Siglent X-E ?A modern 'real' oscilloscope (Siglent and Rigol are probably fine low-cost options) is a better bet if you want a more flexible instrument.
The FFT on both of those is horrible.
Yes we all know the low cost Rigol FFT is poor but an equivalent Siglent X-E ?
::)Yes we all know the low cost Rigol FFT is poor but an equivalent Siglent X-E ?
I'm just looking at the horrible FFT, awful laggy controls and slow update rate shown in this video:
https://www.youtube.com/watch?v=Jf0TgfzYQXE (https://www.youtube.com/watch?v=Jf0TgfzYQXE)
(skip to 4:00)
It doesn't look like much of a step up from the Rigol to me. :-//
eg. At 4:30 he's showing a single sine wave, shouldn't the 'scope be showing a horizontal noise floor with a single vertical spike?
(Attachment Link)
My DSO Quad can manage it. It updates the FFT overlay at 30 fps, too, not the 1 fps of the Siglent.
(Attachment Link)
One glance at the UI and I know it's operating with very old FW and after watching the whole video it's obvious how much better the results would be with the features that have since been added.
So you bought a DSO Quad to supplement the FFT that your Rigol can't do ? :-DD
From 6.45. Also with old firmware but from a guy that knows how to drive Siglent X-E FFT. :phew:One glance at the UI and I know it's operating with very old FW and after watching the whole video it's obvious how much better the results would be with the features that have since been added.
Video? Screenshots? I'm having trouble finding any. Let's see the new frame rates, etc.
Let's see if they've managed to get it up to the level of a DSO Quad.
From 6.45. Also with old firmware but from a guy that knows how to drive Siglent X-E FFT. :phew:
OK, so with the latest firmware a good "driver" can achieve a similar update rate to a DSO Quad by reducing the memory depth to 2.8kpts and the FFT to 2048 points. Got it.
(Attachment Link)
Even so, he couldn't sort out the sloping noise floor or the weird cone shaped "peaks".
Even so, he couldn't sort out the sloping noise floor or the weird cone shaped "peaks".
This may be an accurate evaluation of the applied signal.
Images taken from this thread: https://www.eevblog.com/forum/testgear/siglent-sds1104x-e-fft-frequency-centering/ (https://www.eevblog.com/forum/testgear/siglent-sds1104x-e-fft-frequency-centering/)
Going by those this one must be broken :P
Even so, he couldn't sort out the sloping noise floor or the weird cone shaped "peaks".
This may be an accurate evaluation of the applied signal.
Maybe, but it's not the only place I've seen it, eg. Here's a comparison with a Picoscope:
Picoscope:
(https://www.eevblog.com/forum/testgear/siglent-sds1104x-e-fft-frequency-centering/?action=dlattach;attach=758640;image)
Siglent shows the same signal with cone shaped peaks and sloping noise floor:
(https://www.eevblog.com/forum/testgear/siglent-sds1104x-e-fft-frequency-centering/?action=dlattach;attach=758652;image)
Images taken from this thread: https://www.eevblog.com/forum/testgear/siglent-sds1104x-e-fft-frequency-centering/ (https://www.eevblog.com/forum/testgear/siglent-sds1104x-e-fft-frequency-centering/)
FFT Resolution Bandwidth is too low, try increasing capture time.I agree. I'd assume this is a setting somewhere that limits the FFT length; the length of the capture is more than enough.
Or just zoomed out a lot and half the first peak cropped off to hide it...
Or just zoomed out a lot and half the first peak cropped off to hide it...
Well then, from your post above, half the PicoScope first peak must be 'cropped off' to hide something...
???
The reason I'm not buying the 1013d is that I am thinking about buying a Siglent 1202X-E. It's available though German shops and I will have a more mature product, higher bandwidth, etc.
In fact, I wonder whether one could not simply build a professional scope (like a Siglent 1202X) with a larger screen and an extended version of such a user interface. Fine tuning could be implemented with sliders that are displayed on demand. Coarse adjustments would continue to be simple touch gestures. This 1013d seems to lack two finger gestures. Using those could yield additional improvement of the touch interface.
The reason I'm not buying the 1013d is that I am thinking about buying a Siglent 1202X-E. It's available though German shops and I will have a more mature product, higher bandwidth, etc.
Another drawback of the 1013d is the battery and the power via USB.
Given the rating (5V 2A), it will be hard to find a proper charger. Also, I do not trust the USB charger than comes with it. Better would have been USB PD via USB-C. Then I could have used a notebook USB-C charger or a USB-C PD power bank. 4 hours of usage on battery after charging it for 4 hours is great. Also, having it connected to the power 24/7 while it's standing on my desk seems like a bad idea. The battery will probably suffer, and, as I said, i don't trust the charger. Does it have a mini or micro USB plug?
Same form factor and touchscreen as a 1013D, more powerful than a Siglent.
OK, a bit more expensive than the Siglent but if that's what you're after then it's worth saving up a little bit more.
QuoteOK, a bit more expensive than the Siglent but if that's what you're after then it's worth saving up a little bit more.
A good bit more expensive.
Could you measure the resistance between the two BNC shieldings?
Looking at the pictures, it appears to me that the shielding of the input BNC connectors are actually not grounded. ???
Could you measure the resistance between the two BNC shieldings?
I bet it's ~= 0 Ohms...
Could you measure the resistance between the two BNC shieldings?
I bet it's ~= 0 Ohms...
Yes it is.
So, have you received your 1013d yet? And what's your verdict?
Quick overview, same as what others have seen;
Three of us at work bought them, none of them can be regarded 100MHz scopes. Even using HP 500MHz @10:1 probes (just to make sure its not an issues with the supplied probes), the highest frequency you will see is about 85MHz with a sine input before its starts showing nonsense (signal starts looking like its modulated/unstable), and its attenuated quite a bit.
At my most optimistic I would say its a 40MHz scope.
Quick overview, same as what others have seen;
Three of us at work bought them, none of them can be regarded 100MHz scopes. Even using HP 500MHz @10:1 probes (just to make sure its not an issues with the supplied probes), the highest frequency you will see is about 85MHz with a sine input before its starts showing nonsense (signal starts looking like its modulated/unstable), and its attenuated quite a bit.
At my most optimistic I would say its a 40MHz scope.
That makes perfect sense for a 100Mhz sample rate. Nyquist will be at 50Mhz and that's your maximum frquency, but Nyquist is a very theoretical thing and requires an infinitely wide filter to get the original signal back.
On any practical device you'll start to get artifacts that look like AM as you approach Nyquist, this is due to the samples moving in and out of phase with the peaks and zero crossings in the signal.
The highest frequency you can hope to see correctly will be approx Nyquist/1.25 which just happens to be 40MHz. Bingo! Math, it works. :popcorn:
I'm still mulling over whether to get one of these. OTOH it might be better to sell my Rigol DS1054Z and put the money towards a Micsig.
One question: How shiny are the screens on these? The screens on Micsigs look awfully shiny in videos. I hate that.
I would claim that the scope cannot display a 85MHz sine wave, if the sampling frequency is 100MSa/s. You need at least 2 samples per period of the sine wave. I conclude that this a 200MSa/s scope. But of course, results start degrading much earlier than samplefreq/2. Hence, the results starts becoming unreasonable above 40MHz (which would mean 5 samples per sine wave).
Anyhow, a Mini DS213 has a 100MSa/s samplerate, the price is higher, the display is smaller, and it has no touch screen. So maybe the 1013d is a reasonable choice for its price point?
As for the screen, its shiny, as shiny as the Micsig for all intents and purposes.
1013D doesn't have 1GSa/s!!!Yes, we know that already.
But the way, I made that screenshots of internal parts on the first page...I don't understand. You say 100MSa/s, then 100MHz, and then you conclude with 200Ma/s per channel! That doesn't workout. Do you mean 200MSa/s for both channels (meaning 100MSa/s per channel)?
name of ADC IC is erased, but by pinout can see that this is AD9288-100MSa/s
(also frequency on ENC(A,B) pins is 100MHz).
so the real rate is 200MSa/s on each channel!!!
1013D doesn't have 1GSa/s!!!Yes, we know that already.But the way, I made that screenshots of internal parts on the first page...I don't understand. You say 100MSa/s, then 100MHz, and then you conclude with 200Ma/s per channel! That doesn't workout. Do you mean 200MSa/s for both channels (meaning 100MSa/s per channel)?
name of ADC IC is erased, but by pinout can see that this is AD9288-100MSa/s
(also frequency on ENC(A,B) pins is 100MHz).
so the real rate is 200MSa/s on each channel!!!
As far as I understand ENCA/B defined the sample rate of the ADC. How can the scope reconstruct and show a sine wave of up to 85MHz with only 100MSa/s per channel? That's a mathematical impossibility.
If you measured ENCA/B, that rules our the possibility that they "overclock" the ADCs. Is there a variant of the AD9288 that samples on both edges of ENCA/B?
interleavingThat makes sense. So it's two 100MSa/s ADCs interleaved for both channels giving us 200MSa/s.
interleavingThat makes sense. So it's two 100MSa/s ADCs interleaved for both channels giving us 200MSa/s.
So that explains why things go really bad above 85 MHz.
So following the 1:5 rule, the 1013d is a 40MHz scope.
The reason I'm not buying the 1013d is that I am thinking about buying a Siglent 1202X-E. It's available though German shops and I will have a more mature product, higher bandwidth, etc.
Have you seen the Micsig tablets?
Same form factor and touchscreen as a 1013D, more powerful than a Siglent.
https://micsig.aliexpress.com/store/group/Tablet-Oscilloscope/1293611_509734614.html (https://micsig.aliexpress.com/store/group/Tablet-Oscilloscope/1293611_509734614.html)
OK, a bit more expensive than the Siglent but if that's what you're after then it's worth saving up a little bit more.
I have one.
Same lame interleaved sampling AD9288 100MS/s ADC
Same lame interleaved sampling AD9288 100MS/s ADCThat perfectly fits the observation that the signal goes to hell above 40MHz but it's a MASSIVE lie by the manufacturers.
A new low for testgear number exaggeration/inflation?
Yep. It's 200MS/s actually as both ADC's in the one chip are clocked out of phase, same signal goes into both ADC channels.
Still a dual channel 20MHz 7" touch screen portable tablet scope for $140 isn't bad.
It's still 200MSa/s as explained above. Multiplying by two just because you have two channels doesn't make any sense. Yes, some scopes have 1GSa/s when using one channel and only 500MSa/s when using two channels, but this scope has 200MSa/s regardless of how many channels you use. At least that's what I understood so far. And the "marketing" is off by a factor of 5, which is pretty big lie that's totally unnecessary.Yep. It's 200MS/s actually as both ADC's in the one chip are clocked out of phase, same signal goes into both ADC channels.Is it one chip per channel (the two unmarked chips at bottom right)?
If so that's "400MSamples/sec" - nothing to be ashamed of but I don't see anybody advertising that number. They all have numbers that start with a "1".
Yep. It's 200MS/s actually as both ADC's in the one chip are clocked out of phase, same signal goes into both ADC channels.Is it one chip per channel (the two unmarked chips at bottom right)?
If so that's "400MSamples/sec" - nothing to be ashamed of but I don't see anybody advertising that number. They all have numbers that start with a "1".
Yes, one dual ADC per channel. As far as I see, no way to combine 4 ADC's for one channel.
Without a battery, the MCU should go into boot mode (this is implemented in the circuit), but it does not seem to work.
There is no way to update the firmware.If true, that would be sad.
What do you mean by "without a battery" ? Does it mean, that you disconnect the battery and power this device via USB only?Yes, it is...
Still a dual channel 20MHz 7" touch screen portable tablet scope for $140 isn't bad.
Without a battery, the MCU should go into boot mode (this is implemented in the circuit), but it does not seem to work.
There is no way to update the firmware.
Seriously , updates for a thing that was made like a toy with big hardware limitations ...
In looking at the signals I deal with (hobbyist electronics and automotive stuff) the 50 mv/div sensitivity is not really an issue.It's marginal though when using a 10x probe as we do for most stuff.
In looking at the signals I deal with (hobbyist electronics and automotive stuff) the 50 mv/div sensitivity is not really an issue.It's marginal though when using a 10x probe as we do for most stuff.
In looking at the signals I deal with (hobbyist electronics and automotive stuff) the 50 mv/div sensitivity is not really an issue.It's marginal though when using a 10x probe as we do for most stuff.
That is so...
We shall see, the good news is that if it is not a useful tool for any reason (even if the novelty wears off and it's no longer "fun") it can go back to Amazon within 30 days--for the simple and indisputable fact that it does not meet the published specs....
In looking at the signals I deal with (hobbyist electronics and automotive stuff) the 50 mv/div sensitivity is not really an issue.It's marginal though when using a 10x probe as we do for most stuff.
That is so...
We shall see, the good news is that if it is not a useful tool for any reason (even if the novelty wears off and it's no longer "fun") it can go back to Amazon within 30 days--for the simple and indisputable fact that it does not meet the published specs....
That's like sending a 100MHz scope back to Amazon because it can't measure 500MHz properly. I just bought one of these scopes and whilst it's not perfect I do find that I use it when the other scopes are tied up. Because it is portable and easy on the battery it is a great portable scope I can throw in the car anytime. Much cheaper than buying a battery for the TDS3000 ;) Hopefully they will offer some firmware upgrades and allow the auto triggering level detection to be switched on or off. Like Dave said it is essentially,limited to 20MHz but that is fine with me for a general purpose portable scope for measuring audio and power stuff ;)
cheers
Nope, 500mV/div max sensitivity using a 10x probe is just inadequate for many requirements.In looking at the signals I deal with (hobbyist electronics and automotive stuff) the 50 mv/div sensitivity is not really an issue.It's marginal though when using a 10x probe as we do for most stuff.
That is so...
We shall see, the good news is that if it is not a useful tool for any reason (even if the novelty wears off and it's no longer "fun") it can go back to Amazon within 30 days--for the simple and indisputable fact that it does not meet the published specs....
That's like sending a 100MHz scope back to Amazon because it can't measure 500MHz properly.
Nope, 500mV/div max sensitivity using a 10x probe is just inadequate for many requirements.
In looking at the signals I deal with (hobbyist electronics and automotive stuff) the 50 mv/div sensitivity is not really an issue.It's marginal though when using a 10x probe as we do for most stuff.
That is so...
We shall see, the good news is that if it is not a useful tool for any reason (even if the novelty wears off and it's no longer "fun") it can go back to Amazon within 30 days--for the simple and indisputable fact that it does not meet the published specs....
That's like sending a 100MHz scope back to Amazon because it can't measure 500MHz properly. I just bought one of these scopes and whilst it's not perfect I do find that I use it when the other scopes are tied up. Because it is portable and easy on the battery it is a great portable scope I can throw in the car anytime. Much cheaper than buying a battery for the TDS3000 ;) Hopefully they will offer some firmware upgrades and allow the auto triggering level detection to be switched on or off. Like Dave said it is essentially,limited to 20MHz but that is fine with me for a general purpose portable scope for measuring audio and power stuff ;)
cheers
Not at all; it would be sending back an oscilloscope claimed (by the vendor via Amazon) to have a 100 MHz bandwidth, 1 Gs/s sample rate and <3 ns risetime:
(http://www.paladinmicro.com/TestEquipment/FNIRSI-Claims-00.jpg)
that does not...
If they make their code open source...
It need a small silicone protection and a more expensive 50 € model with real 500 MSa/s
Nope, 500mV/div max sensitivity using a 10x probe is just inadequate for many requirements.In looking at the signals I deal with (hobbyist electronics and automotive stuff) the 50 mv/div sensitivity is not really an issue.It's marginal though when using a 10x probe as we do for most stuff.
That is so...
We shall see, the good news is that if it is not a useful tool for any reason (even if the novelty wears off and it's no longer "fun") it can go back to Amazon within 30 days--for the simple and indisputable fact that it does not meet the published specs....
That's like sending a 100MHz scope back to Amazon because it can't measure 500MHz properly.
If they make their code open source...
If only...It need a small silicone protection and a more expensive 50 € model with real 500 MSa/s
I'm thinking the next generation of these could be awesome.
I just bought one too :palm:
Even with all the lies, bugs and limitations, I find the concept to be excellent.
I sometimes need to "see something" in hard to reach places or when I am not in the lab.
When we just need to see if the clock signal is here or if we have our RS422 pairs at the right place, no need for the big 5000€ scope balanced on the crimping pliers.
The fact that we can increase the battery capacity is great, the big 7" screen is also great, no fan. I hesitated with a handled oscilloscope but I find them very expensive.
If I like the concept, I think it will lead me to buy a Micsig tablet oscilloscope but the small form factor of this little Fnirsi is very very nice.
If they make their code open source, they can sell millions, I think.
It need a small silicone protection and a more expensive 50 € model with real 500 MSa/s
If the improvement over the original bar of soap scope is anything to go by then the next model could be a very serious proposition and this company whoever they may be could become a serious contender in the portable scope market ;)
5.7" display and BW's to 200 MHz and some with 1000V CAT II isolation between channels, all 5 mV sensitivity AND a datasheet that can be trusted !Nope, 500mV/div max sensitivity using a 10x probe is just inadequate for many requirements.In looking at the signals I deal with (hobbyist electronics and automotive stuff) the 50 mv/div sensitivity is not really an issue.It's marginal though when using a 10x probe as we do for most stuff.
That is so...
We shall see, the good news is that if it is not a useful tool for any reason (even if the novelty wears off and it's no longer "fun") it can go back to Amazon within 30 days--for the simple and indisputable fact that it does not meet the published specs....
That's like sending a 100MHz scope back to Amazon because it can't measure 500MHz properly.
OK what has siglent got to offer with battery operated, dual channel, 7 inch 800x480 full color touch sensitive display etc ?? And not some iddy biddy 3 inch QVGA BS either !!
What you got ??
cheers
OK what has siglent got to offer with battery operated, dual channel, 7 inch 800x480 full color touch sensitive display etc ??5.7" display and BW's to 200 MHz and some with 1000V CAT II isolation between channels, all 5 mV sensitivity AND a datasheet that can be trusted !
5.7" display and BW's to 200 MHz and some with 1000V CAT II isolation between channels, all 5 mV sensitivity AND a datasheet that can be trusted !Nope, 500mV/div max sensitivity using a 10x probe is just inadequate for many requirements.In looking at the signals I deal with (hobbyist electronics and automotive stuff) the 50 mv/div sensitivity is not really an issue.It's marginal though when using a 10x probe as we do for most stuff.
That is so...
We shall see, the good news is that if it is not a useful tool for any reason (even if the novelty wears off and it's no longer "fun") it can go back to Amazon within 30 days--for the simple and indisputable fact that it does not meet the published specs....
That's like sending a 100MHz scope back to Amazon because it can't measure 500MHz properly.
OK what has siglent got to offer with battery operated, dual channel, 7 inch 800x480 full color touch sensitive display etc ?? And not some iddy biddy 3 inch QVGA BS either !!
What you got ??
cheers
Nothing flash at all but they work as per their spec.
And you don't think 50 mV max sensitivity is piss poor ? :-//
Siglent SHS800 are battery powered.
This is the first model I looked at when I wanted a portable oscilloscope. But it is too big to be operated by hand, and too expensive as a "small portable bench scope".
The Micsig seems very interesting but too advanced for what I wanted to do.
There is also the Hantek 2C72 but the FNIRSI does just the right thing, 2 channels, large screen and large battery.
This thing cannot and should not be compared to the Siglent or Micsig offer.
And cannot and should not be used as a real scope or to replace a real oscilloscope.
It's just a cheap portable tool that allows you to take measurements very usefull in certain situations.
If the improvement over the original bar of soap scope is anything to go by then the next model could be a very serious proposition and this company whoever they may be could become a serious contender in the portable scope market ;)
The only reason I haven't bought one of these is that if I sell my Rigol DS1054Z and add $140 to the result (the cost of one of these) I'm in Micsig territory. A Micsig would make a lot more sense.
Plus Micsigs have a 4-channel option and I want 4-channel capability somewhere.
(OTOH I've got an Analog Discovery 2 on order so the 4-channel requirement might disappear when that arrives)
I have a 1054z tied up doing I2C decoding so this scope becomes useful for the other measurements when I don't want to boot up the Tek TDS7054 all of the time !
Got mine yesterday evening, haven't "played with it" a lot yet (it is for certain a toy) of course. However I can confirm the following (in no special order):So all that said, and as what I will likely use it for (automotive, motorcycles, etc.) does not require an X10 probe or 100 MHz bandwidth, I think I will keep it. It's portability alone makes it a worthwhile tool. I's too bad the makers feel they need to lie about it's specs.
- It is as cute as a bug's ear;
- The capacitive touch screen UI is quite nice, responsive and nicely configured;
- It triggers properly on aperiodic bursts usin 5 bursts of a 1 MHz pulse at a 100 kHz repetition rate.
- It does not have a usable bandwidth of anywhere near 100 MHz;
- In X10 mode and mucking about with the probe's compensation I found I could create an incredibly non-linear "peaky as hell' response that might perhaps pass a 100 MHz signal--this may be how the rice-burners that market it justify their "100 MHz" and "< 3ns" claims;
- It is as cute as a bug's ear;
- In X10 mode the vertical input characteristics are different at each sensitivity setting--making X10 mode even more useless;
- The FFT math function does nothing but provide a vertically constrained, fixed position, non-calibrated, non-adjustable, clipped off at the top picture of the waveform's spectral content--it is more annoying than useful;
- The battery seems quite capable of meeting the 4 hour runtime claim;
- The user manual is horrid, tiny, incomplete and obviously written by someone with an only partial command of the English language;
- It is as cute as a bug's ear;
- The -3 dB bandwidth in X1 mode (using just a 50 Ω BNC patch cable) is 20 MHz;
- I have no way of measuring the sample rate, however I seriously doubt it is 1 Gs/s;
- Within it's real capabilities the display is very nice;
- It runs well when charging via the supplied wall wart, however when connected to the USB charging station also powering my function generator or my desktop computer it goes haywire--some ground loop issue I suspect;
- It is as cute as a bug's ear;
- Mine is branded Yeapook, though in the Amazon ad copy it was shown as being FNIRSI;
Did I mention it is as cute as a bug's ear?
Would you mind dumping the winbond SPI flash and posting it here? It would definitely help with reverse engineering it! I've ordered one but it's coming on a human-powered boat from China...
I just bought one too :palm:
Even with all the lies, bugs and limitations, I find the concept to be excellent.
I sometimes need to "see something" in hard to reach places or when I am not in the lab.
When we just need to see if the clock signal is here or if we have our RS422 pairs at the right place, no need for the big 5000€ scope balanced on the crimping pliers.
The fact that we can increase the battery capacity is great, the big 7" screen is also great, no fan. I hesitated with a handled oscilloscope but I find them very expensive.
If I like the concept, I think it will lead me to buy a Micsig tablet oscilloscope but the small form factor of this little Fnirsi is very very nice.
If they make their code open source, they can sell millions, I think.
It need a small silicone protection and a more expensive 50 € model with real 500 MSa/s
Would you mind dumping the winbond SPI flash and posting it here? It would definitely help with reverse engineering it! I've ordered one but it's coming on a human-powered boat from China...
I would be pleased to; how do I go about doing so? What do I need?
Would you mind dumping the winbond SPI flash and posting it here? It would definitely help with reverse engineering it! I've ordered one but it's coming on a human-powered boat from China...
I would be pleased to; how do I go about doing so? What do I need?
Awesome! You'll need a CH341A (preferred) or a Raspberry Pi (any model) or, as a last resource, a blue pill board.
If you don't own any of those devices you could order the CH341A on eBay (https://www.ebay.com/itm/JW-USB-Programmer-CH341A-Burner-Chip-Writer-SOP-Clip-Adapter-EEPROM-BIOS-FLAS/233635841518 (https://www.ebay.com/itm/JW-USB-Programmer-CH341A-Burner-Chip-Writer-SOP-Clip-Adapter-EEPROM-BIOS-FLAS/233635841518)), but in that case I think it's not worth it as I'd probably get my device before you get the programmer. However, if the open-source firmware comes along nicely and you want to flash it, you'll need one of those devices too, so it's not wasted money ;)
In case you own a CH341A, you will need to connect it to the SPI memory and dump it using the provided software.
In case of using a Raspberry Pi, a software called "flashrom" can be used to use the GPIO as the interface to the SPI chip. (https://www.flashrom.org/RaspberryPi (https://www.flashrom.org/RaspberryPi))
With the blue pill board it's more tricky to do.
In all cases, the CPU will need to be held in a reset state in order to free the SPI bus for the programmer to use it. The only other way is physically de soldering the SPI chip from the board.
PD: To hold the CPU in reset, pin 70 needs to be shorted to GND. There's a convenient pad attached to it (https://prnt.sc/tjxfnl (https://prnt.sc/tjxfnl)).
Would you mind dumping the winbond SPI flash and posting it here? It would definitely help with reverse engineering it! I've ordered one but it's coming on a human-powered boat from China...
I would be pleased to; how do I go about doing so? What do I need?
Awesome! You'll need a CH341A (preferred) or a Raspberry Pi (any model) or, as a last resource, a blue pill board.
If you don't own any of those devices you could order the CH341A on eBay (https://www.ebay.com/itm/JW-USB-Programmer-CH341A-Burner-Chip-Writer-SOP-Clip-Adapter-EEPROM-BIOS-FLAS/233635841518 (https://www.ebay.com/itm/JW-USB-Programmer-CH341A-Burner-Chip-Writer-SOP-Clip-Adapter-EEPROM-BIOS-FLAS/233635841518)), but in that case I think it's not worth it as I'd probably get my device before you get the programmer. However, if the open-source firmware comes along nicely and you want to flash it, you'll need one of those devices too, so it's not wasted money ;)
In case you own a CH341A, you will need to connect it to the SPI memory and dump it using the provided software.
In case of using a Raspberry Pi, a software called "flashrom" can be used to use the GPIO as the interface to the SPI chip. (https://www.flashrom.org/RaspberryPi (https://www.flashrom.org/RaspberryPi))
With the blue pill board it's more tricky to do.
In all cases, the CPU will need to be held in a reset state in order to free the SPI bus for the programmer to use it. The only other way is physically de soldering the SPI chip from the board.
PD: To hold the CPU in reset, pin 70 needs to be shorted to GND. There's a convenient pad attached to it (https://prnt.sc/tjxfnl (https://prnt.sc/tjxfnl)).
I do not buy from China via eBay, having been stung too many times after waiting weeks on end. I do see what looks like the same device on Amazon for $8.88 w/ Prime shipping (https://www.amazon.com/Gikfun-Programmer-CH341A-Burner-EEPROM/dp/B01I1EU9LG/ref=sr_1_5?dchild=1&keywords=USB+Programmer+CH341A&qid=1595034129&sr=8-5)
Amazon does not vet it's vendors as well as they could/should, eBay is worse!
I have a CP2102 based USB to TTL interface I have used to update firmware on a JYETech DSO112A. I wonder if that could work, however to be honest as my Parkinson's has advanced over the last year I have become less confident about mucking about on SMD boards with a soldering iron, I would hate to brick my new $160 toy (SWMBO would kill me)...
I will do some research any see if it's something I feel comfortable jumping in to...
The one in Amazon is the same, but it does not come with the clip connector which is useful in these situations.
That said, there's no smd soldering involved! FNIRSI were kind enough to give us access to all the pins required with standard 2.54mm pin headers (https://prnt.sc/tjxzwj (https://prnt.sc/tjxzwj)). However, I completely understand that you don't want to risk it and kill your brand new oscilloscope :P
That's okay, I'll do it myself when I receive mine, and post full pinouts for every (unpopulated) header in the board, for future reference.
Thanks for the interest!
I just ordered one from Amazon, with the clip connector and some other physical interface devices ($13.58, this one (https://www.amazon.com/AiTrip-EEPROM-Programmer-CH341A-Adapter/dp/B07VNVVXW6/ref=sr_1_24?dchild=1&keywords=USB+Programmer+CH341A&qid=1595037248&refinements=p_85%3A2470955011&rnid=2470954011&rps=1&s=electronics&sr=1-24)). Supposed to be here Monday (evening is when we get deliveries out here "in the county").
I'll see what I can figure out then...
The only thing you will need to solder is a jumper from the pin 70 header to GND, to keep the CPU in reset mode.
That said, there's no smd soldering involved! FNIRSI were kind enough to give us access to all the pins required with standard 2.54mm pin headers (https://prnt.sc/tjxzwj (https://prnt.sc/tjxzwj)).
Looks like there's a GND hole without solder mask 2.54 millimeters to the left of that.
The only thing you will need to solder is a jumper from the pin 70 header to GND, to keep the CPU in reset mode.
Looks like there's a GND hole without solder mask 2.54 millimeters to theleftright of that.
From the looks of it, that's not GND... This is a (low-res) picture of the underside:
[...] Also, @cliffyk, could you take some clear pictures of the LCD ribbon cable and the Touchscreen IC chip? We need to identify them to write their drivers in the Linux Kernel. [...]
[...] Also, @cliffyk, could you take some clear pictures of the LCD ribbon cable and the Touchscreen IC chip? We need to identify them to write their drivers in the Linux Kernel. [...]
[...] Seeing how quick it boots, I'd think it isn't booting uboot then linux, but maybe, perhaps xboot? + rt-thread, and also the simple UI may as well be littlevGL. [...]
It's not going to be easy, first you've got to be sure you can reverse engineer the interface with the fpga, because without that you're not going anywhere.
P.D. the lichee nano (an F1C100S with a Linux) is $6 at seeedstudio.
I know, very cheap! I have a Lichee Pi Zero which is quite similar, but a bit more powerful.
I know, very cheap! I have a Lichee Pi Zero which is quite similar, but a bit more powerful.
But that's an S3 (V3s?), right?
Yeah, I'll have to either reverse engineer the interface with the FPGA, or program the FPGA myself (which is my plan!). I'll of course back up all the SPI memories to be able to restore the scope to factory defaults. The main reason of buying this scope was to write full open-source code for it.
Yeah, I'll have to either reverse engineer the interface with the FPGA, or program the FPGA myself (which is my plan!). I'll of course back up all the SPI memories to be able to restore the scope to factory defaults. The main reason of buying this scope was to write full open-source code for it.
I'm very interested to see how this goes. I started work on open source for an Instek GDS-2000E but then killed the scope in an accident. I'm trying to get a price on replacing the main board.
Have Fun!
Reg
Has anyone investigated the USB port to see if one can get access via that? I just learned about these recently. I've watched a couple of reviews by Dave and another chap, but not read through all the posts here.
If you can go higher please plot values for a sine wave as I did today in the Rigol DS1202Z-E thread.
https://www.eevblog.com/forum/testgear/rigol-ds1202z-e-entry-level-scope-(200mhz-2-channel)/msg3143092/#msg3143092 (https://www.eevblog.com/forum/testgear/rigol-ds1202z-e-entry-level-scope-(200mhz-2-channel)/msg3143092/#msg3143092)
That will give a much better idea of the usable BW. For a lot of uses such as HF RF work they seem to be pretty viable even with the attenuation and aliasing at higher frequencies.
Have Fun!
Reg
Hey, I just worked out how to turn off the auto triggering level. It's in the system menu |O This scope just got a lot better :-+
34 MHz (3.47 Vpp -3.24 dB)
(http://www.paladinmicro.com/TestEquipment/Yeapook/34MHz-00.jpg)
So, there it is -3 dB @ 33 to 34 MHz with alligator clips! Not too shabby,,,
Note that the square-wave on CH2 (X1 mode via a 50 Ω patch cable) turned to crap at > 10 MHz, which actually validates the 30+ MHz bandwidth...
Hey, I just worked out how to turn off the auto triggering level. It's in the system menu |O This scope just got a lot better :-+
The menu system is weird. It's also where you set / unset the FFT function. A somewhat bizarre FFT, too...
Did you figure out the fast/slow setting near the top that changes responsiveness to the (single-point) screen movement? The single-tap on the left or right on screen to alter the time-base. (I could not figure this out for ages... gah!)
It has very basic functionality and works adequately within those limitations. The vertical accuracy on mine is way off, though, so you should check that against something else if you intend on believing what it claims.
My results seemed a little better: this is 3 Vpp at 50 kHz and 50 MHz, ~2.3 dB down. I was using a calibrator with active heads directly Cabling can cause lots of degradation, and alligator clips is not ideal for high frequency.
I'll send $20 US via PayPal to the first person to post a FW dump.
Ohh, so the "3ns rise time" looks more like "30ns rise time", LOL. What a waste. It's a pity because @200MSps that could look much much better with a decent front end. Maybe the software of this one is the least of the problems.
(http://www.paladinmicro.com/TestEquipment/Yeapook/10MHz-00.jpg)
Ohh, so the "3ns rise time" looks more like "30ns rise time", LOL. What a waste. It's a pity because @200MSps that could look much much better with a decent front end. Maybe the software of this one is the least of the problems.
Can anybody post a "dots" display mode of that WF, so we can count the dots?
Would you mind dumping the winbond SPI flash and posting it here?attached...
You'll need a CH341A (preferred)...This is totally shit programmer...
It appears to be an AD9288:Yep, I said it before...
I'm guessing that the last is a reference to merging all 4 channels into one. So there may be variants which implement that.They don't have hardware support to merge all 4 channels into one...
Does anyone have a disassembler for the chip?IDA Pro, Ghidra... it is ARM9 core
(http://www.paladinmicro.com/TestEquipment/Yeapook/10MHz-00.jpg)
Ohh, so the "3ns rise time" looks more like "30ns rise time", LOL. What a waste. It's a pity because @200MSps that could look much much better with a decent front end. Maybe the software of this one is the least of the problems.
Can anybody post a "dots" display mode of that WF, so we can count the dots?
Personally I can not understand at all why so small amount of noise and ranting is about this "1GSa/s 100MHz" total hoax - fraud. Totally shameful outrageous scam if it is just as in Dave's video and HW is like displayed and if it is true what ADC there is.
Does anyone have a disassembler for the chip?IDA Pro, Ghidra... it is ARM9 core
0030ba0: f001 bde8 0000 a0e3 0082 bde8 1cd0 8de2 ................
0030bb0: f001 bde8 0100 a0e3 0082 bde8 0060 7380 .............`s.
0030bc0: 01ff ff00 01ff ff80 7377 6974 6368 2069 ........switch i
0030bd0: 6e74 6f20 6869 6768 2073 7065 6564 206d nto high speed m
0030be0: 6f64 6520 2121 210d 0a00 0000 04e0 2de5 ode !!!.......-.
0030bf0: 8bdf 4de2 0120 a0e3 ac10 8fe2 0d00 a0e1 ..M.. ..........004d330: e13f a0e3 b0c0 d0e1 9b00 5ce3 1900 009a .?........\.....
004d340: 0110 81e2 0c20 82e0 0118 c1e3 1800 00ea ..... ..........
004d350: ccaf 1880 506c 6561 7365 2069 6e73 6572 ....Please inser
004d360: 7420 7465 7374 2063 6c69 7020 616e 6420 t test clip and
004d370: 7072 6573 7320 4f4b 2074 6f20 636f 6e74 press OK to cont
004d380: 696e 7565 2021 0000 9ced 1880 5901 0000 inue !......Y...
004d390: 4f4b 0000 7227 1980 58cd 1980 02b8 1a80 OK..r'..X.......
004d3a0: cdcc 0000 72cf 1a80 0180 8be2 0ca0 8ae0 ....r...........
004d3b0: 01b8 c8e3 0130 53e2 0200 80e2 dcff ff1a .....0S.........
attached...
This is totally shit programmer...
Who assured that the FW is only the SPI mem contents?
I realized that Dave thought it was an AD9288, but the chips had been sanded off. My point was confirmation from the binary image.
Does anyone recognize the filesystem? It doesn't appear to be UBI which is the only flash filesystem I have any familiarity with, and that is *very* little.
Does it come with an SDCard or is the SD slot empty?
"F1C100S XiaoTaoQi Disk 1.0" inside.
The F1C100s has no internal memory, only RAM, so it must be in flash. Normally they run Linux, but in this case they must be using something else (somebody suggested XBoot paired with other software). It makes sense as the flash chip is only 2MB, Linux won't fit in there.
Does it come with an SDCard or is the SD slot empty?It comes with a 2GB SDCard I think.
Personally I can not understand at all why so small amount of noise and ranting is about this "1GSa/s 100MHz" total hoax - fraud. Totally shameful outrageous scam if it is just as in Dave's video and HW is like displayed and if it is true what ADC there is.
Are you in a position to do anything about it?
We're busy hacking it into something useful.
"F1C100S XiaoTaoQi Disk 1.0" inside.
https://linux-sunxi.org/images/b/ba/F1C100s_Datasheet_V1.0.pdf (https://linux-sunxi.org/images/b/ba/F1C100s_Datasheet_V1.0.pdf)
There is a big part that looks obfuscated (starting around offset 0x184C80).
Does it come with an SDCard or is the SD slot empty?
It comes with a 2GB SDCard I think.
It comes with a 2GB SDCard I think.
Might as well be booting from there, then, no?
I did not find the string in the datasheet. The apparently obfuscated part may be the FPGA bitstream. However, there is a string "Encrypt" in the image.
The F1C200s is the same as F1C100s, but with double the RAM. All the registers are the same, so this user manual applies to our chip too:
https://www.thirtythreeforty.net/posts/2020/02/trying-the-allwinner-f1c200s/Allwinner_F1C200s_User_Manual_V1.1.pdf (https://www.thirtythreeforty.net/posts/2020/02/trying-the-allwinner-f1c200s/Allwinner_F1C200s_User_Manual_V1.1.pdf)
It contains all the CPU and Peripherals registers and descriptions about them. Might be useful to use with Ghidra.
Does it come with an SDCard or is the SD slot empty?
It comes with a 2GB SDCard I think.
Mine came with a SanDisk 1 GB card...
Does it boot w/o the card? Can you have a look and tell us what's in the card?
It has 4 blocks:
00000000 - SPL (secondary bootloader)
00006000 - 1st executable (OS part that deals with the SD card)
00013000 - bitmap
00027000 - 2nd executable (main app)
My best guesses ATM.
It has 4 blocks:
00000000 - SPL (secondary bootloader)
00006000 - 1st executable (OS part that deals with the SD card)
00013000 - bitmap
00027000 - 2nd executable (main app)
My best guesses ATM.
ATM? I shudder to think what google will return for that. Can you explain?
...I think something is missing...Something what? there is no another flash... that is a full dump of SPI flash...
Does anyone recognize the filesystem?this is a plain binary file... not filesystem...
There is a big part that looks obfuscated (starting around offset 0x184C80).it is not obfuscated... it is some table... note values coming in ascending order.
it is not obfuscated... it is some table... note values coming in ascending order.
it looks more as a map, unicode characters conversion table.
Can someone post a disassembly?
Does it come with an SDCard or is the SD slot empty?Yep, 1GB... I've tried 32GB (FAT32) working!
...I did read somewhere that the SDCard only contained the screenshots and saved data.Yep, only for screenshots and saved data.
Does it boot w/o the card? Can you have a look and tell us what's in the card? Ideally, partitions, filesystem types, and start blocks too :-)Yep, working without SD... but hangs if you try to save.
No way, it looks obfuscated. There are very few "clear" strings...My 20 years of experience in reverse engineering tells me that this is a table, not a code. But I will know for sure only when I reach that place.
If we can get documentation for the JuTouch library we should have a pretty good grip on it.
My 20 years of experience in reverse engineering tells me that this is a table, not a code. But I will know for sure only when I reach that place.
It is still "as cute as a bug's ear", but it may be going back...
My 5 minutes look at that part shows an incrementing pattern (with contiguous 0x400 bytes size blocks). That doesn't look like a unicode characters conversion table. I could be wrong...Maybe we talk about different places?
But the fpga has another spi flash chip.
It comes with a 2GB SDCard I think.
Might as well be booting from there, then, no?
I still don't have the scope with me, but I did read somewhere that the SDCard only contained the screenshots and saved data.
If that's the case there will be a bit of assembly code that sits in loop incrementing a pointer through that section reading and then writing the contents to the FPGA load address.
But the fpga has another spi flash chip.
I think that's an I2C EEPROM, judging by the two pull-up resistors on two of the pins.
This is strongly suggestive of a bitstream for the FPGA.FPGA has another standalone chip... as wrote @GeorgeOfTheJungle
But the fpga has another spi flash chip.IC which you mark is I2C, name is erased...
Well, maybe, but my point is/was, isn't that the eeprom that contains the fpga bitstream? And if so, it's not going to be in the other eeprom too, right?
But the fpga has another spi flash chip.IC which you mark is I2C, name is erased...
and the IC a little bit left, is also SPI 25P16VP, and connectors on left (6pin top, and 4pin bottom is to program them)
That is almost certainly wrong. The Zynq at least has it's own facility for loading the bitstream from flash.
But the fpga has another spi flash chip.
I think that's an I2C EEPROM, judging by the two pull-up resistors on two of the pins.
Here is the dump of ST 25P16VP... (this is FPGA stream data and connected to dedicated FPGA pins)
I don't think that it is useful for anyone, just let it be for history...
I2C I guess for store settings.
WARNING: the .RBF file has the bytes bit-reversed! Reversing...
FPGA - RBF/RPD (Raw Binary File) - Filesize: 16 777 216 bits (00200000 bytes)
00000000 - Start of File (Type 1)
[00000048 00000021]
Bit 7 - 1111111111111111111111111111111111111111 FFFFFFFFFF
Bit 6 - 1111111111111111111111111111111111111111 FFFFFFFFFF
Bit 5 - 1111111111111111111111111111111111111111 FFFFFFFFFF
Bit 4 - 1111111111111111111111111111111111111111 FFFFFFFFFF
Bit 3 - 1111111111111111111111111110111010000000 FFFFFFEE80
Bit 2 - 0000011100110011001011111000000000111111 07332F803F
Bit 1 - 1100000000000111100011000000010111111111 C0078C05FF
Bit 0 - 0000000000010101000100010110110111111111 0015116DFF
Bits 0080 - EPCS/EPCQ ID check: Enabled
Bits 005F - Stream size: 943 711 bits (0001CCCC bytes) Compression Bit ON (+1) Size NOT OK
Bits 0056 - 0000 0000 : 0x56-0x5D
Bits 004C - Programming Mode: Active Serial (AS x1)
Bits 003B - IDCode (Version+Part Number only): 0x020F1 (-> 0x024F1)
Bits 0008 - Usercode: 0015116D
00000049 - Header CRC-16_MODBUS: 0033 [00000021-00000048] CRC OK
0000004B - Data Framesize: 207 [0000004B-000000F1]
000000F2 - 4-byte words: 1260 [000000F2-000014A1]
00000000 - Stream Size (Uncompressed): 15 610 872 bits
000014A2 - CRC Framesize: 207+0 # Data Frames: 1727 [000014A2-00059D4F]
Start address: 00000000
00059D50 - Post-device bitstream pad bytes (0xFF): 1583407 [00059D50-001DC67E]
File Checksum: 1E469589
What's the architecture I should select?
What's the architecture I should select?
ARM Little endian with the load addresses that I've previously indicated, after stripping the 32 byte headers!
Well, I got Ghidra 9.1.2 to run, but it does not grok ARM V9. So where to from here?
Reg
What's the architecture I should select?
ARM Little endian with the load addresses that I've previously indicated, after stripping the 32 byte headers!
Not clear what you mean by "stripping the 32 byte headers". Could you give a novice a more detailed description?
Once I can decompile the whole thing I should be able to discover quite a lot. I haven't attacked a completely undocumented code in 30 years, but that was how I was introduced to C & Unix. A 5000 line C code which didn't work correctly on a little endian machine. It had 2 comments both of which read
/* handling special cases */
thanks,
Reg
ARM V4T little endianactually
(the 1st 32 bytes of each block are its header) In the header, at offset 0x10, there is the size of the block (including header).addon
SPL has a Load Address = 0x00000000
The executables have a Load Address = 0x80000000
A teaser function in the attached file.
ARM V4T little endianactually
CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ)
https://steward-fu.github.io/website/mcu/lichee-nano/flash_image.htm
ARM V4T little endianactually
CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ)
https://steward-fu.github.io/website/mcu/lichee-nano/flash_image.htm
So, it turns out that 100 Mhz is the "maximum theoretical value" and if you actually want a 100 Mhz bandwidth you should "buy other better oscilloscope, such as TEKTRONIX..."
So, it turns out that 100 Mhz is the "maximum theoretical value" and if you actually want a 100 Mhz bandwidth you should "buy other better oscilloscope, such as TEKTRONIX..."
It's the Nyquist limit of a 200Mhz sample rate and we know it's 200Mhz. :-+
What about their claim of 1GHz sampling? I'd love to see how they spin that.
I don't get why everybody is so angry about it at this price point.
In my country we have a saying about people who start looking the teeth when you're trying to give them a free horse.
False advertising!
In engineering specifications are everything!
If something is specified to be 100MHz and1G samples - it had better be!
False advertising!
In engineering specifications are everything!
If something is specified to be 100MHz and1G samples - it had better be!
That's just a cultural expectation, not a physical law.
I was raised to believe that a man's word was his bond.
I was raised to believe that a man's word was his bond.That has NEVER been true.
Perhaps not in your circles...
Did anyone check if it was capable of 100Mhz?
Or where its limit is?
I was raised to believe that a man's word was his bond.That has NEVER been true.
Perhaps not in your circles...
I was going to respond "Never been in a firefight, have you?". When you tell a brother you "have his back", YOU HAVE HIS GODDAMN BACK!
Has anybody measured the bandwidth in 1x mode?
Here are some results of my testing bandwidth in X1 mode using alligator clips:
10kHz reference (5.04 Vpp):
(http://www.paladinmicro.com/TestEquipment/Yeapook/10kHz-00.jpg)
1 MHz (4.99 Vpp -0.087 dB)
(http://www.paladinmicro.com/TestEquipment/Yeapook/1MHz-00.jpg)
10 MHz (5.39 Vpp +0.58 dB)
(http://www.paladinmicro.com/TestEquipment/Yeapook/10MHz-00.jpg)
20 MHz (4.99 Vpp -0.087 dB)
(http://www.paladinmicro.com/TestEquipment/Yeapook/20MHz-00.jpg)
30 MHz (4.36 Vpp -1.26 dB)
(http://www.paladinmicro.com/TestEquipment/Yeapook/30MHz-00.jpg)
34 MHz (3.47 Vpp -3.24 dB)
(http://www.paladinmicro.com/TestEquipment/Yeapook/34MHz-00.jpg)
So, there it is -3 dB @ 33 to 34 MHz with alligator clips! Not too shabby,,,
Note that the square-wave on CH2 (X1 mode via a 50 Ω patch cable) turned to crap at > 10 MHz, which actually validates the 30+ MHz bandwidth...
I was going to respond "Never been in a firefight, have you?". When you tell a brother you "have his back", YOU HAVE HIS GODDAMN BACK!
I don't think it's a bad thing to have been raised with the phrase "Caveat Emptor" burned into the psyche.
For example, 0xb34e() has an infinite loop following a series of function calls suggesting that it is the main loop when the DSO is running. However, I can't figure out how to walk back up the call tree from there.
I'm certainly impressed by Ghidra. I had not known of it before, so it's been a very valuable education. I can see lots of uses for it, but I think I need to start by analyzing a less complex program.
Hi,
Mine did arrived - Ordered as fnirsi, it comes a "yeapook"... ;)
First look, cute toy, responsive touchscreen...
Here're my results, a couple others checked it as well:
Here're my results, a couple others checked it as well:
Fed in a sinewave with 1Vrms, starting at 1Mhz. Got -3dB (0.707Vrms) at appx 37 Mhz.
Interesting :
Where at frequencies about 10Mhz or more the waveform looks stable, at 1Mhz it´s somekind of "restless" .
For example, 0xb34e() has an infinite loop following a series of function calls suggesting that it is the main loop when the DSO is running. However, I can't figure out how to walk back up the call tree from there.
I'm certainly impressed by Ghidra. I had not known of it before, so it's been a very valuable education. I can see lots of uses for it, but I think I need to start by analyzing a less complex program.
As Morpheus would say: Welcome to the real world.
It would be very interesting to know the origins of this. The obvious presence in the FW of features not supported by the HW suggests someone developed a base design and FW to sell to manufacturers who in turn set the price point by leaving out HW.
Be serious , this is not a company as it should be , just some guys wanting to make easy money lying ... ;D
Be serious , this is not a company as it should be , just some guys wanting to make easy money lying ... ;D
Be serious , this is not a company as it should be , just some guys wanting to make easy money lying ... ;D
In the west we call those people "managers and salesmen".
There's laws that make it make it difficult to sell products with definite numbers on them though so they mostly stick to homeopathic, gluten-free hairloss remedies that help you sleep and tighten up your abs while you use them. ie. Nothing that can be disproved in a court of law.
(either that or investment-grade "collectables" on the shopping channel that can only go up in value in the future...)
Edit: And then there's the Batteroo brothers.
"Franklin Mint" comes to mind...
Has anybody measured the bandwidth in 1x mode?
Didn't read the entire thread did you?
Cute, really cute toy... :D
That measurement was with "alligator clips". I was interested in the bandwidth with the 1x probes. The 1x probes will have some capacitance that will lower the bandwidth.
If we have to use crocodile clips to get the most from this thing then there should be a way to get better results by adding a small amount of capacitance and limiting the bandwidth to something the system can handle.
Cliff, can you select units of Amps in the channel input menu ?
I quite understand and we needed to do maths on the fly with a CRO however most DSO's are able to display waveforms in the units of Amps.Cliff, can you select units of Amps in the channel input menu ?
With my Lecroy's you can select A as he unit and scale the display, but not with this little fella. However I'm pretty good at math and "make believe"...
Hi,
Done the meausure with the probe switching to 1x.
BW decreases to 17.8Mhz
Martin
I quite understand and we needed to do maths on the fly with a CRO however most DSO's are able to display waveforms in the units of Amps.
Another FAIL for FNIRSI. ::)
I quite understand and we needed to do maths on the fly with a CRO however most DSO's are able to display waveforms in the units of Amps.
But the amount of menu-diving required simply isn't worth it.
Another FAIL for FNIRSI. ::)
Yeah, total fail. They totally should have added a whole extra menu just for that. :palm:
We need ask ourselves who might buy this $120 tablet instead of a proper DSO or for that matter a working CRO ?I quite understand and we needed to do maths on the fly with a CRO however most DSO's are able to display waveforms in the units of Amps.
But the amount of menu-diving required simply isn't worth it.Another FAIL for FNIRSI. ::)
Yeah, total fail. They totally should have added a whole extra menu just for that. Not. :palm:
Hi,
Done the meausure with the probe switching to 1x.
BW decreases to 17.8Mhz
Martin
:-+
Not perfect but also not the disaster promised in the manual.
(Attachment Link)
Theoretically we could gain an extra 15Mhz in 1x mode by making a custom probe with just the right amount of capacitance, but... you'd only need that when you want 50mV/division.
The overlap in the Venn diagram isn't big enough to not bother, IMHO. People who want that would probably be using a real oscilloscope anyway.
That first statement in the manual's red-flagged "Solemn reminder" section ("The bandwidth of the 1x probe file is 5 MHz,...") may be so with regard to the supplied probe in 1X mode, however I got out to 34 MHz at -3 dB, with alligator clips on the end of 16" of 50 Ω cable.
Theoretically we could gain an extra 15Mhz in 1x mode by making a custom probe ...
That first statement in the manual's red-flagged "Solemn reminder" section ("The bandwidth of the 1x probe file is 5 MHz,...") may be so with regard to the supplied probe in 1X mode, however I got out to 34 MHz at -3 dB, with alligator clips on the end of 16" of 50 Ω cable.
It's all about capacitance.
You can get the same bandwidth by switching the probe to 10x mode, you just lose the 50mV range.
(because the x10 probe has a 10:1 voltage divider hidden inside it).
There'll be a compromise in between the two, which is what you're doing with your clips, but I suspect most people won't bother. It's nice to know it's there but the difference in bandwidth isn't huge (you're not getting the promised 100Mhz or anywhere close)
Doing such a scope with a multimedia chip is another example of ingenuity and its developers surely did their best. Once again, I don't think it can be improved much more.
I wonder why did they put a front end so slow when the digitizer runs @ 200MSa/s? It's not a good fit. Perhaps the guy was better at digital than analog? It happened to Woz all time.
There goes the neighborhood... you up the proc, you up the price. It's a fine balance. You have to put the limit somewhere.
Do you think it would have been so much more expensive?
Do you think it would have been so much more expensive?
I think so. When we are at this scale of "upscaling/modding", any small change in any part of the chain might force big € increments in the rest of the chain / total redesign. But, of course, IMHO.
If R12 is reduced to 10-22 Ohm, the frequency response at the HF will become flat to 100 MHz.
If you increase C2, it will level out at the low frequency response.
I don't understand why people are so shocked by the lies and the performance of this oscilloscope.
I don't understand why people are so shocked by the lies and the performance of this oscilloscope.I'm not shocked!
if you have 150$...
Playing around with the stb-3 board :
(Attachment Link)
The demo board provides a variety of testsignals, ideal for doing a quick "overall" test on new scopes.
Sinewaves, squarewaves, pwm, runt, glitch, modulation, eres and several serial bus signals.
And inbetween it´s limitations, the scope performed well.
PWM signals are no problem:
(Attachment Link)
Runt and glitch pulses....Well, no. ;)
Also it couldn´t display the AM signal (25Mhz carrierfrequency) proper, but the rest is not too bad, single/normal trigger works fine.
Showstopper is the minimum resolution of 500mV/div. in 10x mode and the missing of other triggerfunctions.
Interesting:
Frequency will only be measured when the trigger is in "auto" mode, in normal mode it doesn´t work.
Also you can´t "zoom" in after stop.
Continue playing with the board and scope...
We need ask ourselves who might buy this $120 tablet instead of a proper DSO or for that matter a working CRO ?I quite understand and we needed to do maths on the fly with a CRO however most DSO's are able to display waveforms in the units of Amps.
But the amount of menu-diving required simply isn't worth it.Another FAIL for FNIRSI. ::)
Yeah, total fail. They totally should have added a whole extra menu just for that. Not. :palm:
At least an order of magnitude sensitivity better is available in all other scopes and totally without the apparent sensitivity to 10x probes. :o
Yes older instruments do have their limitations too but not so for the most basic of measurements like these.
A buyers expectations of getting a somewhat capable instrument would not be met and for once on this forum I'd recommend the purchase of a CRO so not to be so disappointed. Yes I said that ! :palm:
Yet member bd139 picked up a mint condition TDS210 DSO yesterday for the same price as the topic of this thread of which I strongly suggest will be a much better investment.
I don't understand why people are so shocked by the lies and the performance of this oscilloscope.I'm not shocked!
if you have 150$...
Actual price is 100$ (on taobao.com in China, price is 699 RMB = ~100$), this is how much I paid...
Do you know any alternative for the same price? :)
I suspect 99.44% of the buyers have no need for 100 MHz or < 50 mV/div performance--half of that number probably don't even know what those specs mean...
Yep. It's 200MS/s actually as both ADC's in the one chip are clocked out of phase, same signal goes into both ADC channels.
tv84 is in the place so he will soon be able to unlock the serial bus decoding, the eye diagram and the zone triggering :-/O
Look: https://mysku.ru/blog/aliexpress/80036.html#comment3580231QuoteIf R12 is reduced to 10-22 Ohm, the frequency response at the HF will become flat to 100 MHz.
If you increase C2, it will level out at the low frequency response.
Bodnar-Pulse :
(Attachment Link)
Terminated with 50 \$\Omega\$ ,although it makes no difference... ;D
Has anybody measured the bandwidth in 1x mode?
Has anybody measured the bandwidth in 1x mode?
What specifically did you want verified?
We need ask ourselves who might buy this $120 tablet instead of a proper DSO or for that matter a working CRO ?I quite understand and we needed to do maths on the fly with a CRO however most DSO's are able to display waveforms in the units of Amps.
But the amount of menu-diving required simply isn't worth it.Another FAIL for FNIRSI. ::)
Yeah, total fail. They totally should have added a whole extra menu just for that. Not. :palm:
At least an order of magnitude sensitivity better is available in all other scopes and totally without the apparent sensitivity to 10x probes. :o
Yes older instruments do have their limitations too but not so for the most basic of measurements like these.
A buyers expectations of getting a somewhat capable instrument would not be met and for once on this forum I'd recommend the purchase of a CRO so not to be so disappointed. Yes I said that ! :palm:
Yet member bd139 picked up a mint condition TDS210 DSO yesterday for the same price as the topic of this thread of which I strongly suggest will be a much better investment.
People who want a compact battery operated portable scope they can take with them anytime and can also do floating measurements etc ;) If you have something better to offer let us know. So far I haven't seen any offers of something better for the price. I've seen a lot worse for the price for a portable scope with tiny iddy biddy screens or limited bandwidth etc :( If I want to make my TDS3012 portable I would have to pay $500 US just for a battery and extra for a charger etc !! Yes it's a lot better scope than this one but for on the job in-situ measurements this would be adequate in most cases and compact as well.I get that and for those that understand the limitations of these tablets the price is good however I would never recommend them as a beginners scope which due to their price is tempting to those with a limited budget.
cheers
What specifically did you want verified?
I was wondering what the bandwidth was with the supplied probes in 1x mode. What would a 10Mhz square wave look like with probes in 1x mode?
I get that and for those that understand the limitations of these tablets the price is good however I would never recommend them as a beginners scope which due to their price is tempting to those with a limited budget.
This is a prime case to use a recent Keysight slogan: Get a real scope !
I was wondering what the bandwidth was with the supplied probes in 1x mode. What would a 10Mhz square wave look like with probes in 1x mode?
This is all using the timing signals from the calibrator. 1 Vpp at 10 MHz, nominally squarewave.
The supplied probes were used first, both set to 1X.
Once I have it I'll give it a look over. My expectations are low, but we'll see.
25MHz sinus looks pretty distorted , no wonder why the 10MHz square wave is odd .
That's very good, but the MicSigs last as long too. :-+
25MHz sinus looks pretty distorted , no wonder why the 10MHz square wave is odd .
I believe it is an AM signal, unless I missed it the modulating frequency does not seem to be stated....
I was wondering what the bandwidth was with the supplied probes in 1x mode. What would a 10Mhz square wave look like with probes in 1x mode?
This is all using the timing signals from the calibrator. 1 Vpp at 10 MHz, nominally squarewave.
The supplied probes were used first, both set to 1X.
:-+
Food for thought. I'm surprised at how much difference the probes made at this frequency. There's other threads here that show even the cheapest eBay probes working fine at frequencies an order of magnitude higher.
eg. https://www.eevblog.com/forum/reviews/cheapest-100mhz-oscilloscope-probes-hands-on-review/ (https://www.eevblog.com/forum/reviews/cheapest-100mhz-oscilloscope-probes-hands-on-review/)
Edit: Did you compensate the probes on each device before the screenshots? Images like this say "uncompensated probe" to me:
(https://www.eevblog.com/forum/testgear/fnirsi-1013d-100mhz-tablet-oscilloscope/?action=dlattach;attach=1031238;image)
The AP020 is a FET active probe, isn't it--a $550 (MSRP), $250 (used VG+) probe--that's comparing apples to lemons.
But I get your point, it shows that the signal is pretty damned clean...
the difference between the generic p6100 and the Fnirsi is interesting though.
Chineese P6100 are crappy compared to brand probes , not linear even bellow 100MHz , so that Fnirsi should be the crappiest probes ever made :-DD
Food for thought. I'm surprised at how much difference the probes made at this frequency. There's other threads here that show even the cheapest eBay probes working fine at frequencies an order of magnitude higher.
eg. https://www.eevblog.com/forum/reviews/cheapest-100mhz-oscilloscope-probes-hands-on-review/ (https://www.eevblog.com/forum/reviews/cheapest-100mhz-oscilloscope-probes-hands-on-review/)
Edit: Did you compensate the probes on each device before the screenshots? Images like this say "uncompensated probe" to me:
(https://www.eevblog.com/forum/testgear/fnirsi-1013d-100mhz-tablet-oscilloscope/?action=dlattach;attach=1031238;image)
Once I have it I'll give it a look over. My expectations are low, but we'll see.
User interface looks awful.
In a not at all bandwidth related exercise I tested the 1013D's battery life.
It ran continuously for 6 h 45 m while monitoring two phases of a 4-phase stepper motor being accelerated and cycled clockwise/anticlockwise over a 270° sweep, pulse frequencies 7 to 44 Hz...
Pretty damned good, first thing I've tested that bettered the claimed spec. It took a 3½ hours to recharge at 1.8 A tapering to 0.3 A over the last ½ hour...
I got similar results testing the probe that came with my FNIRSI 5012H. Probe was compensated and then I used a 1V square wave at 2Mhz with 1ns Rise time.
Fnirsi probe:
(https://www.eevblog.com/forum/testgear/fnirsi-1013d-100mhz-tablet-oscilloscope/?action=dlattach;attach=1032676;image)
Generic P6100:
(https://www.eevblog.com/forum/testgear/fnirsi-1013d-100mhz-tablet-oscilloscope/?action=dlattach;attach=1032680;image)
Lecroy AP020:
(https://www.eevblog.com/forum/testgear/fnirsi-1013d-100mhz-tablet-oscilloscope/?action=dlattach;attach=1032684;image)
The probes that came with mine are just plain ol' Chinese P6100s¹--there would be no reason for FNIRSI to make their own, as l suspect in China P6100s come with Happy Meals :
(http://www.paladinmicro.com/TestEquipment/Yeapook/Probes-00.JPG)
------------------------------------------
¹ - Now pretty much generic, and most likely actually made by 37 or more manufacturers. From what I can tell, in Shenzhen, you cannot swing a dead cat without striking at least a dozen electronics producers.
You can't compensate probes on 1x only on 10x. The compensation trimmer cap is not part of the 1x probe circuit.
I tried adjusting both probes with the signal applied, and couldn't get any noticeable change at 1X. :-//
You can't compensate probes on 1x only on 10x. The compensation trimmer cap is not part of the 1x probe circuit.
I tried adjusting both probes with the signal applied, and couldn't get any noticeable change at 1X. :-//
Still, the probes trimming range must suit the input capacitance of the scopes input for 10x work when matching probes to scopes. Yet it is just not that simple either as a probes frequency response when swept to a scopes max BW and beyond needs be a flat as possible for measurements at any rated frequency to be reasonably accurate.
FYI for any instrument tests it's always best to use direct BNC cable connections and assess the probes independently/separately.
The "P6100" probes with my FNIRSI look slightly different to those pictured. Text on labels is finer, moulded text shown in pic beside CE marking is absent, and possibly the moulded "X1" and "X10" are different.
Maybe my mysterious no-nameplate 'scope-type-thing was fished out of the same dumpster as some knock-off P6100s? :-DD
I got similar results testing the probe that came with my FNIRSI 5012H. Probe was compensated and then I used a 1V square wave at 2Mhz with 1ns Rise time.
Fnirsi probe:
(https://www.eevblog.com/forum/testgear/fnirsi-1013d-100mhz-tablet-oscilloscope/?action=dlattach;attach=1032676;image)
Generic P6100:
(https://www.eevblog.com/forum/testgear/fnirsi-1013d-100mhz-tablet-oscilloscope/?action=dlattach;attach=1032680;image)
Lecroy AP020:
(https://www.eevblog.com/forum/testgear/fnirsi-1013d-100mhz-tablet-oscilloscope/?action=dlattach;attach=1032684;image)
Possibly not my ineptness, then.
I tried adjusting both probes with the signal applied, and couldn't get any noticeable change at 1X. :-//
Then the second probe was really bouncing around on that leading edge, while the first was pretty consistent.
Garbage probes, I guess.
Who knows how many let's say "companies" produce P6100 probes ... hard to believe it is just one in the whole China :D Because is low quality and cheap to madeJust one company makes the P6100 probes.
What tools did you use for these nice screenshots? :)
Who knows how many let's say "companies" produce P6100 probes ... hard to believe it is just one in the whole China :D Because is low quality and cheap to madeJust one company makes the P6100 probes.
They have been making probes for decades and make many more than just P6000 models.
Other Chinese probe manufacturers exist too.
the difference between the generic p6100 and the Fnirsi is interesting though.
Yep, I'm wondering how a probe can be that bad when even $5 eBay probes seem to work well up to 300MHz.
Yes but look at your second image, one probe is certainly a copy as it's NOT a P6100.Who knows how many let's say "companies" produce P6100 probes ... hard to believe it is just one in the whole China :D Because is low quality and cheap to madeJust one company makes the P6100 probes.
They have been making probes for decades and make many more than just P6000 models.
Other Chinese probe manufacturers exist too.
Not too sure about that. The generic 6100 (I have 4 identical samples bought from different sources) and FNIRSI Probes are not exactly the same. All generic 6100 in my possession look the same and behave the same. The FNIRSI probe is physically different and behave differently.
Generic 6100 on the left, FNIRSI probe on the right.
(https://www.eevblog.com/forum/testgear/fnirsi-1013d-100mhz-tablet-oscilloscope/?action=dlattach;attach=1033510;image)
(https://www.eevblog.com/forum/testgear/fnirsi-1013d-100mhz-tablet-oscilloscope/?action=dlattach;attach=1033514;image)
(https://www.eevblog.com/forum/testgear/fnirsi-1013d-100mhz-tablet-oscilloscope/?action=dlattach;attach=1033518;image)
I would say they work okish up to 50Mhz (FNIRSI more 25Mhz). 300Mhz not really. Like CDaniel mentioned, linearity is not really good.
I did some tests with a noise source over here:
https://www.eevblog.com/forum/testgear/test-equipment-anonymous-(tea)-group-therapy-thread/msg2416473/#msg2416473 (https://www.eevblog.com/forum/testgear/test-equipment-anonymous-(tea)-group-therapy-thread/msg2416473/#msg2416473)
https://www.eevblog.com/forum/testgear/test-equipment-anonymous-(tea)-group-therapy-thread/msg2860544/#msg2860544 (https://www.eevblog.com/forum/testgear/test-equipment-anonymous-(tea)-group-therapy-thread/msg2860544/#msg2860544)
Yes but look at your second image, one probe is certainly a copy as it's NOT a P6100.Who knows how many let's say "companies" produce P6100 probes ... hard to believe it is just one in the whole China :D Because is low quality and cheap to madeJust one company makes the P6100 probes.
They have been making probes for decades and make many more than just P6000 models.
Other Chinese probe manufacturers exist too.
Not too sure about that. The generic 6100 (I have 4 identical samples bought from different sources) and FNIRSI Probes are not exactly the same. All generic 6100 in my possession look the same and behave the same. The FNIRSI probe is physically different and behave differently.
Generic 6100 on the left, FNIRSI probe on the right.
(https://www.eevblog.com/forum/testgear/fnirsi-1013d-100mhz-tablet-oscilloscope/?action=dlattach;attach=1033510;image)
(https://www.eevblog.com/forum/testgear/fnirsi-1013d-100mhz-tablet-oscilloscope/?action=dlattach;attach=1033514;image)
(https://www.eevblog.com/forum/testgear/fnirsi-1013d-100mhz-tablet-oscilloscope/?action=dlattach;attach=1033518;image)
Of a good few P6100's I've bought over the years all have been from different sources yet by the same manufacturer which after considerable hunting I was able to find however they wouldn't deal with small fry like me.
Now I just get PP510 from Siglent as they are reasonably priced.
I also have one exactly similar to the "6100" but marked "P6100" instead.
(https://www.eevblog.com/forum/testgear/fnirsi-1013d-100mhz-tablet-oscilloscope/?action=dlattach;attach=1033746;image)
Just do a search for "p6100 probe" on ebay. They are all marked as p6100 but are all a little bit different. I don't think there's only one producer :)
Anyway my point is, the P6100 probes from FNIRSI are particularly bad.
You got my curiosity up and I did take a look at eBay's listings, something that caught my eye was how many vendors were touting their product's ability to work with "HP and Tektronix" 'scopes--HP hasn't made a 'scope in over 20 years. I'm not sure if Agilent still makes them
.
You can't compensate probes on 1x only on 10x. The compensation trimmer cap is not part of the 1x probe circuit.
I tried adjusting both probes with the signal applied, and couldn't get any noticeable change at 1X. :-//
FYI for any instrument tests it's always best to use direct BNC cable connections and assess the probes independently/separately.
The original (1995) Honda S2000 delivered 247 H.P. @ 8600 RPM, but just 75 to 120 H.P. from 2500 to 5000 RPM, and barely able to launch itself from a stop. You had to "rev" it to 6 or 7 grand to get a respectable launch--whereupon everyone watching was wondering "WTF is wrong with that A-hole".
It's interesting that the Siglent probes respond radically differently. What is the expected frequency limit for these when set to 1X?For your SDS1202X-E its PP215 probes are 200 MHz probes and are listed as capable of just 6 MHz in 1x mode:
The original (1995) Honda S2000 delivered 247 H.P. @ 8600 RPM, but just 75 to 120 H.P. from 2500 to 5000 RPM, and barely able to launch itself from a stop. You had to "rev" it to 6 or 7 grand to get a respectable launch--whereupon everyone watching was wondering "WTF is wrong with that A-hole".
That's because it was built to be driven, not to be "launched".
Take one out on some twisty mountain roads sometime. :popcorn:
With automobile engines peak H.P. of an engine is an interesting number--power generally happens briefly, just before you shift--but the level and flatness of the torque curve are much more important to real world performance on the street...
The original (1995) Honda S2000 delivered 247 H.P. @ 8600 RPM, but just 75 to 120 H.P. from 2500 to 5000 RPM, and barely able to launch itself from a stop. You had to "rev" it to 6 or 7 grand to get a respectable launch--whereupon everyone watching was wondering "WTF is wrong with that A-hole".
In the end it was just a plain ol' 150 H.P Jap 4-banger built to withstand 9000 RPM, and tuned to make the marketing people happy by producing an unusable horsepower "peak" at that engine speed. It was not at all a fun car to drive, which is the whole point of "sports cars".
The best description I ever saw was that "it is a great car as long as you drive it like you just stole it."
The original (1995) Honda S2000 delivered 247 H.P. @ 8600 RPM, but just 75 to 120 H.P. from 2500 to 5000 RPM, and barely able to launch itself from a stop. You had to "rev" it to 6 or 7 grand to get a respectable launch--whereupon everyone watching was wondering "WTF is wrong with that A-hole".
That's because it was built to be driven, not to be "launched".
Take one out on some twisty mountain roads sometime. :popcorn:
Bollocks. No torque no push, no push no fun, simple as that. It's a girly car anyways.
Yeah, power is torque x rpm, choose your venom. But keep in mind that on the streets you can't drive like a maniac. That's why EVs are so fun to drive.
Just do a search for "p6100 probe" on ebay. They are all marked as p6100 but are all a little bit different. I don't think there's only one producer :)
Read a physics book.
At least we've all moved on from units like "feet"... :scared:What's wrong with feet? I have two, use them all the time, marvelous stuff... :-DD
At least we've all moved on from units like "feet"... :scared:
Not here in the "colonies",
English/Imperial measure is still the official standard--us long with Myanmar (I don't even like saying that word) and Liberia.
Figure out which FPGA pin controls it, make some FPGA code to just set that pin and nothing more. Do the rest later :-)
Edit: Or.... just use the existing FPGA code and send it the command to turn the lights on.
ReplyContent：
hi, friend
The situation you said is measurable, you can contact the store where you bought this product, and she will help you solve this problem. Thank you for your message and wish you a happy life!
ReplyDatetime：
2020-09-02 14:47
Hi,
As the scope couldn´t measure in normal trigger mode, I´ve asked them if there will be any firmware upgrade in the future, to fix that.
This was on 13th august.
Today I receive an answer:QuoteReplyContent：
hi, friend
The situation you said is measurable, you can contact the store where you bought this product, and she will help you solve this problem. Thank you for your message and wish you a happy life!
ReplyDatetime：
2020-09-02 14:47
OK, I´m going to ask AMAZON... :-DD
[How to fix irresponsive touchscreen] [with solution]
So I tried a couple of low value caps (1pF, 5pF, 10pF and 100pF) and they all made things a bit better, but the 100pF one made it just PERFECT :-DMM!
Questions
1. Why is there a cap connected to SCL?
1.1 That's a capacitor, right?
2. Why is the cap connected across two signal lines?
2.1 I never saw anything like that in I2C lines, is this some advance hack?
2.2 What could the other signal be?
3. Why do you think the touchscreen was defective in the first place?
The cap appears to be placed across SDA and SCL. That makes pretty much no sense.
Around 3k3 would be better for 3.3V logic, with no additional capacitance.
maybe the touch controller datasheet had it in the reference design
...
Waveform captures are 15 000 bytes. Take slightly longer than a screen capture - maybe 2.5 seconds. Why 15 000 bytes? Don't know. Perhaps that's the full memory for data points?
...
Still a dual channel 20MHz 7" touch screen portable tablet scope for $140 isn't bad.
The values in DataBlock1 do not appear to be raw ADC values but seem to follow the same scale as the values in DataBlock2 but with a different baseline.
he data buffer readings range 0 - 399 with 200 corresponding to 0
However, it doesn't seem to be pure pixel doubling from an ADC range of 200 as both even and odd values appear in the buffer. E.g the top of a square wave can have values varying by 1.
Is it a fake?
So, if beauty is what you are after...:-DD
I bought this "new" version from Amazon Germany, and received it today. After using it for the first time, and saving one image and one waveform, this obviously damaged the internal SD image... Now I only get a red "SD ERROR" when switching on the device...
Does anyone have a proper SD image for this device (FNRISI-1013D-II), that I can use to fix the device? Any help would be much appreciated!
Would you mind dumping the winbond SPI flash and posting it here?attached...You'll need a CH341A (preferred)...This is totally shit programmer...
I bought EZP2019+... Each reading get different result...
After that order SP16-B (www.sofi-tech.com (http://www.sofi-tech.com)) this one read stable.
Version I of this 'scope appears to use BNC connectors.
Version II appears to use some kind of recessed connector, possibly MCX jack (female).
Can anyone confirm ?
Version I of this 'scope appears to use BNC connectors.
Version II appears to use some kind of recessed connector, possibly MCX jack (female).
Can anyone confirm ?
Well, I finally found the "money shot" of the new version. It appears that it still uses BNCs, but the connectors and the power switch are now recessed into the top of the device
Version I of this 'scope appears to use BNC connectors.
Version II appears to use some kind of recessed connector, possibly MCX jack (female).
Can anyone confirm ?
Well, I finally found the "money shot" of the new version. It appears that it still uses BNCs, but the connectors and the power switch are now recessed into the top of the device
Official product page was updated in the last 2 weeks: http://www.fnirsi.cn/productinfo/556152.html (http://www.fnirsi.cn/productinfo/556152.html)
ADS1013D tablet oscilloscope Review
https://chinese-electronics-products-tested.blogspot.com/p/ads1013d-tablet-oscilloscope-tested.html (https://chinese-electronics-products-tested.blogspot.com/p/ads1013d-tablet-oscilloscope-tested.html)
Hello.
Can someone explain this phenomenon?
As shown in the attached image (5.jpg), a glitch occurs on the waveform at 25ns or 10ns / frequency 7 ~ 12Mhz related to the second channel.
Of course, like the (6.jpg) image, it looks fine at other timings or at higher frequencies.
After 1013d operation, wait 5 minutes and select autoset, it looks normal.
However, when the power is turned off and on, the glitch may appear again.
To solve this, I replaced OPAMP (opa356) and ADC (ad9288), but the result did not change.
Oh and I tried downloading the firmware again, but the result is the same.
Does anyone know how to fix it?
Well... of course I've open it and check all connections. Interesting is that the touch screen generaly works. Only on 2nd chanal menu does not.
The glitch in the CH2 waveform looks to me as missing data in that channel's buffer being masked by the sin(x)/x interpolation algorithm
Well... of course I've open it and check all connections. Interesting is that the touch screen generaly works. Only on 2nd chanal menu does not.
The next thing would be to look for a badly soldered pin on the touch screen IC.
The glitch in the CH2 waveform looks to me as missing data in that channel's buffer being masked by the sin(x)/x interpolation algorithm
It should be OK at 10MHz. These things have been tested up to about 30Mhz with no problems.
Not if the buffer memory also fails at 10 MHz
Not if the buffer memory also fails at 10 MHz
I don't think the frequency of the buffer memory is linked to the frequency of the input signal in any way.
Nor do I, that's why I found your above comment: "It should be OK at 10MHz. These things have been tested up to about 30Mhz with no problems." to be perplexing?
Nor do I, that's why I found your above comment: "It should be OK at 10MHz. These things have been tested up to about 30Mhz with no problems." to be perplexing?
The pics of the distortion here (https://www.eevblog.com/forum/testgear/fnirsi-1013d-100mhz-tablet-oscilloscope/msg3418548/#msg3418548) show distortion at 10MHz but not at 30Mhz.
I can't explain that (but we know this is a sick oscilloscope...)
It certainly is a strange phenomenon, and what I see on mine I suspect it is the hardware. I will try to solve it, but in the case it is software it will be more difficult since that involves reverse engineering of both soft and hardware.
Your problem with the touch screen seems to be a little different than mine. In Your case it does not react in many places. My problem is only in one function. Because of this I would like to know for sure if it is not because of corrupted software.
That is why I will do extensive research and testing and probing before buying anything for it. For you it is wait until I receive my CH341 programmer and I can retrieve the firmware from mine :=\
My dispute ends late today after which aliexpress has to step in and come up with a resolution. When that is out of the way I will open up the device and start my investigation :palm:
If I'll fail with repairing 1013d I'll consider to look for something reliable.
From the above facts, I came to the conclusion that this is not something that can be fixed by replacing one or two parts.
My 1013d seems to be an early pcb type. I know that the most recent release is shieldboxed in the opamp area.
Facts like this make me sad. ~~~ :(
If I'll fail with repairing 1013d I'll consider to look for something reliable.
For eljot it might be something else, but could be the same. If only a small part of the capacitive sensor is corrupt it could result in just a small square on the screen that does not respond.My way of thinking is like that: If a small part of the screen is corrupted it would not response at all at this certain place. But when the 2nd chanel menu does not exist (is not switched on) on the screen the area of the screen is responding ie. I can move coursors and etc. So it means (deduce) the tuch screen is ok. Might be that I'm wrong??? |O
It could easily be a bad solder joint on the PCB - an opamp with no GND or something like that. Go over everything with a soldering iron.
(also make sure there's no stray solder blobs or flux residue in the input area)
You are right about that if it is the touch it should not work for any thing in that region. With my device it is a small band across the whole display, but that being said the buttons run/stop and auto set work without problems and at least the auto set button is partially in the section that does not work.
So the test I wrote about is my best bet for investigating the problem.
6. If noise is applied to the first channel and a square wave is applied to the second channel, it is affected by the noise, and the waveform with noise is also seen in the second channel. (noise.jpg).
When I connect another oscilloscope to the second channel, there is no noise.
6. If noise is applied to the first channel and a square wave is applied to the second channel, it is affected by the noise, and the waveform with noise is also seen in the second channel. (noise.jpg).
When I connect another oscilloscope to the second channel, there is no noise.
The question of the noise signal having an effect on the second channel has been solved.
The reason is that I wrapped the two probes together.
But still, the glitch question cannot be resolved. :-\
Here is the dump of ST 25P16VP... (this is FPGA stream data and connected to dedicated FPGA pins)
I don't think that it is useful for anyone, just let it be for history...
I2C I guess for store settings.
Dears, has anyone dump W25Q32 memory of the new wersion 1013d (Englisch) ? I would like to compare it with mine. I can't still find what is wrong.https://1drv.ms/u/s!Av-Riptwsak2iskvoKrSKJR8rpKr_g?e=m4eMUw
Thanks. After I had "play" with flash memory I was able be to state touch screen damage. One tx chanel of the screen was grouded. I dont know if it is GT911 IC fault or connection tape fault. Now I am waiting for a new touch screen I hope it will fit.
Dears, has anyone dump W25Q32 memory of the new wersion 1013d (Englisch) ? I would like to compare it with mine. I can't still find what is wrong.https://1drv.ms/u/s!Av-Riptwsak2iskvoKrSKJR8rpKr_g?e=m4eMUw
The attached archive contains firmware for RD6006 :-//It is a bug on this forum... it is sometimes replace the file content.
Thanks. After I had "play" with flash memory I was able be to state touch screen damage. One tx chanel of the screen was grouded. I dont know if it is GT911 IC fault or connection tape fault. Now I am waiting for a new touch screen I hope it will fit.
Has anyone experience with the 1013D measuring voltages above 400 volts? With a 1: 100 probe head?
Is this possible with this oscilloscope? Does it have a default setting of 1:100?
Has anyone experience with the 1013D measuring voltages above 400 volts? With a 1: 100 probe head?
Is this possible with this oscilloscope? Does it have a default setting of 1:100?
I asked on another post and it seems like Apple likes to use these, too??
https://youtu.be/5AwdkGKmZ0I?t=943 (https://youtu.be/5AwdkGKmZ0I?t=943)
but can also be a stage, solely for vid purpose.
I see Hantek 2D72/2D72 as another option for this ...You could also take a look at the Owon HDS200 series with a 3.5" screen.
Yes, I have noticed those as well, but looks like those are just the same as mentioned Hantek's?QuoteI see Hantek 2D72/2D72 as another option for this ...You could also take a look at the Owon HDS200 series with a 3.5" screen.
Are there any realistic options to cheaply build an active probe that could eliminate this sensitivity problem, for lower frequencies at least?
I started with re-engineering the schematic, and by the looks of it the 8 pin ic might be an i2c eeprom. Since pin 7 is left floating (as well as pins 1, 2 and 3) it does not appear to be a 24LC04 since they need pin 7 (WP) tied either high or low. On semiconductor devices on the other hand allow for these pins to be floating. There is the N24C64 for instance, but probing the bus will need to be done to see if that is right.
Is going to be quite a bit of work, but as an retired engineer I have time on my hands :)
No that is the one that holds the fpga configuration. There is another chip nearer to the fpga just below the 50MHz oscillator. (In the attached picture above the osc) It has two connections to the fpga and is also routed to the 4 pin not mounted connector near the winbond chip you pointed out.I understand. I didn't see her because of the matrix cable :)
I understand. I didn't see her because of the matrix cable :)
Yes, i have a chip unmarked too >:(I understand. I didn't see her because of the matrix cable :)
Is yours also unmarked? (Same as the fpga and the adc's)
As said it is now a hobby project and might lead to open source scope software. It is in line with interests I have. ;D
In the front end there is a 5 pin smd (sot23-5) with markings 8751 2023. In the old one the marking is OAAI which probably is an OPA356 operational amplifier. Anyone an idea if it is the same ic?OAAI is OPA356 (https://www.ti.com/lit/ds/sbos212a/sbos212a.pdf)
Can anyone verify the LCD connection. Tried to find pinouts on the net but failed.
Does yours show the same reversal of the coordinates when you connect it to the scope?No. The touchscreen I received is doing fine with the coordinate system. Works correctly.
I'm looking for a 7 inch lcd for a lichee nano to do development for the scope but find it hard to obtain specifications of displays offered on aliexpress.
I asked the seller of this one (https://nl.aliexpress.com/item/32691414835.html) for a datasheet, but they don't have it |O
Searching on google does not render much info either.
I think it is a 50pin and might be the same as what is in the FNIRSI-1013D. If so I only need to make a converter from 50pin to 40pin.
Anyone any suggestions or a pointer to a cheap 40pin 7 inch 800x480 lcd compatible with the lichee nano. Preferably on aliexpress.
Any 800x480 RGB lcd should be compatible, only timing will change!
Started with analyzing the I2C from the touch panel. Made a breakout board for it with headers for a bluepill STM32F103C8 and ffc/fpc 0.5mm 6 pin conversion boards. This way it is easy to connect to the signals with either or both the STM and a scope.
At startup a blob of data is being written to the panel and after that it starts polling the panel to see if there is touch. Unfortunately I see errors in the communication where it looks like the SCL is being pulsed more than it should. Have to hook the scope up again to see what is actually going on.
Need to analyze the data being send to see what it is doing. It starts at address 0x8047 (config version) and writes a lot of bytes. Most are acknowledged by the panel, but some are nacked.
After I analyzed the data I will post the results here.
Also monitored the INT and RST lines to see what is happening there, because the device address can be set with these lines. What they do is not so nice. At the startup of the scope the RST line is set high and then the INT line is toggled with a 13ms/200us pulse width ratio for quite some time.
Have to search the disassembly files I made with Ghidra to see if I can find where port A is being controlled.
How does this scope compare to the miniware DS203/213? Looking for a cheap scope that realistically will only get used a few times a year and can't justify spending $$$ on something nicer.
SMTO502S 60MHz 250MSas + 1ch. signal generator. 135USD. (incl, EU VAT)
SMTO1002 100MHz 1GSas 175USD (excl. VAT)
SMTO1002S 100MHz 1GSas + 1ch. signal generator. 205USD (Excl. VAT)
I think we should move our attention to the FPGA protocol since that's what controls the LCD backlight and everything else :)
There are 4 candidate functions(1da04, 1da8c, 2b96c, 4d164 In file FSI-1013en.bin) exchanging with gt910.
On the lichee nano the kernel now uses uart1 as its default ttyS0 and uart0 is disabled.
I have added a linux directory in the github repository with the images output of the buildroot build. Also added the files I changed and the instructions in a readme.txt file.
In the image directory I added a "readme.txt" and "location of uart1 connections.jpg" file.
Will try to change u-boot to use uart1 today and if it works I will upload the image and changed files to the repository. (https://github.com/pecostm32/FNIRSI-1013D-Hack)
Next step would be to move the communications to the USB port like thirtythreeforty did in his business-card, and disable all the uarts.
Might be a good idea to create a new board config for the scope with these options.
u-boot probably needs additional changes to handle initial communication with the fpga, but that still requires a lot of research.
My problem with the back-light not being on is a bit tricky to initially solve in the hardware. The fpga pin is directly connected to the enable pin of the back-light power converter. It is pulled low by a resistor and needs to be high to enable the converter. There is a risk of damaging the fpga when this pin is pulled high by connecting it to the 3,3V rail.
Just tried it again with the sdcard.img you uploaded to github, and still no uart on any of the ports (tried uart0 and uart1)... Weird... However, by removing the sd card the oscilloscope boots normally, so it's not broken.
I also tried flashing the card with Win32DiskImager and with dd from Linux, same result. Very strange.
Just tried it again with the sdcard.img you uploaded to github, and still no uart on any of the ports (tried uart0 and uart1)... Weird... However, by removing the sd card the oscilloscope boots normally, so it's not broken.
I also tried flashing the card with Win32DiskImager and with dd from Linux, same result. Very strange.
Indeed strange. I used a small (128MB) micro sd card, and within the scope it boots to linux without problems. When I insert the sd card in my card reader connected to my linux computer it opens two partitions, showing the boot image and the root file system.
Which version of the scope do you have? The one with the 16Mbit flash or the one with the 32Mbit flash?
I can also mount the image file on my linux mint system with the same result. Two partitions. See picture.
int sub_800167A0()
{
sub_8001764C(0x1C20890, 0, 0);
sub_8001764C(0x1C20890, 1u, 0);
sub_8001764C(0x1C20890, 2u, 0);
sub_8001764C(0x1C20890, 3u, 0);
sub_8001764C(0x1C20890, 4u, 0);
sub_8001764C(0x1C20890, 5u, 0);
sub_8001764C(0x1C20890, 6u, 0);
return sub_8001764C(0x1C20890, 7u, 0);
}
int __fastcall sub_800168FC(unsigned __int8 a1)
{
unsigned __int8 v1; // r4@1
v1 = a1;
sub_8001764C(0x1C20890, 0, 1);
sub_8001764C(0x1C20890, 1u, 1);
sub_8001764C(0x1C20890, 2u, 1);
sub_8001764C(0x1C20890, 3u, 1);
sub_8001764C(0x1C20890, 4u, 1);
sub_8001764C(0x1C20890, 5u, 1);
sub_8001764C(0x1C20890, 6u, 1);
sub_8001764C(0x1C20890, 7u, 1);
sub_8001774C(0x1C20890, 9);
sub_80017738(0x1C20890, 10);
v1C208A0 = v1 | v1C208A0 & 0xFFFFFF00;
sub_80017738(0x1C20890, 8);
return sub_8001774C(0x1C20890, 8);
}
Here is the dump of ST 25P16VP... (this is FPGA stream data and connected to dedicated FPGA pins)
I don't think that it is useful for anyone, just let it be for history...
I2C I guess for store settings.
https://mega.nz/file/MGY3FI5b#wURGvOJB9Zb6dqilI2w5TRbJWrP3fHHG5muqNXtb-r4
WARNING: the .RBF file has the bytes bit-reversed! Reversing...
FPGA - RBF/RPD (Raw Binary File) - Filesize: 16 777 216 bits (00200000 bytes)
00000000 - Start of File (Type 1)
[00000048 00000021]
Bit 7 - 1111111111111111111111111111111111111111 FFFFFFFFFF
Bit 6 - 1111111111111111111111111111111111111111 FFFFFFFFFF
Bit 5 - 1111111111111111111111111111111111111111 FFFFFFFFFF
Bit 4 - 1111111111111111111111111111111111111111 FFFFFFFFFF
Bit 3 - 1111111111111111111111111110111010000000 FFFFFFEE80
Bit 2 - 0000011100110011001011111000000000111111 07332F803F
Bit 1 - 1100000000000111100011000000010111111111 C0078C05FF
Bit 0 - 0000000000010101000100010110110111111111 0015116DFF
Bits 0080 - EPCS/EPCQ ID check: Enabled
Bits 005F - Stream size: 943 711 bits (0001CCCC bytes) Compression Bit ON (+1) Size NOT OK
Bits 0056 - 0000 0000 : 0x56-0x5D
Bits 004C - Programming Mode: Active Serial (AS x1)
Bits 003B - IDCode (Version+Part Number only): 0x020F1 (-> 0x024F1)
Bits 0008 - Usercode: 0015116D
00000049 - Header CRC-16_MODBUS: 0033 [00000021-00000048] CRC OK
0000004B - Data Framesize: 207 [0000004B-000000F1]
000000F2 - 4-byte words: 1260 [000000F2-000014A1]
00000000 - Stream Size (Uncompressed): 15 610 872 bits
000014A2 - CRC Framesize: 207+0 # Data Frames: 1727 [000014A2-00059D4F]
Start address: 00000000
00059D50 - Post-device bitstream pad bytes (0xFF): 1583407 [00059D50-001DC67E]
File Checksum: 1E469589
@pcprogrammer, are you doing the analysis in ASM??!?
Why don't you do the analysis in pseudo-C?
Interesting.
I do have some linux experience. Maybe the issue you're having with U-boot is that the code to enable UART1 has not been added (port configuration, multiplexer config, etc). I'll take a look and see if I can get it to output on UART1 and work from there. I'm tired of soldering the FPGA pins with wirewrap just to get the U-boot uart :P
I have managed to boot u-boot again, both for your image, my image and a licheepi nano image, but no linux seen at the moment.
We'll manage to do it, I'm sure!
We'll manage to do it, I'm sure!
I added the image with u-boot on uart1 that fails in the repository. Also added the tar.gz of the uboot source I used and changed. (https://github.com/pecostm32/FNIRSI-1013D-Hack/tree/main/Linux/changed%20packages/Using%20uart1%20(uboot%20fail))
The u-boot souce code is indeed not prepared for output on UART1. The following link shows how the pin configuration is only available for UART0:
https://github.com/Lichee-Pi/u-boot/blob/013ca457fd64b72444a0f5f480b1bbdd8b7481eb/arch/arm/mach-sunxi/board.c#L86
(this is only pin multiplexer configuration, it won't enable uart1 output even if configured for port A)
Also, in order to get the backlight working under linux, what I do is boot the scope without an SD card inserted, then when it powers up the backlight, I insert the SD card and reset the CPU by pulling the reset pin to GND briefly. This will keep the backlight on, and I think that the FPGA pins are kept high-z because it did not finish initializing it.
Nice job. Can you point me to an image compiled without those changes and one with the changes?
Nice job. Can you point me to an image compiled without those changes and one with the changes?
And well done to iscle on getting the display up and running. What did you to to get that done?
Is it this section that needs to be changed?
Ok I will try that.
As you seem to know your displays any idea on this:
I received the display I bought (https://nl.aliexpress.com/item/32691414835.html?spm=a2g0s.9042311.0.0.27424c4dER5LsR) but it does not work with the FNIRSI-1013D. It shows some white fading and stabilizes in a blue bar on the right side of the display.
On the cable there is "7300130906 E231732 NETRON-YF P08 94V-0\1332"
I made a video of what it does and posted it on youtube (https://youtu.be/K5SbKid2z_o)
Does yours show the same reversal of the coordinates when you connect it to the scope?
And were you able to revert back to a correct working system or did you end up like eljot and me with a reversed touch system.
You can probably use an arduino (make sure to not use 5V on the touch panel) to write a reversed configuration like ser8989 suggested to your panel and load your scope with the old firmware and it should work as before.It will be fun to try. But where can I get an Arduino sketch?
When you have a STM32F103C8T6 bluepill board I can write code for that.
That is an option. I can write and test it anyway. Not yet with the scope itself since my CH341 programmer is not doing what it is supposed to do >:(I bought it at a local online store (https://arduino.ua/prod3022-plata-razrabotchika-cs32f103c8t6-arm-stm32-minimalnaya-konfigyraciya). I'll get it the day after tomorrow. st-link v2 I already have
It is a board like this: https://nl.aliexpress.com/item/4000212446459.html?spm=a2g0o.productlist.0.0.41ef66deCPLsO4&algo_pvid=224a892b-2adc-436f-95c0-8ae21bd6135d&algo_expid=224a892b-2adc-436f-95c0-8ae21bd6135d-0&btsid=0b0a050116182243223341827e38d4&ws_ab_test=searchweb0_0,searchweb201602_,searchweb201603_
And you would need a st-link v2 like this for programming: https://nl.aliexpress.com/item/1005001621626894.html?spm=a2g0o.productlist.0.0.39f67ebbr0exNU&algo_pvid=5d37c412-5aae-4291-9d5f-94f414132190&algo_expid=5d37c412-5aae-4291-9d5f-94f414132190-4&btsid=0b0a050116182244556433490e38d4&ws_ab_test=searchweb0_0,searchweb201602_,searchweb201603_
Just search for the best deal you can find. Prices went up quite a bit since last year |O
The board you ordered has the CS chip on it. Not a problem, but for programming an other chip ID needs to be used. I use openocd under linux for the programming. Will add the correct config for the CS chip too.This one will be ok? https://www.rcscomponents.kiev.ua/product/stm32f103c8t6-modul-dlya-maketirovaniya_72591.html (https://www.rcscomponents.kiev.ua/product/stm32f103c8t6-modul-dlya-maketirovaniya_72591.html)
I'm looking into thirtythreeforty his work for the console to usb, but he only did it for the linux part. He did not remove the bindings to uart0 in u-boot and linux, so it looks like his version still boots on uart0 and for the linux part maybe using both as communication path. His version of u-boot is newer than what we are using now and looks like stuff has moved to other locations, so would have to find the correct files to edit. I will stick to the older version for now.
I did find settings for u-boot to make it use usb as console interface, but not sure if it will work. So will test this first.
undefined4 FUN_8001794c(void) //This is the function that sets up the configuration for the touch panel??
{
char *pcVar1;
undefined4 uVar2;
byte bVar3;
uint uVar4;
undefined4 in_r3;
int iVar5;
undefined4 local_10;
uVar2 = DAT_80017ab4; //DAT_80017ab4 = 0x01C20800 (config register of port A)
local_10 = in_r3;
FUN_8001764c(DAT_80017ab4,3,1,0); //Maybe generation of start condition and sending slave address in next part
FUN_8001764c(uVar2,2,1,0);
FUN_8001774c(uVar2,3);
FUN_8001774c(uVar2,2);
FUN_8001764c(uVar2,0,1);
FUN_8001764c(uVar2,1,1,0);
FUN_80017738(uVar2,0);
FUN_80017738(uVar2,1);
FUN_8000bc34(100);
FUN_8001774c(uVar2,1);
FUN_8000bc34(DAT_80017ab8);
FUN_8001774c(uVar2,0);
FUN_8000bc34(DAT_80017abc);
FUN_8001764c(uVar2,1,0);
FUN_8000bc34(DAT_80017ac0);
uVar2 = DAT_80017ac4;
local_10._0_1_ = 2;
FUN_80017d2c(DAT_80017ac4,&local_10,1);
bVar3 = 0;
uVar4 = 0;
do {
pcVar1 = (char *)(DAT_80017ac8 + uVar4); //There is a buffer at 0x8019CF82 in RAM where it calculates the checksum for the config of the touch panel
iVar5 = DAT_80017ac8 + uVar4;
uVar4 = uVar4 + 2 & 0xfffeffff;
bVar3 = *(char *)(iVar5 + 1) + bVar3 + *pcVar1;
} while (uVar4 < 0xb8);
*(byte *)(DAT_80017ac8 + 0xb8) = ~bVar3 + 1;
FUN_80017d2c(DAT_80017acc,DAT_80017ac8,0xba); //Function to write data to I2C bus?? (DAT_80017acc = 0x8047, DAT_80017ac8 = 0x8019CF82, 186 bytes)
FUN_8000bc34(DAT_80017ad0);
local_10 = (uint)local_10._1_3_ << 8;
FUN_80017d2c(uVar2,&local_10,1);
return 0;
}
How did any of you out there who flashed the scope did it? (eljot, dmitrkov)1. I desolder w25q32 from the board
Well done :)I couldn't find it.
So you found where the function is called from. In the Ghidra analysis it did not show any reference to the function I found, but my mod showed it is being called.
Did you find where the ram buffer is being filled with the configuration bytes?
Can you open up your scope and do measurements with the other in the analog part to see if the signal is there?Thank you
Look at the schematics here: https://github.com/pecostm32/FNIRSI-1013D-Hack/tree/main/Schematics
It is for the new version of the scope, but the analog did not change that much I think.
In the pictures folder in the repository there is also a good picture of the old scope pcb. You can figure out where to measure based on this information.
If it's cause is in the analog part you should see it with your other scope on the output of the opamp. Also check the 2.5V power rail of the opamp and the VRF1 voltage.
The faulty scope says it is 20Vpp but when it is introduced in the opamp section it will be much smaller.
Turning on the oscilloscope on a modified firmware several times in a row, I caught a working (reversible) touchscreen on one of the inclusions. But the next time it was turned on, it did not work again. This happened 2 times at random.Попробуйте мой патч, он немного другой.
S
0x28 A 0x80 A 0x40 A 0x02 A P
//Config used to be send here
S
0x28 A 0x80 A 0x40 A 0x00 A P
S
0x28 A 0x81 A 0x4E A S
0x29 A 0x80 N P
S
0x28 A 0x81 A 0x4E A 0x00 A P
S
0x28 A 0x81 A 0x4E A S
0x29 A 0x00 N P
S
0x28 A 0x81 A 0x4E A S
0x29 A 0x00 N P
S
0x28 A 0x81 A 0x4E A S
0x29 A 0x00 N P
undefined4 FUN_8001794c(void) //This is the function that sets up the configuration for the touch panel
{
char *pcVar1;
undefined4 uVar2;
byte bVar3;
uint uVar4;
undefined4 in_r3;
int iVar5;
undefined4 local_10;
uVar2 = DAT_80017ab4; //0x01C20800. Base register address for Port A
local_10 = in_r3;
FUN_8001764c(DAT_80017ab4,3,1,0); //Setup SCL (PA3) as output
FUN_8001764c(uVar2,2,1,0); //Setup SDA (PA2) as output
FUN_8001774c(uVar2,3); //Set SCL high
FUN_8001774c(uVar2,2); //Set SDA high
FUN_8001764c(uVar2,0,1); //Setup RESET (PA0) as output. Start of slave address init of touch panel
FUN_8001764c(uVar2,1,1,0); //Setup INT (PA1) as output
FUN_80017738(uVar2,0); //Set RESET low
FUN_80017738(uVar2,1); //Set INT low
FUN_8000bc34(100); //Delay function. 100
FUN_8001774c(uVar2,1); //Set INT high. Sequence for selecting 0x14 as slave address (0x28/0x29, write/read bytes)
FUN_8000bc34(DAT_80017ab8); //Delay again. 20000 (Should be 100uS)
FUN_8001774c(uVar2,0); //Set RESET high
FUN_8000bc34(DAT_80017abc); //Delay again. 10000
FUN_8001764c(uVar2,1,0); //Set INT as input
FUN_8000bc34(DAT_80017ac0); //Wait again. 100000
uVar2 = DAT_80017ac4; //0x00008040
local_10._0_1_ = 2;
FUN_80017d2c(DAT_80017ac4,&local_10,1); //Write 0x02 to register address 0x8040. Touch Panel command (read diff data or raw data)
bVar3 = 0;
uVar4 = 0;
do
{
pcVar1 = (char *)(DAT_80017ac8 + uVar4); //There is a buffer at 0x8019CF82 in RAM where it calculates the checksum for the config of the touch panel
iVar5 = DAT_80017ac8 + uVar4;
uVar4 = uVar4 + 2 & 0xfffeffff;
bVar3 = *(char *)(iVar5 + 1) + bVar3 + *pcVar1;
} while (uVar4 < 0xb8);
*(byte *)(DAT_80017ac8 + 0xb8) = ~bVar3 + 1;
//This is the function I nopped out with mov r0,r0
FUN_80017d2c(DAT_80017acc,DAT_80017ac8,0xba); //Write the configuration data the the touch panel starting from register address 0x8047
FUN_8000bc34(DAT_80017ad0); //Wait again. 200000
local_10 = (uint)local_10._1_3_ << 8;
FUN_80017d2c(uVar2,&local_10,1); //Write 0x00 to register address 0x8040. Touch Panel command (read coordinate status)
return 0;
}
I made a new version.In this version, the touchscreen works! :-+ :clap: (while still reversible)
//Read something from the FPGA
uint FUN_80016850(void)
{
int iVar1;
FUN_800167a0(); //Setup port E pins 0:7 for input
iVar1 = DAT_8001689c; //0x01C20890. Port E config register base
FUN_80017738(DAT_8001689c,9); //Set pin PE09 low
FUN_80017738(iVar1,10); //Set pin PE10 low
FUN_80017738(iVar1,8); //Set pin PE08 low
FUN_8001774c(iVar1,8); //Set pin PE08 high
return *(uint *)(iVar1 + 0x10) & 0xff; //Read a byte from the FPGA (port E data register holds twelve bits)
}
//Set port E pins 0:7 as input
void FUN_800167a0(void)
{
uint *puVar1;
puVar1 = DAT_8001684c; //0x01C20890. Port E configuration register (FPGA)
FUN_8001764c(DAT_8001684c,0,0); //Set pin PE0 as input
FUN_8001764c(puVar1,1,0); //Set pin PE1 as input
FUN_8001764c(puVar1,2,0); //Set pin PE2 as input
FUN_8001764c(puVar1,3,0); //Set pin PE3 as input
FUN_8001764c(puVar1,4,0); //Set pin PE4 as input
FUN_8001764c(puVar1,5,0); //Set pin PE5 as input
FUN_8001764c(puVar1,6,0); //Set pin PE6 as input
FUN_8001764c(puVar1,7,0); //Set pin PE7 as input
return;
}
In the repository is a .elf file that holds the code including debug information. I will take a look at making a .hex or .bin for you.Thank You! Can You make reader.hex file to?
Attached is a .hex file. Try if that works for you.
After the bluepill has been programmed it can be connected via the usb port to your computer and you should be able to open it as a serial port like a ch340. The baudrate settings don't matter and do nothing since it is just data over usb.
I'm out of ideas. |O I tried it on two different boards with cs and no cs. On two different PCs with Windows 10 and Windows 7. I tried different programs for monitoring the com port. In which port nothing is displayed. In this case, bring the simplest sketch on arduino to the com port normally ... :-// It remains only to install Linux.....
#define Pn_BASE(n) (0x01C20800 + (n * 0x24))
#define Pn_CFG0(n) ((volatile uint32_t *) (Pn_BASE(n) + 0x00))
#define Pn_DATA(n) ((volatile uint32_t *) (Pn_BASE(n) + 0x10))
#define SET_PIN(n, x) (*Pn_DATA(n) |= (1 << y))
#define CLR_PIN(n, x) (*Pn_DATA(n) &= ~(1 << y))
#define FPGA_SET_DATA(x) (*Pn_DATA(4) = (*Pn_DATA(4) & ~0xFF) | (x & 0xFF))
void fpga_set_input(void) {
*((volatile uint32_t *) Pn_CFG0()) = 0x00000000;
}
void fpga_set_output(void) {
*((volatile uint32_t *) Pn_CFG0()) = 0x11111111;
}
void fpga_write_cmd(uint8_t data) {
SET_PIN(PE_DATA, 9);
SET_PIN(PE_DATA, 10);
FPGA_SET_DATA(data);
CLR_PIN(PE_DATA, 8);
SET_PIN(PE_DATA, 8);
}
void fpga_write_data(uint8_t data) {
SET_PIN(PE_DATA, 9);
CLR_PIN(PE_DATA, 10);
FPGA_SET_DATA(data);
CLR_PIN(PE_DATA, 8);
SET_PIN(PE_DATA, 8);
}
void set_backlight(uint8_t level) {
fpga_set_output();
fpga_write_data_2(0x38);
fpga_write_data(0xEA);
fpga_write_data(level);
}
Did you try the reader.hex, to see if that gives output like I saw on windows 7?I tried it. It also does not output anything to the com port. What connection speed of the com port should be set?
//PE0:7 Databus
//PE08 Clock
//PE09 read/write 0 = read, 1 = write
//PE10 data/command 0 = data, 1 = command
Did you try the reader.hex, to see if that gives output like I saw on windows 7?I tried it. It also does not output anything to the com port. What connection speed of the com port should be set?
I've updated the code. It's not the best thing I've ever wrote, but it's not that bad either :)
Turns out, to make them outputs you had to write 0001001001001001001001001, setting them to all 1s will disable them.
I've updated the code. It's not the best thing I've ever wrote, but it's not that bad either :)
Turns out, to make them outputs you had to write 0001001001001001001001001, setting them to all 1s will disable them.
Totally correct, that is why I wrote the hexadecimal form of it. (0x11111111) :-DD
I could not flash the touchscreen with the bluepill. I connected it to the touchscreen, there is no result - the touchscreen works in reverse. I fleshed it with the arduino (sketch from ser8989). The touchscreen now works correctly! Many thanks to ser8989 and pcprogrammer for the work done! :-+
That is true. I did not read it right because I thought he had 3 zero's per 1 in there. And according to the manual it needs to be so. Bit 3 is reserved, so it is 4 bits per pin.
Update for the possible brightness. The actual brightness is most likely a second byte written after the 0xEA. This is the sequence I found with Ghidra.
FUN_800169F8 is write command to fpga
FUN_800168FC is write data to fpga
The command 0x38 is used twice in the code, so either they set the brightness on two locations or it is not what we think it is.
Question:
I still, did not find where the initialization functions are being called. Found the initialization function (FUN_800168A0) for communication with the FPGA, but there is no XREF for it like for other function.
The XREF in the attached image is for the local_8 variable.
This is the same for the I2C init function for the touch panel.
So if anyone knows where these initialization functions are called please let me know.
Maybe I'm using Ghidra with incorrect settings or it is not as good as the program tv84 is using. But it explains why I could not find the calls to the init functions. Ghidra does not find code at that address.
Edit: The command 0x38 with data 0xEA 0x60 I found is in yet another section of the code, where it handles other errors the system might encounter. (FUN_8001c138) Apparently it can detect failure of "AD9288_1_2"
int Check_HW()
{
int result; // r0@1
int v1; // r0@2
int v2; // r0@2
int v3; // r0@2
int v4; // r0@2
int v5; // r0@2
int v6; // r0@2
int v7; // r0@2
int v8; // r0@2
int v9; // r0@2
int v10; // r1@2
int v11; // r0@2
int v12; // r4@2
signed int v13; // r0@8
int v14; // r0@13
int v15; // r4@14
const char *v16; // r0@15
int v17; // r0@24
int v18; // r0@24
int v19; // r0@24
int v20; // r0@24
result = sub_8002330C();
if ( result != 2 )
{
v1 = sub_80027D88();
v2 = sub_8000690C(v1);
v3 = sub_80009658(v2);
v4 = sub_80001314(v3);
v5 = sub_8000689C(v4);
v6 = sub_800095E8(v5);
v7 = sub_800068D4(v6);
sub_80009620(v7);
sub_80012A4C();
v8 = sub_800267E8();
sub_80002790(v8);
sub_80026808();
sub_800267C4();
v9 = sub_80026828();
v11 = sub_8000696C(v9, v10);
sub_800096B8(v11);
FPGA_write_cmd(0x38u);
FPGA_write_data(0xEAu);
FPGA_write_data(0x60u);
sub_80017778();
sub_80019704(0);
sub_80018F6C(0);
sub_80019730(off_8018B738);
sub_800197C8(0);
FPGA_write_cmd(6u);
v12 = (FPGA_read_data() << 8) & 0xFF00; // Check_FPGA
if ( (FPGA_read_data() | v12) != 0x1432 )
{
sub_80019704(0xFF0000);
print_msg((int)"FPGA", 30, 90);
print_msg((int)"Failed", 100, 90);
while ( 1 )
;
}
sub_80019704(0xFFFFFF);
print_msg((int)"FPGA", 30, 90);
print_msg((int)"OK", 100, 90);
sub_80017CE0();
if ( Check_Encrypt() != 0x8150 )
{
sub_80019704(0xFF0000);
print_msg((int)"Encrypt", 30, 110);
print_msg((int)"Failed", 100, 110);
while ( 1 )
;
}
sub_80019704(0xFFFFFF);
print_msg((int)"Encrypt", 30, 110);
print_msg((int)"OK", 100, 110);
v13 = Check_AD9288();
if ( v13 != 3 )
{
if ( v13 != 1 )
{
if ( v13 != 2 )
{
sub_80019704(0xFF0000);
print_msg((int)"AD9288_1_2", 30, 130);
print_msg((int)"Failed", 120, 130);
while ( 1 )
;
}
sub_80019704(0xFF0000);
print_msg((int)"AD9288_1", 30, 130);
print_msg((int)"Failed", 120, 130);
while ( 1 )
;
}
sub_80019704(0xFF0000);
print_msg((int)"AD9288_2", 30, 130);
print_msg((int)"Failed", 120, 130);
while ( 1 )
;
}
sub_80019704(0xFFFFFF);
print_msg((int)"AD9288", 30, 130);
v14 = print_msg((int)"OK", 100, 130);
if ( !Check_Analog(v14) )
{
sub_80019704(0xFF0000);
print_msg((int)"Analog", 30, 150);
print_msg((int)"Failed", 100, 150);
while ( 1 )
;
}
sub_80019704(0xFFFFFF);
print_msg((int)"Analog", 30, 150);
print_msg((int)"OK", 100, 150);
sub_80019704(0xFFFFFF);
print_msg((int)"Touch", 30, 170);
print_msg((int)"...", 103, 167);
v15 = Check_Touch();
if ( v15 )
{
sub_80019704(0xFFFFFF);
v16 = "OK ";
}
else
{
sub_80019704(0xFF0000);
v16 = "Failed";
}
result = print_msg((int)v16, 100, 170);
if ( v15 )
{
sub_80019704(0xFFFFFF);
print_msg((int)"Hard Checked Successful !", 30, 190);
v8019D5A3 = 0;
v8019D5A6 = 300;
v8019D5AF = 0;
v8019D5B2 = 100;
v8019D5AA = 19;
v17 = sub_8000696C(0x8019D5A0, 0);
v18 = sub_800096B8(v17);
v19 = sub_8000689C(v18);
sub_800095E8(v19);
v20 = sub_800266C4();
sub_80025BB0(v20);
result = sub_8000BC00(500);
}
}
return result;
}Hmm very strange. Do you have the problem on both channels?Unfortunatelly, nothing weird: Supply ok, no ripp^le (at least nothing visible on my old 20Mhz scope), voltage on above pin looks ok too, I mean, stable
Check the following signals on the ADC's to see what is there. Should be stable DC levels. REFOUT (pin 6), AINA = AINB (pin 3 and 10).
Also check if there is distortion on the 3.3V supply, since the ADC's are powered with it. And take a look at the ADC1_OFFSET and ADC2_OFFSET signals coming from the FPGA.
no difference when probing the signal on the other scope, or not ...
I was also suspecting a bad component starrting leaking or something
Even though about external electromagnetic perturbation (led lamp, computer , ...), but no change after having powered off eveything or changing place
Regarding screen, I have noticed that it start flipping when I try to reduce screen brightness when phenomenum occur, after a ~1 minutes.
The strange but noticeable thing is that this parasite appears on both channel even unplugged.
I'll check the LCD back light...
#include "fpga_control.h"
int main(void)
{
fpga_init();
fpga_write_cmd(0x38);
fpga_write_short(0xEA60);
while(1);
}
I looked at the assembly of the code I wrote and it looks similar to what is in the scope. No delays in there.
//Commands to interface with the I2C chip connected to the FPGA
//0x64 Prepare bus for reading. Send twice in a row.
//0x65 Prepare bus for writing. Send twice in a row.
//0x66 Start the communication.
//0x67 Read the status flag. Bit 0 needs to become 1. Needs to be preceded by 0x66
//0x68 Not clear about this one. Is read from a memory address and Ghidra sees it as 0x09.
//0x69 Parameter id and byte count. iiiiiicc. 6 bits id and 2 bits count.
//0x6A Checksum. sum of the other 6 bytes
//0x6B Value byte 3 MSB. 0x69 when not used.
//0x6C Value byte 2. 0x96 when not used.
//0x6D Value byte 1. 0x99 when not used.
//0x6E Value byte 0 LSB.
void FUN_80024b14(void)
{
byte *pbVar1;
uint uVar2;
byte bVar3;
pbVar1 = DAT_80024c78; //0x8035EC04. Buffer in DRAM
uVar2 = 1;
bVar3 = ~*DAT_80024c78; //Byte received from command 68 inverted
*DAT_80024c78 = ~*DAT_80024c78; //Keep it in the same spot for later
do
{
if ((bVar3 & 0x80) != 0) //When bit 7 of the byte from command 0x68 is set
{
pbVar1[uVar2] = ~pbVar1[uVar2] & 0x80 | pbVar1[uVar2] & 0x7f; //Invert bit 7 and or it back in with the rest of the bits
}
if ((bVar3 & 0x40) != 0) //When bit 6 of the byte from command 0x68 is set
{
pbVar1[uVar2] = ~pbVar1[uVar2] & 0x40 | pbVar1[uVar2] & 0xbf; //Invert bit 6 and or it back in with the rest of the bits
}
if ((bVar3 & 0x20) != 0) //When bit 5 of the byte from command 0x68 is set
{
pbVar1[uVar2] = ~pbVar1[uVar2] & 0x20 | pbVar1[uVar2] & 0xdf; //Invert bit 5 and or it back in with the rest of the bits
}
if ((bVar3 & 0x10) != 0) //When bit 4 of the byte from command 0x68 is set
{
pbVar1[uVar2] = ~pbVar1[uVar2] & 0x10 | pbVar1[uVar2] & 0xef; //Invert bit 4 and or it back in with the rest of the bits
}
if ((bVar3 & 8) != 0) //When bit 3 of the byte from command 0x68 is set
{
pbVar1[uVar2] = ~pbVar1[uVar2] & 8 | pbVar1[uVar2] & 0xf7; //Invert bit 3 and or it back in with the rest of the bits
}
if ((bVar3 & 4) != 0) //When bit 2 of the byte from command 0x68 is set
{
pbVar1[uVar2] = ~pbVar1[uVar2] & 4 | pbVar1[uVar2] & 0xfb; //Invert bit 2 and or it back in with the rest of the bits
}
if ((bVar3 & 2) != 0) //When bit 1 of the byte from command 0x68 is set
{
pbVar1[uVar2] = ~pbVar1[uVar2] & 2 | pbVar1[uVar2] & 0xfd; //Invert bit 1 and or it back in with the rest of the bits
}
if ((bVar3 & 1) != 0) //When bit 0 of the byte from command 0x68 is set
{
pbVar1[uVar2] = ~pbVar1[uVar2] & 1 | pbVar1[uVar2] & 0xfe; //Invert bit 0 and or it back in with the rest of the bits
}
uVar2 = uVar2 + 1 & 0xff;
} while (uVar2 < 7); //Process each of the received bytes except the first
return;
}
void fpga_delay(void)
{
int i,j;
//The FPGA has a loading time of ~900mS
//Delay for allowing the FPGA to be up and running
for(i=0,j=0;i<50000;i++)
{
j += 2;
}
if(j>1000)
i=0;
}
void fpga_delay(void)
{
int i,j,n;
//The FPGA has a loading time of ~900mS
//Delay for allowing the FPGA to be up and running
for(i=0,j=0,n=0;i<2000000;i++)
{
j += 2;
n = (j * 3) + i;
}
if((j>1000) && (n>1000))
i=0;
}
And, we've got image!
(https://i.postimg.cc/Lsdrzmb5/photo-2021-04-11-17-52-43.jpg)
Nice, but without the fpga interface it is just a small linux computer
You say that as if a portable Linux computer with screen for 65 Euros is a bad thing. :-//Ok, I got mine for 25 euros due to refund, but if I was on a salary, by the time it is fixed it would be way more expensive. But where did you find it for 65 euros? Cheapest I have seen them was 100 euro on Aliexpress and that was when it was on special sale. Now it is >110 euros.
The next question should be "Does it run MAME"?
where did you find it for 65 euros? Cheapest I have seen them was 100 euro on Aliexpress and that was when it was on special sale. Now it is >110 euros.
where did you find it for 65 euros? Cheapest I have seen them was 100 euro on Aliexpress and that was when it was on special sale. Now it is >110 euros.
My bad, I searched for it and it showed some of those Aliexpress "fake price" results. 65 Euros is the nasty yellow one.
100 Euros still isn't a terrible price for ARM computer+screen+case+battery.
Read the config from your touch panel and make modifications for reversing only the x coordinates, and write them back. (Either the x2x bit or the order of the sensor assignments)
Really enjoying following your progress. Thanks for your efforts. Will those of us on the older/bulkier version of the scope with a W25Q16 need to make any changes before being able to use some of your work?
Nice to hear my work is appreciated. :)
int8_t config_data[0x1f4] =
{
0x01, 0x00, 0x06, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00, 0x01, 0x00, 0x06, 0x00, 0x00, 0x00,
0x00, 0x00, 0x01, 0x00, 0x0D, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00, 0x01, 0x00, 0x01, 0x00,
0x0F, 0x00, 0x00, 0x00, 0x01, 0x00, 0x01, 0x00, 0x03, 0x00, 0xD3, 0x02, 0x00, 0x00, 0x00, 0x00,
0x90, 0x01, 0x90, 0x01, 0x18, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x63, 0x01, 0x5F, 0x00, 0x2C, 0x01, 0x5F, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x3D, 0x00, 0x38, 0x00, 0x01, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00, 0x01, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x01, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0xDC, 0x00, 0x4D, 0x05, 0x45, 0x05, 0x54, 0x05, 0x4D, 0x05, 0x53, 0x05, 0x4C, 0x05, 0xD9, 0x00,
0x5B, 0x05, 0x56, 0x05, 0x61, 0x05, 0x5B, 0x05, 0x60, 0x05, 0x5A, 0x05, 0x00, 0x00, 0x03, 0x00,
0x01, 0x00, 0x07, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x01, 0x00, 0x02, 0x01, 0x3A, 0x02, 0x00, 0x00, 0x5A, 0x00, 0xC1, 0x00, 0x05, 0x00,
0x04, 0x00, 0x07, 0x00, 0x11, 0x00, 0x13, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x32, 0x14, 0x0F, 0x00, 0x00, 0x00, 0x05, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00
};
flash: 0x001BA610 | packet 716: 0x12, 0xFF 0x8019CF82: 0xFF, 0x00,
flash: 0x001BA612 | packet 717: 0x16, 0x04, 0x58, 0x02, 0x0A, 0xFD 0x8019CF84: 0x04, 0x58, 0x02, 0x0A, 0xFD, 0x00,
flash: 0x001BA618 | packet 718: 0x70, 0x09, 0x01, 0x08, 0x28, 0x08, 0x5A, 0x3C, 0x03, 0x05 0x8019CF8A: 0x01, 0x08, 0x28, 0x08, 0x5A, 0x3C, 0x03, 0x05, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
flash: 0x001BA622 | packet 719: 0x30, 0x0C, 0x18, 0x1A, 0x1E, 0x14, 0x87, 0x29, 0x0A, 0x75, 0x77, 0xB2, 0x04 0x8019CF99: 0x18, 0x1A, 0x1E, 0x14, 0x87, 0x29, 0x0A, 0x75, 0x77, 0xB2, 0x04, 0x00, 0x00, 0x00,
flash: 0x001BA62F | packet 720: 0x14, 0x9A, 0x01, 0x11 0x8019CFA7: 0x9A, 0x01, 0x11, 0x00,
flash: 0x001BA633 | packet 721: 0x92, 0x01 0x8019CFAB: 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
flash: 0x001BA635 | packet 722: 0x27, 0x50, 0xA0, 0x94, 0xD5, 0x02, 0x08 0x8019CFB5: 0x50, 0xA0, 0x94, 0xD5, 0x02, 0x08, 0x00, 0x00,
flash: 0x001BA63C | packet 723: 0x14, 0x04, 0xA1, 0x55 0x8019CFBD: 0x04, 0xA1, 0x55, 0x00,
flash: 0x001BA640 | packet 724: 0x13, 0x8F, 0x62 0x8019CFC1: 0x8F, 0x62, 0x00,
flash: 0x001BA643 | packet 725: 0x13, 0x7F, 0x71 0x8019CFC4: 0x7F, 0x71, 0x00,
flash: 0x001BA646 | packet 726: 0x13, 0x73, 0x82 0x8019CFC7: 0x73, 0x82, 0x00,
flash: 0x001BA649 | packet 727: 0x13, 0x69, 0x95 0x8019CFCA: 0x69, 0x95, 0x00,
flash: 0x001BA64C | packet 728: 0x02, 0x24, 0x69 0x8019CFCD: 0x69, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
flash: 0x001BA64F | packet 729: 0x18, 0x0C, 0x02, 0x04, 0x06, 0x08, 0x0A, 0x0C, 0x0E, 0x10, 0x12, 0x14, 0xFF, 0x01 0x8019CFF2: 0x02, 0x04, 0x06, 0x08, 0x0A, 0x0C, 0x0E, 0x10, 0x12, 0x14, 0xFF, 0xFF, 0xFF, 0xFF,
flash: 0x001BA65D | packet 730: 0x01, 0x11 0x8019D000: 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
flash: 0x001BA65F | packet 731: 0x28, 0x10, 0x02, 0x04, 0x06, 0x08, 0x0A, 0x0C, 0x1D, 0x1E, 0x1F, 0x20, 0x21, 0x22, 0x24, 0x26, 0x28, 0x24 0x8019D011: 0x02, 0x04, 0x06, 0x08, 0x0A, 0x0C, 0x1D, 0x1E, 0x1F, 0x20, 0x21, 0x22, 0x24, 0x26, 0x28, 0xFF, 0xFF, 0xFF, 0xFF,
flash: 0x001BA671 | packet 732: 0x49, 0x01 0x8019D024: 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
flash: 0x001BA673 | packet 733: 0x01, 0x11 0x8019D02A: 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
flash: 0x001BA675 | packet 734: 0x89, 0x90 0x8019D03B: 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
rsb r0,r0,r0, lsl #0x4
mov r5,r0, lsl #0x3
void main(void)
{
int iVar1;
undefined auStack568 [568];
sys_clock_init();
some_memory_stuff();
sys_init_uart0(BAUD_115200);
setup_timer_int();
sys_spi0_init();
fpga_init();
turn_off_brightness();
sys_init_display();
setup_display_lib();
tp_i2c_setup();
Your emulator work is interesting and impressive :-+
I would never have tried to write one, it would have seemed too complicated a task (which it is, for me).
typedef struct tagARMV5TL_REGS ARMV5TL_REGS;
typedef struct tagARMV5TL_TRACE_ENTRY ARMV5TL_TRACE_ENTRY;
struct tagARMV5TL_REGS
{
u_int32_t r0;
u_int32_t r1;
u_int32_t r2;
u_int32_t r3;
u_int32_t r4;
u_int32_t r5;
u_int32_t r6;
u_int32_t r7;
u_int32_t r8[2];
u_int32_t r9[2];
u_int32_t r10[2];
u_int32_t r11[2];
u_int32_t r12[2];
u_int32_t r13[6];
u_int32_t r14[6];
u_int32_t r15;
u_int32_t cpsr;
u_int32_t spsr[5];
};
struct tagARMV5TL_TRACE_ENTRY
{
u_int32_t instruction_address; //Address of the traced instruction
u_int32_t instruction_word; //Instruction word for arm, half word for thumb
u_int32_t execution_status; //Information about if the arm instruction has been executed or not
ARMV5TL_REGS registers; //The 37 registers
u_int32_t memory_address; //Depending on the type of instruction this is set with the targeted memory address
u_int32_t memory_direction; //For load or store multiple instructions this signals if the given address is incremented or decremented
u_int32_t data_width; //For instructions that load or store half words or bytes this will reflect this, otherwise word width
u_int32_t data_count; //The number of words read or written by the instruction
u_int32_t data[16]; //The data read or written. Single instruction can do a max of 16 words
};
This means I have to implement a better tracing system. Already have some ideas about this. It will need an other program to read the trace data. The idea is to gather data for each instruction and write it in binary to a file. Already made a structure for it and support in the core code to allow for a circular buffer to be filled with trace data. Next up is add code to the instructions that load or store to or from memory.
:palm: Respect for your work! Would love to see your working methods. :clap:
0x8002FAA8 0xE92D4070 YES stmdb sp!, { r4 r5 r6 lr } r0:0x80857D4C r1:0x8019D464 r2:0x8019D45C r3:0x00000320 r4:0x00000000 r5:0x00000000 r6:0x00000000 r7:0x80192E6B r8_usr:0x80000E48 r9_usr:0x81000000 r10_usr:0x80192E9C r11_usr:0x80192E9C r12_usr:0xFFFFFFFF r13_svc:0x81FF3598 r14_svc:0x8001933C r15:0x8002FAA8 cpsr:0x80000053 memory:0x81FF35A4 type:word count: 4 dir:down 0x8001933C 0x00000000 0x00000000 0x00000000
0x8002FAAC 0xE59F509C YES ldr r5, [pc, #156] r0:0x80857D4C r1:0x8019D464 r2:0x8019D45C r3:0x00000320 r4:0x00000000 r5:0x8019D464 r6:0x00000000 r7:0x80192E6B r8_usr:0x80000E48 r9_usr:0x81000000 r10_usr:0x80192E9C r11_usr:0x80192E9C r12_usr:0xFFFFFFFF r13_svc:0x81FF3598 r14_svc:0x8001933C r15:0x8002FAAC cpsr:0x80000053 memory:0x8002FB50 type:word count: 1 dir:up 0x8019D464
0x8002FAB0 0xE1A04000 YES mov r4, r0 r0:0x80857D4C r1:0x8019D464 r2:0x8019D45C r3:0x00000320 r4:0x80857D4C r5:0x8019D464 r6:0x00000000 r7:0x80192E6B r8_usr:0x80000E48 r9_usr:0x81000000 r10_usr:0x80192E9C r11_usr:0x80192E9C r12_usr:0xFFFFFFFF r13_svc:0x81FF3598 r14_svc:0x8001933C r15:0x8002FAB0 cpsr:0x80000053
0x8002FAB4 0xE595000C YES ldr r0, [r5, #12] r0:0x80857D4C r1:0x8019D464 r2:0x8019D45C r3:0x00000320 r4:0x80857D4C r5:0x8019D464 r6:0x00000000 r7:0x80192E6B r8_usr:0x80000E48 r9_usr:0x81000000 r10_usr:0x80192E9C r11_usr:0x80192E9C r12_usr:0xFFFFFFFF r13_svc:0x81FF3598 r14_svc:0x8001933C r15:0x8002FAB4 cpsr:0x80000053 memory:0x8019D470 type:word count: 1 dir:up 0x80857D4C
0x8002FAB8 0xE28FE030 YES add lr, pc, #48 r0:0x80857D4C r1:0x8019D464 r2:0x8019D45C r3:0x00000320 r4:0x80857D4C r5:0x8019D464 r6:0x00000000 r7:0x80192E6B r8_usr:0x80000E48 r9_usr:0x81000000 r10_usr:0x80192E9C r11_usr:0x80192E9C r12_usr:0xFFFFFFFF r13_svc:0x81FF3598 r14_svc:0x8002FAF0 r15:0x8002FAB8 cpsr:0x80000053
0x8002FABC 0xE2801004 YES add r1, r0, #4 r0:0x80857D4C r1:0x80857D50 r2:0x8019D45C r3:0x00000320 r4:0x80857D4C r5:0x8019D464 r6:0x00000000 r7:0x80192E6B r8_usr:0x80000E48 r9_usr:0x81000000 r10_usr:0x80192E9C r11_usr:0x80192E9C r12_usr:0xFFFFFFFF r13_svc:0x81FF3598 r14_svc:0x8002FAF0 r15:0x8002FABC cpsr:0x80000053
0x8002FAC0 0xE5800038 YES str r0, [r0, #56] r0:0x80857D4C r1:0x80857D50 r2:0x8019D45C r3:0x00000320 r4:0x80857D4C r5:0x8019D464 r6:0x00000000 r7:0x80192E6B r8_usr:0x80000E48 r9_usr:0x81000000 r10_usr:0x80192E9C r11_usr:0x80192E9C r12_usr:0xFFFFFFFF r13_svc:0x81FF3598 r14_svc:0x8002FAF0 r15:0x8002FAC0 cpsr:0x80000053 memory:0x80857D84 type:word count: 1 dir:up 0x80857D4C
0x8002FAC4 0xE580103C YES str r1, [r0, #60] r0:0x80857D4C r1:0x80857D50 r2:0x8019D45C r3:0x00000320 r4:0x80857D4C r5:0x8019D464 r6:0x00000000 r7:0x80192E6B r8_usr:0x80000E48 r9_usr:0x81000000 r10_usr:0x80192E9C r11_usr:0x80192E9C r12_usr:0xFFFFFFFF r13_svc:0x81FF3598 r14_svc:0x8002FAF0 r15:0x8002FAC4 cpsr:0x80000053 memory:0x80857D88 type:word count: 1 dir:up 0x80857D50
0x8002FAC8 0xE2801008 YES add r1, r0, #8 r0:0x80857D4C r1:0x80857D54 r2:0x8019D45C r3:0x00000320 r4:0x80857D4C r5:0x8019D464 r6:0x00000000 r7:0x80192E6B r8_usr:0x80000E48 r9_usr:0x81000000 r10_usr:0x80192E9C r11_usr:0x80192E9C r12_usr:0xFFFFFFFF r13_svc:0x81FF3598 r14_svc:0x8002FAF0 r15:0x8002FAC8 cpsr:0x80000053
0x8002FACC 0xE5800040 YES str r0, [r0, #64] r0:0x80857D4C r1:0x80857D54 r2:0x8019D45C r3:0x00000320 r4:0x80857D4C r5:0x8019D464 r6:0x00000000 r7:0x80192E6B r8_usr:0x80000E48 r9_usr:0x81000000 r10_usr:0x80192E9C r11_usr:0x80192E9C r12_usr:0xFFFFFFFF r13_svc:0x81FF3598 r14_svc:0x8002FAF0 r15:0x8002FACC cpsr:0x80000053 memory:0x80857D8C type:word count: 1 dir:up 0x80857D4C
0x8002FAD0 0xE5841014 YES str r1, [r4, #20] r0:0x80857D4C r1:0x80857D54 r2:0x8019D45C r3:0x00000320 r4:0x80857D4C r5:0x8019D464 r6:0x00000000 r7:0x80192E6B r8_usr:0x80000E48 r9_usr:0x81000000 r10_usr:0x80192E9C r11_usr:0x80192E9C r12_usr:0xFFFFFFFF r13_svc:0x81FF3598 r14_svc:0x8002FAF0 r15:0x8002FAD0 cpsr:0x80000053 memory:0x80857D60 type:word count: 1 dir:up 0x80857D54
0x8002FAD4 0xE5D01011 YES ldrb r1, [r0, #17] r0:0x80857D4C r1:0x00000000 r2:0x8019D45C r3:0x00000320 r4:0x80857D4C r5:0x8019D464 r6:0x00000000 r7:0x80192E6B r8_usr:0x80000E48 r9_usr:0x81000000 r10_usr:0x80192E9C r11_usr:0x80192E9C r12_usr:0xFFFFFFFF r13_svc:0x81FF3598 r14_svc:0x8002FAF0 r15:0x8002FAD4 cpsr:0x80000053 memory:0x80857D5D type:byte count: 1 dir:up 0x00000000
0x8002FAD8 0xE2850024 YES add r0, r5, #36 r0:0x8019D488 r1:0x00000000 r2:0x8019D45C r3:0x00000320 r4:0x80857D4C r5:0x8019D464 r6:0x00000000 r7:0x80192E6B r8_usr:0x80000E48 r9_usr:0x81000000 r10_usr:0x80192E9C r11_usr:0x80192E9C r12_usr:0xFFFFFFFF r13_svc:0x81FF3598 r14_svc:0x8002FAF0 r15:0x8002FAD8 cpsr:0x80000053
0x8002FADC 0xE7900101 YES ldr r0, [r0, r1, lsl #2] r0:0x00000000 r1:0x00000000 r2:0x8019D45C r3:0x00000320 r4:0x80857D4C r5:0x8019D464 r6:0x00000000 r7:0x80192E6B r8_usr:0x80000E48 r9_usr:0x81000000 r10_usr:0x80192E9C r11_usr:0x80192E9C r12_usr:0xFFFFFFFF r13_svc:0x81FF3598 r14_svc:0x8002FAF0 r15:0x8002FADC cpsr:0x80000053 memory:0x8019D488 type:word count: 1 dir:up 0x00000000
0x8002FAE0 0xE590100C YES ldr r1, [r0, #12] r0:0x00000000 r1:0x00000000 r2:0x8019D45C r3:0x00000320 r4:0x80857D4C r5:0x8019D464 r6:0x00000000 r7:0x80192E6B r8_usr:0x80000E48 r9_usr:0x81000000 r10_usr:0x80192E9C r11_usr:0x80192E9C r12_usr:0xFFFFFFFF r13_svc:0x81FF3598 r14_svc:0x8002FAF0 r15:0x8002FAE0 cpsr:0x80000053 memory:0x0000000C type:word count: 1 dir:up 0x00000000
0x8002FAE4 0xE5912030 YES ldr r2, [r1, #48] r0:0x00000000 r1:0x00000000 r2:0x00000000 r3:0x00000320 r4:0x80857D4C r5:0x8019D464 r6:0x00000000 r7:0x80192E6B r8_usr:0x80000E48 r9_usr:0x81000000 r10_usr:0x80192E9C r11_usr:0x80192E9C r12_usr:0xFFFFFFFF r13_svc:0x81FF3598 r14_svc:0x8002FAF0 r15:0x8002FAE4 cpsr:0x80000053 memory:0x00000030 type:word count: 1 dir:up 0x00000000
0x8002FAE8 0xE2841008 YES add r1, r4, #8 r0:0x00000000 r1:0x80857D54 r2:0x00000000 r3:0x00000320 r4:0x80857D4C r5:0x8019D464 r6:0x00000000 r7:0x80192E6B r8_usr:0x80000E48 r9_usr:0x81000000 r10_usr:0x80192E9C r11_usr:0x80192E9C r12_usr:0xFFFFFFFF r13_svc:0x81FF3598 r14_svc:0x8002FAF0 r15:0x8002FAE8 cpsr:0x80000053
0x8002FAEC 0xE12FFF12 YES bx r2 r0:0x00000000 r1:0x80857D54 r2:0x00000000 r3:0x00000320 r4:0x80857D4C r5:0x8019D464 r6:0x00000000 r7:0x80192E6B r8_usr:0x80000E48 r9_usr:0x81000000 r10_usr:0x80192E9C r11_usr:0x80192E9C r12_usr:0xFFFFFFFF r13_svc:0x81FF3598 r14_svc:0x8002FAF0 r15:0x00000000 cpsr:0x80000053
main XREF[1]: prepare_for_main:800001a8(c)
80035320 8e df 4d e2 sub sp,sp,#0x238
80035324 00 00 a0 e3 mov r0,#0x0
80035328 3e cb ff eb bl sys_clock_init void sys_clock_init(void)
8003532c 54 08 00 eb bl some_memory_stuff void some_memory_stuff(void)
80035330 20 01 9f e5 ldr r0,[BAUD_115200] = 0001C200h
80035334 58 cb ff eb bl sys_init_uart0 void sys_init_uart0(uint baudrate)
80035338 2a cb ff eb bl setup_timer_int void setup_timer_int(void)
8003533c 72 bf ff eb bl sys_spi0_init void sys_spi0_init(void)
80035340 56 85 ff eb bl fpga_init void fpga_init(void)
80035344 14 9d ff eb bl turn_off_brightness void turn_off_brightness(void)
80035348 a1 a0 ff eb bl sys_init_display void sys_init_display(void)
8003534c f2 8f ff eb bl setup_display_lib int setup_display_lib(void)
80035350 7d 89 ff eb bl tp_i2c_setup void tp_i2c_setup(void)
void setup_mmu(void)
{
uint baseaddress;
baseaddress = 0x80730000;
setup_mmu_trans_table(baseaddress,0x80000000,0,0,0,0,0x80000000,0,0);
setup_mmu_trans_table(baseaddress,0,0x80000000,0,0x80000000,0,0x80000000,0,0);
setup_mmu_trans_table(baseaddress,0x80000000,0x80000000,0,0x80000000,0,0x2000000,0,3);
mmu_set_base_address(baseaddress);
mmu_clear_wb_tlb();
mmu_set_domain_access(1);
mmu_enable();
mmu_instr_cache_enable();
mmu_data_cache_enable();
return;
}
void setup_mmu_trans_table(uint baseaddress,uint param_2,uint param_3,uint param_4,uint memaddress,uint param_6,uint param_7,uint param_8,uint cacheable)
{
uint uVar1;
uint uVar2;
uint uVar3;
uint uVar4;
bool bVar5;
uVar2 = param_3 >> 0x14 | param_4 << 0xc;
uVar3 = memaddress >> 0x14;
uVar4 = param_7 >> 0x14 | param_8 << 0xc;
uVar1 = param_8 >> 0x14;
while ((uVar1 | uVar4) != 0)
{
*(uint *)(baseaddress + uVar2 * 4) = uVar3 << 0x14 | 0xc10 | (cacheable & 3) << 2 | 2;
bVar5 = uVar4 == 0;
uVar4 = uVar4 - 1;
uVar1 = uVar1 - bVar5;
uVar2 = uVar2 + 1;
uVar3 = uVar3 + 1;
}
return;
}
void FUN_80030564(int *param_1,uint param_2)
{
byte bVar1;
ushort uVar2;
byte extraout_r1;
ushort extraout_r1_00;
int extraout_r1_01;
int extraout_r1_02;
uint extraout_r1_03;
uint extraout_r1_04;
uint uVar3;
uint uVar4;
int *piVar5;
int iVar6;
uVar3 = 0;
do {
uVar4 = 0;
piVar5 = param_1;
while (uVar4 < param_2 >> 2) {
divide(uVar4 + uVar3,0xff);
uVar4 = uVar4 + 1;
*piVar5 = extraout_r1_01;
piVar5 = piVar5 + 1;
}
uVar4 = 0;
piVar5 = param_1;
while (uVar4 < param_2 >> 2) {
iVar6 = *piVar5;
divide(uVar4 + uVar3,0xff);
if (extraout_r1_02 != iVar6) {
return;
}
uVar4 = uVar4 + 1;
piVar5 = piVar5 + 1;
}
uVar3 = uVar3 + 1;
} while (uVar3 < 2);
uVar3 = 0;
do {
uVar4 = 0;
piVar5 = param_1;
while (uVar4 < param_2 >> 1) {
divide(uVar4 + uVar3,0xff);
uVar4 = uVar4 + 1;
*(ushort *)piVar5 = extraout_r1_00;
piVar5 = (int *)((int)piVar5 + 2);
}
uVar4 = 0;
piVar5 = param_1;
while (uVar4 < param_2 >> 1) {
uVar2 = *(ushort *)piVar5;
divide(uVar4 + uVar3,0xff);
if (extraout_r1_03 != uVar2) {
return;
}
uVar4 = uVar4 + 1;
piVar5 = (int *)((int)piVar5 + 2);
}
uVar3 = uVar3 + 1;
} while (uVar3 < 2);
uVar3 = 0;
do {
uVar4 = 0;
piVar5 = param_1;
while (uVar4 < param_2) {
divide(uVar4 + uVar3,0xff);
uVar4 = uVar4 + 1;
*(byte *)piVar5 = extraout_r1;
piVar5 = (int *)((int)piVar5 + 1);
}
uVar4 = 0;
piVar5 = param_1;
while (uVar4 < param_2) {
bVar1 = *(byte *)piVar5;
divide(uVar4 + uVar3,0xff);
if (extraout_r1_04 != bVar1) {
return;
}
uVar4 = uVar4 + 1;
piVar5 = (int *)((int)piVar5 + 1);
}
uVar3 = uVar3 + 1;
} while (uVar3 < 2);
uVar3 = 0;
while (uVar3 < param_2) {
uVar3 = uVar3 + 1;
*(byte *)param_1 = 0;
param_1 = (int *)((int)param_1 + 1);
}
return;
}
case ARM_COND_LOWER_SAME:
//For execute on lower or the same C needs to be cleared and Z needs to be set
if((core->status->flags.C == 0) && (core->status->flags.Z))
execute = 1;
break;
case ARM_COND_LESS_THAN_EQUAL:
//For execute on less than or equal than N needs to be not equal to V and Z needs to be set
if((core->status->flags.N != core->status->flags.V) && (core->status->flags.Z))
execute = 1;
break;
case ARM_COND_LOWER_SAME:
//For execute on lower or the same C needs to be cleared and Z needs to be set
if((core->status->flags.C == 0) || (core->status->flags.Z))
execute = 1;
break;
case ARM_COND_LESS_THAN_EQUAL:
//For execute on less than or equal than N needs to be not equal to V and Z needs to be set
if((core->status->flags.N != core->status->flags.V) || (core->status->flags.Z))
execute = 1;
break;
7：Storage depth: 240KbitSource??
@pcprogrammer
First, your work is highly appreciated. :clap:
But do the daily water level reports really help anyone?7：Storage depth: 240KbitSource??
@pcprogrammer
First, your work is highly appreciated. :clap:
But do the daily water level reports really help anyone?
int FUN_8002cf28(uint param_1)
{
uint *puVar1;
int iVar2;
uint uVar3;
int iVar4;
uint uVar5;
uint uVar6;
int unaff_r5;
FUN_8002fb5c(); //Already called from FUN_80018464 and therefore does nothing
puVar1 = DAT_8002d040; //0x80857C80
uVar5 = DAT_8002d040[0x10]; //*0x80857CC0 = 0x00000010
if (uVar5 <= param_1) //16 <= 6032 ?? cmp r1,r4 | r1 = 0x00000010, r4 = 0x00001790 | carry not set ???
{
uVar5 = param_1 + 3 & 0xfffffffc; //Make it on a word boundary.
}
uVar5 = uVar5 + 0xc; //uvar5 = 0x1C
pa:0x8002CF34 0xE59F6104 YES ldr r6, [pc, #260] r0:0x00000001 r1:0x00000080 r2:0x00000178 r3:0xFFFFFFB8 r4:0x00001790 r5:0x80857C8C r6:0x80857C80 r7:0x80192E6B cpsr:0x20000053
pa:0x8002CF38 0xE5961040 YES ldr r1, [r6, #64] r0:0x00000001 r1:0x00000010 r2:0x00000178 r3:0xFFFFFFB8 r4:0x00001790 r5:0x80857C8C r6:0x80857C80 r7:0x80192E6B cpsr:0x20000053
pa:0x8002CF3C 0xE1510004 YES cmp r1, r4 r0:0x00000001 r1:0x00000010 r2:0x00000178 r3:0xFFFFFFB8 r4:0x00001790 r5:0x80857C8C r6:0x80857C80 r7:0x80192E6B cpsr:0x80000053
pa:0x8002CF40 0x92840003 NO addls r0, r4, #3 r0:0x00000001 r1:0x00000010 r2:0x00000178 r3:0xFFFFFFB8 r4:0x00001790 r5:0x80857C8C r6:0x80857C80 r7:0x80192E6B cpsr:0x80000053
pa:0x8002CF44 0x93C01003 NO bicls r1, r0, #3 r0:0x00000001 r1:0x00000010 r2:0x00000178 r3:0xFFFFFFB8 r4:0x00001790 r5:0x80857C8C r6:0x80857C80 r7:0x80192E6B cpsr:0x80000053
pa:0x8002CF48 0xE5960000 YES ldr r0, [r6, #0] r0:0x00000000 r1:0x00000010 r2:0x00000178 r3:0xFFFFFFB8 r4:0x00001790 r5:0x80857C8C r6:0x80857C80 r7:0x80192E6B cpsr:0x80000053
pa:0x8002CF4C 0xE281400C YES add r4, r1, #12 r0:0x00000000 r1:0x00000010 r2:0x00000178 r3:0xFFFFFFB8 r4:0x0000001C r5:0x80857C8C r6:0x80857C80 r7:0x80192E6B cpsr:0x80000053
LAB_80000634 XREF[1]: 80000628(j)
80000634 02 2c cmp r4,#0x2
80000636 0b d3 bcc LAB_80000650
80000638 67 08 lsr r7,r4,#0x1
8000063a 32 04 lsl count,r6,#0x10
8000063c 7f 00 lsl r7,r7,#0x1
8000063e 32 43 orr count,r6
80000640 79 00 lsl data,r7,#0x1
80000642 28 00 mov dest,r5
80000644 00 91 str data,[sp,#0x0]=>local_20
80000646 00 f0 3a e9 blx FUN_800008bc undefined FUN_800008bc()
8000064a 00 99 ldr data,[sp,#0x0]=>local_20
8000064c e4 1b sub r4,r4,r7
8000064e 4d 19 add r5,data,r5
b) They help me ;) For me it helps to write about what I encounter and sometimes brings light to my brain.
Question.Maybe later this week.
Is there someone with a 1013D scope and a good I2C sniffer willing to capture the data communication between the fpga and the special chip.
I saved the "turn on procedure" of the scope, with "Saleae Logic 2" (my prog version is 2.3.26)
I hope it can be open without hardware device too.
Thanks very much. :-+
.
.
...hope that you are willing to capture more if needed. :)
BUt it should be very hard to read for people just searching for some funded infos on the scope.
Instead of a daily diary i would suggest a seperated thread of its own - "Hacking the tablet scope" .
Or a detailed diary on github or something else ;)
A poll:
How many of the readers of this post want me to move the hacking updates to another thread?
Yes,
I'm happy to help. :)
{ 0x00, 0x36, 0x28, 0x89, 0x69, 0x96, 0x99, 0x13 }, //Checksum ok Crypt mangle ok Id: 0x0A Len: 0
{ 0x01, 0x25, 0x55, 0x39, 0x69, 0x96, 0x99, 0x27 }, //Checksum ok
{ 0x00, 0xA1, 0x50, 0xBC, 0x69, 0x96, 0x99, 0xED }, //Checksum ok Crypt mangle ok Id: 0x14 Len: 0
{ 0x01, 0xCA, 0x55, 0xC4, 0x69, 0x96, 0x99, 0x0D }, //Checksum ok
{ 0x00, 0x1E, 0x58, 0x06, 0x69, 0x96, 0x99, 0x00 }, //Checksum ok Crypt mangle ok Id: 0x16 Len: 0
{ 0x01, 0x05, 0x5A, 0x8B, 0x69, 0x96, 0x7E, 0xAF }, //Checksum ok
{ 0x00, 0xA0, 0x40, 0xE4, 0x69, 0x96, 0x99, 0x64 }, //Checksum ok Crypt mangle ok Id: 0x10 Len: 0
{ 0x01, 0x70, 0x5A, 0x13, 0x69, 0x96, 0xEA, 0x60 }, //Checksum ok
{ 0x00, 0x51, 0x45, 0x09, 0x69, 0x96, 0x7D, 0x97 }, //Checksum ok Crypt mangle ok Id: 0x11 Len: 1
{ 0x01, 0x31, 0x5A, 0x6C, 0x69, 0x96, 0x07, 0xDB }, //Checksum ok
{ 0x00, 0x61, 0x30, 0x0B, 0x69, 0x96, 0x99, 0x00 }, //Checksum ok Crypt mangle ok Id: 0x0C Len: 0
{ 0x01, 0xC1, 0x55, 0xCE, 0x69, 0x96, 0x99, 0x20 }, //Checksum ok
{ 0x00, 0x34, 0x2C, 0xF8, 0x69, 0x96, 0x99, 0x00 }, //Checksum ok Crypt mangle ok Id: 0x0B Len: 0
{ 0x01, 0xA7, 0x55, 0x41, 0x69, 0x96, 0x99, 0xAD }, //Checksum ok
{ 0x00, 0xAD, 0x45, 0x4A, 0x69, 0x96, 0xA5, 0xFA }, //Checksum ok Crypt mangle ok Id: 0x11 Len: 1
{ 0x01, 0xA7, 0x5A, 0x6B, 0x69, 0x96, 0x0A, 0x61 }, //Checksum ok
{ 0x00, 0xAD, 0x30, 0x8F, 0x69, 0x96, 0x99, 0x00 }, //Checksum ok Crypt mangle ok Id: 0x0C Len: 0
{ 0x01, 0x8C, 0x55, 0x99, 0x69, 0x96, 0x99, 0x20 }, //Checksum ok
{ 0x00, 0x86, 0x2C, 0x4A, 0x69, 0x96, 0x99, 0x00 }, //Checksum ok Crypt mangle ok Id: 0x0B Len: 0
{ 0x01, 0x99, 0x55, 0x33, 0x69, 0x96, 0x99, 0xAD }, //Checksum ok
I captured two sessions a' 20 seconds, first samplrate 10MHz, 2nd 4MHz.
Switch on, moving lines(signal*cursors), timbase, trigger, vertical sensivity, switch off - CH1 only with CH2 turned off.
Data saved as DSView format, csv and gnuplot.
(Attachment Link)
The zips contain tgzs, tgz didn't upload :(
But it did not result in working "touch"
Does it matter if our firmwares (maybe) are different?
{ 0x00, 0x4C, 0xD2, 0x07, 0xFB, 0x04, 0x0B, 0xDF },{ 0x00, 0xDE, 0x40, 0x95, 0x69, 0x96, 0x99, 0x4D }, //Checksum ok Id: 0x10 Len: 0
{ 0x01, 0xD2, 0x77, 0x63, 0x44, 0xBB, 0x95, 0x3D },{ 0x01, 0x2D, 0x5A, 0x4E, 0x69, 0x96, 0xB8, 0x10 }, //Checksum ok
{ 0x00, 0xA3, 0x6D, 0x23, 0x44, 0xBB, 0xB4, 0x60 },{ 0x00, 0x8E, 0x40, 0x0E, 0x69, 0x96, 0x99, 0x4D }, //Checksum ok Id: 0x10 Len: 0
{ 0x01, 0xB0, 0x15, 0x3F, 0x26, 0xD9, 0xF7, 0x5F },{ 0x01, 0x4F, 0x5A, 0x70, 0x69, 0x96, 0xB8, 0x10 }, //Checksum ok
{ 0x00, 0xBA, 0x0F, 0xBD, 0x26, 0xD9, 0xD6, 0x1F },{ 0x00, 0xF5, 0x40, 0xF2, 0x69, 0x96, 0x99, 0x50 }, //Checksum ok Id: 0x10 Len: 0
{ 0x01, 0x80, 0x25, 0x49, 0x16, 0xE9, 0xC1, 0xDF },{ 0x01, 0x7F, 0x5A, 0x36, 0x69, 0x96, 0xBE, 0xA0 }, //Checksum ok
{ 0x00, 0xFB, 0x3F, 0x4E, 0x16, 0xE9, 0xE6, 0x2F },{ 0x00, 0x84, 0x40, 0x31, 0x69, 0x96, 0x99, 0x50 }, //Checksum ok Id: 0x10 Len: 0
{ 0x01, 0x79, 0xDC, 0xBB, 0xEF, 0x10, 0x38, 0x26 },{ 0x01, 0x86, 0x5A, 0x3D, 0x69, 0x96, 0xBE, 0xA0 }, //Checksum ok
{ 0x00, 0x8C, 0xC6, 0x46, 0xEF, 0x10, 0x1F, 0xD6 },{ 0x00, 0x0A, 0x40, 0xC0, 0x69, 0x96, 0x99, 0x50 }, //Checksum ok Id: 0x10 Len: 0
{ 0x01, 0x2C, 0x89, 0x59, 0xBA, 0x45, 0x6D, 0x73 },{ 0x01, 0xD3, 0x5A, 0x8A, 0x69, 0x96, 0xBE, 0xA0 }, //Checksum ok
{ 0x00, 0x7C, 0x93, 0xE1, 0xBA, 0x45, 0x4A, 0x89 },{ 0x00, 0xAF, 0x40, 0x32, 0x69, 0x96, 0x99, 0x5A }, //Checksum ok Id: 0x10 Len: 0
{ 0x01, 0x63, 0xC6, 0xD5, 0xF5, 0x0A, 0x48, 0x1C },{ 0x01, 0x9C, 0x5A, 0x49, 0x69, 0x96, 0xD4, 0x80 }, //Checksum ok
{ 0x00, 0xC6, 0xDC, 0x6C, 0xF5, 0x0A, 0x05, 0xC6 },{ 0x00, 0x5A, 0x40, 0xF0, 0x69, 0x96, 0x99, 0x5A }, //Checksum ok Id: 0x10 Len: 0
{ 0x01, 0xAC, 0x09, 0x53, 0x3A, 0xC5, 0x87, 0xD3 },{ 0x01, 0x53, 0x5A, 0x00, 0x69, 0x96, 0xD4, 0x80 }, //Checksum ok
{ 0x00, 0x78, 0x13, 0x84, 0x3A, 0xC5, 0xCA, 0x30 },{ 0x00, 0x2B, 0x40, 0xD7, 0x69, 0x96, 0x99, 0x63 }, //Checksum ok Id: 0x10 Len: 0
{ 0x01, 0xA7, 0x02, 0x91, 0x31, 0xCE, 0xB0, 0x68 },{ 0x01, 0x58, 0x5A, 0xC9, 0x69, 0x96, 0xE8, 0x30 }, //Checksum ok
{ 0x00, 0x52, 0x18, 0x65, 0x31, 0xCE, 0xC1, 0x3B },{ 0x00, 0x0A, 0x40, 0x3D, 0x69, 0x96, 0x99, 0x63 }, //Checksum ok Id: 0x10 Len: 0
{ 0x01, 0xC5, 0x60, 0x91, 0x53, 0xAC, 0xD2, 0x0A },{ 0x01, 0x3A, 0x5A, 0xAB, 0x69, 0x96, 0xE8, 0x30 }, //Checksum ok
{ 0x00, 0x4B, 0x7A, 0xC0, 0x53, 0xAC, 0xA3, 0x59 },{ 0x00, 0x71, 0x40, 0xFA, 0x69, 0x96, 0x99, 0x63 }, //Checksum ok Id: 0x10 Len: 0
{ 0x01, 0xA1, 0x04, 0x91, 0x37, 0xC8, 0xB6, 0x6E },{ 0x01, 0x5E, 0x5A, 0xCF, 0x69, 0x96, 0xE8, 0x30 }, //Checksum ok
{ 0x00, 0xDA, 0x1E, 0xF8, 0x37, 0xC8, 0xC7, 0x3A },{ 0x00, 0x84, 0x40, 0xA6, 0x69, 0x96, 0x99, 0x64 }, //Checksum ok Id: 0x10 Len: 0
{ 0x01, 0x9D, 0x38, 0x67, 0x0B, 0xF4, 0x88, 0x02 },{ 0x01, 0x62, 0x5A, 0x05, 0x69, 0x96, 0xEA, 0x60 }, //Checksum ok
{ 0x00, 0x19, 0x22, 0x3B, 0x0B, 0xF4, 0xFB, 0x06 },{ 0x00, 0x7B, 0x40, 0x59, 0x69, 0x96, 0x99, 0x64 }, //Checksum ok Id: 0x10 Len: 0
{ 0x01, 0x00, 0xA5, 0x5D, 0x96, 0x69, 0x15, 0x9F },{ 0x01, 0xFF, 0x5A, 0xA2, 0x69, 0x96, 0xEA, 0x60 }, //Checksum ok
{ 0x00, 0xFF, 0xBF, 0xBE, 0x96, 0x69, 0x66, 0x9B },{ 0x00, 0x00, 0x40, 0x41, 0x69, 0x96, 0x99, 0x64 }, //Checksum ok Id: 0x10 Len: 0
{ 0x01, 0x24, 0x81, 0xA5, 0xB2, 0x4D, 0x31, 0xBB },{ 0x01, 0xDB, 0x5A, 0x7E, 0x69, 0x96, 0xEA, 0x60 }, //Checksum ok
the data is incomplete.
uint FUN_8001bec4(void)
{
byte bVar1;
byte bVar2;
uint uVar3;
fpga_write_cmd('\x14');
bVar1 = fpga_read_data();
bVar2 = fpga_read_data();
uVar3 = get_setting(0x11, bVar1 & 0xf | (bVar1 & 0xf) << 0xc | (uint)bVar2 << 4);
return uVar3;
}
{ 0x00, 0x51, 0x35, 0x79, 0x19, 0xE6, 0x0D, 0xE7 },{ 0x00, 0x21, 0x45, 0x09, 0x69, 0x96, 0x7D, 0x97 }, //Checksum ok Data: 0x000007D9 Id: 0x11 Len: 1
{ 0x01, 0xCE, 0x6B, 0x5D, 0x58, 0xA7, 0x36, 0xEA },{ 0x01, 0x31, 0x5A, 0x6C, 0x69, 0x96, 0x07, 0xDB }, //Checksum ok Data: 0x000007DB
{ 0x00, 0xAD, 0xE2, 0xED, 0xCE, 0x31, 0x02, 0x5D },{ 0x00, 0x0A, 0x45, 0x4A, 0x69, 0x96, 0xA5, 0xFA }, //Checksum ok Data: 0x00000A5F Id: 0x11 Len: 1
{ 0x01, 0x58, 0xFD, 0xCC, 0xCE, 0x31, 0xAD, 0xC6 },{ 0x01, 0xA7, 0x5A, 0x6B, 0x69, 0x96, 0x0A, 0x61 }, //Checksum ok Data: 0x00000A61
{ 0x00, 0x66, 0xDC, 0xA0, 0xF0, 0x0F, 0x3C, 0x23 },{ 0x00, 0xFF, 0x45, 0x39, 0x69, 0x96, 0xA5, 0xBA }, //Checksum ok Data: 0x00000A5B Id: 0x11 Len: 1
{ 0x01, 0xA4, 0x01, 0x40, 0x32, 0xCD, 0x51, 0x06 },{ 0x01, 0x5B, 0x5A, 0x1B, 0x69, 0x96, 0x0A, 0x5D }, //Checksum ok Data: 0x00000A5D
{ 0x00, 0x62, 0x5C, 0x1C, 0x70, 0x8F, 0xBC, 0xA3 },{ 0x00, 0x7B, 0x45, 0x05, 0x69, 0x96, 0xA5, 0xBA }, //Checksum ok Data: 0x00000A5B Id: 0x11 Len: 1
{ 0x01, 0xFA, 0x5F, 0xC0, 0x6C, 0x93, 0x0F, 0x58 },{ 0x01, 0x05, 0x5A, 0xC5, 0x69, 0x96, 0x0A, 0x5D }, //Checksum ok Data: 0x00000A5D
{ 0x00, 0x60, 0x54, 0x42, 0x78, 0x87, 0xB4, 0xDB },{ 0x00, 0x71, 0x45, 0x53, 0x69, 0x96, 0xA5, 0xCA }, //Checksum ok Data: 0x00000A5C Id: 0x11 Len: 1
{ 0x01, 0x1E, 0xBB, 0x43, 0x88, 0x77, 0xEB, 0xBF },{ 0x01, 0xE1, 0x5A, 0xA2, 0x69, 0x96, 0x0A, 0x5E }, //Checksum ok Data: 0x00000A5E
{ 0x00, 0x68, 0x56, 0x3C, 0x7A, 0x85, 0xB6, 0xC9 },{ 0x00, 0x7B, 0x45, 0x2F, 0x69, 0x96, 0xA5, 0xDA }, //Checksum ok Data: 0x00000A5D Id: 0x11 Len: 1
{ 0x01, 0x55, 0xF0, 0xC6, 0xC3, 0x3C, 0xA0, 0xF5 },{ 0x01, 0xAA, 0x5A, 0x6C, 0x69, 0x96, 0x0A, 0x5F }, //Checksum ok Data: 0x00000A5F
{ 0x00, 0x63, 0x7C, 0x1D, 0x50, 0xAF, 0x9C, 0xA3 },{ 0x00, 0x5A, 0x45, 0x24, 0x69, 0x96, 0xA5, 0x9A }, //Checksum ok Data: 0x00000A59 Id: 0x11 Len: 1
{ 0x01, 0x60, 0xC5, 0xC2, 0xF6, 0x09, 0x95, 0xC4 },{ 0x01, 0x9F, 0x5A, 0x5D, 0x69, 0x96, 0x0A, 0x5B }, //Checksum ok Data: 0x00000A5B
{ 0x00, 0x9A, 0x0B, 0x13, 0x27, 0xD8, 0xEB, 0x84 },{ 0x00, 0xD4, 0x45, 0x5D, 0x69, 0x96, 0xA5, 0xCA }, //Checksum ok Data: 0x00000A5C Id: 0x11 Len: 1
{ 0x01, 0xD7, 0x72, 0xC1, 0x41, 0xBE, 0x22, 0x76 },{ 0x01, 0x28, 0x5A, 0xE9, 0x69, 0x96, 0x0A, 0x5E }, //Checksum ok Data: 0x00000A5E
{ 0x00, 0x30, 0x04, 0xA2, 0x28, 0xD7, 0xE4, 0x8B },{ 0x00, 0x71, 0x45, 0xE3, 0x69, 0x96, 0xA5, 0xCA }, //Checksum ok Data: 0x00000A5C Id: 0x11 Len: 1
{ 0x01, 0x38, 0x9D, 0x4F, 0xAE, 0x51, 0xCD, 0x99 },{ 0x01, 0xC7, 0x5A, 0x88, 0x69, 0x96, 0x0A, 0x5E }, //Checksum ok Data: 0x00000A5E
{ 0x00, 0xA2, 0x48, 0x58, 0x64, 0x9B, 0xA8, 0xC7 },{ 0x00, 0xAF, 0x45, 0x55, 0x69, 0x96, 0xA5, 0xCA }, //Checksum ok Data: 0x00000A5C Id: 0x11 Len: 1
{ 0x01, 0x38, 0x9D, 0x4F, 0xAE, 0x51, 0xCD, 0x99 },{ 0x01, 0xC7, 0x5A, 0x88, 0x69, 0x96, 0x0A, 0x5E }, //Checksum ok Data: 0x00000A5E
{ 0x00, 0x91, 0x21, 0x20, 0x0D, 0xF2, 0xC1, 0xAE },{ 0x00, 0xF5, 0x45, 0x44, 0x69, 0x96, 0xA5, 0xCA }, //Checksum ok Data: 0x00000A5C Id: 0x11 Len: 1
{ 0x01, 0x9A, 0x3F, 0x43, 0x0C, 0xF3, 0x6F, 0x3B },{ 0x01, 0x65, 0x5A, 0x26, 0x69, 0x96, 0x0A, 0x5E }, //Checksum ok Data: 0x00000A5E
{ 0x00, 0xB6, 0x88, 0x5E, 0xA4, 0x5B, 0x00, 0x21 },{ 0x00, 0x7B, 0x45, 0x93, 0x69, 0x96, 0xCD, 0xEC }, //Checksum ok Data: 0x00000CDE Id: 0x11 Len: 1
{ 0x01, 0xC9, 0x6C, 0x4D, 0x5F, 0xA0, 0x3A, 0xD6 },{ 0x01, 0x36, 0x5A, 0x7B, 0x69, 0x96, 0x0C, 0xE0 }, //Checksum ok Data: 0x00000CE0
{ 0x00, 0xB5, 0xA0, 0xD3, 0x8C, 0x73, 0x40, 0x3F },{ 0x00, 0x50, 0x45, 0x36, 0x69, 0x96, 0xA5, 0xDA }, //Checksum ok Data: 0x00000A5D Id: 0x11 Len: 1
{ 0x01, 0x7C, 0xD9, 0xC6, 0xEA, 0x15, 0x89, 0xDC },{ 0x01, 0x83, 0x5A, 0x45, 0x69, 0x96, 0x0A, 0x5F }, //Checksum ok Data: 0x00000A5F
{ 0x00, 0x91, 0x21, 0x30, 0x0D, 0xF2, 0xC1, 0xBE },{ 0x00, 0xF5, 0x45, 0x54, 0x69, 0x96, 0xA5, 0xDA }, //Checksum ok Data: 0x00000A5D Id: 0x11 Len: 1
{ 0x01, 0x53, 0xF6, 0xC2, 0xC5, 0x3A, 0xA6, 0xF3 },{ 0x01, 0xAC, 0x5A, 0x6E, 0x69, 0x96, 0x0A, 0x5F }, //Checksum ok Data: 0x00000A5F
{ 0x00, 0x51, 0x35, 0x54, 0x19, 0xE6, 0xD5, 0xFA },{ 0x00, 0x21, 0x45, 0x24, 0x69, 0x96, 0xA5, 0x8A }, //Checksum ok Data: 0x00000A58 Id: 0x11 Len: 1
{ 0x01, 0x7E, 0xDB, 0xBF, 0xE8, 0x17, 0x8B, 0xDB },{ 0x01, 0x81, 0x5A, 0x3E, 0x69, 0x96, 0x0A, 0x5A }, //Checksum ok Data: 0x00000A5A
{ 0x00, 0x25, 0xE4, 0x47, 0xC8, 0x37, 0x04, 0x3B },{ 0x00, 0x84, 0x45, 0xE6, 0x69, 0x96, 0xA5, 0x9A }, //Checksum ok Data: 0x00000A59 Id: 0x11 Len: 1
{ 0x01, 0x28, 0x8D, 0x42, 0xBE, 0x41, 0xDD, 0x8C },{ 0x01, 0xD7, 0x5A, 0x95, 0x69, 0x96, 0x0A, 0x5B }, //Checksum ok Data: 0x00000A5B
{ 0x00, 0xBF, 0xAA, 0xD7, 0x86, 0x79, 0x4A, 0x25 },{ 0x00, 0x50, 0x45, 0x38, 0x69, 0x96, 0xA5, 0xCA }, //Checksum ok Data: 0x00000A5C Id: 0x11 Len: 1
{ 0x01, 0x9A, 0x3F, 0x43, 0x0C, 0xF3, 0x6F, 0x3B },{ 0x01, 0x65, 0x5A, 0x26, 0x69, 0x96, 0x0A, 0x5E }, //Checksum ok Data: 0x00000A5E
{ 0x00, 0x5A, 0x1F, 0x37, 0x33, 0xCC, 0xFF, 0xC0 },{ 0x00, 0x00, 0x45, 0x6D, 0x69, 0x96, 0xA5, 0x9A }, //Checksum ok Data: 0x00000A59 Id: 0x11 Len: 1
{ 0x01, 0xA1, 0x04, 0x42, 0x37, 0xC8, 0x54, 0x05 },{ 0x01, 0x5E, 0x5A, 0x1C, 0x69, 0x96, 0x0A, 0x5B }, //Checksum ok Data: 0x00000A5B
{ 0x00, 0x61, 0x74, 0x53, 0x58, 0xA7, 0x94, 0xEB },{ 0x00, 0x50, 0x45, 0x62, 0x69, 0x96, 0xA5, 0xDA }, //Checksum ok Data: 0x00000A5D Id: 0x11 Len: 1
{ 0x01, 0xDB, 0x7E, 0xC2, 0x4D, 0xB2, 0x2E, 0x7B },{ 0x01, 0x24, 0x5A, 0xE6, 0x69, 0x96, 0x0A, 0x5F }, //Checksum ok Data: 0x00000A5F
{ 0x00, 0x5A, 0x1F, 0x07, 0x33, 0xCC, 0xFF, 0x90 },{ 0x00, 0x00, 0x45, 0x5D, 0x69, 0x96, 0xA5, 0xCA }, //Checksum ok Data: 0x00000A5C Id: 0x11 Len: 1
{ 0x01, 0x12, 0xB7, 0x43, 0x84, 0x7B, 0xE7, 0xB3 },{ 0x01, 0xED, 0x5A, 0xAE, 0x69, 0x96, 0x0A, 0x5E }, //Checksum ok Data: 0x00000A5E
{ 0x00, 0x49, 0x77, 0x2E, 0x5B, 0xA4, 0x97, 0xD8 },{ 0x00, 0x7B, 0x45, 0x1C, 0x69, 0x96, 0xA5, 0xEA }, //Checksum ok Data: 0x00000A5E Id: 0x11 Len: 1
{ 0x01, 0x7A, 0xDF, 0xCD, 0xEC, 0x13, 0x8F, 0xE5 },{ 0x01, 0x85, 0x5A, 0x48, 0x69, 0x96, 0x0A, 0x60 }, //Checksum ok Data: 0x00000A60
{ 0x00, 0xE6, 0xD8, 0xFC, 0xF4, 0x0B, 0x38, 0x07 },{ 0x00, 0x7B, 0x45, 0x61, 0x69, 0x96, 0xA5, 0x9A }, //Checksum ok Data: 0x00000A59 Id: 0x11 Len: 1
{ 0x01, 0xB7, 0x12, 0x4E, 0x21, 0xDE, 0x42, 0x13 },{ 0x01, 0x48, 0x5A, 0x06, 0x69, 0x96, 0x0A, 0x5B }, //Checksum ok Data: 0x00000A5B
{ 0x00, 0x25, 0xE4, 0x87, 0xC8, 0x37, 0x04, 0x7B },{ 0x00, 0x84, 0x45, 0x26, 0x69, 0x96, 0xA5, 0xDA }, //Checksum ok Data: 0x00000A5D Id: 0x11 Len: 1
{ 0x01, 0x3D, 0x98, 0x46, 0xAB, 0x54, 0xC8, 0x9D },{ 0x01, 0xC2, 0x5A, 0x84, 0x69, 0x96, 0x0A, 0x5F }, //Checksum ok Data: 0x00000A5F
{ 0x00, 0xBE, 0x8A, 0xC6, 0xA6, 0x59, 0x6A, 0x15 },{ 0x00, 0x71, 0x45, 0x09, 0x69, 0x96, 0xA5, 0xDA }, //Checksum ok Data: 0x00000A5D Id: 0x11 Len: 1
{ 0x01, 0x8E, 0x2B, 0x42, 0x18, 0xE7, 0x7B, 0x2E },{ 0x01, 0x71, 0x5A, 0x33, 0x69, 0x96, 0x0A, 0x5F }, //Checksum ok Data: 0x00000A5F
{ 0x00, 0xF5, 0xB0, 0x23, 0x9C, 0x63, 0x50, 0x2F },{ 0x00, 0x00, 0x45, 0xD6, 0x69, 0x96, 0xA5, 0xDA }, //Checksum ok Data: 0x00000A5D Id: 0x11 Len: 1
{ 0x01, 0x79, 0xDC, 0xCE, 0xEF, 0x10, 0x8C, 0xD9 },{ 0x01, 0x86, 0x5A, 0x48, 0x69, 0x96, 0x0A, 0x5F }, //Checksum ok Data: 0x00000A5F
{ 0x00, 0xBB, 0x2A, 0xA3, 0x06, 0xF9, 0xCA, 0xF5 },{ 0x00, 0xD4, 0x45, 0xCC, 0x69, 0x96, 0xA5, 0x9A }, //Checksum ok Data: 0x00000A59 Id: 0x11 Len: 1
{ 0x01, 0xE9, 0x4C, 0xC2, 0x7F, 0x80, 0x1C, 0x4D },{ 0x01, 0x16, 0x5A, 0xD4, 0x69, 0x96, 0x0A, 0x5B }, //Checksum ok Data: 0x00000A5B
{ 0x00, 0x3A, 0x0E, 0xC6, 0x22, 0xDD, 0xEE, 0x91 },{ 0x00, 0x71, 0x45, 0x8D, 0x69, 0x96, 0xA5, 0xDA }, //Checksum ok Data: 0x00000A5D Id: 0x11 Len: 1
{ 0x01, 0xD2, 0x77, 0xC2, 0x44, 0xBB, 0x27, 0x72 },{ 0x01, 0x2D, 0x5A, 0xEF, 0x69, 0x96, 0x0A, 0x5F }, //Checksum ok Data: 0x00000A5F
looking at the images the data still looks as if there is something wrong....There should be 8 bytes per packet with 9 clock pulses per byte
There should be 8 bytes per packet with 9 clock pulses per byte (1 for the ack/nack).IIRC I2C data may vary betwenn 7 and 11 bytes and I'm quite shure that 7and 9 are used, even thouhg quite rarely.
Maybe your capture device will work with the saleae program as well.1st.. I do not think so, 2nd, I'm using FOSS only ;)
looking at the images the data still looks as if there is something wrong....There should be 8 bytes per packet with 9 clock pulses per byte
I beg your pardon but I didn't took a closer look at the data for I have only very little I2C skills, normally I do not use.There should be 8 bytes per packet with 9 clock pulses per byte (1 for the ack/nack).IIRC I2C data may vary betwenn 7 and 11 bytes and I'm quite shure that 7and 9 are used, even thouhg quite rarely.
I'll proceed with booting the latest linux version now, and adding touchscreen drivers and an LVGL test app.
Channel 1 settings
0x32 Is some sort of offset. Changes when the trace on the screen is moved up or down.
0x33 Select the input scaling (V/div). See table below
0x34 Select ac or dc coupling. 0x00 is ac coupling. 0x01 is dc coupling.
The offset is also changed when the V/div is changed.
Scale Screen offset
V/div 0x33 0x32
500mV 0x05 0x02 0xE0 //Uses the same setting as 1V/div. Scaling is done in software
1V 0x05 0x02 0xE0
2V 0x04 0x02 0xE7
5V 0x03 0x02 0xD3
10V 0x02 0x02 0xDA
25V 0x01 0x02 0xB9
50V 0x00 0x02 0xB9
Channel 2 settings
0x35 Is some sort of offset. Changes when the trace on the screen is moved up or down.
0x36 Select the input scaling (V/div). See table below
0x37 Select ac or dc coupling. 0x00 is ac coupling. 0x01 is dc coupling.
The offset is also changed when the V/div is changed.
V/div 0x36 0x35
500mV 0x05 0x04 0x99 //Uses the same setting as 1V/div. Scaling is done in software
1V 0x05 0x04 0x99
2V 0x04 0x04 0x9F
5V 0x03 0x04 0x96
10V 0x02 0x04 0x9C
25V 0x01 0x04 0x8B
50V 0x00 0x04 0x8D
I made some "state-variant" captures.
(Details in the file names...)
{ 0x00, 0xCB, 0x7B, 0xEA, 0x57, 0xA8, 0x08, 0x9D },{ 0x00, 0xF5, 0x45, 0xD4, 0x69, 0x96, 0x36, 0xA3 }, //Checksum ok Data: 0x000036A3 Id: 0x11 Len: 1
{ 0x01, 0xC2, 0x67, 0x38, 0x54, 0xAB, 0x3E, 0x51 },{ 0x01, 0x3D, 0x5A, 0x05, 0x69, 0x96, 0x03, 0x6C }, //Checksum ok Data: 0x0000036C
{ 0x00, 0xE3, 0x0D, 0xD0, 0x54, 0xAB, 0xA4, 0x3D },{ 0x00, 0xDE, 0x30, 0xED, 0x69, 0x96, 0x99, 0x00 }, //Checksum ok Data: 0x00000000 Id: 0x0C Len: 0
{ 0x01, 0x77, 0xDD, 0x1D, 0xE1, 0x1E, 0x11, 0xA8 },{ 0x01, 0x88, 0x55, 0x95, 0x69, 0x96, 0x99, 0x20 }, //Checksum ok Data: 0x00000020
{ 0x00, 0x06, 0xA4, 0x44, 0xE1, 0x1E, 0x11, 0x8A },{ 0x00, 0x8E, 0x2C, 0xCC, 0x69, 0x96, 0x99, 0x02 }, //Checksum ok Data: 0x00000002 Id: 0x0B Len: 0
{ 0x01, 0x24, 0x8E, 0xA7, 0xB2, 0x4D, 0x42, 0x6F },{ 0x01, 0xDB, 0x55, 0x7C, 0x69, 0x96, 0x99, 0xB4 }, //Checksum ok Data: 0x000000B4
{ 0x00, 0x7E, 0xEF, 0x89, 0xB2, 0x4D, 0x42, 0xDB },{ 0x00, 0xA5, 0x34, 0x52, 0x69, 0x96, 0x99, 0x00 }, //Checksum ok Data: 0x00000000 Id: 0x0D Len: 0
{ 0x01, 0x64, 0xCE, 0x31, 0xF2, 0x0D, 0x02, 0xB9 },{ 0x01, 0x9B, 0x55, 0xAA, 0x69, 0x96, 0x99, 0x22 }, //Checksum ok Data: 0x00000022
{ 0x00, 0x6E, 0xB7, 0xBF, 0xF2, 0x0D, 0x02, 0x99 },{ 0x00, 0xF5, 0x2C, 0x24, 0x69, 0x96, 0x99, 0x02 }, //Checksum ok Data: 0x00000002 Id: 0x0B Len: 0
{ 0x01, 0x84, 0x2E, 0x67, 0x12, 0xED, 0xE2, 0xCF },{ 0x01, 0x7B, 0x55, 0x1C, 0x69, 0x96, 0x99, 0xB4 }, //Checksum ok Data: 0x000000B4
Trigger time / div settings
0x0E is written with four data bytes
time / div Command 0x0E bytes
10nS 0x00 0x06 0x45 0xDC (Read data from 0x20, 0x22 and 0x21, 0x23)
25nS 0x00 0x06 0x45 0xDC (Read data from 0x20, 0x22 and 0x21, 0x23)
50nS 0x00 0x06 0x45 0xDC
100nS 0x00 0x06 0x45 0xDC
250nS 0x00 0x06 0x45 0xDC
500nS 0x00 0x06 0x45 0xDC
1uS 0x00 0x03 0x25 0xDC
2uS 0x00 0x01 0x45 0xDC
5uS 0x00 0x00 0x55 0xDC
10uS 0x00 0x00 0x55 0xDC
20uS 0x00 0x00 0x25 0xDC
50uS 0x00 0x00 0x15 0xDC
100uS 0x00 0x00 0x0B 0xB8
200uS 0x00 0x00 0x09 0xC4
500uS 0x00 0x00 0x09 0xC4
1mS 0x00 0x00 0x09 0xC4
2mS 0x00 0x00 0x09 0xC4
5mS 0x00 0x00 0x09 0xC4
10mS 0x00 0x00 0x07 0x08
20mS 0x00 0x00 0x03 0x20
50mS 0x00 0x00 0x03 0x20
From here on it seems that the FPGA switches to 0x0D for time base setting and the data is read with 0x24 and 0x26, 10 bytes per read.
time / div Command 0x0D bytes
100mS 0x00 0x00 0x07 0xD0
200mS 0x00 0x00 0x07 0xD0
500mS 0x00 0x00 0x07 0xD0
1S 0x00 0x00 0x07 0xD0
2S 0x00 0x00 0x07 0xD0
5S 0x00 0x00 0x07 0xD0
10S 0x00 0x00 0x07 0xD0
20S 0x00 0x00 0x07 0xD0
50S 0x00 0x00 0x07 0xD0
a logic analyzer that works with the saleae softwareno chance with me :(
This means it is possible to write one owns software for the scope :)Until last night I had no idea of the F1C100 SOC, I only knew "Allwinner" from my Orange Pis.
a logic analyzer that works with the saleae softwareno chance with me :(
If you still need some data and trouble wih he sigrok format I can try to compress one or more of SRs supportet logical binary formats (SaLEAE isn't supported as output) as there are: raw binary logic or digits logic.This means it is possible to write one owns software for the scope :)Until last night I had no idea of the F1C100 SOC, I only knew "Allwinner" from my Orange Pis.
Last night I must learn F1C..crap be ing based on a more than 20ys old ARM design.. |O |O |O |O :-DD :-DD :-DD
No GPU..no FPU!!
Really worth?
For a frontend with 50mV/div best if you can solve the trigger shit for signals below 200mV?
Guess this is it for now. :=\
Guess this is it for now. :=\
Guess this is it for now. :=\
You've been awake all this time?? :clap:
FONT addresses
0x8018A380
0x8018A3A4
0x8018AC58 (Used for the channel menus)
0x8018B738 (Used for error messages)
0x8018C1C0
0x8018D558
0x8018F508 (Edit: Missed this one)
0x801913B0
**************************************************************
* THUNK FUNCTION *
**************************************************************
thunk undefined Reset()
Thunked-Function: FUN_00000020
undefined r0:1 <RETURN>
Reset XREF[1]: Entry Point(*)
00000000 06 00 00 ea b FUN_00000020
**************************************************************
* FUNCTION *
**************************************************************
undefined UndefinedInstruction()
undefined r0:1 <RETURN>
UndefinedInstruction XREF[1]: Entry Point(*)
00000004 65 47 4f 4e cdpmi p7,0x4,cr4,cr15,cr5,0x3
**************************************************************
* FUNCTION *
**************************************************************
undefined SupervisorCall()
undefined r0:1 <RETURN>
SupervisorCall XREF[1]: Entry Point(*)
00000008 2e 42 54 30 subccs r4,r4,lr, lsr #0x4
**************************************************************
* FUNCTION *
**************************************************************
undefined PrefetchAbort()
undefined r0:1 <RETURN>
PrefetchAbort XREF[1]: Entry Point(*)
0000000c c5 45 42 68 stmdavs r2,{r0 r2 r6 r7 r8 r10 lr}^
**************************************************************
* FUNCTION *
**************************************************************
undefined DataAbort()
undefined r0:1 <RETURN>
DataAbort XREF[1]: Entry Point(*)
00000010 00 26 00 00 andeq r2,r0,r0, lsl #0xc
**************************************************************
* FUNCTION *
**************************************************************
undefined NotUsed()
undefined r0:1 <RETURN>
NotUsed XREF[1]: Entry Point(*)
00000014 53 50 4c 02 subeq r5,r12,#0x53
**************************************************************
* FUNCTION *
**************************************************************
undefined IRQ()
undefined r0:1 <RETURN>
IRQ XREF[1]: Entry Point(*)
00000018 00 00 00 00 andeq r0,r0,r0
**************************************************************
* FUNCTION *
**************************************************************
undefined FIQ()
undefined r0:1 <RETURN>
FIQ XREF[1]: Entry Point(*)
0000001c 00 00 00 00 andeq r0,r0,r0
**************************************************************
* FUNCTION *
**************************************************************
undefined FUN_00000020()
undefined r0:1 <RETURN>
FUN_00000020 XREF[1]: Reset:00000000(T),
Reset:00000000(j)
00000020 00 00 0f e1 mrs r0,cpsr
00000024 1f 00 c0 e3 bic r0,r0,#0x1f
00000028 db 00 80 e3 orr r0,r0,#0xdb
0000002c 00 f0 29 e1 msr cpsr_cf,r0
00000030 78 d0 9f e5 ldr sp,[DAT_000000b0] = 00006C00h
00000034 00 00 0f e1 mrs r0,cpsr
They used several handling styles in their code. |OWhen that happens is because of legacy code, usually. Probably they have some legacy code for less powerful devices that used bitmaps, then added more flexible fonts for all languages, but kept using the old code for those elements since it works and it's tested... Everything new uses the new fonts code
The top bar uses a bitmap for the menu "button", a print text (CH1, CH2, T) and fill rectangle for the channel and trigger "buttons" and bigger bitmaps for the actual menus, instead of building them with code. Certainly faster, but why the mix. Using bitmaps for everything would have been the fastest. A full bitmap for the CTRL "button" instead of filling a rounded rectangle, drawing a rounded rectangle outline and copy in the text bitmap would have been faster.
But this puzzle is also nearing the end. Able to name more and more of the functions and get an understanding of how it works.
I'm also curious as to what people are doing with the data from the repository.
I'm also curious as to what people are doing with the data from the repository.
Sounds like you've got to expand your reversing capabilities! :-DD
Very fine work. Can I get a signed print?
void monitor_battery(void)
{
int iVar1;
undefined *puVar2;
byte bVar3;
uint uVar4;
byte *pbVar5;
int iVar6;
int iVar7;
byte bVar8;
bool bVar9;
iVar1 = DAT_8000a6a8; //Base of settings data
bVar8 = 0xff;
if (0xd < *(byte *)(DAT_8000a6a8 + 10)) //Time base setting If 13 is smaller then, so 14 and up (1mS/div and down)
{
iVar7 = 0x1e; //1mS/div --- 10nS/div, factor is 30
goto LAB_8000a5bc;
}
if (*(byte *)(DAT_8000a6a8 + 10) < 0xc) //Less then 0x0C
{
if (*(byte *)(DAT_8000a6a8 + 10) < 9) //Less then 9
{
if (6 < *(byte *)(DAT_8000a6a8 + 10)) //If 6 is smaller then, so 7 and 8.
{
iVar7 = 100; //200mS/div, 100mS/div, factor is 100
goto LAB_8000a5bc;
}
if (3 < *(byte *)(DAT_8000a6a8 + 10)) //If 3 is smaller then, so 4, 5 and 6
{
iVar7 = 0x32; //2S/div, 1S/div, 500mS/div, factor is 64
goto LAB_8000a5bc;
}
if (1 < *(byte *)(DAT_8000a6a8 + 10)) //If 1 is smaller then, so 2 and 3
goto LAB_8000a5b0; //10S/div, 5S/div, factor is 10
}
iVar7 = 3; //0, 1, 9, 10, 11
//50S/div, 20S/div, 50mS/div, 20mS/div, 10mS/div, factor is 3
}
else
{
LAB_8000a5b0: //12, 13
iVar7 = 10; //5mS/div, 2mS/div factor is 10
}
LAB_8000a5bc:
uVar4 = check_port_pin(DAT_8000a6ac,0xc); //Battery charge detect
puVar2 = PTR_DAT_8000a6b0; //0x80192ed4 some global variable, some accumulator??
if (uVar4 == 0) //If pin is low the battery is being charged
{
if (*(char *)(iVar1 + 0x39) == '\0') //BatteryCharging variable
{
*PTR_DAT_8000a6b0 = 0; //If previous state was not charging this variable is set 0
}
*(undefined *)(iVar1 + 0x39) = 1; //Indicate charging
}
else
{
*(undefined *)(iVar1 + 0x39) = 0; //Indicate not charging
}
bVar3 = read_keyadc_data(); //Battery level reading. result 0 - 0x3F
//0x80361378 Some base pointer
//Some fractional addition to the adc value
// result from scan byte from 0x8036137A (screen brightness) 0x068DB8BB
uVar4 = (uint)bVar3 + (uint)((ulonglong)(uint)((int)(short)(ushort)*(byte *)(DAT_8000a6b4 + 2) * (int)(short)((ushort)bVar3 * 10)) * (ulonglong)DAT_8000a6b8 >> 0x28); //High result byte logical shifted right an extra 8
//Check if on charge
if (*(char *)(iVar1 + 0x39) != '\0')
{
uVar4 = uVar4 - 7; //Take of 7 as compensation
}
//Check if result is less then 25
if (uVar4 < 0x19)
{
//If so set it to the minimum
uVar4 = 0x19;
}
//Divide ((the result minus the minimum) multiplied by 20) by 21
pbVar5 = (byte *)divide((uVar4 - 0x19) * 0x14, 0x15);
//Get data from global variable which is reset when charging starts
//Is an array index
bVar3 = *puVar2;
//0x802F1906 some array where the result is stored
DAT_8000a6bc[bVar3] = (byte)pbVar5;
//As long as the index is lower than the factor obtained from timebase setting
if ((int)(uint)bVar3 < iVar7 + -1)
{
//Increment the index and store it back
*puVar2 = bVar3 + 1;
return; //and quit
}
//When several samples are stored it comes here
//true since none of the timebase compare paths lead to iVar being set zero
bVar9 = iVar7 != 0;
if (bVar9)
{
pbVar5 = DAT_8000a6bc; //Point to the data
}
*puVar2 = 0; //Reset the index
//As long as there is data to process
while (bVar9)
{
bVar3 = *pbVar5; //Get the first byte
pbVar5 = pbVar5 + 1; //Point to the next one
if (bVar3 < bVar8) //Determine the lowest value
{
bVar8 = bVar3; //Keep the lowest value of the samples
}
iVar7 = iVar7 + -1; //One count done
bVar9 = iVar7 != 0; //Check on done
}
//Store result in BatteryChargeLevel
*(byte *)(iVar1 + 0x38) = bVar8;
display_battery_status();
}
Hi folks,
Just found a review of the Fnirsi-1013D with a clear verdict:
Hands off the Fnirsi 1013D (https://www.beis.de/Elektronik/FNIRSI-1013D/FNIRSI-1013D_en.html)
Martin
LAB_8001dc04:
do
{
tp_i2c_read_status();
uVar11 = (uint)*(ushort *)(puVar4 + 2);
if (uVar11 - 0xa2 < 0xb6) //Check the xrange
{
uVar15 = (uint)*(ushort *)(puVar4 + 4); //Get the y pos
bVar27 = 0x2d < uVar15;
bVar26 = uVar15 == 0x2e;
if (0x2e < uVar15)
{
bVar27 = uVar15 <= uVar12;
bVar26 = uVar12 == uVar15;
}
if (bVar27 && !bVar26)
{
uVar16 = uVar11 - 0xdc;
if (((uVar16 < 0x3b) && (0x30 < uVar15)) && (uVar15 < 0x6a))
{
if (*puVar4 != '\0') //Do we have touch
{
*pcVar5 = '\x01'; //This is for channel 1 enable
display_channel1_menu();
FUN_80002790();
tp_i2c_read_status();
cVar1 = *puVar4;
while (cVar1 != '\0')
{
tp_i2c_read_status();
cVar1 = *puVar4;
}
}
}
else
{
uVar18 = uVar11 - 0x11a;
if (((uVar18 < 0x3a) && (0x31 < uVar15)) && (uVar15 < 0x6b))
{
if (*puVar4 != '\0')
{
*pcVar5 = '\0'; //This is for channel 1 disable
display_channel1_menu();
FUN_80002790();
pcVar5[3] = '\0';
FUN_8000689c();
tp_i2c_read_status();
cVar1 = *puVar4;
while (cVar1 != '\0') {
tp_i2c_read_status();
cVar1 = *puVar4;
}
}
}
else {
if (((uVar16 < 0x3b) && (0x6f < uVar15)) && (uVar15 < 0xa9)) {
if (*puVar4 != '\0') {
pcVar5[4] = '\x01';
display_channel1_menu();
tp_i2c_read_status();
cVar1 = *puVar4;
while (cVar1 != '\0') {
tp_i2c_read_status();
cVar1 = *puVar4;
}
}
}
else {
if (((uVar18 < 0x3a) && (0x6f < uVar15)) && (uVar15 < 0xa9)) {
if (*puVar4 != '\0') {
pcVar5[4] = '\0';
display_channel1_menu();
tp_i2c_read_status();
cVar1 = *puVar4;
while (cVar1 != '\0') {
tp_i2c_read_status();
cVar1 = *puVar4;
}
}
}
else {
if (((uVar16 < 0x3b) && (0xad < uVar15)) && (uVar15 < 0xe7)) {
if (*puVar4 != '\0') {
pcVar5[1] = '\0';
FUN_800068d4();
display_channel1_menu();
tp_i2c_read_status();
cVar1 = *puVar4;
while (cVar1 != '\0') {
tp_i2c_read_status();
cVar1 = *puVar4;
}
}
}
else {
if (((uVar18 < 0x3a) && (0xad < uVar15)) && (uVar15 < 0xe7)) {
if (*puVar4 != '\0') {
pcVar5[1] = '\x01';
FUN_800068d4();
display_channel1_menu();
tp_i2c_read_status();
cVar1 = *puVar4;
while (cVar1 != '\0') {
tp_i2c_read_status();
cVar1 = *puVar4;
}
}
}
else {
if (((uVar11 - 0xe6 < 0x22) && (0xeb < uVar15)) && (uVar15 < 0x125)) {
if (*puVar4 != '\0') {
pcVar5[2] = '\0';
display_channel1_menu();
tp_i2c_read_status();
cVar1 = *puVar4;
while (cVar1 != '\0') {
tp_i2c_read_status();
cVar1 = *puVar4;
}
}
}
else {
if (((uVar11 - 0x108 < 0x20) && (0xeb < uVar15)) && (uVar15 < 0x125)) {
if (*puVar4 != '\0') {
pcVar5[2] = '\x01';
display_channel1_menu();
tp_i2c_read_status();
cVar1 = *puVar4;
while (cVar1 != '\0') {
tp_i2c_read_status();
cVar1 = *puVar4;
}
}
}
else {
if (((uVar11 - 0x129 < 0x20) && (0xeb < uVar15)) &&
((uVar15 < 0x125 && (*puVar4 != '\0')))) {
pcVar5[2] = '\x02';
display_channel1_menu();
tp_i2c_read_status();
cVar1 = *puVar4;
while (cVar1 != '\0') {
tp_i2c_read_status();
cVar1 = *puVar4;
}
}
}
}
}
}
}
}
}
}
goto LAB_8001dc04;
}
}
} while (*puVar4 == '\0');
FUN_8000a6c0(); //Copy saved screen rect back to the screen
tp_i2c_read_status();
cVar1 = *puVar4;
while (cVar1 != '\0') {
tp_i2c_read_status();
cVar1 = *puVar4;
}
//Stay in the menu as long as there is no touch outside the menu
while(1)
{
//Scan the touch panel for touch
tp_i2c_read_status();
//Check if there is touch
if(havetouch)
{
//Check if touch within the menu field
if((xtouch >= 161) && (xtouch <= 344) && (ytouch >= 46) && (ytouch <= 298))
{
//Check on channel enable or disable
if((ytouch >= 62) && (ytouch <= 84))
{
//Check on enable
if((xtouch >= 239) && (xtouch <= 271))
{
//Enable the channel
scopesettings.channel1.enable = 1;
//Display this
display_channel1_enable_select();
display_channel1_settings(0);
}
//Check on disable
else if((xtouch >= 291) && (xtouch <= 323))
{
//Disable the channel
scopesettings.channel1.enable = 0;
//Display this
display_channel1_enable_select();
display_channel1_settings(0);
}
}
//Check on fft enable or disable
else if((ytouch >= 124) && (ytouch <= 146))
{
//Check on enable
if((xtouch >= 239) && (xtouch <= 271))
{
//Enable the channel
scopesettings.channel1.fftenable = 1;
//Display this
display_channel1_fft_show();
}
//Check on disable
else if((xtouch >= 291) && (xtouch <= 323))
{
//Disable the channel
scopesettings.channel1.fftenable = 0;
//Display this
display_channel1_fft_show();
}
}
//Check on coupling DC or AD
else if((ytouch >= 188) && (ytouch <= 210))
{
//Check on enable
if((xtouch >= 239) && (xtouch <= 271))
{
//Enable the channel
scopesettings.channel1.coupling = 0;
//Display this
display_channel1_coupling_select();
display_channel1_settings(0);
}
//Check on disable
else if((xtouch >= 291) && (xtouch <= 323))
{
//Disable the channel
scopesettings.channel1.coupling = 1;
//Display this
display_channel1_coupling_select();
display_channel1_settings(0);
}
}
//Check on probe magnification setting
else if((ytouch >= 245) && (ytouch <= 283))
{
//Check on 1x
if((xtouch >= 239) && (xtouch <= 259))
{
//Enable the channel
scopesettings.channel1.magnification = 0;
//Display this
display_channel1_probe_magnification_select();
display_channel1_settings(0);
}
//Check on 10x
else if((xtouch >= 270) && (xtouch <= 293))
{
//Disable the channel
scopesettings.channel1.magnification = 1;
//Display this
display_channel1_probe_magnification_select();
display_channel1_settings(0);
}
//Check on 100x
else if((xtouch >= 299) && (xtouch <= 329))
{
//Disable the channel
scopesettings.channel1.magnification = 2;
//Display this
display_channel1_probe_magnification_select();
display_channel1_settings(0);
}
}
//Wait until touch is released before checking on a new position
while(havetouch)
{
//Scan the touch panel for touch
tp_i2c_read_status();
}
}
else
{
//Touch outside the menu so quit
return;
}
}
}
So it looks like that at startup the channels are either enabled or disabled in the FPGA. Now comes the strange thing. In the menu function for setting the channel enabled of disabled this FPGA function is not called |O
The only other location where these functions are called from, according to Ghidra, is the "check_hardware" function, and that one is bypassed by a setting in the flash memory.
So could it be that these FPGA commands do nothing?
So it looks like that at startup the channels are either enabled or disabled in the FPGA. Now comes the strange thing. In the menu function for setting the channel enabled of disabled this FPGA function is not called |O
The only other location where these functions are called from, according to Ghidra, is the "check_hardware" function, and that one is bypassed by a setting in the flash memory.
So could it be that these FPGA commands do nothing?
Maybe useful info for you:
// On my scopes touch has some blind column, and I ordered a new one, and again a new one (because the first was small).//
When I tried replace with the 1. new touch, I set the 2nd Channel to ON. (here is blind the original touch).
After I connect back the original touch panel, the 2nd channel was OFF again.
My trick was not working. :-(
I sadly put the scope back in its box.
(I hope the 2. touch will arrive on next week)
How the hell are you emulating it?
Does !emu support the f1c100s hardware?
sunxi-fel -p uboot u-boot-sunxi-with-spl.bin write 0x80500000 zImage write 0x81500000 devicetree.dtb write 0x81800000 rootfs.cpio.uboot
sunxi-fel spl u-boot-sunxi-with-spl.bin write 0x80000000 my_code.bin exe 0x80000000
sudo ./sunxi-fel -p spl u-boot-sunxi-with-spl.bin write 0x80000000 fnirsi_1013d_scope_nh.bin exe 0x80000000
As far as I know the spl thing executes nothing. So it's probably something in the code or linker settings...
I doubt it could possibly run Linux later than 1.0. But it would work really well with Mecrisp Stellaris. The thing that forth excels at is bringing up new or unknown hardware. You can test what things do interactively as you figure out what to do from documentation or FW dumps.
I am not a Linux guy. I'm a Unix guy. But Linux is close enough. If it needs doing, I can do it.
FWIW My Hantek 2D42 uses an STM32F103. Imagine what it could do with a '303 part.
BTW I'd relly appreciate a link to a summary of components and measurements of 1013D performance. I've started reading the thread going back to the start, but it's pretty long.
Have Fun!
Reg
I know. But the flash has a specific header (eGON) for the bootloader to recognize it. I'd try compiling a simple program that blinks a led or something, and work on that.
If it's small enough you could run it from the sram, I don't remember the address right now.
I don't know either, but also I don't feel it's worth the effort on these devices, specially when talking about linux.
set_display_fg_color(DAT_80010f04); //0x00008800 Dark green (my comment)
DAT_80010f04 XREF[1]: display_sys_menu_always_trigger_
80010f04 88 88 88 00 undefined4 00888888h
Take a look at the pictures and see if you can spot it :-DD
sudo ./sunxi-fel -p spl fnirsi_1013d_startup_with_fel.binsudo ./sunxi-fel -p write 0x7FFFFFE0 fnirsi_1013d_scope.bin exe 0x80000000sudo dd if=fnirsi_1013d_startup_with_fel.bin of=/dev/sdc bs=1024 seek=8
**************************************************************
* FUNCTION *
**************************************************************
void __stdcall display_slide_down_main_menu(void)
void <VOID> <RETURN>
undefined4 Stack[-0x14]:4 local_14 XREF[1]: 8000e7dc(*)
undefined4 Stack[-0x28]:4 local_28 XREF[1]: 8000e7d8(*)
display_slide_down_main_menu XREF[1]: setup_main_menu:8002916c(c)
8000e6f8 00 5e 2d e9 stmdb sp!,{r9 r10 r11 r12 lr}
8000e6fc f0 01 2d e9 stmdb sp!,{r4 r5 r6 r7 r8}
8000e700 dc 00 9f e5 ldr r0,[DAT_8000e7e4] = 001B1B1Bh
8000e704 ea 52 00 eb bl convert_color ushort convert_color(uint color)
8000e708 00 40 a0 e1 mov r4,r0
8000e70c 00 00 a0 e3 mov r0,#0x0
8000e710 e7 52 00 eb bl convert_color ushort convert_color(uint color)
8000e714 cc 60 9f e5 ldr r6,[PTR_DAT_8000e7e8] = 80192ef8
8000e718 00 50 a0 e1 mov r5,r0
8000e71c 02 20 a0 e3 mov r2,#0x2
8000e720 2e 00 a0 e3 mov r0,#0x2e
8000e724 b0 20 c6 e1 strh r2,[r6,#0x0]=>DAT_80192ef8 = 0154h
8000e728 97 10 a0 e3 mov r1,#0x97
8000e72c b2 00 c6 e1 strh r0,[r6,#0x2]=>DAT_80192efa = 0914h
8000e730 b4 10 c6 e1 strh r1,[r6,#0x4]=>DAT_80192efc = 6828h
8000e734 b6 00 c6 e1 strh r0,[r6,#0x6]=>DAT_80192efe = 1409h
8000e738 0e 24 00 eb bl set_screen_to_global_pointer void set_screen_to_global_pointe
8000e73c a8 a0 9f e5 ldr r10,[->BITMAP_MAIN_MENU] = 800ac420
8000e740 a8 b0 9f e5 ldr r11,[Global_Frame_Buffer_Pointer] = 8019CF60h
8000e744 eb 00 a0 e3 mov r0,#0xeb
LAB_8000e748 XREF[1]: 8000e7d4(j)
8000e748 eb 00 50 e3 cmp r0,#0xeb
8000e74c 00 30 a0 e1 mov r3,r0
8000e750 19 00 00 2a bcs LAB_8000e7bc
LAB_8000e754 XREF[1]: 8000e7b8(j)
8000e754 b2 c0 d6 e1 ldrh r12,[r6,#0x2]=>DAT_80192efa = 0914h
8000e758 00 20 43 e0 sub r2,r3,r0
8000e75c b0 70 d6 e1 ldrh r7,[r6,#0x0]=>DAT_80192ef8 = 0154h
8000e760 02 c0 8c e0 add r12,r12,r2
8000e764 95 10 a0 e3 mov r1,#0x95
8000e768 93 01 01 e0 mul r1,r3,r1
8000e76c 8c 91 8c e0 add r9,r12,r12, lsl #0x3
8000e770 00 80 9b e5 ldr r8,[r11,#0x0]=>DAT_8019cf60
8000e774 0c c2 89 e0 add r12,r9,r12, lsl #0x4
8000e778 8c c2 87 e0 add r12,r7,r12, lsl #0x5
8000e77c 95 20 a0 e3 mov r2,#0x95
8000e780 81 10 8a e0 add r1,r10,r1, lsl #0x1
8000e784 8c 70 88 e0 add r7,r8,r12, lsl #0x1
LAB_8000e788 XREF[1]: 8000e7a8(j)
8000e788 b2 c0 d1 e0 ldrh r12,[r1],#0x2=>TEXT_BITMAP_CALIB_START
8000e78c 00 00 5c e3 cmp r12,#0x0
8000e790 04 c0 a0 01 moveq r12,r4
8000e794 01 00 00 0a beq LAB_8000e7a0
8000e798 3e 0b 5c e3 cmp r12,#0xf800
8000e79c 05 c0 a0 01 moveq r12,r5
LAB_8000e7a0 XREF[1]: 8000e794(j)
8000e7a0 01 20 52 e2 subs r2,r2,#0x1
8000e7a4 b2 c0 c7 e0 strh r12,[r7],#0x2
8000e7a8 f6 ff ff 1a bne LAB_8000e788
8000e7ac 01 10 83 e2 add r1,r3,#0x1
8000e7b0 01 38 c1 e3 bic r3,r1,#0x10000
8000e7b4 eb 00 53 e3 cmp r3,#0xeb
8000e7b8 e5 ff ff 3a bcc LAB_8000e754
LAB_8000e7bc XREF[1]: 8000e750(j)
8000e7bc 30 10 9f e5 ldr r1,[DAT_8000e7f4] = 0000E38Fh
8000e7c0 90 01 01 e0 mul r1,r0,r1
8000e7c4 21 0a 40 e0 sub r0,r0,r1, lsr #0x14
8000e7c8 01 00 40 e2 sub r0,r0,#0x1
8000e7cc 00 08 a0 e1 mov r0,r0, lsl #0x10
8000e7d0 20 08 b0 e1 movs r0,r0, lsr #0x10
8000e7d4 db ff ff 1a bne LAB_8000e748
8000e7d8 f0 01 bd e8 ldmia sp!,{r4 r5 r6 r7 r8}=>local_28
8000e7dc 00 5e bd e8 ldmia sp!,{r9 r10 r11 r12 lr}=>local_14
8000e7e0 de 23 00 ea b set_frame_to_global_pointer
**************************************************************
* FUNCTION *
**************************************************************
void __stdcall display_slide_top_rect_onto_screen(ushort
void <VOID> <RETURN>
ushort r0:2 xpos
ushort r1:2 ypos
ushort r2:2 width
ushort r3:2 height
uint Stack[0x0]:4 speed XREF[2]: 80001a94(R),
80001be0(R)
undefined4 Stack[-0x4]:4 local_4 XREF[2]: 80001a54(W),
80001c28(*)
undefined4 Stack[-0xc]:4 local_c XREF[4]: 80001b2c(W),
80001b60(R),
80001b98(R),
80001ba0(W)
undefined4 Stack[-0x10]:4 local_10 XREF[4]: 80001b14(W),
80001b50(R),
80001bb0(R),
80001bb8(W)
undefined2 Stack[-0x12]:2 local_12 XREF[7]: 80001ac4(W),
80001af0(R),
80001b30(R),
80001bd8(R),
80001bdc(R),
80001c0c(W),
80001c10(R)
undefined2 Stack[-0x14]:2 local_14 XREF[4]: 80001b34(W),
80001bbc(R),
80001bc4(W),
80001bc8(R)
undefined2 Stack[-0x16]:2 local_16 XREF[6]: 80001b40(W),
80001b48(R),
80001b58(R),
80001b70(R),
80001b78(W),
80001b7c(R)
undefined4 Stack[-0x1c]:4 local_1c XREF[3]: 80001ae0(W),
80001b04(R),
80001b20(R)
undefined2 Stack[-0x22]:2 local_22 XREF[2]: 80001a74(W),
80001ac8(R)
undefined2 Stack[-0x24]:2 local_24 XREF[2]: 80001a7c(W),
80001acc(R)
undefined2 Stack[-0x26]:2 local_26 XREF[2]: 80001a84(W),
80001b80(R)
undefined2 Stack[-0x28]:2 local_28 XREF[4]: 80001a8c(W),
80001a90(R),
80001aa8(R),
80001bcc(R)
display_slide_top_rect_onto_screen XREF[4]: FUN_80005ae0:80005bac(c),
FUN_80005f40:8000608c(c),
FUN_8000667c:800067c8(c),
FUN_80006de8:80006f00(c)
80001a54 04 b0 2d e5 str r11,[sp,#local_4]!
80001a58 00 b0 8d e2 add r11,sp,#0x0
80001a5c 24 d0 4d e2 sub sp,sp,#0x24
80001a60 00 c0 a0 e1 mov r12,xpos
80001a64 01 00 a0 e1 mov xpos,ypos
80001a68 02 10 a0 e1 mov ypos,width
80001a6c 03 20 a0 e1 mov width,height
80001a70 0c 30 a0 e1 mov height,r12
80001a74 be 31 4b e1 strh height,[r11,#local_22]
80001a78 00 30 a0 e1 mov height,xpos
80001a7c b0 32 4b e1 strh height,[r11,#local_24]
80001a80 01 30 a0 e1 mov height,ypos
80001a84 b2 32 4b e1 strh height,[r11,#local_26]
80001a88 02 30 a0 e1 mov height,width
80001a8c b4 32 4b e1 strh height,[r11,#local_28]
80001a90 b4 32 5b e1 ldrh height,[r11,#local_28]
80001a94 04 20 9b e5 ldr width,[r11,#speed]
80001a98 92 03 03 e0 mul height,width,height
80001a9c 23 3a a0 e1 mov height,height, lsr #0x14
80001aa0 03 38 a0 e1 mov height,height, lsl #0x10
80001aa4 23 38 a0 e1 mov height,height, lsr #0x10
80001aa8 b4 22 5b e1 ldrh width,[r11,#local_28]
80001aac 03 30 42 e0 sub height,width,height
80001ab0 03 38 a0 e1 mov height,height, lsl #0x10
80001ab4 23 38 a0 e1 mov height,height, lsr #0x10
80001ab8 01 30 43 e2 sub height,height,#0x1
80001abc 03 38 a0 e1 mov height,height, lsl #0x10
80001ac0 23 38 a0 e1 mov height,height, lsr #0x10
80001ac4 be 30 4b e1 strh height,[r11,#local_12]
80001ac8 be 21 5b e1 ldrh width,[r11,#local_22]
80001acc b0 32 5b e1 ldrh height,[r11,#local_24]
80001ad0 58 11 9f e5 ldr ypos,[DAT_80001c30] = 80012208h
80001ad4 b0 12 d1 e1 ldrh ypos,[ypos,#0x20]=>DAT_80012228
80001ad8 91 03 03 e0 mul height,ypos,height
80001adc 03 30 82 e0 add height,width,height
80001ae0 18 30 0b e5 str height,[r11,#local_1c]
80001ae4 49 00 00 ea b LAB_80001c10
LAB_80001ae8 XREF[1]: 80001c18(j)
80001ae8 40 31 9f e5 ldr height,[DAT_80001c30] = 80012208h
80001aec 0c 20 93 e5 ldr width,[height,#0xc]=>DAT_80012214
80001af0 fe 30 5b e1 ldrsh height,[r11,#local_12]
80001af4 34 11 9f e5 ldr ypos,[DAT_80001c30] = 80012208h
80001af8 b0 12 d1 e1 ldrh ypos,[ypos,#0x20]=>DAT_80012228
80001afc 91 03 03 e0 mul height,ypos,height
80001b00 03 10 a0 e1 mov ypos,height
80001b04 18 30 1b e5 ldr height,[r11,#local_1c]
80001b08 03 30 81 e0 add height,ypos,height
80001b0c 83 30 a0 e1 mov height,height, lsl #0x1
80001b10 03 30 82 e0 add height,width,height
80001b14 0c 30 0b e5 str height,[r11,#local_10]
80001b18 10 31 9f e5 ldr height,[DAT_80001c30] = 80012208h
80001b1c 08 20 93 e5 ldr width,[height,#0x8]=>DAT_80012210
80001b20 18 30 1b e5 ldr height,[r11,#local_1c]
80001b24 83 30 a0 e1 mov height,height, lsl #0x1
80001b28 03 30 82 e0 add height,width,height
80001b2c 08 30 0b e5 str height,[r11,#local_c]
80001b30 be 30 5b e1 ldrh height,[r11,#local_12]
80001b34 b0 31 4b e1 strh height,[r11,#local_14]
80001b38 22 00 00 ea b LAB_80001bc8
LAB_80001b3c XREF[1]: 80001bd4(j)
80001b3c 00 30 a0 e3 mov height,#0x0
80001b40 b2 31 4b e1 strh height,[r11,#local_16]
80001b44 0c 00 00 ea b LAB_80001b7c
LAB_80001b48 XREF[1]: 80001b88(j)
80001b48 b2 31 5b e1 ldrh height,[r11,#local_16]
80001b4c 83 30 a0 e1 mov height,height, lsl #0x1
80001b50 0c 20 1b e5 ldr width,[r11,#local_10]
80001b54 03 20 82 e0 add width,width,height
80001b58 b2 31 5b e1 ldrh height,[r11,#local_16]
80001b5c 83 30 a0 e1 mov height,height, lsl #0x1
80001b60 08 10 1b e5 ldr ypos,[r11,#local_c]
80001b64 03 30 81 e0 add height,ypos,height
80001b68 b0 20 d2 e1 ldrh width,[width,#0x0]
80001b6c b0 20 c3 e1 strh width,[height,#0x0]
80001b70 b2 31 5b e1 ldrh height,[r11,#local_16]
80001b74 01 30 83 e2 add height,height,#0x1
80001b78 b2 31 4b e1 strh height,[r11,#local_16]
LAB_80001b7c XREF[1]: 80001b44(j)
80001b7c b2 21 5b e1 ldrh width,[r11,#local_16]
80001b80 b2 32 5b e1 ldrh height,[r11,#local_26]
80001b84 03 00 52 e1 cmp width,height
80001b88 ee ff ff 9a bls LAB_80001b48
80001b8c 9c 30 9f e5 ldr height,[DAT_80001c30] = 80012208h
80001b90 b0 32 d3 e1 ldrh height,[height,#0x20]=>DAT_80012228
80001b94 83 30 a0 e1 mov height,height, lsl #0x1
80001b98 08 20 1b e5 ldr width,[r11,#local_c]
80001b9c 03 30 82 e0 add height,width,height
80001ba0 08 30 0b e5 str height,[r11,#local_c]
80001ba4 84 30 9f e5 ldr height,[DAT_80001c30] = 80012208h
80001ba8 b0 32 d3 e1 ldrh height,[height,#0x20]=>DAT_80012228
80001bac 83 30 a0 e1 mov height,height, lsl #0x1
80001bb0 0c 20 1b e5 ldr width,[r11,#local_10]
80001bb4 03 30 82 e0 add height,width,height
80001bb8 0c 30 0b e5 str height,[r11,#local_10]
80001bbc b0 31 5b e1 ldrh height,[r11,#local_14]
80001bc0 01 30 83 e2 add height,height,#0x1
80001bc4 b0 31 4b e1 strh height,[r11,#local_14]
LAB_80001bc8 XREF[1]: 80001b38(j)
80001bc8 b0 21 5b e1 ldrh width,[r11,#local_14]
80001bcc b4 32 5b e1 ldrh height,[r11,#local_28]
80001bd0 03 00 52 e1 cmp width,height
80001bd4 d8 ff ff 9a bls LAB_80001b3c
80001bd8 be 20 5b e1 ldrh width,[r11,#local_12]
80001bdc fe 30 5b e1 ldrsh height,[r11,#local_12]
80001be0 04 10 9b e5 ldr ypos,[r11,#speed]
80001be4 91 03 03 e0 mul height,ypos,height
80001be8 23 3a a0 e1 mov height,height, lsr #0x14
80001bec 03 38 a0 e1 mov height,height, lsl #0x10
80001bf0 23 38 a0 e1 mov height,height, lsr #0x10
80001bf4 03 30 42 e0 sub height,width,height
80001bf8 03 38 a0 e1 mov height,height, lsl #0x10
80001bfc 23 38 a0 e1 mov height,height, lsr #0x10
80001c00 01 30 43 e2 sub height,height,#0x1
80001c04 03 38 a0 e1 mov height,height, lsl #0x10
80001c08 23 38 a0 e1 mov height,height, lsr #0x10
80001c0c be 30 4b e1 strh height,[r11,#local_12]
LAB_80001c10 XREF[1]: 80001ae4(j)
80001c10 fe 30 5b e1 ldrsh height,[r11,#local_12]
80001c14 00 00 53 e3 cmp height,#0x0
80001c18 b2 ff ff aa bge LAB_80001ae8
80001c1c 00 00 a0 e1 mov xpos,xpos
80001c20 00 00 a0 e1 mov xpos,xpos
80001c24 00 d0 8b e2 add sp,r11,#0x0
80001c28 04 b0 9d e4 ldr r11=>local_4,[sp],#0x4
80001c2c 1e ff 2f e1 bx lr
void display_slide_top_rect_onto_screen(uint16 xpos, uint16 ypos, uint16 width, uint16 height, uint32 speed)
{
uint16 *ptr1, *ptr2;
int16 startline; //Needs to be an int because it has to become negative to stop
uint16 line;
uint32 startxy;
uint16 pixel;
//Starting line of the rectangle to display first
startline = height - ((height * speed) >> 20) - 1;
//Start x,y offset for source and destination calculation
startxy = xpos + (ypos * displaydata.pixelsperline);
//Draw lines as long as is needed to get the whole rectangle on screen
while(startline >= 0)
{
//Source pointer is based on the current line
ptr2 = displaydata.sourcebuffer + startxy + (startline * displaydata.pixelsperline);
//Destination pointer is always the first line
ptr1 = displaydata.screenbuffer + startxy;
//Handle the needed number of lines for this loop
for(line=startline;line<=height;line++)
{
//Copy a single line to the screen buffer
for(pixel=0;pixel<=width;pixel++)
{
//Copy one pixel at a time
ptr1[pixel] = ptr2[pixel];
}
//Point to the next line of pixels in both destination and source
ptr1 += displaydata.pixelsperline;
ptr2 += displaydata.pixelsperline;
}
//Calculate the new starting line
startline = startline - 1 - ((startline * speed) >> 20);
}
}
void display_slide_top_rect_onto_screen(ushort xpos,ushort ypos,ushort width,ushort height,uint speed)
{
int iVar1;
ushort local_16;
ushort local_14;
ushort local_12;
int local_10;
int local_c;
local_12 = (ushort)((((uint)height - (speed * height >> 0x14) & 0xffff) - 1) * 0x10000 >> 0x10);
iVar1 = (uint)xpos + (uint)*(ushort *)(DAT_80001c30 + 0x20) * (uint)ypos;
while (-1 < (short)local_12)
{
local_10 = *(int *)(DAT_80001c30 + 0xc) + ((uint)*(ushort *)(DAT_80001c30 + 0x20) * (int)(short)local_12 + iVar1) * 2;
local_c = *(int *)(DAT_80001c30 + 8) + iVar1 * 2;
local_14 = local_12;
while (local_14 <= height)
{
local_16 = 0;
while (local_16 <= width)
{
*(undefined2 *)(local_c + (uint)local_16 * 2) = *(undefined2 *)(local_10 + (uint)local_16 * 2);
local_16 = local_16 + 1;
}
local_c = local_c + (uint)*(ushort *)(DAT_80001c30 + 0x20) * 2;
local_10 = local_10 + (uint)*(ushort *)(DAT_80001c30 + 0x20) * 2;
local_14 = local_14 + 1;
}
local_12 = (ushort)((((uint)local_12 - (speed * (int)(short)local_12 >> 0x14) & 0xffff) - 1) * 0x10000 >> 0x10);
}
}
void display_slide_top_rect_onto_screen(uint32 xpos, uint32 ypos, uint32 width, uint32 height, uint32 speed)
{
register uint16 *ptr1, *ptr2;
register int32 startline; //Needs to be an int because it has to become negative to stop
register uint32 line;
register uint32 startxy;
register uint32 pixel;
register uint32 pixels = displaydata.pixelsperline;
//Starting line of the rectangle to display first
startline = height - ((height * speed) >> 20) - 1;
//Start x,y offset for source and destination calculation
startxy = xpos + (ypos * displaydata.pixelsperline);
//Draw lines as long as is needed to get the whole rectangle on screen
while(startline >= 0)
{
//Source pointer is based on the current line
ptr2 = displaydata.sourcebuffer + startxy + (startline * pixels);
//Destination pointer is always the first line
ptr1 = displaydata.screenbuffer + startxy;
//Handle the needed number of lines for this loop
for(line=startline;line<=height;line++)
{
//Copy a single line to the screen buffer
for(pixel=0;pixel<=width;pixel++)
{
//Copy one pixel at a time
ptr1[pixel] = ptr2[pixel];
}
//Point to the next line of pixels in both destination and source
ptr1 += pixels;
ptr2 += pixels;
}
//Calculate the new starting line
startline = startline - 1 - ((startline * speed) >> 20);
}
}
**************************************************************
* FUNCTION *
**************************************************************
void __stdcall display_slide_top_rect_onto_screen(ushort
void <VOID> <RETURN>
ushort r0:2 xpos
ushort r1:2 ypos
ushort r2:2 width
ushort r3:2 height
uint Stack[0x0]:4 speed XREF[2]: 80001a80(R),
80001b48(R)
undefined4 Stack[-0x20]:4 local_20 XREF[1]: 80001b74(*)
undefined4 Stack[-0x24]:4 local_24 XREF[2]: 80001a60(W),
80001ab0(R)
undefined4 Stack[-0x28]:4 local_28 XREF[2]: 80001a64(W),
80001aa8(R)
undefined4 Stack[-0x2c]:4 local_2c XREF[2]: 80001a68(W),
80001b14(R)
undefined4 Stack[-0x30]:4 local_30 XREF[4]: 80001a6c(W),
80001a7c(R),
80001a8c(R),
80001b34(R)
display_slide_top_rect_onto_screen XREF[4]: FUN_80005a2c:80005af8(c),
FUN_80005e8c:80005fd8(c),
FUN_800065c8:80006714(c),
FUN_80006d34:80006e4c(c)
80001a54 f0 0f 2d e9 stmdb sp!,{r4 r5 r6 r7 r8 r9 r10 r11}
80001a58 1c b0 8d e2 add r11,sp,#0x1c
80001a5c 10 d0 4d e2 sub sp,sp,#0x10
80001a60 20 00 0b e5 str xpos,[r11,#local_24]
80001a64 24 10 0b e5 str ypos,[r11,#local_28]
80001a68 28 20 0b e5 str width,[r11,#local_2c]
80001a6c 2c 30 0b e5 str height,[r11,#local_30]
80001a70 04 31 9f e5 ldr height,[PTR_DAT_80001b7c] = 80012154
80001a74 b0 32 d3 e1 ldrh height,[height,#0x20]=>DAT_80012174
80001a78 03 70 a0 e1 mov r7,height
80001a7c 2c 30 1b e5 ldr height,[r11,#local_30]
80001a80 04 20 9b e5 ldr width,[r11,#speed]
80001a84 92 03 03 e0 mul height,width,height
80001a88 23 3a a0 e1 mov height,height, lsr #0x14
80001a8c 2c 20 1b e5 ldr width,[r11,#local_30]
80001a90 03 30 42 e0 sub height,width,height
80001a94 01 30 43 e2 sub height,height,#0x1
80001a98 03 a0 a0 e1 mov r10,height
80001a9c d8 30 9f e5 ldr height,[PTR_DAT_80001b7c] = 80012154
80001aa0 b0 32 d3 e1 ldrh height,[height,#0x20]=>DAT_80012174
80001aa4 03 20 a0 e1 mov width,height
80001aa8 24 30 1b e5 ldr height,[r11,#local_28]
80001aac 93 02 02 e0 mul width,height,width
80001ab0 20 30 1b e5 ldr height,[r11,#local_24]
80001ab4 03 90 82 e0 add r9,width,height
80001ab8 28 00 00 ea b LAB_80001b60
LAB_80001abc XREF[1]: 80001b64(j)
80001abc b8 30 9f e5 ldr height,[PTR_DAT_80001b7c] = 80012154
80001ac0 0c 20 93 e5 ldr width,[height,#0xc]=>DAT_80012160
80001ac4 0a 30 a0 e1 mov height,r10
80001ac8 97 03 03 e0 mul height,r7,height
80001acc 03 30 89 e0 add height,r9,height
80001ad0 83 30 a0 e1 mov height,height, lsl #0x1
80001ad4 03 60 82 e0 add r6,width,height
80001ad8 9c 30 9f e5 ldr height,[PTR_DAT_80001b7c] = 80012154
80001adc 08 20 93 e5 ldr width,[height,#0x8]=>DAT_8001215c
80001ae0 89 30 a0 e1 mov height,r9, lsl #0x1
80001ae4 03 50 82 e0 add r5,width,height
80001ae8 0a 80 a0 e1 mov r8,r10
80001aec 10 00 00 ea b LAB_80001b34
LAB_80001af0 XREF[1]: 80001b3c(j)
80001af0 00 40 a0 e3 mov r4,#0x0
80001af4 06 00 00 ea b LAB_80001b14
LAB_80001af8 XREF[1]: 80001b1c(j)
80001af8 84 30 a0 e1 mov height,r4, lsl #0x1
80001afc 03 20 86 e0 add width,r6,height
80001b00 84 30 a0 e1 mov height,r4, lsl #0x1
80001b04 03 30 85 e0 add height,r5,height
80001b08 b0 20 d2 e1 ldrh width,[width,#0x0]
80001b0c b0 20 c3 e1 strh width,[height,#0x0]
80001b10 01 40 84 e2 add r4,r4,#0x1
LAB_80001b14 XREF[1]: 80001af4(j)
80001b14 28 30 1b e5 ldr height,[r11,#local_2c]
80001b18 03 00 54 e1 cmp r4,height
80001b1c f5 ff ff 9a bls LAB_80001af8
80001b20 87 30 a0 e1 mov height,r7, lsl #0x1
80001b24 03 50 85 e0 add r5,r5,height
80001b28 87 30 a0 e1 mov height,r7, lsl #0x1
80001b2c 03 60 86 e0 add r6,r6,height
80001b30 01 80 88 e2 add r8,r8,#0x1
LAB_80001b34 XREF[1]: 80001aec(j)
80001b34 2c 30 1b e5 ldr height,[r11,#local_30]
80001b38 03 00 58 e1 cmp r8,height
80001b3c eb ff ff 9a bls LAB_80001af0
80001b40 0a 20 a0 e1 mov width,r10
80001b44 0a 10 a0 e1 mov ypos,r10
80001b48 04 30 9b e5 ldr height,[r11,#speed]
80001b4c 91 03 03 e0 mul height,ypos,height
80001b50 23 3a a0 e1 mov height,height, lsr #0x14
80001b54 03 30 42 e0 sub height,width,height
80001b58 01 30 43 e2 sub height,height,#0x1
80001b5c 03 a0 a0 e1 mov r10,height
LAB_80001b60 XREF[1]: 80001ab8(j)
80001b60 00 00 5a e3 cmp r10,#0x0
80001b64 d4 ff ff aa bge LAB_80001abc
80001b68 00 00 a0 e1 mov xpos,xpos
80001b6c 00 00 a0 e1 mov xpos,xpos
80001b70 1c d0 4b e2 sub sp,r11,#0x1c
80001b74 f0 0f bd e8 ldmia sp!,{r4 r5 r6 r7 r8 r9 r10 r11}=>local_20
80001b78 1e ff 2f e1 bx lr
PTR_DAT_80001b7c XREF[4]: display_slide_top_rect_onto_scre
display_slide_top_rect_onto_scre
display_slide_top_rect_onto_scre
display_slide_top_rect_onto_scre
80001b7c 54 21 01 80 addr DAT_80012154
//Copy a single line to the screen buffer
for(pixel=0;pixel<=width;pixel++)
{
//Copy one pixel at a time
ptr1[pixel] = ptr2[pixel];
}
//Copy a single line to the screen buffer
memcpy( ptr1, ptr2, 2*width); // *2 because memcpy works with bytes, and you're copying uint16_t!
// You might need to do this instead:
memcpy((uint8_t*)ptr1, (uint8_t*)ptr2, 2*width);
It's slow because a for/for/for loop drawing one pixel at a time is extremely unefficient!
It's slow because a for/for/for loop drawing one pixel at a time is extremely unefficient!Code: [Select]//Copy a single line to the screen buffer
for(pixel=0;pixel<=width;pixel++)
{
//Copy one pixel at a time
ptr1[pixel] = ptr2[pixel];
}
Instead, try something like:Code: [Select]//Copy a single line to the screen buffer
memcpy(ptr1[pixel], ptr2[pixel], 2*width); // *2 because memcpy works with bytes, and you're copying uint16_t!
Damn, I corrected the code too late, you had already quoted me! :-DD
It's slow because a for/for/for loop drawing one pixel at a time is extremely unefficient!
I usually compile with O2. The speed increase is noticeable.
Why does the optimization break the touchscreen?
LAB_8000a4f8 XREF[1]: 8000a4a0(j)
8000a4f8 48 00 9f e5 ldr r0,[DAT_8000a548] = 80360BA8h
8000a4fc fa 1f a0 e3 mov r1,#0x3e8
8000a500 dc d8 ff eb bl memclear void memclear(uint address, uint
8000a504 3c 10 9f e5 ldr r1,[DAT_8000a548] = 80360BA8h
8000a508 fa 2f a0 e3 mov r2,#0x3e8
8000a50c 27 0a a0 e3 mov r0,#0x27000 Start address of program in flash
8000a510 24 6b 00 eb bl write_to_flash void write_to_flash(uint address
8000a514 16 77 00 eb bl sys_init_watchdog void sys_init_watchdog(void)
8000a518 a3 df 8d e2 add sp,sp,#0x28c
8000a51c f0 01 bd e8 ldmia sp!,{r4 r5 r6 r7 r8}=>local_24
8000a520 00 8e bd e8 ldmia sp!,{r9 r10 r11 pc}
Guess I will skip this one.
Guess I will skip this one.
Don't agree. You promised a full reversal! :-DD
When I was on approximately 20th page of this thread I got so excited that I ordered one on ebay.
Now that I got to the page 38 I'm not sure anymore that this was wise decision. :P
I just hope that you (and community) will be able to fix many hidden shortcomings of this scope. Today I have received it and It's an older model with protruding BNCs but it seems really nice. ;)
//------------------------------------------------------------------------------------------------------------------------------------------------
void scope_pre_process_50ns_data(uint16 *buffer,uint offset,uint count)
{
uint uVar1;
ushort uVar2;
longlong lVar3;
longlong lVar4;
int iVar5;
ushort *puVar6;
uint16 *puVar7;
undefined2 *puVar8;
uint uVar9;
uint16 *puVar10;
ushort *puVar11;
undefined2 *puVar12;
int iVar13;
int iVar14;
uint uVar15;
ushort uVar16;
uint uVar17;
short sVar18;
short *psVar19;
uVar9 = count * DAT_8001360c; //0x0000CCCD
uVar15 = uVar9 >> 0x13; // count / 10
if (uVar15 != 0)
{
puVar7 = (uint16 *)((int)buffer + offset * 2);
puVar8 = DAT_80013610; //0x801AEF16 ten samples before
puVar10 = (uint16 *)((int)puVar7 + -2);
if ((uVar15 & 1) != 0)
{
puVar8 = DAT_80013610 + 10;
*puVar8 = *(undefined2 *)puVar7;
puVar10 = puVar7;
}
uVar17 = (uVar15 << 0xf) >> 0x10;
while (uVar17 != 0)
{
puVar8[10] = *(undefined2 *)((int)puVar10 + 2);
puVar10 = (uint16 *)((int)puVar10 + 4);
uVar17 = uVar17 - 1 & 0xffff;
puVar8 = puVar8 + 0x14;
*puVar8 = *(undefined2 *)puVar10;
}
}
iVar5 = DAT_80013614; //0x66666667
uVar17 = 0;
if (0 < (int)(uVar15 - 1))
{
do
{
puVar11 = (ushort *)(DAT_80013618 + uVar17 * 0x14); //801AEF2A start of buffer
uVar2 = *puVar11; //sample 1
uVar16 = puVar11[10]; //sample 2
if (uVar2 < uVar16)
{
uVar1 = (uint)(ushort)(uVar16 - uVar2); //Positive delta
iVar13 = 1;
sVar18 = 4;
puVar11 = puVar11 + 1; //sample 2
//one tenth step????
*puVar11 = ((short)(int)((longlong)iVar5 * (longlong)(int)uVar1 >> 0x22) - (short)((longlong)iVar5 * (longlong)(int)uVar1 >> 0x3f)) + uVar2;
do
{
lVar3 = (longlong)iVar5 * (longlong)(int)(uVar1 * (iVar13 + 2)); //3 tenths
lVar4 = (longlong)iVar5 * (longlong)(int)(uVar1 * (iVar13 + 1)); //2 tenths
sVar18 = sVar18 + -1;
puVar11[1] = ((short)(int)(lVar4 >> 0x22) - (short)(lVar4 >> 0x3f)) + uVar2;
iVar13 = iVar13 + 2;
puVar11 = puVar11 + 2;
*puVar11 = ((short)(int)(lVar3 >> 0x22) - (short)(lVar3 >> 0x3f)) + uVar2;
} while (sVar18 != 0);
}
else
{
uVar1 = (uint)(ushort)(uVar2 - uVar16);
iVar13 = 1;
sVar18 = 4;
puVar11 = puVar11 + 1;
*puVar11 = uVar2 - ((short)(int)((longlong)iVar5 * (longlong)(int)uVar1 >> 0x22) - (short)((longlong)iVar5 * (longlong)(int)uVar1 >> 0x3f));
do
{
lVar3 = (longlong)iVar5 * (longlong)(int)(uVar1 * (iVar13 + 2));
lVar4 = (longlong)iVar5 * (longlong)(int)(uVar1 * (iVar13 + 1));
sVar18 = sVar18 + -1;
puVar11[1] = uVar2 - ((short)(int)(lVar4 >> 0x22) - (short)(lVar4 >> 0x3f));
iVar13 = iVar13 + 2;
puVar11 = puVar11 + 2;
*puVar11 = uVar2 - ((short)(int)(lVar3 >> 0x22) - (short)(lVar3 >> 0x3f));
} while (sVar18 != 0);
}
uVar17 = uVar17 + 1 & 0xfffeffff;
} while ((int)uVar17 < (int)(uVar15 - 1));
}
uVar17 = uVar15 - 1;
if (0 < (int)uVar17)
{
puVar8 = DAT_80013620; //0x801B8B60
puVar12 = DAT_8001361c; //0x801AEF20
if ((uVar17 & 1) != 0)
{
puVar12 = DAT_8001361c + 10;
puVar8 = DAT_80013620 + 10;
*puVar8 = *puVar12;
}
uVar17 = uVar17 * 0x8000 >> 0x10; // /2
while (uVar17 != 0)
{
puVar8[10] = puVar12[10];
puVar12 = puVar12 + 0x14;
uVar17 = uVar17 - 1 & 0xffff;
puVar8 = puVar8 + 0x14;
*puVar8 = *puVar12;
}
}
uVar17 = 0;
if (0 < (int)(uVar15 - 2))
{
do
{
iVar13 = DAT_80013624 + uVar17 * 0x14;
uVar2 = *(ushort *)(iVar13 + 10);
uVar16 = *(ushort *)(iVar13 + 0x1e);
if (uVar2 < uVar16)
{
uVar1 = (uint)(ushort)(uVar16 - uVar2);
iVar14 = 1;
sVar18 = 4;
psVar19 = (short *)(iVar13 + 0xc);
*psVar19 = ((short)(int)((longlong)iVar5 * (longlong)(int)uVar1 >> 0x22) - (short)((longlong)iVar5 * (longlong)(int)uVar1 >> 0x3f)) + uVar2;
do
{
lVar3 = (longlong)iVar5 * (longlong)(int)(uVar1 * (iVar14 + 1));
lVar4 = (longlong)iVar5 * (longlong)(int)(uVar1 * (iVar14 + 2));
sVar18 = sVar18 + -1;
psVar19[1] = ((short)(int)(lVar3 >> 0x22) - (short)(lVar3 >> 0x3f)) + uVar2;
iVar14 = iVar14 + 2;
psVar19 = psVar19 + 2;
*psVar19 = ((short)(int)(lVar4 >> 0x22) - (short)(lVar4 >> 0x3f)) + uVar2;
} while (sVar18 != 0);
}
else
{
uVar1 = (uint)(ushort)(uVar2 - uVar16);
iVar14 = 1;
sVar18 = 4;
psVar19 = (short *)(iVar13 + 0xc);
*psVar19 = uVar2 - ((short)(int)((longlong)iVar5 * (longlong)(int)uVar1 >> 0x22) - (short)((longlong)iVar5 * (longlong)(int)uVar1 >> 0x3f));
do
{
lVar3 = (longlong)iVar5 * (longlong)(int)(uVar1 * (iVar14 + 1));
lVar4 = (longlong)iVar5 * (longlong)(int)(uVar1 * (iVar14 + 2));
sVar18 = sVar18 + -1;
psVar19[1] = uVar2 - ((short)(int)(lVar3 >> 0x22) - (short)(lVar3 >> 0x3f));
iVar14 = iVar14 + 2;
psVar19 = psVar19 + 2;
*psVar19 = uVar2 - ((short)(int)(lVar4 >> 0x22) - (short)(lVar4 >> 0x3f));
} while (sVar18 != 0);
}
uVar17 = uVar17 + 1 & 0xfffeffff;
} while ((int)uVar17 < (int)(uVar15 - 2));
}
uVar15 = count >> 1;
if (count != 0)
{
uVar17 = uVar15;
puVar10 = (uint16 *)((int)buffer + -2);
puVar11 = DAT_80013628;
puVar6 = DAT_8001362c;
if ((count & 1) != 0)
{
puVar11 = DAT_80013628 + 1;
puVar6 = DAT_8001362c + 1;
*(short *)buffer = (short)((uint)*puVar11 + (uint)*puVar6 >> 1);
puVar10 = buffer;
}
while (uVar17 != 0)
{
*(short *)((int)puVar10 + 2) = (short)((uint)puVar11[1] + (uint)puVar6[1] >> 1);
*(short *)(uint16 *)((int)puVar10 + 4) = (short)((uint)puVar11[2] + (uint)puVar6[2] >> 1);
uVar17 = uVar17 - 1;
puVar10 = (uint16 *)((int)puVar10 + 4);
puVar11 = puVar11 + 2;
puVar6 = puVar6 + 2;
}
}
uVar9 = uVar9 >> 0x12;
uVar17 = uVar9 - 1;
if (0 < (int)uVar17)
{
puVar12 = (undefined2 *)((int)buffer + -6);
puVar8 = DAT_80013630;
if ((uVar17 & 1) != 0)
{
puVar12 = (undefined2 *)((int)buffer + 4);
puVar8 = DAT_80013630 + 5;
*puVar8 = *puVar12;
}
uVar17 = uVar17 * 0x8000 >> 0x10;
while (uVar17 != 0)
{
puVar8[5] = puVar12[5];
puVar12 = puVar12 + 10;
uVar17 = uVar17 - 1 & 0xffff;
puVar8 = puVar8 + 10;
*puVar8 = *puVar12;
}
}
uVar17 = DAT_80013638;
uVar9 = uVar9 - 2;
if (0 < (int)uVar9)
{
uVar9 = uVar9 & 0xffff;
puVar11 = DAT_80013634;
do
{
uVar2 = *puVar11;
uVar16 = puVar11[5];
if (uVar2 < uVar16)
{
uVar16 = uVar16 - uVar2;
puVar11[1] = uVar2 + (ushort)((uint)uVar16 * DAT_8001360c >> 0x12);
puVar11[2] = (short)(uint)((ulonglong)uVar16 * 2 * (ulonglong)uVar17 >> 0x22) + uVar2;
sVar18 = (short)(uint)((ulonglong)uVar16 * 4 * (ulonglong)uVar17 >> 0x22);
puVar11[3] = (short)(uint)((ulonglong)((uint)uVar16 * 3) * (ulonglong)uVar17 >> 0x22) + uVar2;
}
else
{
uVar16 = uVar2 - uVar16;
puVar11[1] = uVar2 - (ushort)((uint)uVar16 * DAT_8001360c >> 0x12);
puVar11[2] = uVar2 - (short)(uint)((ulonglong)uVar16 * 2 * (ulonglong)uVar17 >> 0x22);
sVar18 = -(short)(uint)((ulonglong)uVar16 * 4 * (ulonglong)uVar17 >> 0x22);
puVar11[3] = uVar2 - (short)(uint)((ulonglong)((uint)uVar16 * 3) * (ulonglong)uVar17 >> 0x22
);
}
puVar11[4] = uVar2 + sVar18;
uVar9 = uVar9 - 1 & 0xffff;
puVar11 = puVar11 + 5;
} while (uVar9 != 0);
}
if (count != 0)
{
puVar10 = (uint16 *)((int)buffer + -2);
puVar11 = DAT_8001362c;
if ((count & 1) != 0)
{
puVar11 = DAT_8001362c + 1;
*(short *)buffer = (short)((uint)*(ushort *)buffer + (uint)*puVar11 >> 1);
puVar10 = buffer;
}
if (uVar15 != 0)
{
do
{
puVar6 = (ushort *)((int)puVar10 + 2);
uVar15 = uVar15 - 1;
puVar10 = (uint16 *)((int)puVar10 + 4);
*puVar6 = (ushort)((uint)*puVar6 + (uint)puVar11[1] >> 1);
puVar11 = puVar11 + 2;
*(ushort *)puVar10 = (ushort)((uint)*puVar11 + (uint)*(ushort *)puVar10 >> 1);
} while (uVar15 != 0);
return;
}
return;
}
return;
}
//------------------------------------------------------------------------------------------------------------------------------------------------
void display_channel1_long_timebase_trace(void)
{
undefined2 *puVar1;
undefined *puVar2;
int iVar3;
uint uVar4;
uint ystart;
uint uVar5;
uint yend;
bool bVar6;
bool bVar7;
set_display_fg_color(DAT_80006890);
puVar2 = PTR_DAT_80006894;
uVar4 = (uint)*(ushort *)PTR_DAT_80006894;
if (uVar4 == 0)
{
puVar1 = (undefined2 *)(PTR_DAT_80006894 + 0x16);
*(undefined2 *)(PTR_DAT_80006894 + 2) = *puVar1;
*(undefined2 *)(puVar2 + 6) = *puVar1;
}
yend = (uint)*(ushort *)(puVar2 + 0x16);
ystart = (uint)*(ushort *)(puVar2 + 2);
uVar5 = yend + 0xf;
bVar7 = ystart <= uVar5;
bVar6 = uVar5 == ystart;
if (bVar7 && !bVar6)
{
uVar5 = ystart + 0xf;
}
if (bVar7 && !bVar6)
{
bVar7 = yend <= uVar5;
bVar6 = uVar5 == yend;
}
if (!bVar7 || bVar6)
{
uVar5 = ystart + 0x14;
bVar7 = uVar5 <= yend;
bVar6 = yend == uVar5;
if (!bVar7 || bVar6)
{
uVar5 = yend + 0x14;
}
if (!bVar7 || bVar6)
{
bVar7 = uVar5 <= ystart;
bVar6 = ystart == uVar5;
}
if (bVar7 && !bVar6)
{
display_draw_line(uVar4 + 3,ystart,uVar4 + 3,yend);
display_draw_line(*(ushort *)puVar2 + 3,*(ushort *)(puVar2 + 2) + 1,*(ushort *)puVar2 + 3,*(ushort *)(puVar2 + 0x16) + 1);
goto LAB_80006828;
}
}
else
{
yend = yend + ystart >> 1;
*(short *)(puVar2 + 0x16) = (short)yend;
}
display_draw_line(uVar4 + 3,ystart,uVar4 + 4,yend);
display_draw_line(*(ushort *)puVar2 + 3,*(ushort *)(puVar2 + 2) + 1,*(ushort *)puVar2 + 4,*(ushort *)(puVar2 + 0x16) + 1);
LAB_80006828:
iVar3 = DAT_80006898;
*(undefined2 *)(puVar2 + 6) = *(undefined2 *)(puVar2 + 2);
*(undefined2 *)(puVar2 + 2) = *(undefined2 *)(puVar2 + 0x16);
*(undefined2 *)(iVar3 + (uint)*(ushort *)puVar2 * 2) = *(undefined2 *)(puVar2 + 0x16);
return;
}
//Check on rise speed of the signal
if(disp_ch1_y < disp_ch1_prev_y)
{
//previous bigger then current so subtract from it to get positive delta
dy = disp_ch1_prev_y - disp_ch1_y;
}
else
{
//current bigger then previous so subtract from it to get positive delta
dy = disp_ch1_y - disp_ch1_prev_y;
}
//Take action based on the delta
if(dy < 15)
{
//Less then 15 apart slow the trace by stopping on the average of the two points
disp_ch1_y = (disp_ch1_y + disp_ch1_prev_y) >> 1;
}
else if(dy > 20)
{
//Else if delta bigger then 20 draw on a single x position
xpos2--;
}
//Draw the lines. When on a single x point it is a bit inefficient. Would be better to only draw one line and make it one longer for the double width
display_draw_line(xpos1, disp_ch1_prev_y, xpos2, disp_ch1_y);
display_draw_line(xpos1, disp_ch1_prev_y + 1, xpos2, disp_ch1_y + 1);
I must say I'm a bit disappointed about the lack of feedback. I really hoped on some input about the up sampling issue :(
In my putzing with this I have come to the conclusion that the HW is *much* better than the SW. With better software I think it would be very usable for HF radio work and low clock rate MCUs. It's also a great test bed for developing DSO touchscreen UIs.
I've been studying the code in msg #950 more and realized I need to know the hardware details, byte sex, ISA, memory map, etc.
Where can I find that info?
Reg
A poll:
How many of the readers of this post want me to move the hacking updates to another thread?
A poll:
How many of the readers of this post want me to move the hacking updates to another thread?
If you do that then what would be left in this thread?
Where did you get the information about the bus width? I tried to find info on the DRAM controller settings, but failed. Used source code from the sunxi factory for it but it does not provide a lot of insight in the working of it all.
312MHz: 29.91s, 273.88MB/s
408MHz: 23.15s, 353.86MB/s
The performance increase is linear, so clearly the bottleneck here is the ram itself.
Being memory copy (read+write), the bandwidth would be 2x those numbers: 548 and 707MB/s
void FUN_80006654(void)
{
uint uVar1;
uint uVar2;
ushort *puVar3;
uint uVar4;
uint uVar5;
ushort *unaff_r4;
ushort *puVar6;
int unaff_r5;
int iVar7;
ushort uVar8;
uint uVar9;
puVar6 = DAT_800067a0; //0x801AC04A sample buffer
uVar8 = *(ushort *)(DAT_80006798 + 0xec); //0x801FA24C channel 1 average
uVar1 = (uint)uVar8; //again average
uVar5 = 0;
if (*(char *)(DAT_8000679c + 3) == '\x06') //0x8019D5A0 channel 1 volt per div
{
uVar2 = 0x23; //Some minimum value???
}
else
{
uVar2 = 0x14; //Less when signal not doubled
}
uVar4 = DAT_800067a4; //0x000009C4 2500 number of samples
if (*(byte *)(DAT_8000679c + 10) < 0x19) //Time base less then 25 (50mS/div - 500nS/div)
{
uVar4 = DAT_800067a8; //000005DC 1500 number of samples
}
//Skip when signal is high enough
if (uVar2 <= *(ushort *)(DAT_80006798 + 0xe8)) //signal peak peak
{
return;
}
//Channel screen offset
// avg + minimum signal needed less then screen offset or screen offset plus minimum signal needed less then avg
//Check if the center of the signal is outside the minimal signal band around the center line
if ((uVar1 + uVar2 < (uint)*(ushort *)(DAT_8000679c + 6)) || (*(ushort *)(DAT_8000679c + 6) + uVar2 < uVar1))
{
//some dc component detection with small signal on it
//Double compensation less then peakpeak
if (uVar2 >> 1 < (uint)*(ushort *)(DAT_80006798 + 0xe8)) //This is nonsense. Only if signal peak peak is less then uVar2 it can get here!!
{
return;
}
if (uVar4 == 0) //What the bullshit here. Is set to a fixed value in the above code!!!!
{
return;
}
//With full compiler optimisation it probably does not make a difference if the loop does only one sample at a time
//Plus with the number of samples set above (1500 or 2500) it will always be even number
puVar3 = DAT_800067a0 + -1; //Point to 1 sample before buffer
if ((uVar4 & 1) != 0) //Odd number of samples to do
{
*DAT_800067a0 = uVar8; //fill the buffer with avg value??
puVar3 = puVar6; //sample buffer
}
uVar4 = uVar4 >> 1; //Half the count
if (uVar4 == 0) //How can it be zero when you set it to 2500 or 1500!!!!!!!!!
{
return;
}
do //Fill the buffer with average value
{
puVar3[1] = uVar8;
uVar4 = uVar4 - 1;
puVar3 = puVar3 + 2;
*puVar3 = uVar8;
} while (uVar4 != 0);
return;
}
iVar7 = DAT_8000679c; //Settings base 0x8019D5A0
if (uVar4 == 0) //Again how can it be zero!!!!
{
puVar6 = unaff_r4; //Some stack stuff restore for return. Ghidra nonsense
iVar7 = unaff_r5;
}
uVar2 = 0; //Init
if (uVar4 == 0) //And again how can it be zero!!!!!!
{
return;
}
do
{
uVar9 = (uint)puVar6[uVar2]; //Sample buffer indexed, so get sample
if (uVar1 <= uVar9 && uVar9 != uVar1) //if average less or equal and it is not equal, so sample above average line or not
{
//above average line
if (uVar5 < 0x15) //starts on zero so first samples are on offset
{
LAB_80006738:
uVar8 = *(ushort *)(iVar7 + 6); //avg var is channel offset
}
else
{
uVar5 = 0; //Reset counter
uVar8 = *(short *)(iVar7 + 6) + 1; //avg var is offset + 1
}
}
else
{
//below average line
if (uVar1 <= uVar9) //Can only be equal since the other if takes the average less then samples
{
uVar8 = *(ushort *)(iVar7 + 6); //avg var is channel offset
uVar5 = uVar5 + 1 & 0xfffeffff;
}
else
{
if ((uVar5 < 0x15) || (uVar5 = 0, *(short *)(iVar7 + 6) == 0)) //The offset can't be zero since it is limitited between 7 and 395 but as safe guard checked on zero before subtract
goto LAB_80006738;
uVar8 = *(short *)(iVar7 + 6) - 1;
}
}
puVar6[uVar2] = uVar8; //overwrite the sample
uVar2 = uVar2 + 1 & 0xfffeffff;
if (uVar4 <= uVar2) //do all the samples
{
return;
}
} while( true );
}
if ((uint)((ulonglong)(uint)*(byte *)(iVar3 + 0xb) * (ulonglong)DAT_8001af94 >> 0x21) * -3 + (uint)*(byte *)(iVar3 + 0xb) == 0)if (((((ulonglong)backup * (ulonglong)0xAAAAAAAB) >> 0x21) * -3) + backup) == 0)if((backup % 3) == 0)Damn, that's almost ofuscated code! :-DD
Here's johnny >:D
int FUN_800337c4(char **param_1,uchar *param_2,uint param_3)
{
if (param_1 == (char **)0x0)
{
return 9;
}
typedef enum
{
FR_INVALID_OBJECT, //(9) The file/directory object is invalid
} FRESULT;
FRESULT f_open (FIL* fp, const TCHAR* path, BYTE mode)
{
if (!fp)
return FR_INVALID_OBJECT;
uint FUN_80033b18(int param_1,int param_2,uint param_3,int *param_4)
{
*param_4 = 0;
uVar1 = FUN_800390e8(param_1,aiStack44);
FRESULT f_read (FIL* fp, void* buff, UINT btr, UINT* br)
{
*br = 0; //Clear read byte counter
res = validate(&fp->obj, &fs); //Check validity of the file object
Think I found the source code used for the file system used in the scope.
The "no no" is probably optimized because the compiler saw that there was a valid pointer when calling the function.
FatFS is widely used in the embedded world, no surprises here :)
uVar7 = (uint)data->data & 0xffffffe0;
while (uVar7 <= ((uint)(data->data + data->blocks * data->blocksize) & 0xffffffe0))
{
coproc_moveto_Invalidate_Data_Cache_by_MVA(uVar7);
coproc_moveto_Invalidate_Instruction_Cache_by_MVA(uVar7);
uVar7 = uVar7 + 0x20;
}
LAB_800370b8
800370b8 3e 0f 07 ee mcr p15,0x0,r0,cr7,cr14,0x1
800370bc 35 0f 07 ee mcr p15,0x0,r0,cr7,cr5,0x1
800370c0 20 00 80 e2 add r0,r0,#0x20
800370c4 01 00 50 e1 cmp r0,r1
800370c8 fa ff ff 9a bls LAB_800370b8
Anyone?
Anyone?
Sorry, can't help. Remember sometimes it's not the app programmers, but the guys that implemented the compiler... :)
They invalidate both the data and the instruction cache for 32 byte blocks. A pointer to where the data resides is send to the co-processor. This pointer is incremented with 32 after every iteration of the loop.I know nothing about this specific processor, but in one of the processors I worked with (STM32H7), you needed to invalidate the cache to ensure that the DMA transferred actual data and not stale data from the memory not yet updated from the cache to actual RAM. More here https://community.st.com/s/article/FAQ-DMA-is-not-working-on-STM32H7-devices
Anyone?
If you're stuck until you get the data, it won't make any difference.
if (cmd->resp_type & MMC_RSP_136)
{
cmd->response[0] = readl(&priv->reg->resp3);
cmd->response[1] = readl(&priv->reg->resp2);
cmd->response[2] = readl(&priv->reg->resp1);
cmd->response[3] = readl(&priv->reg->resp0);
debug("mmc resp 0x%08x 0x%08x 0x%08x 0x%08x\n", cmd->response[3], cmd->response[2], cmd->response[1], cmd->response[0]);
}
else
{
cmd->response[0] = readl(&priv->reg->resp0);
debug("mmc resp 0x%08x\n", cmd->response[0]);
}
//Send some initialization commands until the card is ready?????
do
{
//Send application specific command follows command to the card
command.cmdidx = 55;
command.cmdarg = 0;
command.resp_type = 5;
sd_card_send_command(&command, 0);
//Send host capacity support information command
command.cmdidx = 41;
command.cmdarg = 0x40FF8000; //Need to figure out these settings
command.resp_type = 7;
result = sd_card_send_command(&command, 0);
//0 means still initializing
} while((command.response[3] & 0x80000000) == 0);
cmd->response[0] = puVar6[8];
cmd->response[1] = puVar6[9];
if ((cmd->resp_type & 2) != 0)
{
cmd->response[2] = puVar6[10];
cmd->response[3] = puVar6[11];
}
Hello, is it me you're looking for? 8)
but that probably is to expensive :-DD
if (uVar2 < 0x50)
{
cVar1 = *PTR_DAT_80022bb8; //0x80192f02
while (cVar1 != '\0') //Wait for touch release
{
tp_i2c_read_status();
cVar1 = *puVar3;
}
wait_for_touch_release();
return 1; //Return button touched
}
void wait_for_touch_release(void)
{
undefined *puVar1;
tp_i2c_read_status();
puVar1 = PTR_DAT_8002b120; //0x80192f02
if (*PTR_DAT_8002b120 == '\0') //0 means no touch
{
return;
}
do
{
tp_i2c_read_status();
} while (*puVar1 != '\0'); //not 0 means touch
return;
}
void tp_i2c_wait_for_touch_release(void)
{
//Wait until touch is released
while(havetouch)
{
//Read the touch panel status
tp_i2c_read_status();
}
}
If they opened the code and offered it as a platform similar to some of the phone projects there would be a lot of opportunities as display devices. I would really like a stand alone low frequency FFT analyzer. The current FFT in it is borderline useless. I suspect there are other special cases that do not need extended bandwidth.
/*-----------------------------------------------------------------------*/
/* Read File */
/*-----------------------------------------------------------------------*/
FRESULT f_read (
FIL* fp, /* Open file to be read */
void* buff, /* Data buffer to store the read data */
UINT btr, /* Number of bytes to read */
UINT* br /* Number of bytes read */
)
{
FRESULT res;
FATFS *fs;
DWORD clst;
LBA_t sect;
FSIZE_t remain;
UINT rcnt, cc, csect;
BYTE *rbuff = (BYTE*)buff;
*br = 0; /* Clear read byte counter */
res = validate(&fp->obj, &fs); /* Check validity of the file object */
if (res != FR_OK || (res = (FRESULT)fp->err) != FR_OK) LEAVE_FF(fs, res); /* Check validity */
if (!(fp->flag & FA_READ)) LEAVE_FF(fs, FR_DENIED); /* Check access mode */
remain = fp->obj.objsize - fp->fptr;
if (btr > remain) btr = (UINT)remain; /* Truncate btr by remaining bytes */
for ( ; btr > 0; btr -= rcnt, *br += rcnt, rbuff += rcnt, fp->fptr += rcnt) { /* Repeat until btr bytes read */
if (fp->fptr % SS(fs) == 0) { /* On the sector boundary? */
csect = (UINT)(fp->fptr / SS(fs) & (fs->csize - 1)); /* Sector offset in the cluster */
if (csect == 0) { /* On the cluster boundary? */
if (fp->fptr == 0) { /* On the top of the file? */
clst = fp->obj.sclust; /* Follow cluster chain from the origin */
} else { /* Middle or end of the file */
#if FF_USE_FASTSEEK
if (fp->cltbl) {
clst = clmt_clust(fp, fp->fptr); /* Get cluster# from the CLMT */
} else
#endif
{
clst = get_fat(&fp->obj, fp->clust); /* Follow cluster chain on the FAT */
}
}
if (clst < 2) ABORT(fs, FR_INT_ERR);
if (clst == 0xFFFFFFFF) ABORT(fs, FR_DISK_ERR);
fp->clust = clst; /* Update current cluster */
}
sect = clst2sect(fs, fp->clust); /* Get current sector */
if (sect == 0) ABORT(fs, FR_INT_ERR);
sect += csect;
cc = btr / SS(fs); /* When remaining bytes >= sector size, */
if (cc > 0) { /* Read maximum contiguous sectors directly */
if (csect + cc > fs->csize) { /* Clip at cluster boundary */
cc = fs->csize - csect;
}
if (disk_read(fs->pdrv, rbuff, sect, cc) != RES_OK) ABORT(fs, FR_DISK_ERR);
#if !FF_FS_READONLY && FF_FS_MINIMIZE <= 2 /* Replace one of the read sectors with cached data if it contains a dirty sector */
#if FF_FS_TINY
if (fs->wflag && fs->winsect - sect < cc) {
memcpy(rbuff + ((fs->winsect - sect) * SS(fs)), fs->win, SS(fs));
}
#else
if ((fp->flag & FA_DIRTY) && fp->sect - sect < cc) {
memcpy(rbuff + ((fp->sect - sect) * SS(fs)), fp->buf, SS(fs));
}
#endif
#endif
rcnt = SS(fs) * cc; /* Number of bytes transferred */
continue;
}
#if !FF_FS_TINY
if (fp->sect != sect) { /* Load data sector if not in cache */
#if !FF_FS_READONLY
if (fp->flag & FA_DIRTY) { /* Write-back dirty sector cache */
if (disk_write(fs->pdrv, fp->buf, fp->sect, 1) != RES_OK) ABORT(fs, FR_DISK_ERR);
fp->flag &= (BYTE)~FA_DIRTY;
}
#endif
if (disk_read(fs->pdrv, fp->buf, sect, 1) != RES_OK) ABORT(fs, FR_DISK_ERR); /* Fill sector cache */
}
#endif
fp->sect = sect;
}
rcnt = SS(fs) - (UINT)fp->fptr % SS(fs); /* Number of bytes remains in the sector */
if (rcnt > btr) rcnt = btr; /* Clip it by btr if needed */
#if FF_FS_TINY
if (move_window(fs, fp->sect) != FR_OK) ABORT(fs, FR_DISK_ERR); /* Move sector window */
memcpy(rbuff, fs->win + fp->fptr % SS(fs), rcnt); /* Extract partial sector */
#else
memcpy(rbuff, fp->buf + fp->fptr % SS(fs), rcnt); /* Extract partial sector */
#endif
}
LEAVE_FF(fs, FR_OK);
}
//----------------------------------------------------------------------------------------------------------------------------------
//Read File
//
//Return:
// A FRESULT value
//
//Input:
// Pointer to the file structure
// Buffer to store the read data
// Number of bytes to read
// Pointer to a varialble to return the number of bytes read in
//
//----------------------------------------------------------------------------------------------------------------------------------
FRESULT f_read(FIL* fp, void* buff, UINT btr, UINT* br)
{
FRESULT res;
FATFS *fs;
DWORD clst;
LBA_t sect;
FSIZE_t remain;
UINT rcnt, cc, csect;
BYTE *rbuff = (BYTE*)buff;
//Check if the input parameters are valid
if(!fp || !buff)
return(FR_INVALID_OBJECT);
//Clear read byte counter when given
if(br)
*br = 0;
//Check validity of the file object
res = validate(&fp->obj, &fs);
//Check validity
if(res != FR_OK || (res = (FRESULT)fp->err) != FR_OK)
LEAVE_FF(fs, res);
//Check access mode
if(!(fp->flag & FA_READ))
LEAVE_FF(fs, FR_DENIED);
//Calculate how many bytes are left in the file
remain = fp->obj.objsize - fp->fptr;
//Truncate btr by remaining bytes
if(btr > remain)
btr = (UINT)remain;
//Repeat until btr bytes read
while(btr > 0)
{
//On the sector boundary?
if((fp->fptr % SS(fs)) == 0)
{
//Sector offset in the cluster
csect = (UINT)(fp->fptr / SS(fs) & (fs->csize - 1));
//On the cluster boundary?
if(csect == 0)
{
//On the top of the file?
if(fp->fptr == 0)
{
//Follow cluster chain from the origin
clst = fp->obj.sclust;
}
//Middle or end of the file
else
{
#if FF_USE_FASTSEEK
if(fp->cltbl)
{
//Get cluster# from the CLMT
clst = clmt_clust(fp, fp->fptr);
}
else
#endif
{
//Follow cluster chain on the FAT
clst = get_fat(&fp->obj, fp->clust);
}
}
//cluster in wrong place??
if(clst < 2)
ABORT(fs, FR_INT_ERR);
//Cluster out of range??
if(clst == 0xFFFFFFFF)
ABORT(fs, FR_DISK_ERR);
//Update current cluster
fp->clust = clst;
}
//Get current sector
sect = clst2sect(fs, fp->clust);
//Invalid sector??
if(sect == 0)
ABORT(fs, FR_INT_ERR);
sect += csect;
cc = btr / SS(fs);
//When remaining bytes >= sector size,
if(cc > 0)
{
//Read maximum contiguous sectors directly
//Clip at cluster boundary
if((csect + cc) > fs->csize)
{
cc = fs->csize - csect;
}
if(disk_read(fs->pdrv, rbuff, sect, cc) != RES_OK)
ABORT(fs, FR_DISK_ERR);
#if !FF_FS_READONLY && FF_FS_MINIMIZE <= 2
//Replace one of the read sectors with cached data if it contains a dirty sector
#if FF_FS_TINY
if(fs->wflag && ((fs->winsect - sect) < cc))
{
memcpy((rbuff + ((fs->winsect - sect) * SS(fs))), fs->win, SS(fs));
}
#else
if((fp->flag & FA_DIRTY) && ((fp->sect - sect) < cc))
{
memcpy((rbuff + ((fp->sect - sect) * SS(fs))), fp->buf, SS(fs));
}
#endif
#endif
//Number of bytes transferred
rcnt = SS(fs) * cc;
//Continue after update of counters and pointers. Original code uses for loop and continue
goto read_update;
}
#if !FF_FS_TINY
//Load data sector if not in cache
if(fp->sect != sect)
{
#if !FF_FS_READONLY
if(fp->flag & FA_DIRTY)
{
//Write-back dirty sector cache
if(disk_write(fs->pdrv, fp->buf, fp->sect, 1) != RES_OK)
ABORT(fs, FR_DISK_ERR);
fp->flag &= (BYTE)~FA_DIRTY;
}
#endif
//Fill sector cache
if(disk_read(fs->pdrv, fp->buf, sect, 1) != RES_OK)
ABORT(fs, FR_DISK_ERR);
}
#endif
fp->sect = sect;
}
//Number of bytes remains in the sector
rcnt = SS(fs) - (UINT)fp->fptr % SS(fs);
//Clip it by btr if needed
if(rcnt > btr)
rcnt = btr;
#if FF_FS_TINY
//Move sector window
if(move_window(fs, fp->sect) != FR_OK)
ABORT(fs, FR_DISK_ERR);
//Extract partial sector
memcpy(rbuff, (fs->win + (fp->fptr % SS(fs))), rcnt);
#else
//Extract partial sector
memcpy(rbuff, (fp->buf + (fp->fptr % SS(fs))), rcnt);
#endif
//Update counters and pointers
read_update:
btr -= rcnt;
rbuff += rcnt;
fp->fptr += rcnt;
//Return bytes read, only when variable is given
if(br)
*br += rcnt;
}
LEAVE_FF(fs, FR_OK);
}
//----------------------------------------------------------------------------------------------------------------------------------
//Data is saved as shorts.
*(ushort *)buffer = (ushort)pbVar2[0x3a]; //run mode
*(ushort *)((int)buffer + 2) = (ushort)*pbVar2; //channel 1 enable
*(ushort *)((int)buffer + 4) = (ushort)pbVar2[3]; //volts/div
*(ushort *)((int)buffer + 6) = (ushort)pbVar2[4]; //fft enable
*(ushort *)((int)buffer + 8) = (ushort)pbVar2[1]; //coupling
*(ushort *)((int)buffer + 10) = (ushort)pbVar2[2]; //magnification
*(ushort *)((int)buffer + 0xc) = (ushort)pbVar2[0xc]; //channel 2 enable
*(ushort *)((int)buffer + 0xe) = (ushort)pbVar2[0xf]; //volt/div
*(ushort *)((int)buffer + 0x10) = (ushort)pbVar2[0x10]; //fft enable
*(ushort *)((int)buffer + 0x12) = (ushort)pbVar2[0xd]; //coupling
*(ushort *)((int)buffer + 0x14) = (ushort)pbVar2[0xe]; //magnification
*(ushort *)((int)buffer + 0x16) = (ushort)pbVar2[10]; //time base setting
*(ushort *)((int)buffer + 0x18) = (ushort)pbVar2[0x16]; //move speed
*(ushort *)((int)buffer + 0x1a) = (ushort)pbVar2[0x21]; //trigger mode
*(ushort *)((int)buffer + 0x1c) = (ushort)pbVar2[0x22]; //trigger edge
*(ushort *)((int)buffer + 0x1e) = (ushort)pbVar2[0x23]; //trigger channel
*(ushort *)((int)buffer + 0x20) = (ushort)pbVar2[0x38]; //battery charge level. Is used to display the state of when picture or waveform was taken
*(ushort *)((int)buffer + 0x22) = (ushort)pbVar2[0x42]; //right menu mode
*(ushort *)((int)buffer + 0x24) = (ushort)pbVar2[0x18]; //triggerflag2
*(ushort *)((int)buffer + 0x26) = (ushort)pbVar2[0x17]; //triggerflag1
*(undefined2 *)((int)buffer + 0x28) = *(undefined2 *)(pbVar2 + 0x1a); //disp_x_start.
puVar10 = PTR_DAT_80002024; //0x80192ece
iVar21 = DAT_8000201c; //0x80361378
if (pbVar2[10] < 9) //time base setting. Long time base values 50S - 100mS
{
sVar4 = *(short *)PTR_DAT_80002014 + -1; //0x80192eaa (disp_xpos)
}
else //short time base settings. 50mS - 10nS
{
sVar4 = *(short *)(pbVar2 + 0x1c); //disp_sample_count
}
*(short *)((int)buffer + 0x2a) = sVar4; //time base dependent save of sample count info
iVar25 = DAT_80002020; //0x801FA24C base address of measurement settings
puVar30 = (ushort *)((int)buffer + 0x12e); //index into the buffer
*(undefined2 *)((int)buffer + 0x2c) = *(undefined2 *)PTR_DAT_80002018; //0x80192ec4 State flag for getting start+end in sample buffers???
pbVar15 = (byte *)(iVar25 + -1); //0x801FA24B
sVar4 = 0xc;
*(undefined2 *)((int)buffer + 0x2e) = *(undefined2 *)puVar10; //0x80192ece
*(undefined2 *)((int)buffer + 0x30) = *(undefined2 *)PTR_DAT_80002028; //0x80192ebc
*(undefined2 *)((int)buffer + 0x32) = *(undefined2 *)PTR_DAT_8000202c; //0x80192ebe
*(ushort *)((int)buffer + 0x34) = (ushort)pbVar2[0xb]; //copy of time base settings
*(ushort *)((int)buffer + 0x36) = (ushort)pbVar2[0x43]; //view mode
*(undefined2 *)((int)buffer + 0x50) = *(undefined2 *)(pbVar2 + 0x24); //trigger pos on screen
*(undefined2 *)((int)buffer + 0x52) = *(undefined2 *)(pbVar2 + 0x26); //trigger level screen offset
*(undefined2 *)((int)buffer + 0x54) = *(undefined2 *)(pbVar2 + 6); //channel 1 trace offset
*(undefined2 *)((int)buffer + 0x56) = *(undefined2 *)(pbVar2 + 0x12); //channel 2 trace offset
*(ushort *)((int)buffer + 0x78) = (ushort)*(byte *)(iVar21 + 2); //screen brightness
*(ushort *)((int)buffer + 0x7a) = (ushort)*(byte *)(iVar21 + 3); //grid brightness
*(ushort *)((int)buffer + 0x7c) = (ushort)*(byte *)(iVar21 + 4); //always trigger 50%
*(ushort *)((int)buffer + 0x7e) = (ushort)*(byte *)(iVar21 + 7); //x-y display mode
//measurements enable channel 1
*(ushort *)((int)buffer + 0xa0) = (ushort)*(byte *)(iVar25 + 0x100); //vmax
*(ushort *)((int)buffer + 0xa2) = (ushort)*(byte *)(iVar25 + 0x112); //vmin
*(ushort *)((int)buffer + 0xa4) = (ushort)*(byte *)(iVar25 + 0x122);
*(ushort *)((int)buffer + 0xa6) = (ushort)*(byte *)(iVar25 + 0x132);
*(ushort *)((int)buffer + 0xa8) = (ushort)*(byte *)(iVar25 + 0x142);
*(ushort *)((int)buffer + 0xaa) = (ushort)*(byte *)(iVar25 + 0x152);
*(ushort *)((int)buffer + 0xac) = (ushort)*(byte *)(iVar25 + 0x162);
*(ushort *)((int)buffer + 0xae) = (ushort)*(byte *)(iVar25 + 0x172);
*(ushort *)((int)buffer + 0xb0) = (ushort)*(byte *)(iVar25 + 0x182);
*(ushort *)((int)buffer + 0xb2) = (ushort)*(byte *)(iVar25 + 0x192);
*(ushort *)((int)buffer + 0xb4) = (ushort)*(byte *)(iVar25 + 0x1a2);
*(ushort *)((int)buffer + 0xb6) = (ushort)*(byte *)(iVar25 + 0x1b2); //duty-
//measurements enable channel 2
*(ushort *)((int)buffer + 0xb8) = (ushort)*(byte *)(iVar25 + 0x1c2); //vmax
*(ushort *)((int)buffer + 0xba) = (ushort)*(byte *)(iVar25 + 0x1d2);
*(ushort *)((int)buffer + 0xbc) = (ushort)*(byte *)(iVar25 + 0x1e2);
*(ushort *)((int)buffer + 0xbe) = (ushort)*(byte *)(iVar25 + 0x1f2);
*(ushort *)((int)buffer + 0xc0) = (ushort)*(byte *)(iVar25 + 0x202);
*(ushort *)((int)buffer + 0xc2) = (ushort)*(byte *)(iVar25 + 0x212);
*(ushort *)((int)buffer + 0xc4) = (ushort)*(byte *)(iVar25 + 0x232);
*(ushort *)((int)buffer + 0xc6) = (ushort)*(byte *)(iVar25 + 0x242);
*(ushort *)((int)buffer + 200) = (ushort)*(byte *)(iVar25 + 0x252);
*(ushort *)((int)buffer + 0xca) = (ushort)*(byte *)(iVar25 + 0x262);
*(ushort *)((int)buffer + 0xcc) = (ushort)*(byte *)(iVar25 + 0x272);
*(ushort *)((int)buffer + 0xce) = (ushort)*(byte *)(iVar25 + 0x282); //duty-
//Channel 1 measured values????
*(short *)((int)buffer + 0xd0) = (short)((uint)*(undefined4 *)(iVar25 + 0x104) >> 0x10);
*(short *)((int)buffer + 0xd2) = (short)*(undefined4 *)(iVar25 + 0x104);
*(short *)((int)buffer + 0xd4) = (short)((uint)*(undefined4 *)(iVar25 + 0x114) >> 0x10);
*(short *)((int)buffer + 0xd6) = (short)*(undefined4 *)(iVar25 + 0x114);
*(short *)((int)buffer + 0xd8) = (short)((uint)*(undefined4 *)(iVar25 + 0x124) >> 0x10);
*(short *)((int)buffer + 0xda) = (short)*(undefined4 *)(iVar25 + 0x124);
*(short *)((int)buffer + 0xdc) = (short)((uint)*(undefined4 *)(iVar25 + 0x134) >> 0x10);
*(short *)((int)buffer + 0xde) = (short)*(undefined4 *)(iVar25 + 0x134);
*(short *)((int)buffer + 0xe0) = (short)((uint)*(undefined4 *)(iVar25 + 0x144) >> 0x10);
*(short *)((int)buffer + 0xe2) = (short)*(undefined4 *)(iVar25 + 0x144);
*(short *)((int)buffer + 0xe4) = (short)((uint)*(undefined4 *)(iVar25 + 0x154) >> 0x10);
*(short *)((int)buffer + 0xe6) = (short)*(undefined4 *)(iVar25 + 0x154);
*(short *)((int)buffer + 0xe8) = (short)((uint)*(undefined4 *)(iVar25 + 0x164) >> 0x10);
*(short *)((int)buffer + 0xea) = (short)*(undefined4 *)(iVar25 + 0x164);
*(short *)((int)buffer + 0xec) = (short)((uint)*(undefined4 *)(iVar25 + 0x174) >> 0x10);
*(short *)((int)buffer + 0xee) = (short)*(undefined4 *)(iVar25 + 0x174);
*(short *)((int)buffer + 0xf0) = (short)((uint)*(undefined4 *)(iVar25 + 0x184) >> 0x10);
*(short *)((int)buffer + 0xf2) = (short)*(undefined4 *)(iVar25 + 0x184);
*(short *)((int)buffer + 0xf4) = (short)((uint)*(undefined4 *)(iVar25 + 0x194) >> 0x10);
*(short *)((int)buffer + 0xf6) = (short)*(undefined4 *)(iVar25 + 0x194);
*(short *)((int)buffer + 0xf8) = (short)((uint)*(undefined4 *)(iVar25 + 0x1a4) >> 0x10);
*(short *)((int)buffer + 0xfa) = (short)*(undefined4 *)(iVar25 + 0x1a4);
*(short *)((int)buffer + 0xfc) = (short)((uint)*(undefined4 *)(iVar25 + 0x1b4) >> 0x10);
*(short *)((int)buffer + 0xfe) = (short)*(undefined4 *)(iVar25 + 0x1b4);
//Channel 2 measured values????
*(short *)((int)buffer + 0x100) = (short)((uint)*(undefined4 *)(iVar25 + 0x1c4) >> 0x10);
*(short *)((int)buffer + 0x102) = (short)*(undefined4 *)(iVar25 + 0x1c4);
*(short *)((int)buffer + 0x104) = (short)((uint)*(undefined4 *)(iVar25 + 0x1d4) >> 0x10);
*(short *)((int)buffer + 0x106) = (short)*(undefined4 *)(iVar25 + 0x1d4);
*(short *)((int)buffer + 0x108) = (short)((uint)*(undefined4 *)(iVar25 + 0x1e4) >> 0x10);
*(short *)((int)buffer + 0x10a) = (short)*(undefined4 *)(iVar25 + 0x1e4);
*(short *)((int)buffer + 0x10c) = (short)((uint)*(undefined4 *)(iVar25 + 500) >> 0x10);
*(short *)((int)buffer + 0x10e) = (short)*(undefined4 *)(iVar25 + 500);
*(short *)((int)buffer + 0x110) = (short)((uint)*(undefined4 *)(iVar25 + 0x204) >> 0x10);
*(short *)((int)buffer + 0x112) = (short)*(undefined4 *)(iVar25 + 0x204);
*(short *)((int)buffer + 0x114) = (short)((uint)*(undefined4 *)(iVar25 + 0x214) >> 0x10);
*(short *)((int)buffer + 0x116) = (short)*(undefined4 *)(iVar25 + 0x214);
*(short *)((int)buffer + 0x118) = (short)((uint)*(undefined4 *)(iVar25 + 0x234) >> 0x10);
*(short *)((int)buffer + 0x11a) = (short)*(undefined4 *)(iVar25 + 0x234);
*(short *)((int)buffer + 0x11c) = (short)((uint)*(undefined4 *)(iVar25 + 0x244) >> 0x10);
*(short *)((int)buffer + 0x11e) = (short)*(undefined4 *)(iVar25 + 0x244);
*(short *)((int)buffer + 0x120) = (short)((uint)*(undefined4 *)(iVar25 + 0x254) >> 0x10);
*(short *)((int)buffer + 0x122) = (short)*(undefined4 *)(iVar25 + 0x254);
*(short *)((int)buffer + 0x124) = (short)((uint)*(undefined4 *)(iVar25 + 0x264) >> 0x10);
*(short *)((int)buffer + 0x126) = (short)*(undefined4 *)(iVar25 + 0x264);
*(short *)((int)buffer + 0x128) = (short)((uint)*(undefined4 *)(iVar25 + 0x274) >> 0x10);
*(short *)((int)buffer + 0x12a) = (short)*(undefined4 *)(iVar25 + 0x274);
*(short *)((int)buffer + 300) = (short)((uint)*(undefined4 *)(iVar25 + 0x284) >> 0x10);
*(short *)((int)buffer + 0x12e) = (short)*(undefined4 *)(iVar25 + 0x284);
//Copy 12 * 2 values. This is the list of enabled measurements to show them on the display
do //puVar30 = (ushort *)((int)buffer + 0x12e);
{
sVar4 = sVar4 + -1;
puVar30[1] = (ushort)pbVar15[1]; //Initial pVar15 = //0x801FA24B
pbVar15 = pbVar15 + 2;
puVar30 = puVar30 + 2;
*puVar30 = (ushort)*pbVar15;
} while (sVar4 != 0);
*(ushort *)((int)buffer + 400) = (ushort)pbVar2[0x39]; //charging indicator
*(ushort *)((int)buffer + 0x192) = (ushort)pbVar2[0x38]; //battery charge level
*(undefined2 *)((int)buffer + 0x194) = *(undefined2 *)PTR_DAT_80002030; //0x80192ec6
*(undefined2 *)((int)buffer + 0x196) = *(undefined2 *)PTR_DAT_80002034; //0x80192ec8
Perseverance!
That's what you need for doing something like this :-+And a lot of time, or to be a very smart cat so you have 7 lives for fixing that crappy chinesium thing :-DD
Glad you worked it out. I was going to suggest a corrupt SD card.
I've encountered embedded FAT code (elm-chan maybe) that could read files fine, but will fail to write when there was some corruption.
Obviously there is no embedded chkdsk/fsck type functionality, so you have to run that on a PC to fix things.
Perseverance!
And a lot of time
For others who are thinking of doing something like this be prepared to invest a lot of time.
I would vote for #2... but you could also make it configurable.
So if you made a settings change (I assume it's saved to the sd card) would it generate the same messages?
//Open the new file. On failure signal this and quit
result = f_open(&viewfp, viewfilename, FA_CREATE_NEW | FA_WRITE);
//Check if file opened without problems
if(result == FR_OK)
{
//For pictures the bitmap header needs to be written
if(type == VIEW_TYPE_PICTURE)
{
//Write the bitmap header
result = f_write(&viewfp, bmpheader, sizeof(bmpheader), 0);
}
//Check if still ok to proceed
if(result == FR_OK)
{
//Save the settings for the trace portion of the data and write them to the file
scope_prepare_setup_for_file();
//Write the setup data to the file
if((result = f_write(&viewfp, viewfilesetupdata, sizeof(viewfilesetupdata), 0)) == FR_OK)
{
//Write the trace data to the file
//Save the channel 1 sample data
if((result = f_write(&viewfp, (uint8 *)channel1tracebuffer4, 3000, 0)) == FR_OK)
{
//Save the channel 2 sample data
if((result = f_write(&viewfp, (uint8 *)channel2tracebuffer4, 3000, 0)) == FR_OK)
{
//Save the channel 1 display data
if((result = f_write(&viewfp, (uint8 *)channel1ypoints, 1500, 0)) == FR_OK)
{
//Save the channel 2 display data
if((result = f_write(&viewfp, (uint8 *)channel2ypoints, 1500, 0)) == FR_OK)
{
//Finish with an empty blob of data to reach the needed file size
//Clear part of the thumbnail data for this. Is reloaded anyway so does not matter
memset((uint8 *)viewthumbnaildata, 0, 5000);
//Save it to the file
if((result = f_write(&viewfp, (uint8 *)viewthumbnaildata, 5000, 0)) == FR_OK)
{
//For pictures extra code is needed to write the pixel data to the file
if(type == VIEW_TYPE_PICTURE)
{
//Write the pixel data
result = f_write(&viewfp, (uint8 *)maindisplaybuffer, PICTURE_DATA_SIZE, 0);
}
}
}
}
}
}
}
}
//Close the file
f_close(&viewfp);
//Check if all went well
if(result == FR_OK)
{
//Show the saved successful message
scope_display_file_status_message(MESSAGE_SAVE_SUCCESSFUL);
}
else
{
//Signal unable to write to the file
scope_display_file_status_message(MESSAGE_FILE_WRITE_FAILED);
}
}
else
{
//Signal unable to create the file
scope_display_file_status_message(MESSAGE_FILE_OPEN_FAILED);
}
int disk_write(int pdrv,byte *buff,int sector,uint count)
{
uint *buffer;
int iVar1;
uint unaff_r4;
switch(pdrv)
{
case 0:
if (((uint)buff & 3) == 0) {
iVar1 = sd_card_write(0,sector,count,buff);
if (iVar1 == 0) {
return 0;
}
}
else {
buffer = malloc(count << 9);
if (buffer != NULL) {
memcpy(buffer,buff,count << 9);
iVar1 = sd_card_write(0,sector,count,(byte *)buffer);
free(buffer);
return (uint)(iVar1 != 0);
}
}
unaff_r4 = 1;
break;
case 1:
case 2:
case 3:
case 4:
break;
default:
unaff_r4 = 4;
}
return unaff_r4;
}
int disk_read(int pdrv,byte *buff,int sector,uint count)
{
uint *buffer;
int iVar1;
if (pdrv == 0)
{
if (((uint)buff & 3) == 0)
{
iVar1 = sd_card_read(0,sector,count,buff);
if (iVar1 == 0)
{
return 0;
}
}
else
{
buffer = malloc(count << 9);
if (buffer != NULL)
{
iVar1 = sd_card_read(0,sector,count,(byte *)buffer);
memcpy(buff,buffer,count << 9);
free(buffer);
return (uint)(iVar1 != 0);
}
}
count = 1;
}
return count;
}
:blah: Also seeing through what a compiler did to get to the assembly code is not easy.
uVar4 = DAT_800253b8; //0x38E38E39
puVar7 = DAT_800253c8; //0x801C3748 channel 1 trace on screen buffer channel1ypoints[-1]
lVar1 = (longlong)(int)uVar4 * (longlong)(int)((puVar7[1] - 0x2e) * 10);
*(char *)(iVar2 + dataindex + 0x14 + (iVar6 >> 2)) = ((char)(int)(lVar1 >> 0x23) - (char)(lVar1 >> 0x3f)) + '\x05';
void restore_config_data(uint *address) //0x8035344E
{
undefined2 uVar1;
undefined *puVar2;
int iVar3;
int iVar4;
undefined2 *puVar5;
uint *puVar6;
int iVar7;
undefined *puVar8;
puVar5 = DAT_80027a1c; //0x802F18B0
iVar4 = DAT_80027a18; //0x801FA24C base of measurement settings
iVar3 = DAT_80027a14; //0x80361378 base of settings like screen brightness
puVar2 = DAT_80027a10; //0x8019D5A0 base of scope settings
puVar6 = address + 0x53;
puVar8 = (undefined *)(iVar4 + -1);
iVar7 = 0xc;
// bytes
puVar2[0] = *(undefined *)address; //channel 1 enable 0x8035344E 0
puVar2[3] = *(undefined *)((int)address + 2); // volts/div 0x80353450 1
puVar2[4] = *(undefined *)(address + 1); // fft enable 0x80353452 2
puVar2[1] = *(undefined *)((int)address + 6); // coupling 0x80353454 3
puVar2[2] = *(undefined *)(address + 2); // magnification 0x80353456 4
// bytes
puVar2[0xc] = *(undefined *)((int)address + 10); //channel 2 enable 0x80353458 5
puVar2[0xf] = *(undefined *)(address + 3); // volts/div 0x8035345A 6
puVar2[0x10] = *(undefined *)((int)address + 0xe); // fft enable 0x8035345C 7
puVar2[0xd] = *(undefined *)(address + 4); // coupling 0x8035345E 8
puVar2[0xe] = *(undefined *)((int)address + 0x12); // magnification 0x80353460 9
// byte
puVar2[10] = *(undefined *)(address + 5); //time base 0x80353462 10
// byte
puVar2[0x16] = *(undefined *)((int)address + 0x16); //move speed 0x80353464 11
// bytes
puVar2[0x21] = *(undefined *)(address + 6); //trigger mode 0x80353466 12
puVar2[0x22] = *(undefined *)((int)address + 0x1a); //trigger edge 0x80353468 13
puVar2[0x23] = *(undefined *)(address + 7); //trigger channel 0x8035346A 14
// byte
puVar2[0x42] = *(undefined *)((int)address + 0x1e); //right menu state 0x8035346C 15
// shorts
*(undefined2 *)(puVar2 + 0x24) = *(undefined2 *)(address + 0x14); //0x8035349E trigger position on screen 40
*(undefined2 *)(puVar2 + 0x26) = *(undefined2 *)((int)address + 0x52); //0x803534A0 trigger level screen offset 41
// shorts
*(undefined2 *)(puVar2 + 6) = *(undefined2 *)(address + 0x15); //0x803534A2 channel 1 screen offset 42
*(undefined2 *)(puVar2 + 0x12) = *(undefined2 *)((int)address + 0x56); //0x803534A4 channel 2 screen offset 43
// bytes
*(undefined *)(iVar3 + 2) = *(undefined *)(address + 0x1e); //0x803534C6 screen brightness 60
*(undefined *)(iVar3 + 3) = *(undefined *)((int)address + 0x7a); //0x803534C8 grid brightness 61
*(undefined *)(iVar3 + 4) = *(undefined *)(address + 0x1f); //0x803534CA always 50% trigger 62
*(undefined *)(iVar3 + 7) = *(undefined *)((int)address + 0x7e); //0x803534CC xy display mode 63
//Measurement settings
//Channel 1 enable 12 items bytes
*(undefined *)(iVar4 + 0x100) = *(undefined *)(address + 0x28); //0x803534EE Vmax 80
*(undefined *)(iVar4 + 0x112) = *(undefined *)((int)address + 0xa2); //0x803534F0 Vmin 81
*(undefined *)(iVar4 + 0x122) = *(undefined *)(address + 0x29); //0x803534F2 Vavg 82
*(undefined *)(iVar4 + 0x132) = *(undefined *)((int)address + 0xa6); //0x803534F4 Vrms 83
*(undefined *)(iVar4 + 0x142) = *(undefined *)(address + 0x2a); //0x803534F6 Vpp 84
*(undefined *)(iVar4 + 0x152) = *(undefined *)((int)address + 0xaa); //0x803534F8 Vp 85
*(undefined *)(iVar4 + 0x162) = *(undefined *)(address + 0x2b); //0x803534FA Freq 86
*(undefined *)(iVar4 + 0x172) = *(undefined *)((int)address + 0xae); //0x803534FC Cycle 87
*(undefined *)(iVar4 + 0x182) = *(undefined *)(address + 0x2c); //0x803534FE Tim+ 88
*(undefined *)(iVar4 + 0x192) = *(undefined *)((int)address + 0xb2); //0x80353500 Tim- 89
*(undefined *)(iVar4 + 0x1a2) = *(undefined *)(address + 0x2d); //0x80353502 Duty+ 90
*(undefined *)(iVar4 + 0x1b2) = *(undefined *)((int)address + 0xb6); //0x80353504 Duty- 91
//Channel 2 enable 12 items bytes
*(undefined *)(iVar4 + 0x1c2) = *(undefined *)(address + 0x2e); //0x80353506 Vmax 92
*(undefined *)(iVar4 + 0x1d2) = *(undefined *)((int)address + 0xba); //0x80353508 Vmin 93
*(undefined *)(iVar4 + 0x1e2) = *(undefined *)(address + 0x2f); //0x8035350A Vavg 94
*(undefined *)(iVar4 + 0x1f2) = *(undefined *)((int)address + 0xbe); //0x8035350C Vrms 95
*(undefined *)(iVar4 + 0x202) = *(undefined *)(address + 0x30); //0x8035350E Vpp 96
*(undefined *)(iVar4 + 0x212) = *(undefined *)((int)address + 0xc2); //0x80353510 Vp 97
*(undefined *)(iVar4 + 0x232) = *(undefined *)(address + 0x31); //0x80353512 Freq 98
*(undefined *)(iVar4 + 0x242) = *(undefined *)((int)address + 0xc6); //0x80353514 Cycle 99
*(undefined *)(iVar4 + 0x252) = *(undefined *)(address + 0x32); //0x80353516 Tim+ 100
*(undefined *)(iVar4 + 0x262) = *(undefined *)((int)address + 0xca); //0x80353518 Tim- 101
*(undefined *)(iVar4 + 0x272) = *(undefined *)(address + 0x33); //0x8035351A Duty+ 102
*(undefined *)(iVar4 + 0x282) = *(undefined *)((int)address + 0xce); //0x8035351C Duty- 103
//Channel 1 calibration data shorts
puVar5[0] = *(undefined2 *)(address + 0x3c); //0x802F18B0 = 0x8035353E channel1_calibration_factor 120
puVar5[1] = *(undefined2 *)((int)address + 0xf2); //0x802F18B2 = 0x80353540 channel1_calibration_data[0]
puVar5[2] = *(undefined2 *)(address + 0x3d); //0x802F18B4 = 0x80353542
puVar5[3] = *(undefined2 *)((int)address + 0xf6); //0x802F18B6 = 0x80353544
puVar5[4] = *(undefined2 *)(address + 0x3e); //0x802F18B8 = 0x80353546
puVar5[5] = *(undefined2 *)((int)address + 0xfa); //0x802F18BA = 0x80353548
puVar5[6] = *(undefined2 *)(address + 0x3f); //0x802F18BC = 0x8035354A channel1_calibration_data[5] (needs to be copied into [6]!!)
//Channel 2 calibration data shorts
puVar5[7] = *(undefined2 *)((int)address + 0xfe); //0x802F18BE = 0x8035354C channel2_calibration_factor 127
puVar5[8] = *(undefined2 *)(address + 0x40); //0x802F18C0 = 0x8035354E channel2_calibration_data[0]
puVar5[9] = *(undefined2 *)((int)address + 0x102); //0x802F18C2 = 0x80353550
puVar5[10] = *(undefined2 *)(address + 0x41); //0x802F18C4 = 0x80353552
puVar5[0xb] = *(undefined2 *)((int)address + 0x106); //0x802F18C6 = 0x80353554
puVar5[0xc] = *(undefined2 *)(address + 0x42); //0x802F18C8 = 0x80353556
puVar5[0xd] = *(undefined2 *)((int)address + 0x10a); //0x802F18CA = 0x80353558 channel2_calibration_data[5] 133
//Some other calibration data that still needs to be investigated
// shorts
puVar5[0xe] = *(undefined2 *)(address + 0x43); //0x802F18CC = 0x8035355A 134
puVar5[0xf] = *(undefined2 *)((int)address + 0x10e); //0x802F18CE = 0x8035355C
puVar5[0x10] = *(undefined2 *)(address + 0x44); //0x802F18D0 = 0x8035355E
puVar5[0x11] = *(undefined2 *)((int)address + 0x112); //0x802F18D2 = 0x80353560
// bytes
*(undefined *)(puVar5 + 0x12) = *(undefined *)(address + 0x45); //0x802F18D4 = 0x80353562
*(undefined *)((int)puVar5 + 0x25) = *(undefined *)((int)address + 0x116); //0x802F18D5 = 0x80353564
*(undefined *)(puVar5 + 0x13) = *(undefined *)(address + 0x46); //0x802F18D6 = 0x80353566
*(undefined *)((int)puVar5 + 0x27) = *(undefined *)((int)address + 0x11a); //0x802F18D7 = 0x80353568
*(undefined *)(puVar5 + 0x14) = *(undefined *)(address + 0x47); //0x802F18D8 = 0x8035356A
*(undefined *)((int)puVar5 + 0x29) = *(undefined *)((int)address + 0x11e); //0x802F18D9 = 0x8035356C
// shorts
puVar5[0x15] = *(undefined2 *)(address + 0x48); //0x802F18DA = 0x8035356E
puVar5[0x16] = *(undefined2 *)((int)address + 0x122); //0x802F18DC = 0x80353570
puVar5[0x17] = *(undefined2 *)(address + 0x49); //0x802F18DE = 0x80353572
puVar5[0x18] = *(undefined2 *)((int)address + 0x126); //0x802F18E0 = 0x80353574
puVar5[0x19] = *(undefined2 *)(address + 0x4a); //0x802F18E2 = 0x80353576
puVar5[0x1a] = *(undefined2 *)((int)address + 0x12a); //0x802F18E4 = 0x80353578
// bytes
*(undefined *)(puVar5 + 0x1b) = *(undefined *)(address + 0x4b); //0x802F18E6 = 0x8035357A
*(undefined *)((int)puVar5 + 0x37) = *(undefined *)((int)address + 0x12e); //0x802F18E7 = 0x8035357C
*(undefined *)(puVar5 + 0x1c) = *(undefined *)(address + 0x4c); //0x802F18E8 = 0x8035357E
*(undefined *)((int)puVar5 + 0x39) = *(undefined *)((int)address + 0x132); //0x802F18E9 = 0x80353580
*(undefined *)(puVar5 + 0x1d) = *(undefined *)(address + 0x4d); //0x802F18EA = 0x80353582
*(undefined *)((int)puVar5 + 0x3b) = *(undefined *)((int)address + 0x136); //0x802F18EB = 0x80353584
// shorts
puVar5[0x1e] = *(undefined2 *)(address + 0x4e); //0x802F18EC = 0x80353586
puVar5[0x1f] = *(undefined2 *)((int)address + 0x13a); //0x802F18EE = 0x80353588
puVar5[0x20] = *(undefined2 *)(address + 0x4f); //0x802F18F0 = 0x8035358A
puVar5[0x21] = *(undefined2 *)((int)address + 0x13e); //0x802F18F2 = 0x8035358C
puVar5[0x22] = *(undefined2 *)(address + 0x50); //0x802F18F4 = 0x8035358E
uVar1 = *(undefined2 *)((int)address + 0x142); // 0x80353590
// short
puVar5[0x23] = uVar1; //0x802F18F6 = 0x80353590 time cursor enable??? for what
// byte
*(char *)(iVar4 + 0x292) = (char)uVar1; //0x801FA4DE = 0x80353590 time cursor enable 161
// shorts
*(undefined2 *)(iVar4 + 0x294) = *(undefined2 *)(address + 0x51); //0x801FA4E0 = 0x80353592 time cursor 1 position 162
*(undefined2 *)(iVar4 + 0x296) = *(undefined2 *)((int)address + 0x146); //0x801FA4E2 = 0x80353594 time cursor 2 position 163
// byte
*(undefined *)(iVar4 + 0x29a) = *(undefined *)(address + 0x52); //0x801FA4E6 = 0x80353596 volt cursor enable 164
// shorts
*(undefined2 *)(iVar4 + 0x29c) = *(undefined2 *)((int)address + 0x14a); //0x801FA4E8 = 0x80353598 volt cursor 1 position 165
*(undefined2 *)(iVar4 + 0x29e) = *(undefined2 *)(address + 0x53); //0x801FA4EA = 0x8035359A volt cursor 2 position 166
//12 items times 2
//Load and store bytes
//Source start 0x8035359C
//Destination start 0x801FA24C
//This is the list of enabled measurement items in the order of displaying
do {
iVar7 = iVar7 + -1;
puVar8[1] = *(undefined *)((int)puVar6 + 2);
puVar6 = puVar6 + 1;
puVar8 = puVar8 + 2;
*puVar8 = *(undefined *)puVar6;
} while (iVar7 != 0);
//System OK flag (0x1432) short
*(undefined2 *)(puVar2 + 0x44) = *(undefined2 *)(address + 100); //0x8019D5E4 = 803535DE
return;
}
void scope_restore_config_data(void)
{
uint32 channel;
uint32 index;
uint16 *ptr;
//Restore the channel 1 settings
scopesettings.channel1.enable = settingsworkbuffer[0];
scopesettings.channel1.coupling = settingsworkbuffer[3];
scopesettings.channel1.magnification = settingsworkbuffer[4];
scopesettings.channel1.voltperdiv = settingsworkbuffer[1];
scopesettings.channel1.fftenable = settingsworkbuffer[2];
scopesettings.channel1.traceoffset = settingsworkbuffer[42];
//Restore the channel 2 settings
scopesettings.channel2.enable = settingsworkbuffer[5];
scopesettings.channel2.coupling = settingsworkbuffer[8];
scopesettings.channel2.magnification = settingsworkbuffer[9];
scopesettings.channel2.voltperdiv = settingsworkbuffer[6];
scopesettings.channel2.fftenable = settingsworkbuffer[7];
scopesettings.channel2.traceoffset = settingsworkbuffer[43];
//Restore trigger settings
scopesettings.triggermode = settingsworkbuffer[12];
scopesettings.triggeredge = settingsworkbuffer[13];
scopesettings.triggerchannel = settingsworkbuffer[14];
scopesettings.triggerposition = settingsworkbuffer[40];
scopesettings.triggeroffset = settingsworkbuffer[41];
//Restore the time base
scopesettings.timeperdiv = settingsworkbuffer[10];
//Restore the move speed
scopesettings.movespeed = settingsworkbuffer[11];
//Restore the right menu state
scopesettings.rightmenustate = settingsworkbuffer[15];
//Restore screen brightness, grid brightness, always 50% trigger and xy display mode
scopesettings.screenbrightness = settingsworkbuffer[60];
scopesettings.gridbrightness = settingsworkbuffer[61];
scopesettings.alwaystrigger50 = settingsworkbuffer[62];
scopesettings.xymodedisplay = settingsworkbuffer[63];
//Restore the time cursor settings
scopesettings.timecursorsenable = settingsworkbuffer[161];
scopesettings.timecursor1position = settingsworkbuffer[162];
scopesettings.timecursor2position = settingsworkbuffer[163];
//Restore the volt cursor settings
scopesettings.voltcursorsenable = settingsworkbuffer[164];
scopesettings.voltcursor1position = settingsworkbuffer[165];
scopesettings.voltcursor2position = settingsworkbuffer[166];
//Point to the first measurement enable setting
ptr = &settingsworkbuffer[80];
//Restore the measurements enable states
for(channel=0;channel<2;channel++)
{
//12 measurements per channel
for(index=0;index<12;index++)
{
//Copy the current measurement state and point to the next one
scopesettings.measuresstate[channel][index] = *ptr++;
}
}
//Restore the calibration data
channel1_calibration_factor = settingsworkbuffer[120];
channel2_calibration_factor = settingsworkbuffer[127];
//Point to the first channel calibration value
ptr = &settingsworkbuffer[121];
//Copy the saved values to the working set
for(index=0;index<6;index++,ptr++)
{
//Copy the data for both channels
channel1_calibration_data[index] = ptr[0];
channel2_calibration_data[index] = ptr[7];
}
//The last entry is a copy of the fore last value
//Different from the original code where they use a switch statement instead of an array index for getting the data
channel1_calibration_data[6] = settingsworkbuffer[126];
channel2_calibration_data[6] = settingsworkbuffer[133];
//Need the system ok flag (settingsworkbuffer[200])
}
if (uVar9 == 1000)
{
LAB_80010258:
local_80 = '1';
local_7f = 'G';
local_7e = 'H';
local_7d = 'z';
local_7c = 0;
goto LAB_80010394;
}
typedef struct tagTimeCalcData TIMECALCDATA, *PTIMECALCDATA;
typedef struct tagVoltCalcData VOLTCALCDATA, *PVOLTCALCDATA;
struct tagTimeCalcData
{
uint32 mul_factor;
uint8 time_scale;
uint8 freq_scale;
};
struct tagVoltCalcData
{
uint32 mul_factor;
uint8 volt_scale;
};
const TIMECALCDATA time_calc_data[21] =
{
{ 100, 3, 3 }, // 50mS/div
{ 40000, 2, 4 }, // 20mS/div
{ 20000, 2, 4 }, // 10mS/div
{ 10000, 2, 4 }, // 5mS/div
{ 4000, 2, 4 }, // 2mS/div
{ 2000, 2, 4 }, // 1mS/div
{ 1000, 2, 4 }, //500uS/div
{ 400, 2, 4 }, //200uS/div
{ 200, 2, 4 }, //100uS/div
{ 100, 2, 4 }, // 50uS/div
{ 40000, 1, 5 }, // 20uS/div
{ 20000, 1, 5 }, // 10uS/div
{ 10000, 1, 5 }, // 5uS/div
{ 4000, 1, 5 }, // 2uS/div
{ 2000, 1, 5 }, // 1uS/div
{ 1000, 1, 5 }, //500nS/div
{ 500, 1, 5 }, //250nS/div
{ 200, 1, 5 }, //100nS/div
{ 100, 1, 5 }, // 50nS/div
{ 50000, 0, 6 }, // 25nS/div
{ 20000, 0, 6 } // 10nS/div
};
const VOLTCALCDATA volt_calc_data[3][7] =
{
{ { 10000, 3 }, { 5000, 3 }, { 2000, 3 }, { 1000, 3 }, { 400, 3 }, { 200, 3 }, { 100, 3 } },
{ { 100000, 3 }, { 50000, 3 }, { 20000, 3 }, { 10000, 3 }, { 4000, 3 }, { 2000, 3 }, { 1000, 3 } },
{ { 1000, 4 }, { 500, 4 }, { 200, 4 }, { 100, 4 }, { 40, 4 }, { 20, 4 }, { 10, 4 } }
};
const char *magnitude_scaler[8] = { "p", "n", "u", "m", "", "K", "M", "G"};
void scope_display_cursor_measurements(void)
{
uint32 height = 5;
uint32 ch1ypos = 52;
uint32 ch2ypos = 52;
uint32 delta;
char displaytext[10];
//Check if need to do anything here
if(scopesettings.timecursorsenable || (scopesettings.voltcursorsenable && (scopesettings.channel1.enable || scopesettings.channel2.enable)))
{
//Check if time cursor is enabled
if(scopesettings.timecursorsenable)
{
//Add height for two text lines
height += 32;
//Shift the voltage text positions down
ch1ypos += 32;
ch2ypos += 32;
}
//Check if volt cursor is enabled
if(scopesettings.voltcursorsenable)
{
//Check if channel 1 is enabled
if(scopesettings.channel1.enable)
{
//Add height for one text line
height += 16;
//Shift the channel 2 voltage text down
ch2ypos += 16;
}
//Check if channel 2 is enabled
if(scopesettings.channel2.enable)
{
//Add height for one text line
height += 16;
}
}
//Set gray background for the cursor measurements
display_set_fg_color(0x00404040);
//Draw rounded rectangle depending on what is enabled.
display_fill_rounded_rect(5, 49, 102, height, 2);
//Use white text and font_0
display_set_fg_color(0x00FFFFFF);
display_set_font(&font_0);
//Check if time cursor is enabled
if(scopesettings.timecursorsenable)
{
//Time texts are always on the top two lines
//Get the time delta based on the cursor positions
delta = scopesettings.timecursor2position - scopesettings.timecursor1position;
//Get the time calculation data for this time base setting. Only for the short time bases so take of the first 9
PTIMECALCDATA tcd = (PTIMECALCDATA)&time_calc_data[scopesettings.timeperdiv - 9];
//For the time multiply with the scaling factor and display based on the time scale
delta *= tcd->mul_factor;
//Format the time for displaying
scope_print_value(displaytext, delta, tcd->time_scale, "T ", "S");
display_text(10, 52, displaytext);
//Calculate the frequency for this time. Need to adjust for stay within 32 bits
delta /= 10;
delta = 1000000000/ delta;
//Format the frequency for displaying
scope_print_value(displaytext, delta, tcd->freq_scale, "F ", "Hz");
display_text(10, 68, displaytext);
}
//Check if volt cursor is enabled
if(scopesettings.voltcursorsenable)
{
PVOLTCALCDATA vcd;
uint32 volts;
//Get the volts delta based on the cursor positions
delta = scopesettings.voltcursor2position - scopesettings.voltcursor1position;
//Check if channel 1 is enabled
if(scopesettings.channel1.enable)
{
//Calculate the voltage based on the channel 1 settings
vcd = (PVOLTCALCDATA)&volt_calc_data[scopesettings.channel1.magnification][scopesettings.channel1.voltperdiv];
//Multiply with the scaling factor for the channel 1 settings
volts = delta * vcd->mul_factor;
//Channel 1 text has a variable position
//Format the voltage for displaying
scope_print_value(displaytext, volts, vcd->volt_scale, "V1 ", "V");
display_text(10, ch1ypos, displaytext);
}
//Check if channel 2 is enabled
if(scopesettings.channel2.enable)
{
//Calculate the voltage based on the channel 2 settings
vcd = (PVOLTCALCDATA)&volt_calc_data[scopesettings.channel2.magnification][scopesettings.channel2.voltperdiv];
//Multiply with the scaling factor for the channel 2 settings
volts = delta * vcd->mul_factor;
//Channel 2 text has a variable position
//Format the voltage for displaying
scope_print_value(displaytext, volts, vcd->volt_scale, "V2 ", "V");
display_text(10, ch2ypos, displaytext);
}
}
}
}
//----------------------------------------------------------------------------------------------------------------------------------
//Simple non optimized function for string copy that returns the position of the terminator
//----------------------------------------------------------------------------------------------------------------------------------
char *strcpy(char *dst, const char *src)
{
while(*src)
{
*dst++ = *src++;
}
//Terminate the copy
*dst = 0;
return(dst);
}
//----------------------------------------------------------------------------------------------------------------------------------
void scope_print_value(char *buffer, uint32 value, uint32 scale, char *header, char *sign)
{
//Copy the header into the string buffer
buffer = strcpy(buffer, header);
//Need to find the magnitude scale for the input
//The calculations are based on fixed point
while(value >= 100000)
{
//Skip to the next magnitude
scale++;
//Bring the value in range
value /= 1000;
}
//Format the remainder for displaying. Only 3 digits are allowed to be displayed
if(value < 1000)
{
//Less then 1000 means x.yy
buffer = scope_print_decimal(buffer, value, 2);
}
else if(value < 10000)
{
//More then 1000 but less then 10000 means xx.y
value /= 10;
buffer = scope_print_decimal(buffer, value, 1);
}
else
{
//More then 10000 and less then 100000 means xxx
value /= 100;
buffer = scope_print_decimal(buffer, value, 0);
}
//Make sure scale is not out of range
if(scale > 7)
{
scale = 7;
}
//Add the magnitude scaler
buffer = strcpy(buffer, magnitude_scaler[scale]);
//Add the type of measurement sign
strcpy(buffer, sign);
}
//----------------------------------------------------------------------------------------------------------------------------------
char *scope_print_decimal(char *buffer, uint32 value, uint32 decimals)
{
char b[12];
uint32 i = 12; //Start beyond the array since the index is pre decremented
uint32 s;
//For value 0 no need to do the work
if(value == 0)
{
//Value is zero so just set 0 character
b[--i] = '0';
}
else
{
//Process the digits
while(value)
{
//Set current digit to decreased index
b[--i] = (value % 10) + '0';
//Check if decimal point needs to be placed
if(i == 12 - decimals)
{
//If so put it in
b[--i] = '.';
}
//Take of the current digit
value /= 10;
}
}
//Determine the size of the string
s = 12 - i;
//Copy to the buffer
memcpy(buffer, &b[i], s);
//terminate the string
buffer[s] = 0;
//Return the position of the terminator to allow appending
return(&buffer[s]);
}
void scope_pre_process_ch1_25ns_data(void)
{
undefined2 uVar1;
int iVar2;
int iVar3;
uint *puVar4;
uint *puVar5;
uint *puVar6;
uint *puVar7;
uint **ppuVar8;
uint **ppuVar9;
byte *pbVar10;
undefined2 *puVar11;
uint uVar12;
uint uVar13;
byte bVar14;
uint uVar15;
int iVar16;
short *psVar17;
byte bVar18;
undefined2 uVar19;
uint *puVar20;
uint *puVar21;
uint uVar22;
uint uVar23;
uint uVar24;
bool bVar25;
bool bVar26;
puVar7 = DAT_8000470c;
puVar21 = DAT_80004708;
iVar16 = 0x2e8;
*(undefined2 *)((int)DAT_8000470c + 2) = *(undefined2 *)DAT_80004708;
uVar19 = *(undefined2 *)((int)puVar21 + 2);
puVar11 = (undefined2 *)((int)puVar7 + 2);
do {
uVar1 = *(undefined2 *)(puVar21 + 1);
puVar11[2] = uVar19;
uVar19 = *(undefined2 *)((int)puVar21 + 6);
iVar16 = iVar16 + -1;
puVar11 = puVar11 + 4;
*puVar11 = uVar1;
iVar3 = DAT_8000471c;
iVar2 = DAT_80004718;
puVar21 = puVar21 + 1;
} while (iVar16 != 0);
*(undefined2 *)(DAT_80004714 + 2) = *DAT_80004710;
uVar15 = DAT_80004720;
uVar12 = 0;
if (*(short *)(iVar2 + 0x1c) == 0) {
do {
uVar13 = (uint)*(ushort *)(iVar3 + uVar12 * 2);
if (*(ushort *)(iVar2 + 0x1e) < uVar13) {
puVar21 = (uint *)(uVar13 - *(ushort *)(iVar2 + 0x1e));
*(short *)(puVar7 + uVar12) = (short)puVar21;
}
else {
puVar21 = puVar7 + uVar12;
*(undefined2 *)puVar21 = 0;
}
uVar12 = uVar12 + 1 & 0xfffeffff;
} while (uVar12 < uVar15);
}
else {
do {
psVar17 = (short *)(iVar3 + uVar12 * 2);
puVar21 = puVar7 + uVar12;
uVar12 = uVar12 + 2 & 0xfffeffff;
*(short *)puVar21 = *psVar17 + *(short *)(iVar2 + 0x1e);
*(short *)(puVar21 + 1) = psVar17[1] + *(short *)(iVar2 + 0x1e);
} while (uVar12 < uVar15);
}
uVar12 = DAT_80004724;
puVar5 = DAT_80004708;
puVar7 = DAT_8000470c;
if (3 < DAT_80004724) {
puVar20 = (uint *)((uint)DAT_80004708 & 3);
uVar13 = DAT_80004724;
puVar21 = puVar20;
if (puVar20 != NULL) {
bVar14 = *(byte *)DAT_8000470c;
puVar6 = (uint *)((int)DAT_8000470c + 1);
if (puVar20 < (uint *)0x3) {
puVar6 = (uint *)((int)DAT_8000470c + 2);
puVar21 = (uint *)(uint)*(byte *)(uint *)((int)DAT_8000470c + 1);
}
puVar4 = (uint *)((int)DAT_80004708 + 1);
*(byte *)DAT_80004708 = bVar14;
puVar7 = puVar6;
if (puVar20 < (uint *)0x2) {
puVar7 = (uint *)((int)puVar6 + 1);
bVar14 = *(byte *)puVar6;
}
puVar6 = puVar4;
if (puVar20 < (uint *)0x3) {
puVar6 = (uint *)((int)puVar5 + 2);
*(byte *)puVar4 = (byte)puVar21;
}
uVar13 = (int)puVar20 + (uVar12 - 4);
puVar5 = puVar6;
if (puVar20 < (uint *)0x2) {
puVar5 = (uint *)((int)puVar6 + 1);
*(byte *)puVar6 = bVar14;
}
}
uVar15 = (uint)puVar7 & 3;
if (uVar15 == 0) {
while (uVar12 = uVar13 - 0x20, 0x1f < uVar13) {
uVar15 = puVar7[1];
uVar13 = puVar7[2];
uVar22 = puVar7[3];
*puVar5 = *puVar7;
puVar5[1] = uVar15;
puVar5[2] = uVar13;
puVar5[3] = uVar22;
uVar15 = puVar7[4];
uVar13 = puVar7[5];
uVar22 = puVar7[6];
uVar23 = puVar7[7];
puVar7 = puVar7 + 8;
puVar5[4] = uVar15;
puVar5[5] = uVar13;
puVar5[6] = uVar22;
puVar5[7] = uVar23;
puVar5 = puVar5 + 8;
uVar13 = uVar12;
}
if ((bool)((byte)(uVar12 >> 4) & 1)) {
uVar15 = *puVar7;
uVar22 = puVar7[1];
uVar23 = puVar7[2];
uVar24 = puVar7[3];
puVar7 = puVar7 + 4;
*puVar5 = uVar15;
puVar5[1] = uVar22;
puVar5[2] = uVar23;
puVar5[3] = uVar24;
puVar5 = puVar5 + 4;
}
if ((int)(uVar13 << 0x1c) < 0) {
uVar15 = *puVar7;
uVar22 = puVar7[1];
puVar7 = puVar7 + 2;
*puVar5 = uVar15;
puVar5[1] = uVar22;
puVar5 = puVar5 + 2;
}
puVar20 = puVar5;
puVar21 = puVar7;
if ((bool)((byte)(uVar12 >> 2) & 1)) {
puVar21 = puVar7 + 1;
uVar15 = *puVar7;
puVar20 = puVar5 + 1;
*puVar5 = uVar15;
}
uVar19 = (undefined2)uVar15;
if ((uVar12 & 3) != 0) {
bVar26 = (bool)((byte)(uVar12 >> 1) & 1);
uVar13 = uVar13 << 0x1f;
bVar25 = (int)uVar13 < 0;
puVar7 = puVar21;
if (bVar26) {
puVar7 = (uint *)((int)puVar21 + 2);
uVar19 = *(undefined2 *)puVar21;
}
if (bVar25) {
uVar13 = (uint)*(byte *)puVar7;
}
puVar21 = puVar20;
if (bVar26) {
puVar21 = (uint *)((int)puVar20 + 2);
*(undefined2 *)puVar20 = uVar19;
}
if (bVar25) {
*(byte *)puVar21 = (byte)uVar13;
}
return;
}
return;
}
uVar12 = uVar13 - 4;
if (3 < uVar13) {
ppuVar8 = (uint **)((int)puVar7 - uVar15);
puVar21 = *ppuVar8;
puVar7 = puVar5;
if (uVar15 == 2) {
do {
ppuVar9 = ppuVar8;
uVar15 = (uint)puVar21 >> 0x10;
ppuVar8 = ppuVar9 + 1;
puVar21 = *ppuVar8;
bVar25 = 3 < uVar12;
uVar12 = uVar12 - 4;
uVar15 = uVar15 | (int)puVar21 << 0x10;
puVar5 = puVar7 + 1;
*puVar7 = uVar15;
puVar7 = puVar5;
} while (bVar25);
puVar7 = (uint *)((int)ppuVar9 + 6);
}
else {
if (uVar15 < 3) {
do {
ppuVar9 = ppuVar8;
uVar15 = (uint)puVar21 >> 8;
ppuVar8 = ppuVar9 + 1;
puVar21 = *ppuVar8;
bVar25 = 3 < uVar12;
uVar12 = uVar12 - 4;
uVar15 = uVar15 | (int)puVar21 << 0x18;
puVar5 = puVar7 + 1;
*puVar7 = uVar15;
puVar7 = puVar5;
} while (bVar25);
puVar7 = (uint *)((int)ppuVar9 + 5);
}
else {
do {
ppuVar9 = ppuVar8;
uVar15 = (uint)puVar21 >> 0x18;
ppuVar8 = ppuVar9 + 1;
puVar21 = *ppuVar8;
bVar25 = 3 < uVar12;
uVar12 = uVar12 - 4;
uVar15 = uVar15 | (int)puVar21 << 8;
puVar5 = puVar7 + 1;
*puVar7 = uVar15;
puVar7 = puVar5;
} while (bVar25);
puVar7 = (uint *)((int)ppuVar9 + 7);
}
}
}
}
bVar18 = (byte)puVar21;
bVar14 = (byte)uVar15;
bVar26 = (bool)((byte)(uVar12 >> 1) & 1);
uVar12 = uVar12 << 0x1f;
bVar25 = (int)uVar12 < 0;
if (bVar26) {
pbVar10 = (byte *)((int)puVar7 + 1);
bVar14 = *(byte *)puVar7;
puVar7 = (uint *)((int)puVar7 + 2);
bVar18 = *pbVar10;
}
if (bVar25) {
uVar12 = (uint)*(byte *)puVar7;
}
if (bVar26) {
pbVar10 = (byte *)((int)puVar5 + 1);
*(byte *)puVar5 = bVar14;
puVar5 = (uint *)((int)puVar5 + 2);
*pbVar10 = bVar18;
}
if (bVar25) {
*(byte *)puVar5 = (byte)uVar12;
}
return;
}
**************************************************************
* FUNCTION *
**************************************************************
void __stdcall scope_pre_process_ch1_25ns_data(void)
void <VOID> <RETURN>
undefined4 Stack[-0x18]:4 local_18 XREF[2]: 80004614(W),
800046b0(*)
scope_pre_process_ch1_25ns_data XREF[1]: scope_get_short_timebase_data:80
8000460c e0 03 2d e9 stmdb sp!,{r5 r6 r7 r8 r9}
80004610 f0 20 9f e5 ldr r2,[DAT_80004708] = 8019D5EAh
80004614 04 40 2d e5 str r4,[sp,#local_18]!
80004618 b0 c0 d2 e1 ldrh r12,[r2,#0x0]=>DAT_8019d5ea
8000461c e8 00 9f e5 ldr r0,[DAT_8000470c] = 801AEF2Ah
80004620 ba 3f a0 e3 mov r3,#0x2e8
80004624 b2 c0 c0 e1 strh r12,[r0,#0x2]=>DAT_801aef2c
80004628 b2 c0 d2 e1 ldrh r12,[r2,#0x2]=>DAT_8019d5ec
8000462c 02 10 80 e2 add r1,r0,#0x2
LAB_80004630 XREF[1]: 80004644(j)
80004630 b4 40 f2 e1 ldrh r4,[r2,#0x4]!=>DAT_8019d5ee
80004634 b4 c0 c1 e1 strh r12,[r1,#0x4]=>DAT_801aef30
80004638 b2 c0 d2 e1 ldrh r12,[r2,#0x2]=>DAT_8019d5f0
8000463c 01 30 53 e2 subs r3,r3,#0x1
80004640 b8 40 e1 e1 strh r4,[r1,#0x8]!=>DAT_801aef34
80004644 f9 ff ff 1a bne LAB_80004630
80004648 c0 10 9f e5 ldr r1,[DAT_80004710] = 8019E18Ch
8000464c c0 c0 9f e5 ldr r12,[DAT_80004714] = 801B066Eh
80004650 b0 10 d1 e1 ldrh r1,[r1,#0x0]=>DAT_8019e18c
80004654 bc 20 9f e5 ldr r2,[DAT_80004718] = 802F18B0h
80004658 bc 50 9f e5 ldr r5,[DAT_8000471c] = 8019ED5Ah
8000465c b2 10 cc e1 strh r1,[r12,#0x2]=>DAT_801b0670
80004660 bc 11 d2 e1 ldrh r1,[r2,#0x1c]=>DAT_802f18cc
80004664 b4 30 9f e5 ldr r3,[DAT_80004720] = 000005D2h
80004668 00 00 51 e3 cmp r1,#0x0
8000466c 00 10 a0 e3 mov r1,#0x0
80004670 00 40 a0 03 moveq r4,#0x0
80004674 13 00 00 0a beq LAB_800046c8
LAB_80004678 XREF[1]: 800046ac(j)
80004678 be 71 d2 e1 ldrh r7,[r2,#0x1e]=>DAT_802f18ce
8000467c 02 60 81 e2 add r6,r1,#0x2
80004680 81 40 85 e0 add r4,r5,r1, lsl #0x1
80004684 b0 80 d4 e1 ldrh r8,[r4,#0x0]=>DAT_8019ed5a
80004688 01 c1 80 e0 add r12,r0,r1, lsl #0x2
8000468c 01 18 c6 e3 bic r1,r6,#0x10000
80004690 07 60 88 e0 add r6,r8,r7
80004694 b0 60 cc e1 strh r6,[r12,#0x0]=>DAT_801aef2a
80004698 b2 40 d4 e1 ldrh r4,[r4,#0x2]=>DAT_8019ed5c
8000469c be 61 d2 e1 ldrh r6,[r2,#0x1e]=>DAT_802f18ce
800046a0 03 00 51 e1 cmp r1,r3
800046a4 06 40 84 e0 add r4,r4,r6
800046a8 b4 40 cc e1 strh r4,[r12,#0x4]=>DAT_801aef2e
800046ac f1 ff ff 3a bcc LAB_80004678
LAB_800046b0 XREF[1]: 80004704(j)
800046b0 f0 01 bd e8 ldmia sp!,{r4 r5 r6 r7 r8}=>local_18
800046b4 68 20 9f e5 ldr r2,[DAT_80004724] = 000016A8h
800046b8 4c 10 9f e5 ldr r1,[DAT_8000470c] = 801AEF2Ah
800046bc 44 00 9f e5 ldr r0,[DAT_80004708] = 8019D5EAh
800046c0 04 90 9d e4 ldr r9,[sp],#0x4
800046c4 e4 ef ff ea b memcpy
LAB_800046c8 XREF[2]: 80004674(j), 80004700(j)
800046c8 81 c0 85 e0 add r12,r5,r1, lsl #0x1
800046cc b0 c0 dc e1 ldrh r12,[r12,#0x0]=>DAT_8019ed5a
800046d0 be 61 d2 e1 ldrh r6,[r2,#0x1e]=>DAT_802f18ce
800046d4 0c 00 56 e1 cmp r6,r12
800046d8 01 c1 80 20 addcs r12,r0,r1, lsl #0x2
800046dc b0 40 cc 21 strhcs r4,[r12,#0x0]
800046e0 03 00 00 2a bcs LAB_800046f4
800046e4 be 61 d2 e1 ldrh r6,[r2,#0x1e]=>DAT_802f18ce
800046e8 01 71 80 e0 add r7,r0,r1, lsl #0x2
800046ec 06 c0 4c e0 sub r12,r12,r6
800046f0 b0 c0 c7 e1 strh r12,[r7,#0x0]=>DAT_801aef2a
LAB_800046f4 XREF[1]: 800046e0(j)
800046f4 01 10 81 e2 add r1,r1,#0x1
800046f8 01 18 c1 e3 bic r1,r1,#0x10000
800046fc 03 00 51 e1 cmp r1,r3
80004700 f0 ff ff 3a bcc LAB_800046c8
80004704 e9 ff ff ea b LAB_800046b0
void scope_pre_process_ch1_25ns_data(void)
{
undefined2 uVar1;
int iVar2;
int iVar3;
uint *puVar4;
uint *puVar5;
uint *puVar6;
uint *puVar7;
uint **ppuVar8;
uint **ppuVar9;
byte *pbVar10;
undefined2 *puVar11;
uint uVar12;
uint uVar13;
byte bVar14;
uint uVar15;
int iVar16;
short *psVar17;
byte bVar18;
undefined2 uVar19;
uint *puVar20;
uint *puVar21;
uint uVar22;
uint uVar23;
uint uVar24;
bool bVar25;
bool bVar26;
puVar7 = DAT_8000470c; //0x801AEF2A = temptracebuffer1 + 4
puVar21 = DAT_80004708; //0x8019D5EA = channel1tracebuffer1 (1500 samples from most likely adc1)
iVar16 = 0x2e8; //744
//Copy a short from buffer1 to buffer2
*(undefined2 *)((int)DAT_8000470c + 2) = *(undefined2 *)DAT_80004708; //0x801aef2c = 0x8019d5ea
uVar19 = *(undefined2 *)((int)puVar21 + 2); //Get data from 0x8019d5ec
puVar11 = (undefined2 *)((int)puVar7 + 2); //point to next item in the temp buffer
//Copy data from sample buffer to temp buffer while skipping a sample in the temp buffer. (Make room for another sample???)
do
{
uVar1 = *(undefined2 *)(puVar21 + 1); //0x8019d5ee
puVar11[2] = uVar19; //0x801aef30 = 0x8019d5ec skip one item
uVar19 = *(undefined2 *)((int)puVar21 + 6); //0x8019d5f0
iVar16 = iVar16 + -1;
puVar11 = puVar11 + 4;
*puVar11 = uVar1; //0x801aef34 = 0x8019d5ee
puVar21 = puVar21 + 1;
} while (iVar16 != 0);
//Last copies done
//0x0x801B0668 = 0x8019E18A
//0x0x801B066C = 0x8019E18C
iVar3 = DAT_8000471c; //0x8019ED5A channel1tracebuffer2 (1500 samples from most likely adc2)
iVar2 = DAT_80004718; //0x802F18B0 Calibration data
*(undefined2 *)(DAT_80004714 + 2) = *DAT_80004710; //0x801B0670 = 0x8019E18C
uVar15 = DAT_80004720; //0x000005D2 = 1490
uVar12 = 0;
if (*(short *)(iVar2 + 0x1c) == 0) //0x802f18cc Either 1 or 0 based on some calibration action
{
//Trace data showed this to be zero on my scope, so this loop is done
do
{
uVar13 = (uint)*(ushort *)(iVar3 + uVar12 * 2); //First sample from 0x8019ed5a
if (*(ushort *)(iVar2 + 0x1e) < uVar13) //0x802f18ce also some calibration data (3 on my scope)
{
puVar21 = (uint *)(uVar13 - *(ushort *)(iVar2 + 0x1e));
*(short *)(puVar7 + uVar12) = (short)puVar21; //puVar7 = temp trace buffer
}
else
{
puVar21 = puVar7 + uVar12;
*(undefined2 *)puVar21 = 0;
}
uVar12 = uVar12 + 1 & 0xfffeffff;
} while (uVar12 < uVar15);
//Trace shows this
//First samples
//0x801AEF2A = 0x8019ED5A
//0x801AEF2E = 0x8019ED5C
//0x801AEF32 = 0x8019ED5E
//Last samples
//0x801B066A = 0x8019F8FA
//0x801B066E = 0x8019F8FC
}
else
{
do
{ //two samples at a time, but I miss the interleaving???? Maybe buffers or pointers defined as 32 bit items
psVar17 = (short *)(iVar3 + uVar12 * 2);
puVar21 = puVar7 + uVar12;
uVar12 = uVar12 + 2 & 0xfffeffff;
*(short *)puVar21 = *psVar17 + *(short *)(iVar2 + 0x1e);
*(short *)(puVar21 + 1) = psVar17[1] + *(short *)(iVar2 + 0x1e);
} while (uVar12 < uVar15);
//Trace shows this
//First samples
//0x801AEF2A = 0x8019ED5A
//0x801AEF2E = 0x8019ED5C
//0x801AEF32 = 0x8019ED5E
//0x801AEF36 = 0x8019ED60
//Last samples
//0x801B0662 = 0x8019F8F6
//0x801B0666 = 0x8019F8F8
//0x801B066A = 0x8019F8FA
//0x801B066E = 0x8019F8FC
}
//DAT_80004724; //0x000016A8 5800 bytes
//DAT_80004708; //0x8019D5EA first buffer destination
//DAT_8000470c; //0x801AEF2A temp buffer source
//Copy the temp buffer back to the first trace buffer
memcpy(DAT_80004708, DAT_8000470c, DAT_80004724);
}
void scope_up_sample_x_10(uint16 * buffer, uint32 count)
{
register uint32 cnt, idx;
register uint16 *sptr;
register uint16 *dptr;
register int32 sample1, sample2;
register int32 delta;
//Only do one tenth of the samples
cnt = count / 10;
//For the source point to the last sample to use
sptr = &buffer[cnt];
//For the destination point to the last result sample
dptr = &buffer[count];
//Get the first sample to use
sample1 = *sptr--;
//Process all the needed samples
while(cnt)
{
//Store the first sample
*dptr-- = sample1;
//Get the second sample
sample2 = *sptr--;
//Fill in the in between samples
//The original code uses a different approach
//Get the samples shifted up for fractional calculations 10.22 bits
sample1 <<= 22;
//Calculate a delta step between the samples
delta = (sample1 - (sample2 << 22)) / 10;
for(idx=0;idx<9;idx++)
{
//Calculate the next sample with fixed point calculation
//Since the direction is from last sample to first sample the step needs to be taken off
sample1 -= delta;
//Store the decimal part of it
*dptr-- = sample1 >> 22;
}
//Save the second sample as the first sample
sample1 = sample2;
//One set of samples done
cnt--;
}
}
uint32 i;
for(i=0;i<1500;i++)
{
samples1[i] = (i * 10) % 200;
}
void scope_up_sample_x_10(uint32 count)
{
register uint32 cnt, idx;
register uint16 *sptr;
register uint16 *sptr2;
register uint16 *dptr;
register int32 sample1, sample2;
register int32 delta;
//Only do one tenth of the samples
cnt = count / 10;
//For the source point to the last sample to use
sptr = &samples1[cnt];
//For the destination point to the last result sample
dptr = &samples2[count];
//Get the first sample to use
sample1 = *sptr--;
//Process all the needed samples
while(cnt)
{
//Store the first sample
*dptr-- = sample1;
//Get the second sample
sample2 = *sptr--;
//Fill in the in between samples
//The original code uses a different approach
//Get the samples shifted up for fractional calculations 10.22 bits
sample1 <<= 22;
//Calculate a delta step between the samples
delta = (sample1 - (sample2 << 22)) / 10;
for(idx=0;idx<9;idx++)
{
//Calculate the next sample with fixed point calculation
//Since the direction is from last sample to first sample the step needs to be taken off
sample1 -= delta;
//Store the decimal part of it
*dptr-- = sample1 >> 22;
}
//Save the second sample as the first sample
sample1 = sample2;
//One set of samples done
cnt--;
//In here for debugging
if(cnt == 1)
{
sample2 = 20;
}
}
//These newly interpolated samples need to be averaged with the first set, which might be possible to do in the single run directly back into the original buffer
//Create a second interpolated set of data based on the interpolated samples
//Only do one tenth of the samples minus one since the data is shifted
cnt = (count / 10) - 1;
//For the source point to the last sample to use
sptr = &samples2[count - 5];
//For the destination point to the last result sample in a temp buffer
//Also on shifted sample to end where needed
dptr = &samples3[count - 5];
//Get the first sample to use and skip ten samples
sample1 = *sptr;
sptr -= 10;
//Process all the needed samples
while(cnt)
{
//Store the first sample
*dptr-- = sample1;
//Get the second sample and skip ten samples
sample2 = *sptr;
sptr -= 10;
//Fill in the in between samples
//Get the samples shifted up for fractional calculations 10.22 bits
sample1 <<= 22;
//Calculate a delta step between the samples
delta = (sample1 - (sample2 << 22)) / 10;
for(idx=0;idx<9;idx++)
{
//Calculate the next sample with fixed point calculation
//Since the direction is from last sample to first sample the step needs to be taken off
sample1 -= delta;
//Store the decimal part of it
*dptr-- = sample1 >> 22;
}
//Save the second sample as the first sample
sample1 = sample2;
//One set of samples done
cnt--;
//In here for debugging
if(cnt == 1)
{
sample2 = 20;
}
}
//Store the last sample
*dptr = sample1;
//Average these two sets
cnt = count;
sptr = samples2;
sptr2 = samples3;
dptr = samples4;
while(cnt)
{
*dptr++ = (*sptr + *sptr2) / 2;
sptr++;
sptr2++;
cnt--;
}
//The last step is a 5 time up sampling of the processed data and averaging that with the processed data
//Only do one fifth of the samples
cnt = (count / 5) - 1;
//For the source point to the last sample to use
//Takes the second sample as last input
sptr = &samples4[count - 8];
//For the destination point to the last result sample
dptr = &samples5[count];
//Get the first sample to use
sample1 = *sptr--;
//Process all the needed samples
while(cnt)
{
//Store the first sample
*dptr-- = sample1;
//Get the second sample and skip 5 samples
sample2 = *sptr;
sptr -= 5;
//Fill in the in between samples
//The original code uses a different approach
//Get the samples shifted up for fractional calculations 10.22 bits
sample1 <<= 22;
//Calculate a delta step between the samples
delta = (sample1 - (sample2 << 22)) / 5;
for(idx=0;idx<4;idx++)
{
//Calculate the next sample with fixed point calculation
//Since the direction is from last sample to first sample the step needs to be taken off
sample1 -= delta;
//Store the decimal part of it
*dptr-- = sample1 >> 22;
}
//Save the second sample as the first sample
sample1 = sample2;
//One set of samples done
cnt--;
//In here for debugging
if(cnt == 1)
{
sample2 = 20;
}
}
//Store the last sample
*dptr = sample1;
//Average these two sets
cnt = count;
sptr = samples4;
sptr2 = samples5;
dptr = samples6;
while(cnt)
{
*dptr++ = (*sptr + *sptr2) / 2;
sptr++;
sptr2++;
cnt--;
}
}
void scope_process_ch1_25ns_data(void)
{
ushort uVar1;
longlong lVar2;
longlong lVar3;
undefined2 uVar4;
uint uVar5;
uint uVar6;
uint uVar7;
ushort *puVar8;
int iVar9;
uint16 *puVar10;
ushort *puVar11;
undefined2 *puVar12;
ushort uVar13;
short *psVar14;
int iVar15;
ushort uVar16;
short sVar17;
uint uVar18;
uint uVar19;
undefined4 uVar20;
uint16 *puVar21;
int iVar22;
uint16 *puVar23;
undefined2 *puVar24;
undefined8 uVar25;
undefined8 uVar26;
undefined8 uVar27;
undefined8 uVar28;
undefined8 uVar29;
undefined8 uVar30;
uVar19 = DAT_80006504; //0x000009C4 2500
iVar22 = DAT_80006500; //0x8019D5A0 settings base
uVar7 = 0;
puVar8 = (ushort *)((int)DAT_800064f0 + 200); //0x8019D5EA sample buffer + 200 (100 samples in) (&channel1tracebuffer1[100])
uVar20 = 0;
iVar9 = DAT_800064f8; //0x0000056E 1390
uVar18 = DAT_800064f4; //0x0000FFFF 65535
//Loop through 1390 samples
//Start on 0x8019D6B2 (100 samples into the buffer)
do
{
uVar5 = (uint)*puVar8; //Get the sample
puVar8 = puVar8 + 1;
//Determine max value
if (uVar7 < uVar5)
{
uVar7 = uVar5;
}
//Determine min value
if (uVar5 < uVar18)
{
uVar18 = uVar5;
}
iVar9 = iVar9 + -1;
} while (iVar9 != 0);
puVar21 = (uint16 *)(uVar7 + uVar18 >> 1); //Average between min and max
uVar5 = 0;
puVar8 = (ushort *)((int)DAT_800064f0 + 0x14); // &channel1tracebuffer1[10]
iVar9 = DAT_800064fc; //0x000005C8 1480
puVar23 = DAT_800064f0; //0x8019D5EA channel1tracebuffer1
//Determine if there is high frequency signal in the buffer (more then 320 rising edges)
//Loop through 1480 samples
//Start on 0x8019D5FE
do
{
puVar10 = (uint16 *)(uint)*puVar8; //Get sample
if (puVar10 < puVar21) //Check sample against average
{
puVar23 = (uint16 *)(uint)puVar8[1]; //Below average then get the next sample too
}
//Need to figure this out on what it is counting
//first sample below average and second sample above average or second sample above or equal to average
//Count the rising edges in the buffer discriminating on a single bit
//The first part of the if is abundant
if ((puVar10 < puVar21 && puVar21 < puVar23) || ((puVar10 < puVar21 && (puVar21 <= (uint16 *)(uint)puVar8[1]))))
{
uVar5 = uVar5 + 1 & 0xfffeffff; //Count the number of samples that comply to what???
}
iVar9 = iVar9 + -1; //one sample done
puVar8 = puVar8 + 1; //select next sample
} while (iVar9 != 0);
/*
LAB_80006320 XREF[1]: 80006358(j)
80006320 b0 30 d0 e1 ldrh r3,[r0,#0x0]=>DAT_8019d5fe ;get a sample
80006324 01 00 53 e1 cmp r3,r1 ;compare it to the average
80006328 b2 c0 d0 31 ldrhcc r12,[r0,#0x2]=>DAT_8019d600 ;if below average get the next sample
8000632c 0c 00 51 31 cmpcc r1,r12 ;and compare the average with it
80006330 04 00 00 3a bcc LAB_80006348 ;average below then jump to count
80006334 03 00 51 e1 cmp r1,r3 ;compare average with first sample again
80006338 04 00 00 9a bls LAB_80006350 ;average less then jump
8000633c b2 30 d0 e1 ldrh r3,[r0,#0x2]=>DAT_8019d600 ;get the next sanmple
80006340 03 00 51 e1 cmp r1,r3 ;compare the average with it
80006344 01 00 00 8a bhi LAB_80006350 ;average higher then jump
LAB_80006348 XREF[1]: 80006330(j)
80006348 01 30 84 e2 add r3,r4,#0x1 ;increment the counter
8000634c 01 48 c3 e3 bic r4,r3,#0x10000
LAB_80006350 XREF[2]: 80006338(j), 80006344(j)
80006350 01 20 52 e2 subs r2,r2,#0x1 ;one sample set done
80006354 02 00 80 e2 add r0=>DAT_8019d600,r0,#0x2 ;point to next sample
80006358 f0 ff ff 1a bne LAB_80006320 ;repeat until done
*/
//If more then 320 samples comply do this next bit. This means high frequency signal or noise
//This is the case in the emulator with the given input (alternates on every sample between 0x6D and 0xB0 or 0x90)
if (0x140 < uVar5)
{
uVar6 = get_timer_ticks();
puVar21 = DAT_800064f0; //0x8019D5EA channel1tracebuffer1
if (*(char *)(iVar22 + 10) == '\x1c') //time base = 25nS/div
{
uVar20 = 0x14;
}
if (*(char *)(iVar22 + 10) == '\x1d') //time base = 10nS/div
{
uVar20 = 0x32;
}
iVar9 = 0;
//y + (((y * 2863311531) / 8589934592) * -3)
//2863311531 / 8589934592 ~ 1/3 so the rounding of error leads to a modulo 3
//Is indeed %3 based on the timer ticks. What is the use of it. Some sort of random number input????
uVar25 = FUN_800397d0(uVar6 + (uint)((ulonglong)uVar6 * (ulonglong)DAT_80006508 >> 0x21) * -3); //do some calc on the timer ticks???
uVar26 = FUN_800397d0(uVar18); //min value
uVar27 = FUN_800397d0((uVar7 - uVar18 & 0xffff) >> 1); //max minus min value / 2
uVar28 = FUN_800397d0(uVar5); //number of complying??? samples
uVar29 = FUN_800397d0(uVar20); //Time base dependent input
uVar29 = FUN_800393ec(DAT_8000650c,DAT_80006510,(int)uVar29,(int)((ulonglong)uVar29 >> 0x20));
//Process 2500 samples???
do
{
uVar30 = FUN_8003979c(iVar9);
uVar30 = FUN_80039890((int)uVar30,(int)((ulonglong)uVar30 >> 0x20),(int)uVar29,(int)((ulonglong)uVar29 >> 0x20));
FUN_80039890((int)uVar30,(int)((ulonglong)uVar30 >> 0x20),(int)uVar28,(int)((ulonglong)uVar28 >> 0x20));
uVar30 = FUN_80036000();
uVar30 = FUN_8003926c((int)uVar30,(int)((ulonglong)uVar30 >> 0x20),0,DAT_80006514);
uVar30 = FUN_80039890((int)uVar30,(int)((ulonglong)uVar30 >> 0x20),(int)uVar27,(int)((ulonglong)uVar27 >> 0x20));
uVar30 = FUN_8003926c((int)uVar30,(int)((ulonglong)uVar30 >> 0x20),(int)uVar26,(int)((ulonglong)uVar26 >> 0x20));
FUN_8003926c((int)uVar30,(int)((ulonglong)uVar30 >> 0x20),(int)uVar25,(int)((ulonglong)uVar25 >> 0x20));
uVar4 = FUN_8003972c();
*(undefined2 *)puVar21 = uVar4;
uVar19 = uVar19 - 1 & 0xffff; //one sample done
iVar9 = iVar9 + 1; //next index
puVar21 = (uint16 *)((int)puVar21 + 2); //point to next buffer entry
} while (uVar19 != 0);
return;
}
if (*(char *)(DAT_80006500 + 10) == '\x1c') //0x8019D5AA is time base setting 28 = 25nS/div
{
//With 5nS per sample this up sampling leads to 25nS/div. Every tenth pixel is 5nS, so 50 pixels is 25nS
scope_up_sample_x_10(DAT_800064f0,0,DAT_80006504);
}
puVar21 = DAT_800064f0;
//From here on down is for 10nS/div time base setting. Most likely it is the up sampling needed to go from 5nS per sample
//to 10nS/div. With 50 pixels per div each pixel is 200pS, so need up sampling x_25
if (*(char *)(iVar22 + 10) == '\x1d')
{
puVar8 = (ushort *)(uVar19 * DAT_80013e70 + 0xa3d7 >> 0x14);
if (puVar8 != NULL)
{
puVar11 = DAT_80013e74;
puVar23 = (uint16 *)((int)DAT_800064f0 + -2);
if (((uint)puVar8 & 1) != 0)
{
puVar11 = DAT_80013e74 + 0x19;
*puVar11 = *(ushort *)DAT_800064f0;
puVar23 = puVar21;
}
uVar7 = (uint)((int)puVar8 << 0xf) >> 0x10;
while (uVar7 != 0)
{
puVar11[0x19] = *(ushort *)((int)puVar23 + 2);
puVar23 = (uint16 *)((int)puVar23 + 4);
uVar7 = uVar7 - 1 & 0xffff;
puVar11 = puVar11 + 0x32;
*puVar11 = *(ushort *)puVar23;
}
}
iVar22 = DAT_80013e78;
uVar7 = 0;
if (0 < (int)((int)puVar8 - 1U))
{
do {
puVar11 = (ushort *)(DAT_80013e7c + uVar7 * 0x32);
uVar1 = *puVar11;
uVar13 = puVar11[0x19];
sVar17 = 0xc;
if (uVar1 < uVar13) {
uVar16 = uVar13 - uVar1;
}
else {
uVar16 = uVar1 - uVar13;
}
iVar9 = 0;
uVar18 = (uint)uVar16;
if (uVar1 < uVar13) {
do {
lVar2 = (longlong)iVar22 * (longlong)(int)(uVar18 * (iVar9 + 2));
lVar3 = (longlong)iVar22 * (longlong)(int)(uVar18 * (iVar9 + 1));
sVar17 = sVar17 + -1;
puVar11[1] = ((short)(int)(lVar3 >> 0x23) - (short)(lVar3 >> 0x3f)) + uVar1;
iVar9 = iVar9 + 2;
puVar11 = puVar11 + 2;
*puVar11 = ((short)(int)(lVar2 >> 0x23) - (short)(lVar2 >> 0x3f)) + uVar1;
} while (sVar17 != 0);
}
else {
do {
lVar2 = (longlong)iVar22 * (longlong)(int)(uVar18 * (iVar9 + 2));
lVar3 = (longlong)iVar22 * (longlong)(int)(uVar18 * (iVar9 + 1));
sVar17 = sVar17 + -1;
puVar11[1] = uVar1 - ((short)(int)(lVar3 >> 0x23) - (short)(lVar3 >> 0x3f));
iVar9 = iVar9 + 2;
puVar11 = puVar11 + 2;
*puVar11 = uVar1 - ((short)(int)(lVar2 >> 0x23) - (short)(lVar2 >> 0x3f));
} while (sVar17 != 0);
}
uVar7 = uVar7 + 1 & 0xfffeffff;
} while ((int)uVar7 < (int)((int)puVar8 - 1U));
}
uVar7 = (int)puVar8 - 1;
if (0 < (int)uVar7)
{
puVar12 = DAT_80013e84;
puVar24 = DAT_80013e80;
if ((uVar7 & 1) != 0)
{
puVar24 = DAT_80013e80 + 0x19;
puVar12 = DAT_80013e84 + 0x19;
*puVar12 = *puVar24;
}
uVar7 = uVar7 * 0x8000 >> 0x10;
while (uVar7 != 0)
{
puVar12[0x19] = puVar24[0x19];
puVar24 = puVar24 + 0x32;
uVar7 = uVar7 - 1 & 0xffff;
puVar12 = puVar12 + 0x32;
*puVar12 = *puVar24;
}
}
uVar7 = 0;
puVar11 = puVar8 + -1;
if (0 < (int)puVar11)
{
do
{
iVar9 = DAT_80013e88 + uVar7 * 0x32;
uVar1 = *(ushort *)(iVar9 + 0x18);
uVar13 = *(ushort *)(iVar9 + 0x4a);
if (uVar1 < uVar13)
{
psVar14 = (short *)(iVar9 + 0x18);
iVar9 = 0;
sVar17 = 0xc;
do
{
lVar2 = (longlong)iVar22 * (longlong)(int)((uint)(ushort)(uVar13 - uVar1) * (iVar9 + 1));
lVar3 = (longlong)iVar22 * (longlong)(int)((uint)(ushort)(uVar13 - uVar1) * (iVar9 + 2));
sVar17 = sVar17 + -1;
psVar14[1] = ((short)(int)(lVar2 >> 0x23) - (short)(lVar2 >> 0x3f)) + uVar1;
iVar9 = iVar9 + 2;
psVar14 = psVar14 + 2;
*psVar14 = ((short)(int)(lVar3 >> 0x23) - (short)(lVar3 >> 0x3f)) + uVar1;
} while (sVar17 != 0);
}
else
{
psVar14 = (short *)(iVar9 + 0x18);
iVar9 = 0;
sVar17 = 0xc;
do
{
lVar2 = (longlong)iVar22 * (longlong)(int)((uint)(ushort)(uVar1 - uVar13) * (iVar9 + 1));
lVar3 = (longlong)iVar22 * (longlong)(int)((uint)(ushort)(uVar1 - uVar13) * (iVar9 + 2));
sVar17 = sVar17 + -1;
psVar14[1] = uVar1 - ((short)(int)(lVar2 >> 0x23) - (short)(lVar2 >> 0x3f));
iVar9 = iVar9 + 2;
psVar14 = psVar14 + 2;
*psVar14 = uVar1 - ((short)(int)(lVar3 >> 0x23) - (short)(lVar3 >> 0x3f));
} while (sVar17 != 0);
}
puVar8 = (ushort *)(uVar7 + 1);
uVar7 = (uint)puVar8 & 0xfffeffff;
} while ((int)uVar7 < (int)puVar11);
}
uVar7 = uVar19 >> 1;
if (uVar19 != 0)
{
uVar18 = uVar7;
puVar11 = DAT_80013e90;
puVar8 = DAT_80013e8c;
puVar23 = (uint16 *)((int)puVar21 + -2);
if ((uVar19 & 1) != 0)
{
puVar8 = DAT_80013e8c + 1;
puVar11 = DAT_80013e90 + 1;
*(short *)puVar21 = (short)((uint)*puVar8 + (uint)*puVar11 >> 1);
puVar23 = puVar21;
}
while (uVar18 != 0)
{
*(short *)((int)puVar23 + 2) = (short)((uint)puVar8[1] + (uint)puVar11[1] >> 1);
*(short *)(uint16 *)((int)puVar23 + 4) = (short)((uint)puVar11[2] + (uint)puVar8[2] >> 1);
uVar18 = uVar18 - 1;
puVar11 = puVar11 + 2;
puVar8 = puVar8 + 2;
puVar23 = (uint16 *)((int)puVar23 + 4);
}
}
uVar5 = uVar19 * DAT_80013e94;
uVar18 = uVar5 >> 0x13;
uVar6 = uVar18 - 1;
if (0 < (int)uVar6)
{
puVar11 = (ushort *)((int)puVar21 + -0xc);
puVar8 = DAT_80013e98;
if ((uVar6 & 1) != 0)
{
puVar11 = (ushort *)((int)puVar21 + 0xc);
puVar8 = DAT_80013e98 + 0xc;
*puVar8 = *puVar11;
}
uVar6 = uVar6 * 0x8000 >> 0x10;
while (uVar6 != 0)
{
puVar8[0xc] = puVar11[0xc];
puVar11 = puVar11 + 0x18;
uVar6 = uVar6 - 1 & 0xffff;
puVar8 = puVar8 + 0x18;
*puVar8 = *puVar11;
}
}
iVar22 = uVar18 - 2;
if (0 < iVar22)
{
puVar8 = DAT_80013e9c;
}
uVar18 = 0;
if (0 < iVar22)
{
do
{
iVar9 = DAT_80013e88 + uVar18 * 0x18;
uVar1 = *(ushort *)(iVar9 + 0xc);
uVar13 = *(ushort *)(iVar9 + 0x24);
if (uVar1 < uVar13)
{
uVar6 = (uint)(ushort)(uVar13 - uVar1);
iVar15 = 1;
sVar17 = 5;
psVar14 = (short *)(iVar9 + 0xe);
*psVar14 = ((short)(int)((longlong)(int)puVar8 * (longlong)(int)uVar6 >> 0x21) - (short)((longlong)(int)puVar8 * (longlong)(int)uVar6 >> 0x3f)) + uVar1;
do
{
lVar2 = (longlong)(int)puVar8 * (longlong)(int)(uVar6 * (iVar15 + 1));
lVar3 = (longlong)(int)puVar8 * (longlong)(int)(uVar6 * (iVar15 + 2));
sVar17 = sVar17 + -1;
psVar14[1] = ((short)(int)(lVar2 >> 0x21) - (short)(lVar2 >> 0x3f)) + uVar1;
iVar15 = iVar15 + 2;
psVar14 = psVar14 + 2;
*psVar14 = ((short)(int)(lVar3 >> 0x21) - (short)(lVar3 >> 0x3f)) + uVar1;
} while (sVar17 != 0);
}
else
{
uVar6 = (uint)(ushort)(uVar1 - uVar13);
iVar15 = 1;
sVar17 = 5;
psVar14 = (short *)(iVar9 + 0xe);
*psVar14 = uVar1 - ((short)(int)((longlong)(int)puVar8 * (longlong)(int)uVar6 >> 0x21) - (short)((longlong)(int)puVar8 * (longlong)(int)uVar6 >> 0x3f));
do
{
lVar2 = (longlong)(int)puVar8 * (longlong)(int)(uVar6 * (iVar15 + 1));
lVar3 = (longlong)(int)puVar8 * (longlong)(int)(uVar6 * (iVar15 + 2));
sVar17 = sVar17 + -1;
psVar14[1] = uVar1 - ((short)(int)(lVar2 >> 0x21) - (short)(lVar2 >> 0x3f));
iVar15 = iVar15 + 2;
psVar14 = psVar14 + 2;
*psVar14 = uVar1 - ((short)(int)(lVar3 >> 0x21) - (short)(lVar3 >> 0x3f));
} while (sVar17 != 0);
}
uVar18 = uVar18 + 1 & 0xfffeffff;
} while ((int)uVar18 < iVar22);
}
if (uVar19 != 0)
{
uVar18 = uVar7;
puVar23 = (uint16 *)((int)puVar21 + -2);
puVar8 = DAT_80013e90;
if ((uVar19 & 1) != 0)
{
puVar8 = DAT_80013e90 + 1;
*(short *)puVar21 = (short)((uint)*(ushort *)puVar21 + (uint)*puVar8 >> 1);
puVar23 = puVar21;
}
while (uVar18 != 0)
{
puVar10 = (uint16 *)((int)puVar23 + 4);
*(ushort *)((int)puVar23 + 2) = (ushort)((uint)*(ushort *)((int)puVar23 + 2) + (uint)puVar8[1] >> 1);
*(ushort *)puVar10 = (ushort)((uint)puVar8[2] + (uint)*(ushort *)puVar10 >> 1);
uVar18 = uVar18 - 1;
puVar23 = puVar10;
puVar8 = puVar8 + 2;
}
}
uVar5 = uVar5 >> 0x12;
uVar18 = uVar5 - 1;
if (0 < (int)uVar18)
{
puVar11 = (ushort *)((int)puVar21 + -6);
puVar8 = DAT_80013ea0;
if ((uVar18 & 1) != 0)
{
puVar11 = (ushort *)((int)puVar21 + 6);
puVar8 = DAT_80013ea0 + 6;
*puVar8 = *puVar11;
}
uVar18 = uVar18 * 0x8000 >> 0x10;
while (uVar18 != 0)
{
puVar8[6] = puVar11[6];
puVar11 = puVar11 + 0xc;
uVar18 = uVar18 - 1 & 0xffff;
puVar8 = puVar8 + 0xc;
*puVar8 = *puVar11;
}
}
uVar18 = DAT_80013ea8;
uVar5 = uVar5 - 2;
if (0 < (int)uVar5)
{
uVar5 = uVar5 & 0xffff;
puVar8 = DAT_80013ea4;
do
{
uVar1 = *puVar8;
uVar13 = puVar8[6];
if (uVar1 < uVar13)
{
uVar13 = uVar13 - uVar1;
uVar6 = (uint)uVar13;
puVar8[1] = uVar1 + (ushort)(uVar6 * DAT_80013e94 >> 0x12);
puVar8[2] = uVar1 + (short)(uint)((ulonglong)uVar13 * 2 * (ulonglong)uVar18 >> 0x22);
puVar8[3] = uVar1 + (short)(uint)((ulonglong)(uVar6 * 3) * (ulonglong)uVar18 >> 0x22);
puVar8[4] = uVar1 + (short)(uint)((ulonglong)uVar13 * 4 * (ulonglong)uVar18 >> 0x22);
puVar8[5] = uVar1 + (short)(uint)((ulonglong)(uVar6 * 5) * (ulonglong)uVar18 >> 0x22);
}
else
{
uVar13 = uVar1 - uVar13;
uVar6 = (uint)uVar13;
puVar8[1] = uVar1 - (ushort)(uVar6 * DAT_80013e94 >> 0x12);
puVar8[2] = uVar1 - (short)(uint)((ulonglong)uVar13 * 2 * (ulonglong)uVar18 >> 0x22);
puVar8[3] = uVar1 - (short)(uint)((ulonglong)(uVar6 * 3) * (ulonglong)uVar18 >> 0x22);
puVar8[4] = uVar1 - (short)(uint)((ulonglong)uVar13 * 4 * (ulonglong)uVar18 >> 0x22);
puVar8[5] = uVar1 - (short)(uint)((ulonglong)(uVar6 * 5) * (ulonglong)uVar18 >> 0x22);
}
uVar5 = uVar5 - 1 & 0xffff;
puVar8 = puVar8 + 6;
} while (uVar5 != 0);
}
if (uVar19 != 0)
{
puVar23 = (uint16 *)((int)puVar21 + -2);
puVar8 = DAT_80013e90;
if ((uVar19 & 1) != 0)
{
puVar8 = DAT_80013e90 + 1;
*(short *)puVar21 = (short)((uint)*(ushort *)puVar21 + (uint)*puVar8 >> 1);
puVar23 = puVar21;
}
if (uVar7 != 0)
{
do
{
puVar11 = (ushort *)((int)puVar23 + 2);
uVar7 = uVar7 - 1;
puVar23 = (uint16 *)((int)puVar23 + 4);
*puVar11 = (ushort)((uint)*puVar11 + (uint)puVar8[1] >> 1);
puVar8 = puVar8 + 2;
*(ushort *)puVar23 = (ushort)((uint)*(ushort *)puVar23 + (uint)*puVar8 >> 1);
} while (uVar7 != 0);
return;
}
return;
}
return;
}
return;
}
Just a question or suggestion nut sure... ;D
If code looks strange why not just skip it and try to make it your way. You might save some time?
If at later times you find out that your code indeed needs some more work you can get back to that part and improve it?
I am also a developer (mostly C# + t-sql) and I often have to fix other people mistakes.
But it's usually faster to just do part of the code (or sql procedure) from scratch than trying to get into the brains of someone who had little knowledge and was just trying to get the job done...
I am also a developer (mostly C# + t-sql) and I often have to fix other people mistakes.
With C# this is or was the case with just the tools themselfTrue true. But it pays the bills... ;)
memcpy(auStack104,DAT_80000f40 + 0x5000,0xc);
memset((uint)(puVar6 + 0x5000),0xc,0xff);
80000dcc 05 19 85 e2 add r1,r5,#0x14000
80000dd0 92 0f 8d e2 add r0,sp,#0x248
80000dd4 5d fd ff eb bl memcpy longlong memcpy(void * dest, voi
80000dd8 ff 20 a0 e3 mov r2,#0xff
80000ddc 0c 10 a0 e3 mov r1,#0xc
80000de0 05 09 85 e2 add r0,r5,#0x14000
80000de4 a7 fd ff eb bl memset void memset(uint address, uint c
sudo ./sunxi-fel -p spiflash-read 0 2097152 w25q16_new_scope.bin
And on the big flex cable there is no IC on top or bottom side:
Is it my internet or is EEVBLOG having problems. :-// The last couple of days it takes longer to load a page or start a new post. To get to this one it first timed out and needed a reload to get it open again.
Edit: Why is the image not being showed on the "attachimg=1" location? I used the "Inline full-size image" option.
Once the FNIRSI is done you can have a peek at the webserver code here in EEVBLOG...
//Setup the interrupt for the USB interface
setup_interrupt(TMR0_IRQ_NUM, usb_irq_handle, 0);
//Setup the interrupt for the USB interface
setup_interrupt(USB_IRQ_NUM, usb_irq_handle, 0);
1423 18.279385 host 1.18.1 USBMS 95 SCSI: Read(10) LUN: 0x00 (LBA: 0x0000c660, Len: 240)
1424 18.279399 1.18.1 host USB 64 URB_BULK out
1425 18.279435 host 1.18.1 USB 64 URB_BULK in
1426 18.290936 1.18.1 host USBMS 122944 SCSI: Data In LUN: 0x00 (Read(10) Response Data)
1427 18.290982 host 1.18.1 USB 64 URB_BULK in
1428 18.291015 1.18.1 host USBMS 77 SCSI: Response LUN: 0x00 (Read(10)) (Good)
1429 18.291098 host 1.18.1 USBMS 95 SCSI: Read(10) LUN: 0x00 (LBA: 0x0000c750, Len: 16)
1430 18.291145 1.18.1 host USB 64 URB_BULK out
1431 18.291180 host 1.18.1 USB 64 URB_BULK in
1432 18.292487 1.18.1 host USBMS 8256 SCSI: Data In LUN: 0x00 (Read(10) Response Data)
1433 18.292525 host 1.18.1 USB 64 URB_BULK in
1434 18.292562 1.18.1 host USBMS 77 SCSI: Response LUN: 0x00 (Read(10)) (Good)
1435 18.292895 host 1.18.1 USBMS 95 SCSI: Read(10) LUN: 0x00 (LBA: 0x0000c760, Len: 240)
1436 18.292906 1.18.1 host USB 64 URB_BULK out
1437 18.292946 host 1.18.1 USB 64 URB_BULK in
1440 18.304417 1.18.1 host USBMS 122944 SCSI: Data In LUN: 0x00 (Read(10) Response Data)
1441 18.304462 host 1.18.1 USB 64 URB_BULK in
1442 18.304477 1.18.1 host USBMS 77 SCSI: Response LUN: 0x00 (Read(10)) (Good)
1443 18.304554 host 1.18.1 USBMS 95 SCSI: Read(10) LUN: 0x00 (LBA: 0x0000c850, Len: 16)
1444 18.304563 1.18.1 host USB 64 URB_BULK out
1445 18.304569 host 1.18.1 USB 64 URB_BULK in
1446 18.305946 1.18.1 host USBMS 8256 SCSI: Data In LUN: 0x00 (Read(10) Response Data)
1447 18.305979 host 1.18.1 USB 64 URB_BULK in
1448 18.306014 1.18.1 host USBMS 77 SCSI: Response LUN: 0x00 (Read(10)) (Good)
1449 18.306096 host 1.18.1 USBMS 95 SCSI: Read(10) LUN: 0x00 (LBA: 0x0000c860, Len: 240)
1450 18.306106 1.18.1 host USB 64 URB_BULK out
1451 18.306145 host 1.18.1 USB 64 URB_BULK in
1452 18.317644 1.18.1 host USBMS 122944 SCSI: Data In LUN: 0x00 (Read(10) Response Data)
1453 18.317676 host 1.18.1 USB 64 URB_BULK in
1454 18.317685 1.18.1 host USBMS 77 SCSI: Response LUN: 0x00 (Read(10)) (Good)
1455 18.317752 host 1.18.1 USBMS 95 SCSI: Read(10) LUN: 0x00 (LBA: 0x0000c950, Len: 16)
1456 18.317800 1.18.1 host USB 64 URB_BULK out
1457 18.317844 host 1.18.1 USB 64 URB_BULK in
1458 18.319139 1.18.1 host USBMS 8256 SCSI: Data In LUN: 0x00 (Read(10) Response Data)
1459 18.319173 host 1.18.1 USB 64 URB_BULK in
1460 18.319211 1.18.1 host USBMS 77 SCSI: Response LUN: 0x00 (Read(10)) (Good)
1461 18.319297 host 1.18.1 USBMS 95 SCSI: Read(10) LUN: 0x00 (LBA: 0x0000c960, Len: 240)
1462 18.319307 1.18.1 host USB 64 URB_BULK out
1463 18.319345 host 1.18.1 USB 64 URB_BULK in
1464 18.330856 1.18.1 host USBMS 122944 SCSI: Data In LUN: 0x00 (Read(10) Response Data)
1465 18.330911 host 1.18.1 USB 64 URB_BULK in
1466 18.330948 1.18.1 host USBMS 77 SCSI: Response LUN: 0x00 (Read(10)) (Good)
1467 18.331002 host 1.18.1 USBMS 95 SCSI: Read(10) LUN: 0x00 (LBA: 0x0000ca50, Len: 16)
1468 18.331022 1.18.1 host USB 64 URB_BULK out
1469 18.331026 host 1.18.1 USB 64 URB_BULK in
1470 18.332387 1.18.1 host USBMS 8256 SCSI: Data In LUN: 0x00 (Read(10) Response Data)
1471 18.332393 host 1.18.1 USB 64 URB_BULK in
1472 18.332460 1.18.1 host USBMS 77 SCSI: Response LUN: 0x00 (Read(10)) (Good)
1473 18.332477 host 1.18.1 USBMS 95 SCSI: Read(10) LUN: 0x00 (LBA: 0x0000ca60, Len: 240)
1474 18.332528 1.18.1 host USB 64 URB_BULK out
1475 18.332533 host 1.18.1 USB 64 URB_BULK in
1476 18.344028 1.18.1 host USBMS 122944 SCSI: Data In LUN: 0x00 (Read(10) Response Data)
1477 18.344086 host 1.18.1 USB 64 URB_BULK in
1478 18.344133 1.18.1 host USBMS 77 SCSI: Response LUN: 0x00 (Read(10)) (Good)
1479 18.344189 host 1.18.1 USBMS 95 SCSI: Read(10) LUN: 0x00 (LBA: 0x0000cb50, Len: 16)
1480 18.344214 1.18.1 host USB 64 URB_BULK out
1481 18.344248 host 1.18.1 USB 64 URB_BULK in
1482 18.345597 1.18.1 host USBMS 8256 SCSI: Data In LUN: 0x00 (Read(10) Response Data)
1483 18.345604 host 1.18.1 USB 64 URB_BULK in
1484 18.345659 1.18.1 host USBMS 77 SCSI: Response LUN: 0x00 (Read(10)) (Good)
1485 18.345727 host 1.18.1 USBMS 95 SCSI: Read(10) LUN: 0x00 (LBA: 0x0000cb60, Len: 240)
1486 18.345738 1.18.1 host USB 64 URB_BULK out
1487 18.345792 host 1.18.1 USB 64 URB_BULK in
1488 18.357253 1.18.1 host USBMS 122944 SCSI: Data In LUN: 0x00 (Read(10) Response Data)
1489 18.357300 host 1.18.1 USB 64 URB_BULK in
1490 18.357307 1.18.1 host USBMS 77 SCSI: Response LUN: 0x00 (Read(10)) (Good)
1491 18.357363 host 1.18.1 USBMS 95 SCSI: Read(10) LUN: 0x00 (LBA: 0x0000cc50, Len: 43)
1492 18.357373 1.18.1 host USB 64 URB_BULK out
1493 18.357427 host 1.18.1 USB 64 URB_BULK in
1494 18.359918 1.18.1 host USBMS 22080 SCSI: Data In LUN: 0x00 (Read(10) Response Data)
1495 18.359929 host 1.18.1 USB 64 URB_BULK in
1496 18.359955 1.18.1 host USBMS 77 SCSI: Response LUN: 0x00 (Read(10)) (Good)
1473 37.161925 host 1.17.1 USBMS 95 SCSI: Read(10) LUN: 0x00 (LBA: 0x000110c0, Len: 240)
1474 37.161974 1.17.1 host USB 64 URB_BULK out
1475 37.162023 host 1.17.1 USB 64 URB_BULK in
1478 37.518151 1.17.1 host USBMS 122944 SCSI: Data In LUN: 0x00 (Read(10) Response Data)
1479 37.518224 host 1.17.1 USB 64 URB_BULK in
1480 37.518299 1.17.1 host USBMS 77 SCSI: Response LUN: 0x00 (Read(10)) (Good)
1481 37.518440 host 1.17.1 USBMS 95 SCSI: Read(10) LUN: 0x00 (LBA: 0x000111b0, Len: 16)
1482 37.518488 1.17.1 host USB 64 URB_BULK out
1483 37.518542 host 1.17.1 USB 64 URB_BULK in
1484 37.546236 1.17.1 host USBMS 8256 SCSI: Data In LUN: 0x00 (Read(10) Response Data)
1485 37.546310 host 1.17.1 USB 64 URB_BULK in
1486 37.546372 1.17.1 host USBMS 77 SCSI: Response LUN: 0x00 (Read(10)) (Good)
1487 37.547731 host 1.17.1 USBMS 95 SCSI: Read(10) LUN: 0x00 (LBA: 0x000111c0, Len: 240)
1488 37.547798 1.17.1 host USB 64 URB_BULK out
1489 37.547857 host 1.17.1 USB 64 URB_BULK in
1490 37.904446 1.17.1 host USBMS 122944 SCSI: Data In LUN: 0x00 (Read(10) Response Data)
1491 37.904558 host 1.17.1 USB 64 URB_BULK in
1492 37.904623 1.17.1 host USBMS 77 SCSI: Response LUN: 0x00 (Read(10)) (Good)
1493 37.904795 host 1.17.1 USBMS 95 SCSI: Read(10) LUN: 0x00 (LBA: 0x000112b0, Len: 16)
1494 37.904831 1.17.1 host USB 64 URB_BULK out
1495 37.904851 host 1.17.1 USB 64 URB_BULK in
1496 37.932611 1.17.1 host USBMS 8256 SCSI: Data In LUN: 0x00 (Read(10) Response Data)
1497 37.932640 host 1.17.1 USB 64 URB_BULK in
1498 37.932652 1.17.1 host USBMS 77 SCSI: Response LUN: 0x00 (Read(10)) (Good)
1499 37.932763 host 1.17.1 USBMS 95 SCSI: Read(10) LUN: 0x00 (LBA: 0x000112c0, Len: 240)
1500 37.932820 1.17.1 host USB 64 URB_BULK out
1501 37.932877 host 1.17.1 USB 64 URB_BULK in
1520 38.289367 1.17.1 host USBMS 122944 SCSI: Data In LUN: 0x00 (Read(10) Response Data)
1521 38.289441 host 1.17.1 USB 64 URB_BULK in
1522 38.289468 1.17.1 host USBMS 77 SCSI: Response LUN: 0x00 (Read(10)) (Good)
1523 38.289631 host 1.17.1 USBMS 95 SCSI: Read(10) LUN: 0x00 (LBA: 0x000113b0, Len: 16)
1524 38.289645 1.17.1 host USB 64 URB_BULK out
1525 38.289657 host 1.17.1 USB 64 URB_BULK in
1532 38.317430 1.17.1 host USBMS 8256 SCSI: Data In LUN: 0x00 (Read(10) Response Data)
1533 38.317488 host 1.17.1 USB 64 URB_BULK in
1534 38.317502 1.17.1 host USBMS 77 SCSI: Response LUN: 0x00 (Read(10)) (Good)
1535 38.317612 host 1.17.1 USBMS 95 SCSI: Read(10) LUN: 0x00 (LBA: 0x000113c0, Len: 240)
1536 38.317626 1.17.1 host USB 64 URB_BULK out
1537 38.317638 host 1.17.1 USB 64 URB_BULK in
1628 38.674216 1.17.1 host USBMS 122944 SCSI: Data In LUN: 0x00 (Read(10) Response Data)
1629 38.674310 host 1.17.1 USB 64 URB_BULK in
1630 38.674337 1.17.1 host USBMS 77 SCSI: Response LUN: 0x00 (Read(10)) (Good)
1631 38.674464 host 1.17.1 USBMS 95 SCSI: Read(10) LUN: 0x00 (LBA: 0x000114b0, Len: 16)
1632 38.674479 1.17.1 host USB 64 URB_BULK out
1633 38.674502 host 1.17.1 USB 64 URB_BULK in
1640 38.702252 1.17.1 host USBMS 8256 SCSI: Data In LUN: 0x00 (Read(10) Response Data)
1641 38.702326 host 1.17.1 USB 64 URB_BULK in
1642 38.702341 1.17.1 host USBMS 77 SCSI: Response LUN: 0x00 (Read(10)) (Good)
1643 38.702457 host 1.17.1 USBMS 95 SCSI: Read(10) LUN: 0x00 (LBA: 0x000114c0, Len: 240)
1644 38.702472 1.17.1 host USB 64 URB_BULK out
1645 38.702484 host 1.17.1 USB 64 URB_BULK in
1722 39.059089 1.17.1 host USBMS 122944 SCSI: Data In LUN: 0x00 (Read(10) Response Data)
1723 39.059195 host 1.17.1 USB 64 URB_BULK in
1724 39.059258 1.17.1 host USBMS 77 SCSI: Response LUN: 0x00 (Read(10)) (Good)
1725 39.059427 host 1.17.1 USBMS 95 SCSI: Read(10) LUN: 0x00 (LBA: 0x000115b0, Len: 16)
1726 39.059463 1.17.1 host USB 64 URB_BULK out
1727 39.059474 host 1.17.1 USB 64 URB_BULK in
1730 39.087230 1.17.1 host USBMS 8256 SCSI: Data In LUN: 0x00 (Read(10) Response Data)
1731 39.087261 host 1.17.1 USB 64 URB_BULK in
1732 39.087272 1.17.1 host USBMS 77 SCSI: Response LUN: 0x00 (Read(10)) (Good)
1733 39.087376 host 1.17.1 USBMS 95 SCSI: Read(10) LUN: 0x00 (LBA: 0x000115c0, Len: 240)
1734 39.087398 1.17.1 host USB 64 URB_BULK out
1735 39.087412 host 1.17.1 USB 64 URB_BULK in
1736 39.443931 1.17.1 host USBMS 122944 SCSI: Data In LUN: 0x00 (Read(10) Response Data)
1737 39.444045 host 1.17.1 USB 64 URB_BULK in
1738 39.444121 1.17.1 host USBMS 77 SCSI: Response LUN: 0x00 (Read(10)) (Good)
1739 39.444293 host 1.17.1 USBMS 95 SCSI: Test Unit Ready LUN: 0x00
1740 39.444317 1.17.1 host USB 64 URB_BULK out
1741 39.444327 host 1.17.1 USB 64 URB_BULK in
1742 39.444362 1.17.1 host USBMS 77 SCSI: Response LUN: 0x00 (Test Unit Ready) (Good)
1743 39.444519 host 1.17.1 USBMS 95 SCSI: Read(10) LUN: 0x00 (LBA: 0x000116b0, Len: 10)
1744 39.444543 1.17.1 host USB 64 URB_BULK out
1745 39.444553 host 1.17.1 USB 64 URB_BULK in
1746 39.461909 1.17.1 host USBMS 5184 SCSI: Data In LUN: 0x00 (Read(10) Response Data)
1747 39.461939 host 1.17.1 USB 64 URB_BULK in
1748 39.461950 1.17.1 host USBMS 77 SCSI: Response LUN: 0x00 (Read(10)) (Good)
I usually compile with O2. The speed increase is noticeable.
Why does the optimization break the touchscreen?
The touch panel delay routine was an empty for loop. This is removed by the compiler when optimization is set to 1 or higher. Changed it to an assembly loop and now it works with optimization level O2.
The speed of the sliding in of the menu's is much better now. There will still be room for improvement, but the first goal is to get working code that mimics the scope.
And that is coming along, but still a lot of work. Put in the code for changing the screen brightness. It uses special functionality of the FPGA, for which I reversed the code a while back but did not test it until now. Happy to say that it works.
Oh, and all this time I thought the "pc" in "pcprogrammer" stood for "personal computer" :-DD
MEMORY
{
ram : org = 0x7FFFFFE0, len = 32M
}
SECTIONS
{
. = ORIGIN(ram);
.text :
{
build/Debug/GNU_ARM-Linux/start.o (.text)
*(.text);
} >ram
.data :
{
*(.data);
*(.rodata);
} >ram
BSS_START = .;
.bss :
{
*(.bss);
} >ram
BSS_END = .;
__program_size = SIZEOF(.text) + SIZEOF(.data);
}
MEMORY
{
ram : org = 0x7FFFFFE0, len = 32M
}
SECTIONS
{
. = ORIGIN(ram);
PRGM_START = .;
.text :
{
build/Debug/GNU_ARM-Linux/start.o (.text)
*(.text);
} >ram
.data :
{
*(.data);
*(.rodata);
} >ram
PRGM_END = .;
BSS_START = .;
.bss :
{
*(.bss);
} >ram
BSS_END = .;
}
__program_size = PRGM_END - PRGM_START;
//Connect the scope to the computer and enable USB
//Un-mount the partition
sudo umount /dev/sdc1
//Load the package
sudo dd if=fnirsi_1013d.bin of=/dev/sdc bs=1024 seek=8
//Connect the scope to the computer and enable USB
//Un-mount the partition
sudo umount /dev/sdc1
//Un-load the package
sudo dd if=/dev/zero of=/dev/sdc bs=1024 seek=8 count=1
0x76 0x8B 0x76 0x8B 0xA0 0xB9 0xD0 0xDE 0xEC 0xF0 0xEE 0xE4 0xCF 0xC1 0xA6 0x91
0x7C 0x6B 0x60 0x59 0x5D 0x67 0x76 0x8A 0xA1 0xB9 0xD0 0xDD 0xEC 0xF1 0xEE 0xE4
0xD0 0xC1 0xA7 0x90 0x7C 0x6B 0x60 0x59 0x5D 0x68 0x77 0x8A 0xA1 0xB9 0xD0 0xDE
... I wrote before that the scope makes up its own signal when the input frequency is above some value. Did calculations on it, and determined it is more then 43.3MHz This can be seen in the video near the end. I start at 80MHz, which it does measure, so hats of for that, but the amplitude is faked. My version next to it shows a much smaller signal. There only the up sampling is done.
When I lower the frequency the signal on both gets bigger and I have to lower the sensitivity. After that I start fiddling around the 43MHz. When I switch to 44MHz you can see the signal strength increase :-DD (Near 0:49 into the video) This is not the case on my version. ...
A detailed study of the origin of such a suspicious smoothness of the oscillogram showed that at sweeps of 10 ns / div. and 25 ns / div. when the frequency of the input signal goes from 43.3 MHz to 43.4 MHz, the oscilloscope begins to turn any signal into the purest sine!
... The turning orange of the "buttons" means they are being touched. Same as for the trigger (T) menu changing color. When the scope is touched it also freezes the signals on the screen.Oh, of course. I haven't noticed this because I cover buttons with my finger while touching them and I didn't pay attention what's happening there under. :-[
This could easily mean that the touch panel has a hardware problem or reacts to some interference due to sensitivity settings.However, freezing isn't always related to scope considering menu button being touched and so altering button color - it frequently freezes without any visible changes on the screen, likely this needs some more investigation.
Could you run my firmware backup program I posted on the previous page? Take the new one. When you follow the steps given in the post with the red warnings you will be fine. Upload the files here on the forum and I can take a look at the touch panel settings to see if it differs from "normal"As far as I understand from your referred post, the proposed method implies using Linux as PC OS while all my machines are Windows at this moment, so it seems not so straightforward in my case, nevertheless what's the easiest workaround?
Also try to make a video of the behavior and open a dispute on Aliexpress, even though the 15 days might be over. Use the chat function to get them to open a dispute for you. It is not how the scope should behave and thus makes it a defective device.I checked product page once again and yes it has some warranty statement in description so maybe it's worth following your proposal, I just want to collect more exhaustive data as it's still appearing, yesterday more-less normal work of the device was present after it has been on for a few hours, today after switching it on I've noticed some more strange things apart of those already mentioned - such as partial display of input signal, when left side of the screen displays close to reality, while from center and to the right some garbled-frozen mix is displayed.
For checking if the touch panel is the sole cause of your problems, open up the scope and disconnect the touch panel cable. Small 6 pin connector near the bigger display connector. Many pictures in this thread showing the inside.Yes I've seen this. ;)
The scope freezes where ever the touch panel is touched. So no button needs to be active.I still should say that if freezing won't happen without touch-screen this still shouldn't strictly mean its pure hardware problem, may also be wrong software reaction to panel signals - not actually happening while disconnected.
If the freezing keeps happening it is safe to say there is an other problem :-//
No matter which seller, if you bought it on Aliexpress they can force the restitution if they decide in your favor.The problem is that after 15-day period there's no more option to "open dispute" thus involving Aliexpress, the only option now seems to be contacting particular seller, what I've already done and waiting for response.
Edit: It is possible to run linux from an usb stick. As long as dd is available on the stick it will work without wrecking your windows machine, as long as you make sure the drive you target is the correct one. Look for live linux on google or so. (https://www.linuxliveusb.com/ (https://www.linuxliveusb.com/))Ok, I'll see this option on occasion.
No matter which seller, if you bought it on Aliexpress they can force the restitution if they decide in your favor.The problem is that after 15-day period there's no more option to "open dispute" thus involving Aliexpress, the only option now seems to be contacting particular seller, what I've already done and waiting for response.
(correct me if I'm wrong)
You should start a chat session with the Aliexpress robot eve and insist on getting a human on the line. Might take a while, but it will help. Explain your problem and mention that you have proof. Best to have your video ready. Insist on them opening a dispute for you. I have done this a couple of times and with success. One time even after months of the protection period running out.Ok, I'll try this option if I won't succeed with the seller.
Concerning your trace looking weird, I have no explanation for that :-// That is one strange looking signal. What is the source you are measuring?I'm as usually just touching the probe tip with my hand, so it's the common inside-building 50Hz interference on the screen. ;D
But still, opening the scope up and disconnecting the touch panel and do measurements without it will give a better insight in the problem. Without it, it is very unlikely that there will be touch detected. It needs a specific response on the I2C bus, even though it is bit banged, to decide there is touch.Of course I'll also try this. But my notice was that if there's say wrong software reaction to correct panel signals, the former may not happen while the latter remains disconnected.
If it removes the problems you will have to replace the touch panel. Not an easy task but doable. Lots of info about that in the thread too.With all existing and awaiting problems it seems that just getting one more such scope could become best option overall - for both cross-diagnostic and cross-repair purposes, the only concern being as it's already clear - its already compromised reliability. :-\
You should start a chat session with the Aliexpress robot eve and insist on getting a human on the line. Might take a while, but it will help. Explain your problem and mention that you have proof. Best to have your video ready. Insist on them opening a dispute for you. I have done this a couple of times and with success. One time even after months of the protection period running out.Ok, I'll try this option if I won't succeed with the seller.
Ah ha, 50Hz signal a like. Think it is better to use the calibration signal to do a more proper diagnosis.Concerning your trace looking weird, I have no explanation for that :-// That is one strange looking signal. What is the source you are measuring?I'm as usually just touching the probe tip with my hand, so it's the common inside-building 50Hz interference on the screen. ;D
The idea of bad software is less likely. To my opinion a fallen over bit won't show such behavior. Since I reversed the whole user interface part of the software, I can explain all the freezing behavior, except the weird signal stopping and re-starting on a later location on the screen. The two problems might not be related.But still, opening the scope up and disconnecting the touch panel and do measurements without it will give a better insight in the problem. Without it, it is very unlikely that there will be touch detected. It needs a specific response on the I2C bus, even though it is bit banged, to decide there is touch.Of course I'll also try this. But my notice was that if there's say wrong software reaction to correct panel signals, the former may not happen while the latter remains disconnected.
There are ate least two things backing this option:
- touching the "frozen" button always corrects the situation (while if there was panel failure falsely imitating respective touch signal, there should rather be no reaction to actual touch of the same button),
- freezing frequently happens without any visible menu button alteration (while in case alike "bad panel - good software" it should be always followed by altered menu button color as the "legal" cause of freezing).
If it removes the problems you will have to replace the touch panel. Not an easy task but doable. Lots of info about that in the thread too.With all existing and awaiting problems it seems that just getting one more such scope could become best option overall - for both cross-diagnostic and cross-repair purposes, the only concern being as it's already clear - its already compromised reliability. :-\
Hello Ultimator,
I had problems with this scope (I have one of the first models with the old box).
Sometimes it didn't want to start at all or crashed.
It was due to bad soldering on the FPGA.
I re-worked it with good solder and the right amount of flux ( ;))
I cleaned everything with IPA and now it now works like a charm.
I would not wait. The seller will not offer you anything since there is no dispute. Delaying it their game.It's just a usual expression of politeness valid for for a few days while awaiting for seller response - as most sellers don't welcome customers raising disputes in advance of contacting them personally first.
Ah ha, 50Hz signal a like. Think it is better to use the calibration signal to do a more proper diagnosis.Rather not in this particular case, as my goal was to expose freezing in auto mode when display update shouldn't stop even with unstable input signal - which so is more suitable to provoke this fault.
The idea of bad software is less likely. To my opinion a fallen over bit won't show such behavior. Since I reversed the whole user interface part of the software, I can explain all the freezing behavior, except the weird signal stopping and re-starting on a later location on the screen. The two problems might not be related.It's a subject for further investigation, in addition to testing the touch panel and RC values on its bus.
My explanation for the behavior he was seeing is that when the MCU reads the status register of the touch panel, the bit signaling touch is flipped, and then when it reads the coordinates it gets the last coordinates touched. In your case it might be reading a prolonged false being touch status. The scope waits for the touch to be released before continuing.It's still unclear for me what causes freezing when there's no altering-color indication of some button seemingly still being touched.
Sure that is an option, but I would then consider buying a Hantek DSO2C10 and upgrade that to a DSO2D15. A better scope with more options and not that much more expensive. Lots of info about it on this forum.No wonder that many full-size benchtop scopes are more capable even regarding their higher cost, but the very idea behind 1013D is it's unique field-portable-full-screeen form-factor - also being the reason of my interest in this device.
Hello Ultimator,I'll check for assembly-related issues when testing touch panel, but in case of partial display fault it's strange that signal crops frequently do happen in highly synchronized manner at exactly the same position on the screen as in my previous screenshot. This can hardly be explained by bad soldering of IC.
I had problems with this scope (I have one of the first models with the old box).
Sometimes it didn't want to start at all or crashed.
It was due to bad soldering on the FPGA.
I re-worked it with good solder and the right amount of flux ( ;))
I cleaned everything with IPA and now it now works like a charm.
Hi Ultimator,This is also on "to do" list, just slightly further.
It would be interesting to see if your problem with the touch panel also occurs with my version of the software. The whole user interface part works the same, and there is trace display on channel one.
I wrote my own I2C bit banging and like to believe it is better than the original 8)
The procedure to get it running is the same as the firmware backup program, so in your case a bit of a problem.
The package is also on page 45 of this thread.
My explanation for the behavior he was seeing is that when the MCU reads the status register of the touch panel, the bit signaling touch is flipped, and then when it reads the coordinates it gets the last coordinates touched. In your case it might be reading a prolonged false being touch status. The scope waits for the touch to be released before continuing.It's still unclear for me what causes freezing when there's no altering-color indication of some button seemingly still being touched.
Sure that is an option, but I would then consider buying a Hantek DSO2C10 and upgrade that to a DSO2D15. A better scope with more options and not that much more expensive. Lots of info about it on this forum.No wonder that many full-size benchtop scopes are more capable even regarding their higher cost, but the very idea behind 1013D is it's unique field-portable-full-screeen form-factor - also being the reason of my interest in this device.
Touch, no matter where on the screen, freezes the display. It is how the software is. The moment it sees touch it looks at the coordinates and decides what to do with it, but only does it after touch is released, or there is movement. (Trace offset, cursors, etc.) But as long as there is touch the updating of the signal stops. You can see this when in roll mode (100mS/div and up). Touch the screen and the updating stops.In other words when display freezes without visible altering some menu button color - this likely means that false touch is still being detected but in area where there are no menu buttons, so this aspect can be considered logically explained.
For me it was the small size that made me buy it :) The fact that it arrived with a defective touch screen led me to where we are now. Almost reverse engineered software :-DDWho could know in advance that finally it will appear cheaper to buy "expensive" branded alternative. I seem to be closing to this too.
Can I put in a request to KEEP the Tap Left/Right method to change the timebase - I find this an extremely easy way to change timebase up/down - WITHOUT having to click away at menu's. Annoying menu's (especially for trigger settings), was the main reason I didn't get a Hantek, I found setting my (borrowed) DSO5102P annoyingly tedious
ctrl + alt + t to open a terminal window
sudo apt-get update #Load latest package list
sudo apt-get upgrade #Upgrade what is needed to latest version
sudo apt-get autoclean #Clean the package list
sudo apt-get autoremove #Remove no longer needed packages
sudo chmod +x netbeans-8.2-cpp-linux-x64.sh #Change the execution flag for this file
sudo ./netbeans-8.2-cpp-linux-x64.sh #run this file to instal netbeans
sudo apt-get install gcc make build-essential #install all the needed tools for making and building code
sudo apt-get install gcc-arm-none-eabi #install the gnu arm compiler tools (needed for compiling the scope project for the real target)
I am trying to follow along and so far I got your experimental firmware working on the box. It looks promising.
And why not use the correct lowercase 's' for seconds in the 'Time per Division' choices block?
Maybe you can add an indication of the resulting 'Samples per Division' somewhere, at the bottom of this foldout?.
A new item on the ACQ menu might be the choice of sample 'processing': to display the sample dots, linear interpolation or whatever approximation is possible with the processor. Or, maybe a choice of averaging 1, 2, 4, .., many.
Did you have any problems with the SD card format, or did the partition already start on a high enough sector?
I'm working on determining this at the moment. Making a spread sheet with all the possible sample rates and time per division settings to determine what is useful. For instance, when using the highest sample rate and 5us/div there are not enough samples for a full screen. Only 21% of the screen can be filled. The question is if this has any use and if it is better to limit the settings to only 1us/div on which it has enough samples for a full screen?
This boundary shifts with the lowering of the sample rate. At a certain point it makes not a lot of sense to switch to the smaller time per division settings. It will only be a straight line from one side of the screen to the other.
Something to think about. Input is welcome :)
Some kicking in open doors(Dutch expression):
Did you have any problems with the SD card format, or did the partition already start on a high enough sector?
The smallest micro SD the local 'Expert' shop has available was 16GB. I dd'ed your test firmware on it and copied the standard files as well. Swapped the card with the original (8GB) one in the box. It simply worked!! I did not do any re-partitioning.
The problem with making a new FPGA programming is the loading it to the scopes out there. You have to open up your scope and attach a programmer to the flash connected to the FPGA. The scope needs to be on to be able to read this flash, at least that is my experience. So most like the same applies for programming.Sure, I do agree with that view. Loading another FPGA content is a delicate business, avoiding to damage anything. And maybe it isn't needed to improve the box's behavior. The original firmware seems not too shabby getting the 'wiggly lines' on the screen.
That is why I have been trying to make something based on the hardware as is now.
Hello everyone.
I have an oscilloscope with the inscription FNIRSI on the front panel. Extracted the firmware.
When installing a new firmware, the image is shifted up and to the left.
Loading another FPGA content is a delicate business, avoiding to damage anything. And maybe it isn't needed to improve the box's behavior. The original firmware seems not too shabby getting the 'wiggly lines' on the screen.
The battery charging icon, the arrow, points to the right, to the bottom of the battery symbol. My first thought was: the battery is discharching. Maybe point the arrow to the left to indicate that battery level is increasing.
About the ACQ menu: When selecting a sample rate in the upper block the available gray - white indication in the lower block does not change. Only after selecting a gray or white item in the time per division block the gray - white indication changes according the earlier selected sample rate.
The trigger levels on both traces are about right, from time base 10 ms / div. up to 500ns / div. The 50% button is not active? On the highest speeds trigger is way of. On the slowest time base settings roll mode is not implemented yet, and the trigger level indicator is still showing.
Now about the signals on the screen: The new firmware, like the previous one causes flashing interruptions of the traces, combined with wild excursions. They occur at irregular intervals of about several seconds, irregular, Like missing a heart beat. More noticeable on the higher speeds. This needs to be solved somehow.
Comparing this new firmware with the original one it is obvious that the original firmware does average a few captures. This can be observed by using the single mode. In single mode the original firmware shows a trace with noise while this noise is filtered out when running in normal or auto. It is averaged out by averaging at least two or more captured traces.*) Your new firmware does not do any averaging (as yet) and so the trace in auto or normal mode shows the noise the same as single mode. And it makes the trigger point 'jittery'.
*) This same effect is noticeable on my Hameg when variating the number of averages of the trace.
So it seems the original firmware uses averaging. Now I start speculating:.... Most probably this is done by the FPGA, even at the same time as capturing a new trace. Maybe some of the memory blocks are used for this purpose, storing intermediate results. Together with the use of the secret IC, it makes me wonder:... can't you use the capture functions as they are in the original firmware?. The original firmware is OKish here. Only the shortest time / div settings are producing nonsense. Here it is better just to show the user what is captured and maybe try to do real equivalent time sampling...? With fixed 50% trigger level?
I have a lot of respect for your efforts, but since it is unpractical to change the FPGA programming I think the best thing is to use it as it was designed. When the original capture stuff is working in your firmware you have already achieved a lot. And there is more coming.. I hope.
Here it is better just to show the user what is captured and maybe try to do real equivalent time sampling...?
Hello everyone.
I have an oscilloscope with the inscription FNIRSI on the front panel. Extracted the firmware.
When installing a new firmware, the image is shifted up and to the left.
About the ACQ menu: When selecting a sample rate in the upper block the available gray - white indication in the lower block does not change. Only after selecting a gray or white item in the time per division block the gray - white indication changes according the earlier selected sample rate.
Hi Maurits,Hi Peter,
especially for you :)
What do you think, is this a genuine Altera Cyclone IV?The part number found in the programming stream by tv84 is 0x020F1, that checks with the IDCODE for EP4CE6 (Cyclone IV Device Handbook, Volume 1, table 10-2).
The part number found in the programming stream by tv84 is 0x020F1, that checks with the IDCODE for EP4CE6 (Cyclone IV Device Handbook, Volume 1, table 10-2).
Open On-Chip Debugger 0.10.0
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Warn : Adapter driver 'usb_blaster' did not declare which transports it allows; assuming legacy JTAG-only
Info : only one transport option; autoselect 'jtag'
Info : No lowlevel driver configured, will try them all
Info : usb blaster interface using libftdi
Info : This adapter doesn't support configurable speed
Info : JTAG tap: sesame.tap tap/device found: 0x18006c31 (mfg: 0x618 (<unknown>), part: 0x8006, ver: 0x1)
Error: sesame.tap: IR capture error; saw 0x3ff not 0x1
Warn : Bypassing JTAG setup events due to errors
Warn : gdb services need one or more targets defined
Any idea on how it can be tested to see if it offers the full EP4CE10 capabilities?
Open On-Chip Debugger 0.10.0
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Warn : Adapter driver 'usb_blaster' did not declare which transports it allows; assuming legacy JTAG-only
Info : only one transport option; autoselect 'jtag'
Warn : sesame.tap: nonstandard IR value
Info : No lowlevel driver configured, will try them all
Info : usb blaster interface using libftdi
Info : This adapter doesn't support configurable speed
Info : JTAG tap: sesame.tap tap/device found: 0x18006c31 (mfg: 0x618 (<unknown>), part: 0x8006, ver: 0x1)
Warn : gdb services need one or more targets defined
TapName Enabled IdCode Expected IrLen IrCap IrMask
-- ------------------- -------- ---------- ---------- ----- ----- ------
0 sesame.tap Y 0x18006c31 0x18006c31 10 0x03 0x03
open("project.svf"): No such file or directory
svf svf [-tap device.tap] <file> [quiet] [nil] [progress] [ignore_error]
xsvf (tapname|'plain') filename ['virt2'] ['quiet']
They need a better name. "FNIRSI" how does one pronounce that?
Good one :-DDThey need a better name. "FNIRSI" how does one pronounce that?
I think it might be an acronym?
F - Fictional
N - Non-triggering
I - Imaginary
R - Real-time
S - Sampling
I - Instrument
The problem with this hardware is that the DC offset is not on the front end circuitry and therefore does not help in amplifier saturation. It is on the "negative" input of the ADC, so the signal is already through the amplifier before any shifting is done.
//Data read out special IC
if(f_open(&viewfp, "special_ic_data.txt", FA_CREATE_NEW | FA_WRITE) == FR_OK)
{
uint32 offset;
uint32 offset1;
uint32 offset2;
int8 valuestring[100];
int8 *ptr;
int8 headerstring[] = "low,high,result\n";
f_write(&viewfp, headerstring, sizeof(headerstring) - 1, 0);
for(offset1=200;offset1<=1500;offset1+=50)
{
for(offset2=1500;offset2>=200;offset2-=50)
{
offset = fpga_read_parameter_ic(0x12, (offset1 & 0x0000FFFF) | (offset2 << 16));
ptr = scope_print_decimal(valuestring, offset1, 0);
*ptr++ = ',';
ptr = scope_print_decimal(ptr, offset2, 0);
*ptr++ = ',';
ptr = scope_print_decimal(ptr, offset, 0);
*ptr++ = '\n';
f_write(&viewfp, valuestring, ptr - valuestring, 0);
}
}
//Close the file to finish the write
f_close(&viewfp);
//Show the saved successful message
scope_display_file_status_message(MESSAGE_SAVE_SUCCESSFUL, 1);
}
//Load the data bytes with the value
parameter_buffer[3] = (uint8)(value >> 24);
parameter_buffer[4] = (uint8)(value >> 16);
parameter_buffer[5] = (uint8)(value >> 8);
parameter_buffer[6] = (uint8)(value);
//Check if MSB is actually used
if(parameter_buffer[3] == 0x00)
{
//Set the MSB to a fixed value if not used
parameter_buffer[3] = 0x69;
//Take one of the length
length--;
}
//Check if MLSB is actually used
if(parameter_buffer[4] == 0x00)
{
//Set the MLSB to a fixed value if not used
parameter_buffer[4] = 0x96;
//Take one of the length
length--;
}
//Check if LMSB is actually used
if(parameter_buffer[5] == 0x00)
{
//Set the LMSB to a fixed value if not used
parameter_buffer[5] = 0x99;
//Take one of the length
length--;
}
//Load the data bytes with the value
parameter_buffer[3] = (uint8)(value >> 24);
parameter_buffer[4] = (uint8)(value >> 16);
parameter_buffer[5] = (uint8)(value >> 8);
parameter_buffer[6] = (uint8)(value);
//Check if MSB is actually used
if(parameter_buffer[3] == 0x00)
{
//Set the MSB to a fixed value if not used
parameter_buffer[3] = 0x69;
//Take one of the length
length--;
//When MSB is not used check if MLSB is actually used
if(parameter_buffer[4] == 0x00)
{
//Set the MLSB to a fixed value if not used
parameter_buffer[4] = 0x96;
//Take one of the length
length--;
//When MSB and MLSB are not used check if LMSB is actually used
if(parameter_buffer[5] == 0x00)
{
//Set the LMSB to a fixed value if not used
parameter_buffer[5] = 0x99;
//Take one of the length
length--;
}
}
}
Edit1: The software on linux is in English and needs to be started with ./td -gui
Edit2: The manual frenky supplied shows that the TD application can convert Quartus projects if the device is pin compatible. Should then be easy enough to get started by converting a simple Quartes design :)
pcVar16[10] = (char)uVar10; //Start on 10mns/div
set_fpga_trigger_timebase();
get_short_timebase_data(); //Uses the normal capture system to get the samples and calculate min, max, etc.
if (pcVar16[0x23] == '\0') //Trigger channel
{
calculate_ch1_min_max_avg();
iVar12 = DAT_8000278c; //0x801AC04A channel 1 buffer 4
}
else
{
calculate_ch2_min_max_avg();
iVar12 = DAT_80002788; //0x801AD7BA channel 2 buffer 4
}
uVar13 = 0;
puVar20 = (ushort *)(iVar12 + 0x14);
uVar18 = 0; //max value
uVar19 = uVar5; //0x0000FFFF min value
iVar11 = iVar4;
//Determine min and max value
do
{
uVar17 = (uint)*puVar20; //Active channel sample buffer
puVar20 = puVar20 + 1;
if (uVar18 < uVar17) //Get max
{
uVar18 = uVar17;
}
if (uVar17 < uVar19) //Get min
{
uVar19 = uVar17;
}
iVar11 = iVar11 + -1;
} while (iVar11 != 0);
uVar15 = 10;
uVar17 = uVar18 - uVar19 & 0xffff; //vpp
*(short *)(pcVar16 + 0x26) = (short)(uVar18 + uVar19 >> 1); //center value for trigger level 50%
X Error of failed request: BadMatch (invalid parameter attributes)
Major opcode of failed request: 73 (X_GetImage)
Serial number of failed request: 20
Current serial number in output stream: 20
//Connect the scope to the computer and enable USB (MENU -> USB Connection)
//Un-mount the partition. Make sure the scope is connected to /dev/sdc. Can be checked with lsblk command.
sudo umount /dev/sdc1
//Un-load the package
sudo dd if=/dev/zero of=/dev/sdc bs=1024 seek=8 count=1
//Connect the scope to the computer and enable USB (MENU -> USB Connection)
//Un-mount the partition. Make sure the scope is connected to /dev/sdc. Can be checked with lsblk command.
sudo umount /dev/sdc1
//Load the package
sudo dd if=fnirsi_1013d.bin of=/dev/sdc bs=1024 seek=8
//Setup the scopes USB connection
//See where the device is connected and use that in the below commands. Mine always pops up at /dev/sdc
//This is needed for dd to work properly
sudo umount /dev/sdc1
//This puts the config data in sector 710
sudo dd if=shifted_display_config_sector.bin of=/dev/sdc bs=1024 seek=355
The data order is LSB first.
The data order is LSB first.
Nitpicking Peter: LSB or little endian?
In a not at all bandwidth related exercise I tested the 1013D's battery life.
It ran continuously for 6 h 45 m while monitoring two phases of a 4-phase stepper motor being accelerated and cycled clockwise/anticlockwise over a 270° sweep, pulse frequencies 7 to 44 Hz...
Pretty damned good, first thing I've tested that bettered the claimed spec. It took a 3½ hours to recharge at 1.8 A tapering to 0.3 A over the last ½ hour...
Aligns with what I have found.
Turn it on, forget that it is still running, go back two hours later, still plenty of power. Would be a good in-the-field device if they could improve the UI and accuracy. (Still limited by triggering options, capture depth, etc. – so not going to replace a 'real' portable 'scope for some applications.)
Plug it in to a PC or what have you, and it's fully charged very quickly.
Talking of chineese user interfaces,i have a hp 54503A scope,the on off/power switch is at the rear and not on the front panel,total ass to have to reach over the workbench to even turn it on! WTF!
uint32 dochannel1 = scopesettings.channel1.enable;
uint32 dochannel2 = scopesettings.channel1.enable;
uint32 dochannel2 = scopesettings.channel2.enable;
void scope_prepare_setup_for_file(void);
void scope_restore_setup_from_file(void);
int32 scope_check_waveform_file(void);
void scope_save_view_item_file(int32 type);
int32 scope_load_trace_data(void);
While doing so I found a small bug: if channel 1 is turned off, then the AUTO-SET function does not work.
And because of my poking I also found the solution: it can easily be corrected by just changing a '1' to a '2' in 8th line in the function scope_do_auto_setup() in scope_functions.c ...
I also guess how that happened - I only say: copy line...
Andreas
The new repository is created and loaded with the latest version.Maybe you could add a Signature in your Forum Profile with this info?
I'm afraid I'm kind of an old fart trying to figure out how to load any of this firmware. I saw comments about it only being for 8GB cards. I opened mine up and found it has a 1GB micro sd card. I have other 4, 8 and 16GB cards. Is there some way to use one of them to update the scope?
Thank you.
Hi, new here. I was looking for info about this oscilloscope which I plan to buy for checking stuff around the house (utility power, UPS, and portable generator outputs, etc.) My search took me to this forum and I'm glad it did.
I've started reading through a few pages but I've hardly scratched the surface as the information is overwhelming. Is there like a Wiki for this instrument where information about things like usage, capabilities, limitations, hacks, etc. are structured?
Thanks!
Hi TiredOldDad, also welcome to the forum.
Unfortunately there is no wiki about this instrument.
You write about checking things around the house and more specific mains power related issues. For that kind of work I would use a digital multi meter, which is safer than hooking up a scope to mains voltage. Even with a battery powered scope like this one, things can easily go wrong.
This scope is nice for simple projects with micro-controllers or other electronics were the signals are large enough to measure. This scope can measure in steps of ~3mV at best. The hardware only does 100mV per division, with 8 divisions for a full screen. This with an 8 bit ADC means 0,003125V per step.
If I was you I would do some more research or start a new thread with a more specified question for advice on buying the right equipment for your tasks.
Cheers,
Peter
...
This scope is nice for simple projects with micro-controllers or other electronics were the signals are large enough to measure. This scope can measure in steps of ~3mV at best. The hardware only does 100mV per division, with 8 divisions for a full screen. This with an 8 bit ADC means 0,003125V per step.
...
RE FFT- My experiece with "hybrid" FFT + waveforms is that one other the is compromised in display, i.e. you get 1-2 cycles of waveform and little ore no detail in the FFT OR you get lots of waves such that you cant really see them but useful detail in the FFT. I currently have one scope (Tek 5K) looking at the waveform and another (Tek 7K + Wavetek FFT plug in) for the FFT. A good FFT interface is important for the spectrum to be useful. I would not hesitate to get a second 1013 for a spectrum display if I got useful info from having both. In the larger scheme it would be very cost effective.
Since we can modify the firmware what about the feasibility of hacking the front-end hardware to give a higher amplification mode?
Dear friends. I bought a non working 1013D at eBay. The scope starts up but the touchpad is inoperative. Im gessing the F1C100S sends the TP configuration on start up, if this is true, something is wrong because no I2C signals are present at any time at the TP connector. I removed the flash I and put all the firmwares I found at /pecostm32, still nothing at the GT911 signal pins. You mentioned an arduino sketch to program de TP but Im unable to find it, any way would be great if you help me to save my toy. Thanks in advance. :-BROKE
sudo dd if=fel-sdboot.sunxi.txt of=/dev/sdc bs=1024 seek=8
Hi, new here. I was looking for info about this oscilloscope which I plan to buy for checking stuff around the house (utility power, UPS, and portable generator outputs, etc.)
Why I gess there is a problem with the TP (maybe just configuration) is because touching the panel send no I2C signals at all to the 100S.
Since the lines always seem to be high it can also be that they are shorted to VCC, causing larger currents to flow when the F1C100s makes these lines low. This could explain the high temperature of it.
It was not easy with older eyes and not as steady in the hand anymore as time has gone by rather quickly. One moment you are in your forties and then you are almost sixty.I'm also a kid of the 60s. And when I started working with electronics, components were big and my eyes were good. Then components kept getting smaller and my eyes getting worse, untl I crossed a threshold.
Hi everyone I'm a newbie I have a 2013d but the screen is cracked not the front glass it doesn't work at all does anyone know of a screen I can replace it with the makers do not want to know at all ⁴
frame bit tilename type x y
0 826 mic_lr_x0y22 miscs_mic_io_l 0 22
0 828 mic_lr_x0y22 miscs_mic_io_l 0 22
0 829 mic_lr_x0y22 miscs_mic_io_l 0 22
0 880 mic_lr_x0y22 miscs_mic_io_l 0 22
0 882 mic_lr_x0y22 miscs_mic_io_l 0 22
0 883 mic_lr_x0y22 miscs_mic_io_l 0 22
0 904 mic_lr_x0y22 miscs_mic_io_l 0 22
0 906 mic_lr_x0y22 miscs_mic_io_l 0 22
0 907 mic_lr_x0y22 miscs_mic_io_l 0 22
0 923 mic_lr_x0y22 miscs_mic_io_l 0 22
0 958 mic_lr_x0y22 miscs_mic_io_l 0 22
0 960 mic_lr_x0y22 miscs_mic_io_l 0 22
0 961 mic_lr_x0y22 miscs_mic_io_l 0 22
1 914 mic_lr_x0y22 miscs_mic_io_l 0 22
1 921 mic_lr_x0y22 miscs_mic_io_l 0 22
1 932 mic_lr_x0y22 miscs_mic_io_l 0 22
2 940 x0y20 pib 0 20
3 619 x0y26 pib 0 26
4 621 x0y26 pib 0 26
5 942 x0y20 pib 0 20
24 975 x0y19 pib 0 19
27 975 x0y19 pib 0 19
156 620 x5y26 plb 5 26
158 620 x5y26 plb 5 26
246 616 x8y26 pib 8 26
249 297 x8y32 pib 8 32
250 295 x8y32 pib 8 32
250 617 x8y26 pib 8 26
433 285 x14y32 plb 14 32
435 284 x14y32 plb 14 32
617 297 x20y32 plb 20 32
619 296 x20y32 plb 20 32
801 292 x26y32 plb 26 32
802 294 x26y32 plb 26 32
811 27 x26y37 pib 26 37
813 26 x26y37 pib 26 37
880 22 x28y37 pib 28 37
882 23 x28y37 pib 28 37
882 57 x28y36 plb 28 36
885 57 x28y36 plb 28 36
887 11 mic_tb_x28y37 miscs_mic_io_t 28 37
887 21 mic_tb_x28y37 miscs_mic_io_t 28 37
887 23 mic_tb_x28y37 miscs_mic_io_t 28 37
888 13 mic_tb_x28y37 miscs_mic_io_t 28 37
888 20 mic_tb_x28y37 miscs_mic_io_t 28 37
888 22 mic_tb_x28y37 miscs_mic_io_t 28 37
890 8 mic_tb_x28y37 miscs_mic_io_t 28 37
890 21 mic_tb_x28y37 miscs_mic_io_t 28 37
890 23 mic_tb_x28y37 miscs_mic_io_t 28 37
918 14 mic_tb_x29y37 miscs_mic_io_t 29 37
918 16 mic_tb_x29y37 miscs_mic_io_t 29 37
918 23 mic_tb_x29y37 miscs_mic_io_t 29 37
919 18 mic_tb_x29y37 miscs_mic_io_t 29 37
919 20 mic_tb_x29y37 miscs_mic_io_t 29 37
919 22 mic_tb_x29y37 miscs_mic_io_t 29 37
o56v~ 3 0
CcD 4 25 qPn"QxyGnwTr}5E.6 1 r|c\tR3qHSxT 2 r|c\tR3qPdeD 3 r|c\tR3rPT5CutIa 4 tN3}E_5D}ucVtVvd 5 E[5Or#cQ"G3|Ycg 6 C}2QP&as|In"W(e 7 E[5Or#cQ"G3|Yci 8 C}2QP&as|In"W(g 9 E[5Or#cQ"G3}Y[*3i+5G 10 tN3}E_5D}uc\+N(i\H 11 tN3}E_5D}uc\+Ze 12 qPn#C$2JF#W, 13 qPn#C$2JG#W, 14 qPn#C$2KP*Ge 15 qPn#C$2P[#W, 16 qPn#C$2Pd*3 17 r|c\tR3|Yce 18 C}2QP&a}(XB 19 tN3}E_5N)'8 20 P"a~qTn"W(e 21 E[5Or#c[+Vg 22 qPn#C$2Qd"V3qHS 23 tN3}E_5O)+8 24 P"a~qTn)G% 25
CerA 5 45 C}2QP&a}(X@ 26 tN3}E_5N)'5n5f99e!uBv 27 r|c\tR3|Yce 28 C}2QP&a}(XA5a88jpKnH 29 qPn#C$2Pd*5 30 r|c\tR3|Ycfa37iu7w@G 31 E[5Or#c[+Ve 32 qPn#C$2Pd*632ht<cI?x 33 P"a~qTn"W(e 34 E[5Or#c[+Vf2cs;h5Hp!t 35 tN3}E_5N)': 36 P"a~qTn"W(fcn:g:4y{J 37 C}2QP&a'uU 38 P"a~qTn)G%2cs;h5Hp!t 39 tN3#Lh5D&qQBeM32ht<cI?x 40 P"a$x]nuTr}cn:g:4y{J 41 C}2TW/at|OS|X32ht<cI?x 42 P"a$x]nyKw"cn:g:4y{J 43 C}2TW/axsPZ5a88jpKnH 44 qPn&J-2M^vN|2cs;h5Hp!t 45 tN3#Lh5N'|MRxa3?f{;73b 46 E[5Ry,c[)NzsIn5n6?iE53 47 r|c_{[3|W[|Ev2c{8n92q!uN63b 48 E[5Ry,c[)NzsIn5nG8une 49 C}2TW/a~&PXvG32qqBge26 50 P"a$x]n#U}yGT5aA5pthab 51 qPn&J-2Qb"KtucnCd@8cp:f9EcA 52 tN3#Lh5O'|MRxa3@f{;a;4xtgac 53 qPn&J-2Qb"KtucnCd@8c|Kze25 54 P"a$x]n#U}yGT5aAFi!q54 55 r|c_{[3}Y[*3i2c|KnHa<!xd:3a 56 E[5Ry,c\+N(a<n5oI?xHN;3b 57 E[5Ry,c_tF32ht<cI?x 58 P"a$x]n,Rrtcn:g:4y{J 59 n6?iD 60 Bd@8: 61 {8n92q!uN6 62 A5ptg 63 o6?iD 64 Cd@8cp:f9E 65 qqBg3:e!t;6 66 A5pt5oIK8 67 |KnHa<!xd: 68 AHp!tlzj 69 Fi!q 70
FjM 6 19 qPn&J-2FP$M&uJ 71 P"a$x]nuTr} 72 E[5Ry,cQ(C~c6Z 73 tN3#Lh5Ev~X\+Z 74 r|c_{[3sPZwK* 75 qPn&J-2G^$Hzw 76 E[5Ry,cR)D 77 r|c_{[3vMU% 78 C}2TW/axsPZ 79 tN3#Lh5K#sPZ 80 tN3#Lh5N'|MRx 81 C}2TW/a~&PXvG 82 r|c_{[3}Y[*3i 83 qPn&J-2Sbv 84 C}2TW/a$qH 85 P"a$x]n&Ks 86 qPn&J-2T[" 87 C}2TW/a$%I\+Z 88 r|c_{[3)TPw 89
r=Ac!t;uH2xsFc7> 1 1 txDaH8w!t 90
FkB2xtIv3Gh!r;c8 1 1 Cm}5v9Fx 91
!p?p3Gi!sJaH7v!tB 1 1 r=Ac!t;uH 92
Js!rA 0 1 r=Ac!t;uH 93
qPn"QxyGnwTr}5E.6 2 5 1 0 1
8< 1 vp:fF 2 Jes:t 3 K6pz 4 Mg 5
8B 6
macro 3 0
map 4 25 AL_LOGIC_DRAM16X4 1 AL_MAP_ADDER 2 AL_MAP_ALU2B 3 AL_MAP_BLE_ADDER 4 AL_MAP_BLE_GATE4 5 AL_MAP_BLE_LUT4 6 AL_MAP_BLE_LUT5 7 AL_MAP_BLE_LUT6 8 AL_MAP_BLE_LUT7 9 AL_MAP_BLE_MULT18X18 10 AL_MAP_BLE_MULT9X9 11 AL_MAP_BLE_MUX4 12 AL_MAP_F7MUX 13 AL_MAP_F8MUX 14 AL_MAP_GATE4 15 AL_MAP_LLMUX 16 AL_MAP_LUT1 17 AL_MAP_LUT2 18 AL_MAP_LUT3 19 AL_MAP_LUT4 20 AL_MAP_LUT5 21 AL_MAP_LUT6 22 AL_MAP_MULT_ADD 23 AL_MAP_MUX4 24 AL_MAP_SEQ 25
pack 5 45 AL_MAP_LUT1 26 AL_MAP_LUT1__default 27 AL_MAP_LUT2 28 AL_MAP_LUT2__default 29 AL_MAP_LUT3 30 AL_MAP_LUT3__default 31 AL_MAP_LUT4 32 AL_MAP_LUT4__default 33 AL_MAP_LUT5 34 AL_MAP_LUT5__default 35 AL_MAP_LUT6 36 AL_MAP_LUT6__default 37 AL_MAP_SEQ 38 AL_MAP_SEQ__default 39 AL_PHY_BRAM32K__default 40 AL_PHY_BRAM__default 41 AL_PHY_CLKDIV__default 42 AL_PHY_FIFO__default 43 AL_PHY_GCLK__default 44 AL_PHY_IOCLK__default 45 AL_PHY_LSLICE__lble5_2 46 AL_PHY_LSLICE__lble6_1 47 AL_PHY_LSLICE__lble_mux4_2 48 AL_PHY_LSLICE__lseq_2 49 AL_PHY_MSLICE__mble4_2 50 AL_PHY_MSLICE__mble5_1 51 AL_PHY_MSLICE__mble_adder_2 52 AL_PHY_MSLICE__mble_gate4_2 53 AL_PHY_MSLICE__mble_mux4_1 54 AL_PHY_MSLICE__mseq_2 55 AL_PHY_MULT18__mult18x18_1 56 AL_PHY_MULT18__mult9x9_2 57 AL_PHY_PAD__default 58 AL_PHY_VPAD__default 59 lble5 60 lble6 61 lble_mux4 62 mble4 63 mble5 64 mble_adder 65 mble_gate4 66 mble_mux4 67 mult18x18 68 mult9x9 69 seq 70
phy 6 19 AL_PHY_BANKREF 71 AL_PHY_BRAM 72 AL_PHY_BRAM32K 73 AL_PHY_CENTMUX 74 AL_PHY_CLKDIV 75 AL_PHY_CONFIG 76 AL_PHY_CSB 77 AL_PHY_FIFO 78 AL_PHY_GCLK 79 AL_PHY_IOCLK 80 AL_PHY_LSLICE 81 AL_PHY_MSLICE 82 AL_PHY_MULT18 83 AL_PHY_OSC 84 AL_PHY_PAD 85 AL_PHY_PIB 86 AL_PHY_PLL 87 AL_PHY_PREMUX 88 AL_PHY_VPAD 89
pin_test_tdpack 1 1 pin_test 90
pin_test_tdread 1 1 pin_test 91
pin_test_tdrtl 1 1 pin_test 92
work 0 1 pin_test 93
AL_LOGIC_DRAM16X4 2 5 1 0 1
di 1 raddr 2 waddr 3 wclk 4 we 5
do 6
34 34 34 34 105 0 0 1 1 16
253270 253271 253280 253281 253282 253283 253290 253291 253292 253293 253298 253299 253306 253307 253378 253380
34 34 34 34 106 0 0 1 1 18
253270 253271 253280 253281 253282 253283 253290 253291 253292 253293 253298 253299 253306 253307 253325 253335 253382 253384
34 34 34 34 107 0 0 1 1 18
253272 253273 253278 253279 253284 253285 253290 253291 253292 253293 253298 253299 253304 253305 253324 253326 253377 253379
34 34 34 34 108 0 0 1 1 16
253272 253273 253278 253279 253284 253285 253290 253291 253292 253293 253298 253299 253304 253305 253381 253383
34 34 34 34 109 0 0 1 1 18
253268 253269 253274 253275 253288 253289 253308 253309 253324 253326 253381 253382 253383 253384 253433 253434 253435 253436
34 34 34 34 110 0 0 1 1 12
253268 253269 253274 253275 253288 253289 253308 253309 253433 253434 253435 253436
34 34 34 34 111 0 1 1 0 0
34 34 34 34 112 0 1 1 0 0
34 34 34 34 113 0 1 1 0 0
34 34 34 34 114 0 1 1 0 0
34 34 34 34 115 0 1 1 0 0
34 34 34 34 116 0 1 1 0 0
Don't be so hard on your self.
Just brainstorming here:
Would it be easier to make new "code" for FPGA from scratch?
Could we replace this FPGA with some pin compatible that is easier to work with?
Anyway for me 1013D (with your firmware) is now perfectly usable DSO even if it gets no further updates...
BTW, yesterday I left the oscilloscope on and the battery is at exactly 0 voltys today, sad this toy has not an battery undervoltage protection.Many batteries has a built in BMS which does this,
Dear PCP, were can I find your latest 1013D .bin firmware, I gess this is what I must load to the SD card using the USB port. Thanks a lot.
Thanks PCP. After almost two hours I was able to transfer the new firmware (003) to the scope but sadly the touch screen is reversed. Is there something I can do?
Thanks for your effort dera friend. Now Im even more confused. No TL431/432 can produce any voltage bellow its 2.49V reference, so neither of the chips dedicated for VREF and VREF1 are TL´s.
In my OS. VREF is 2.49 (a correct value for a TL) and VREF1 is 1.2V, the correct value for 2.5/2, then my SMD marked 432 is something different to a TL. Still surprised about your 1.19V at VREF.
The setting for this is in the same menu as in the original. Menu -> system settings -> X-Y display mode. It is near the calibration setting, so you might have touched it by accident.Thanks, must've touched that while trying to navigate baseline calibration with inverted touch. :palm:
sudo dd if=standard_display_tp_xy_swap_config_sector.bin.txt of=/dev/sdc bs=1024 seek=355
Dear PCP, yesterday I got some timefor my toy and found all FOUR BNC decoupling capacitors short circuited, and as an extra de 150 nF input capacitor for channel one was 0 ohms too. Now the reference 1.25V is present at the BNC connectors thanks to you.
Which are de improvements on your firmware, I´m very curious about to know them in order to proceed with the flash with your help to invert X/Y TP coordinates.
Works perfectly now. For me only X-axis was inverted, I swapped the Y config value back to 0xFF and now touch works. Looking forward to playing around a bit more over the next few days.
Hello dear PCP, four hours and a half trying to send the .bin file to the scope and no way. I´m using a 4GB SD instead of the 8GB you are using,
it´s the only one variable, does it matter?
Thanks so much
Hello,
First of all, congratulations on your great efforts, especially the pcrogrammer member :clap: :-+
I noticed that when inserting new firmware (V0.002, V0.003, V0.004) when switching trigger mode to single or normal, the oscilloscope freezes after a couple of touch commands and must turn off after which we have to switch trigger mode to auto to used normally.
This does not happen with the original firmware, it is an older scope with 25Q16 flash.
Trigger mode is not overly necessary, but just to see if something can be fixed in one of the following firmware .
Came across this forum topic when I realized the FFT on this scope was rather lacking.
So I thought that having access to the .CSV data would allow me to process it on a pc using a python script.
Unfortunately the scope does not give you access to .CSV data.
So my first question I guess is the following: Is the plan to add this sort functionality(Access to .CSV file via usb) in the future?
I will be honest in saying that I have not attempted load this new firmware yet. (Afraid I will brick/damage scope, Significant amount of justification was involved to justify this purchase to my better half :scared: )
Therefore I don't know what functionality have been added so far in terms of MATHS functions.
Will basic maths functions be added: -,+,/,x?
Ahh nothing like checking the free support section in the morning :-DD
BTW the 1.2 Volts supply used by the FPGA is very stable, it comes from a linear regulator. Please tell me you have any good idea about hot to use your 0.005 and get an acceptable behavior.
BTW the 1.2 Volts supply used by the FPGA is very stable, it comes from a linear regulator. Please tell me you have any good idea about hot to use your 0.005 and get an acceptable behavior.
All the main voltages are made with linear regulators. Only for the display boost converters are used. The negative voltage you write about is only used for the display. The problem lies in the fact that they did not use a separate regulator for the ADC's supply and the way they made the DC offset voltages. Also the PCB design could have been better with separate ground planes and ferrite filters for the different sections of the circuit. The whole design is flawed and cheap.
It might be improved upon with bigger capacitors near the ADC's. The signal looks stable right up to the ADC input, so the wobble is introduced in the conversion.
I'm not going to make improvements to the software. It was fun and I learned a lot from doing the reverse engineering, but it was also frustrating at times.
Have you tried attaching an external regulator to the ADC? Zoombie board?
Do you have any suggestions for the switching noise when reduce lcd brightness?
There is a difference in the firmware of the units shipped recently.
But it is not available, to upgrade you have to buy a new product. :--
Would be interesting to see what they changed, but to buy a new unit for it :--
If anyone has a new unit they can try the firmware backup program I wrote to get a copy of the FLASH onto the SD card, and post it here.
Through the support contact recently, and they sent me this firmware file. :box:
The attached file is exactly as I received it, for both display models.
Can you check if they are really different? I don't trust this company.
Hello kerleada77,Thank you so much
welcome to the forum.
If you had searched this thread you would have found the link to where the schematics can be found.
All you need to work on the scope can be found here: https://github.com/pecostm32/FNIRSI-1013D-1014D-Hack (https://github.com/pecostm32/FNIRSI-1013D-1014D-Hack)
Hello, a new version of the 1013d oscilloscope came to me.If you think it's a new version/revision of the PCB,
In the readme there is also an explanation about the configuration file.
Most factory formatted SD cards have the free space needed before the partition to store the new firmware, so, I guess, yes you could use a new card.
Can't help you with the mac tools for formatting disks. Have never used modern mac's.
Reversing the programming: only in God mode...
Ok it took way more then 7 days, but if I had a son I would have to rename him Jesus, because I did it. :-DD
The verilog is quite crude and there are some errors still, which might be timing related, but it works on the scope, at least with my firmware.
You could also take a look at the Owon HDS242,
the specs are real and it goes down to 10mV/div.
Hey all, I'm pretty sure I used to have an account years ago to talk about repairs but I guess it's gone now :)in general, stay away from USB scopes like the Hantek 6022BE. I have one, and it's junk. No hardware trigger, no AC coupling, poor software (even if there are slightly better open osurce alternatives). Also, USB scopes put your laptop at risk when used for high voltages/currents like in a car
I wanted to take advantage of the 11.11 sales to get my first scope for basic hobby and electronics or car repair stuff. I don't work on electronics every day, and in fact more like a few times a month so I wanted to keep the budget reasonable. Is this scope still a decent option? Right now it's about $140 including shipping and VAT. Some other alternatives I see could be the Hantek 6022BE, maybe 1008c, or Owon VDS1022. The tablet/usb form factor I think would be helpful for using it outside occasionally.
I've read through (some) of this and other budget scope threads but unfortunately I don't know enough to be able to tell what's a big deal or not. Is 13ns rise time ok for a budget scope? Is fake 100Mhz better than the more realistic 20Mhz in the other scopes? Software/hardware triggers, etc, I've no idea. Use would be occasional Arduino/ESP32 project, hobby-level repair or watching sensors in the car, etc. Thanks, appreciate any suggestions.
For Arduino and similar, a logic analyzer is a much more useful tool than a scope. Even a ~$10 Saleae clone (24MHz, 8 channels) will give you a lot of value. Most of the times, when working with processors, you need to analyze digital signals and protocols, things a logic analyzers excels at, and very few scopes do well.
I never found that to be a problem. With proper triggering (currently using a DsLogic), you can capture the relevant event and have it displayed in a fraction of a second.
But sometimes you want to watch the signals in real time, which those gadgets don't seem to do.
(Why not? It would be 10x more useful... :-// )
By definition, signals you capture with a logic analyzer are too fast to be analyzed in real time. Even a relatively slow I2C fully decoded, is still too fast for real time display.
So, you basically want a multimeter set in voltmeter mode? >:DBy definition, signals you capture with a logic analyzer are too fast to be analyzed in real time. Even a relatively slow I2C fully decoded, is still too fast for real time display.
Sometimes I just want to see if a Arduino pin is changing or not after I press a button. I don't want to be constantly pressing "record"..."stop"...mouse around a bit to find the signal... :horse:
Just show me the state of the line in real time.
Incidentally, the hardware is capable of doing it, even the cheap $10 Seleae clones. Nobody seems to have written the code to handle it.
So, you basically want a multimeter set in voltmeter mode? >:D
BTW, could you produce a brief description of config file structure?
So, the question is:
are there kind enougth people, who can make card image from his Scope and upload here.
You might look at the DSO2512G:Thanks, this is what I ended up going with. Seems like both reasonably cheap and useful enough, and if I end up getting a real bench scope later, it would be a useful portable tool thus minimizing "waste" :) Let's see.
https://www.aliexpress.us/item/3256802899439203.html (https://www.aliexpress.us/item/3256802899439203.html)
Recent eevblog discussion:
https://www.eevblog.com/forum/testgear/new-2ch-pocket-dsosg-sigpeak-dso2512g/msg4506109/#msg4506109 (https://www.eevblog.com/forum/testgear/new-2ch-pocket-dsosg-sigpeak-dso2512g/msg4506109/#msg4506109)
Note that the video output is PAL not NTSC so you won't get color on NTSC monitors.
The Adrian Black video is here:
4/12 This $57 portable oscilloscope has a really cool feature (ZEEWEII DSO1511G review)
https://youtu.be/Uqrel5fQpK4 (https://youtu.be/Uqrel5fQpK4)
Adrian talks about the PAL/NTSC issue at 43:30.
Did you use the calibration function first?
Can a LM2577 or LM2596 be used instead of the MIC2903
TNX it helped a lot. BAT is ok on MIC29302 3.3V pin i have 1,92V. I have injected 3.3v on that pin and it has turned on. I have measured on the same chip input and it is BAT input but output is 1,92. So i assume that the MIC29302 is defect. Will order replacement chips.
I have used variable power supply to inject voltage (DPS5020) and it showed 0,8A at the beginning when the relays triggered, after that it has dropped to around 0,55A.
Maybe attach those photos with ref voltages into the git for easy troubleshoot.
I hope you will continue to make it better.
I found another bug. When connected to a sine with a DC offset, firstly, the autoset did not work, and secondly, synchronization was only when the trigger level was "under" the sine, as if a signal without a DC was being received by the trigger
Confirm
On a Windows PC with Rufus 3.21 the 'NO_LABEL.vhd' that you been so kind and packed
into V0.005_Windows.7z transferred to a 16GB SD
Reversing the programming: only in God mode...
Ok it took way more then 7 days, but if I had a son I would have to rename him Jesus, because I did it. :-DD
Ok, this is confiusing. One God worshipping another one. :scared:
However I wonder what this 1013D with unofficial firmware could do. I looked at the github repository and more or less parsed this thread, but I'm unable to get a feature list of shortcomings solved or new features added by this firmware. It seems that pcprogrammer's firmware more or less does for the FNIRSI the same as oriantbr's for the Owon. I would love to know what this device is capable of, after reflashing. Does that feature list exist? Could you guys give me a pointer to it? Are there any remaining problems?
Also it seem there are at least two variants of 1013D, with recessed or protruding BNC connectors. Any hints about which one would be "better"?
I would not advise buying either the FNIRSI 1013D or 1014D. The input sensitivity is crap. They say 50mV per division, but that is based on a software zoom. It is 100mV per division with a 1x probe.
But like tunk wrote, a bit more money spend can get your friend a better scope.
Michal Derkacz (github user ziutek) made an update for the firmware. He improved the RMS measurement and created a new version v0.006 for it. I merged it into the repository after looking at the code. Did not test it myself and took it on face value.
There is no new image file made like for version v0.005, so windows users who fail to use the binary in the repository have to hope on someone posting a new image file here on the forum.
@Sleo
What's wrong?
Launched with admin permissions
Tested on two PC and two card-readers
Your card may be formatted with not enough space between MBR and first partition. Try, please, press "Clear" button
Maybe you reccomend the right formating?
Clear did nothing.
Your card may be formatted with not enough space between MBR and first partition. Try, please, press "Clear" button
Maybe you reccomend the right formating?
Clear did nothing.
By the way. With Windows and original firmware, the oscilloscope mounts as a disk device one second after selecting "USB Connect". With PCProrgammer's firmware (v0.005 and v0.006 tested) this takes some time, maybe a minute. Just wait, then reselect device, if not in the list.
Checked with the device manager in Win10. There is a flick of the screen by tapping ON/OFF, could not find out if and what has changed.
....
Best to start a specific topic with the question about measuring high voltages. I'm no expert on this subject, but would not trust this scope to be save with a 10x probe measuring mains voltage.
But if you do make sure there is no USB connection to anything. Power adapter or computer.
Anyway, does anybody already do it ???? 10x probe to measure a pure sine wave of 230VAC ?
Of course somebody did :)
Just do not connect the scope to the computer with the USB cable during this measurement. The probe itself is limited to 600V peak-to-peak (at 10x) and the scope input is limited to about 40V (400v with 10x probe), so it's suitable for 230V power line measurement.
230V is an RMS value (measured at the line terminal with respect to the neutral terminal or vice versa). The peak value is 1.41 * Vrms = 325V. Both values are displayed relative to zero, which is the ground of the scope. On the one half of the period, Vpeak is +325V, on the other half -325V, so the total sine waveform sweep is 650V. But the maximum peak-to-peak voltage is only 325V with polarity reversal each half of a period.
This oscilloscope has a maximum v/div = 50v (with 10x att) and 8 vertical divisions, so the maximum screen space is 400V. The 650V wave will be off screen with 10x attenuation. To see the full wave, you need a probe with 100x attenuation. You can move the wave up or down to see the bottom or top half, but there is a bug in the alternative firmware with displaying vertically shifted waveforms.
Pictures 1 and 2 - alternative firmware v0.006, pictures 3 and 4 - original Fnirsi firmware.
I had a doubt about the 40V limit. I didn't know if it was -20 to 20V or -40 to 40V. As I have read you, the answer is -20 to 20V is the real limit.No, No. The answer is 40V difference, regardless of polarity. You can measure -40V relative to ground, or +40V relative to ground. But not +40V relative to -40V. This is not the case for an AC power line, where +V and -V present on L-wire relative to N-wire at different times. Maximum peak voltage between L and N for 230VAC line is 325V (absolute value). But the sine waveform is 650V in height due to polarity change during period.
Why have you not broken it with a 10x probe? You are really measuring -32.5 to 32.5V aren't you?40V limit was found in old version of scope manual. It's not a hardware limit, but just a scope screen height at max v/div. The hardware limit is very high, at least some hundred volts even with 1x probe. The input resistance is at least 1.2MOhm, allowable input current of operational amplifier protection diodes is 10 mA, so it needs about 12 KV on the input terminal to break the input amplifier. The real limit depends on the break voltage of passive components - resistors, capacitors, relays, PCB, probe, etc.
Do you know if I use a step down transformer to reduce 230VAC to .... 24VAC por example ... will it disturb/smooth/.... the wave? what about FFT (armonics) ? are they affected?Why not to use just a resistive divider? Two resistors 200-500 KOhm @ 0.5W should be a good choice. Transformer has an inductance and magnetization effects, that may affect your waveform.
1) get an X100 probe rated for 1 KV. They are not expensive if you don't need 200 MHz (you don't).I have one x100 from AliExpress claimed rated for 1KV. After some time it simply stop working, so I have to disassemble it. There was some problem with the central wire. It doesn't look reliable and safe enough. Resisters used in voltage divider definitely not rated for 1KV and isolation itself is very poor.
2) a transformer is a very good and safe way to monitor the power line.
It seems that RMS measurement implemented in the version v0.006 requires some changes for the saved WAVE files. Currently it doesn't show correct value.Good day. you can specify the problem more precisely. what it does, how it manifests itself, when and where.
Possible solutions could be: save calculated RMS value with the other WAVE file settings or recalculate RMS value from the file samples after loading.
Does anyone know of any bugs?
... You can move the wave up or down to see the bottom or top half, but there is a bug in the alternative firmware with displaying vertically shifted waveforms.
Pictures 1 and 2 - alternative firmware v0.006, pictures 3 and 4 - original Fnirsi firmware.
The benefit of this setup is that it is possible to move saved wave forms up and down, the down side that it does not work like the original.It seems to me that the best way is a combination of two - offset shift when live waveform moved, and screen data shift when saved waveform moved.
Does anyone know of any bugs?One more bug (or a feature) is a very slow storage device mounting on Windows (fw .005 to .013 tested, Win10/11). It takes about a minute after pressing "USB Connection". Original firmware mounts in a second.
Does anyone know of any bugs?... You can move the wave up or down to see the bottom or top half, but there is a bug in the alternative firmware with displaying vertically shifted waveforms.It's not a bug, it's a feature. The original programmer decided to move the signal only in software, the original firmware moves it by changing the voltage level on the AD converter. Otherwise, when you exceed the range of the converter in the alternative software, you will see the upper-limit or the lower-limit line.
Pictures 1 and 2 - alternative firmware v0.006, pictures 3 and 4 - original Fnirsi firmware.
This oscilloscope will never be good, so put a resistor in front of the probe and you will be in the AD converter range :D you will just have to use your head to calculate the voltage.
Look at pictures 2 and 4 in https://www.eevblog.com/forum/testgear/fnirsi-1013d-100mhz-tablet-oscilloscope/msg4768094/#msg4768094 (https://www.eevblog.com/forum/testgear/fnirsi-1013d-100mhz-tablet-oscilloscope/msg4768094/#msg4768094) - firmware .005 and .006 cute off top/bottom of wave that is higher half of screen, when center is shifted down/up (original firmware do not).
I have tried both firmwares and both shows the same behavior. On original when I do the test measure on the back of the oscilloscope the 1khz option the wave is shown. Also there is a clear view of the screen.Please pictures, thank
On both non original firmwares only one tiny violet line is shown when 1khz test is connected. And screen shows on the yellow tumbs brighter horizontal spots.
Can someone explain to me the reason why they did not use an analog trigger with a comparator?
FPGA Does anyone know what type it is?
I looked at it. It's a shame that you didn't finish it so that more memory is used for the samples. But it's very complicated. I would have to install new programs and learn how to work with them. And then what? new AD converters, new PCB, new input amplifier with divider. And finally, a box with a completely different oscilloscope.
Hi, I bought a new version of the oscilloscope, I am posting the file for the touchscreen. When I did backup according to the instructions, a message appeared on the display special touch panel detected.
So, I have to load the firmware into the oscilloscope, and when I find a problem (but it may be necessary to select the sdcard because it won't be able to click on the usb connection), I have to load the downloaded configuration into the loader, fix it and upload it. (I see that there are quite different numbers in his file)
Подскажите пожалуйста подключил свой fnirsi-1013D к компу хотел попробовать обновить,но при открытии программы за сомневался вроде ни че не нажимал потом отключил.Через день включаю он сначала заставка,а потом черный экран и надпись SD Cart error :-//Insert a new card into the oscilloscope, or format the card fat32 and use the loader program. Zip and clear/return to factory function. Alternatively, just remove and insert the card into the oscilloscope, sometimes the card has a bad contact.
Win 3x send message: usbd status canceled, but it takes 3x20s. And for 4 times the oscilloscope after the data is accepted and then the disk is connected.
I'll look into it, but it's very unknown things.
Подскажите пожалуйста подключил свой fnirsi-1013D к компу хотел попробовать обновить,но при открытии программы за сомневался вроде ни че не нажимал потом отключил.Через день включаю он сначала заставка,а потом черный экран и надпись SD Cart error :-//
Please tell me, I connected my fnirsi-1013D to the computer, I wanted to try to update, but when I opened the program I doubted it, I didn’t press anything, then I turned it off. Every other day I turn on the screensaver first, and then the black screen and the inscription
Hello, the mod firmware has a problem measuring high frequency sine waves.
Test video follow this link https://youtu.be/7SoDIUYZDho
...I didn't understand your phrase. Do I need to take any action?
P. S. You need a menu for calibration.
So what next? Implementation of FFT or hardware shift of the signal (in dc mode)
To determine if it is an error made by me or by Atlan, could you try the same test with my latest version found here (https://github.com/pecostm32/FNIRSI_1013D_Firmware/blob/main/fnirsi_1013d_scope/dist/Debug/GNU_ARM-Linux/fnirsi_1013d.bin).I cannot confirm this problem. Tested with a sine wave from 1 to 25 MHz, firmware v.005, v.006 and v.019b. I do not see any spikes, except of broken and shaky line due to no filtering. MHS-5200A DDS-generator was used.
But too late, I already fixed it. but it may still be seen.Confirmed, v.019b connected as fast as the original firmware.
Try it, the disk will be available in win7 in 6 seconds
thank you
I thought it was enough for fpga to send the value for the timer. (and appropriate fpga settings) And everything else is already provided by fpga, ie it takes 10 samples, makes an average and stores in fifo. When the memory fills up with 3000 samples, it will be notified. The data is then processed and displayed. I'm wrong?
If you are bored, take a peek at all the "labscope" automotive use cases on YouTube. You will find an amazing use of the scope for those cases. Pico automotive software is a good example.
According to the specs of FNIRSI-1013D it has 128Kpts storage but 4 screens seems very little.
...v0019c . Signal limitation occurs at 4.5 screen cells. On the original with 8 cells.
After these shifts, any DC will never measure it accurately.
v0.019c add hardware DC shift. Only channel 1 and only for positive osffet. (for negatives it should work as in previous versions)
automatic mode is now in DC mode and the offset is incredibly slow
...
Hello, I noticed one nuance, when setting the brightness of the display from 0 to 50% there is a squeak inside. Is it like this?
Tokar: try 0.019d?
Hi! Looks like a small bug with setting of pin 14 U1 (output from CPU to LCD) - very small amplitude of LCD_D12 (1V and 50Hz distortions from environment). On original FW there is full amplitude 3V. Because of it there is some graphical noise in a middle of screen (lower bit of Red color is distorted, it viewable on ACQ menu). Maybe this pin it is not programmed as output?
Also because of it startup logo have not quite smooth gradient
void sys_init_display(uint16 xsize, uint16 ysize, uint16 *address)
{
int32 time;
uint32 *ptr = DISPLAY_CONFIG_ADDRESS;
uint32 checksum = 0;
uint32 index;
//Setup the used port D pins for LCD
*PORTD_CFG0_REG = 0x22222227; //PD00 is not used for the display
*PORTD_CFG1_REG = 0x22272222; //PD12 is not used for the display
*PORTD_CFG2_REG = 0x00222222; //Only 22 pins for port D
I hope that there is no similar error when reading data from fpga.
I still can't get over the noise on the AD converter. I tried to use a 10-bit converter and the noise is almost the same... I tried to split the power supply for the analog and digital parts at 8-bit and it didn't help.
Menu for calibration of input dividers
Fill in "00" from 16 to 2047 physical sector.
//----------------------------------------------------------------------------------------------------------------------------------
//Defines
//----------------------------------------------------------------------------------------------------------------------------------
#define SETTINGS_SECTOR 700 //Location of the settings on the SD card for now
Nothing prevents you from uploading it, or another firmware again. But there will be confidence that no remnants from the previous code will interfere. Or did I misunderstand the question about deleting data?Fill in "00" from 16 to 2047 physical sector.
That is the way to get rid of the new firmware :-+
My goal was to get the device into flood condition. Neither the command zero nor the return to the default state via the loader will erase the configuration data from the sd card.
What will happen if it has more than 300kB?
I have a feeling that loader does not write data. I tried to write the configuration to sector 700. The result should be data corruption and loading of preset values. It didn't do anything. Even uploading a different configuration does nothing to the display. It will either not be written or the program data will be shifted and it will be written to the wrong location.I had to remember; the loader was written almost a year ago... It really rewrites one sector, i.e. 512 bytes, because of this is a requirement of WinAPI and driver. BUT it changes only the first 30 bytes (the rest 482 bytes is a copy of old sector), exactly as described by pcprogrammer. Sorry for misrepresentation. To write the whole sector you have to prepare 512-bytes binary file and load it using 'Firmware' tab (start sector may be edited by double click on words 'Start sector'). The location of written data should be correct, if you enter sector 700, loader writes to offset 0x57800. I just read sector 700 of my device (v0.019b) and corrected byte 16 (0x5780F) from 0x00 to 0x0F. As you can see in HxD it was written to correct location.
Code: [Select]//----------------------------------------------------------------------------------------------------------------------------------
#include "display_control.h"
#define DISPLAY_CONFIG_ADDRESS (uint32 *)0x81BFFC00
So check if your changes to the main program "fnirsi_1013d_scope" overwrite the memory starting from 0x81BFFC00 in any way.
So check if your changes to the main program "fnirsi_1013d_scope" overwrite the memory starting from 0x81BFFC00 in any way.
I have no way of finding out. For uP there is no development environment, no simulation.
If I understand correctly, the program from the sd card is copied to RAM. It is possible that there is already so much that the program (and RAM value etc Buffer) reached the address where the data for the display is.
It will not be easier to move the incriminated data further by a few KB
//----------------------------------------------------------------------------------------------------------------------------------
#define PROGRAM_START_SECTOR 48
#define DISPLAY_CONFIG_SECTOR 710
//----------------------------------------------------------------------------------------------------------------------------------
#define PROGRAM_START_SECTOR 92
Is it possible to return the .BMP to its original format? Оriginal .BMPs displays correctly everywhere.
Quite strange that the header is not found to be correct, because it is based on the guide lines given here (https://en.wikipedia.org/wiki/BMP_file_format).
Linux is a very fun system, just that fun cost me 3 hours of my life.
Quite strange that the header is not found to be correct, because it is based on the guide lines given here (https://en.wikipedia.org/wiki/BMP_file_format).
Maybe this will help fix the problem:
I look Pillow code. It check header size (https://github.com/python-pillow/Pillow/blob/main/src/PIL/BmpImagePlugin.py#L98) and raise error because header size is 56 bytes.
0.020f Did it solve the calibration problem?
Switch trigger to AUTO. Fix later...
It already works in every mode v0.020h, thanks for reporting the error. if only they were such easy mistakes.
..connect the required voltage to both channels at once..
Quite strange that the header is not found to be correct, because it is based on the guide lines given here (https://en.wikipedia.org/wiki/BMP_file_format).
Maybe this will help fix the problem:
I look Pillow code. It check header size (https://github.com/python-pillow/Pillow/blob/main/src/PIL/BmpImagePlugin.py#L98) and raise error because header size is 56 bytes.
Quite strange that the header is not found to be correct, because it is based on the guide lines given here (https://en.wikipedia.org/wiki/BMP_file_format).
Maybe this will help fix the problem:
I look Pillow code. It check header size (https://github.com/python-pillow/Pillow/blob/main/src/PIL/BmpImagePlugin.py#L98) and raise error because header size is 56 bytes.
After add value 56 to check header size (https://github.com/python-pillow/Pillow/blob/main/src/PIL/BmpImagePlugin.py#L98) condition Pillow successfully opens a 768070 bytes bmp.
Maybe you can try just increasing the BMP header to 64 bytes?
As I understand it, 56 is a non-standard header size, which causes a problem in many cases.
Can I ask about purpose?I want to know what the tolerance is on the input part that did not pass the calibration.
won't I be missing some data in the header?
won't I be missing some data in the header?Position of pixel array (https://github.com/pecostm32/FNIRSI_1013D_Firmware/blob/main/fnirsi_1013d_scope/variables.c#L645) still correct - it not changed.
v0.021a
The last 16 bytes of the DIB header just won't be used, I think.
fnirsi_1013d.bin v0.020j.binI had similar results yesterday pulling 20J.; though mine was that it didn't work correctly in higher V/div settings only. I recalibrated 3 times (which is a huge pain as I had to hack some interesting BNC splitters and bench DMM probes to detect exact voltages at the inputs and tweak with analog power supply dials). Manually fiddling with volt range on each channels got signals showing correctly.
Something wrong with CH1 below 500mV after calibration
Fargo, an image with data as I wrote above. (auto settings not work in DC mode?)
I will take one BNC T-piece, insert it into ch1, connect it to ch2, and from the BNC T-piece I will stretch the cable with alligator clips to the measuring device and the power source.
I confirm.
With the version updated to v0.021c, resetting the calibration in the USB menu does not work. At least in my case.
I would like a picture with calibration data.My results. (might be useful too)
The top photo is kind of blue. :D text in menu is white?
I wanted to use the rd6006, but when I saw what it had on the output, I used an analog source. See text up.
Hello, I get a calibration error in the last step of 15v.
... Added text if there is a problem with offset calibration. (which no one will ever see, unless there is a HW problem)...I created an error and saw the message. :)
Does the original firmware also detect whether it is AC or DC when you press "auto"? Or does he leave this choice to the operator?I applied AC + DC to channel 1, and only AC to channel 2. Visually (by the AC, DC icons in the channel menu) there is no search for whether channels belong to AC or DC. The polarity and complex signal level (AC + DC) in DC mode are taken into account. And the level of the AC signal (without DC) in AC mode.
I bought a film and stuck it on the display. 20x100cm https://www.aliexpress.com/item/1005005179170765.html?spm=a2g0o.order_list.order_list_main.234.96651802iflMid (https://www.aliexpress.com/item/1005005179170765.html?spm=a2g0o.order_list.order_list_main.234.96651802iflMid)
found one more problem - oscilloscope gives a SD error 3..5 times of 10 starts. Tryed two different cards with 8Gb capacity. FW loaded by firmware loader. Tryed one more 32Gb card - no change. Rewrited config sector, did calibration - but it starts not often
No, when I write orig FW (through USB) - it starts every time, even if I don't touch SDcard. Maybe need to add some delays in FW to access SD?
I tried to save/view pictures/waveforms - all works. On orig FW and custom all is OK. Problem only when it starts. I see splashscreen and 70/30% normal start or "SD error". On orig FW it never give an error. It works same on any SD card.
Calibration done? Picture calibration value? Video?
try this
What is this for? What do the values mean?
#define SETTING_SECTOR_VERSION_HIGH 0x0100
#define SETTING_SECTOR_VERSION_LOW 0x0002 //0x0003
Did you turn on the USB connection and click as accurately as possible in the center of the screen? And there he reset the values by clicking OK.
Reload the latest version 0.022f.
What does the original software do? didn't you make a short circuit?
Baseline calibration always works, and its task is to set zero. PLS VIDEO!!
Can I set the 2 constants to any value? So that default values are loaded with a new firmware release?
Every time I look at the pcb, how the power supply and bus lines are solved, I want to cry. It is not possible that in the era of simulators and Altium Designer and high-quality oscilloscopes, something like this could be created.
I would like to try to install some ferrites to reduce interference. Yes, they can be given somewhere. But where they could make the most difference with the AD converter, it is impossible there.
I was also looking at the nice lines from AD to FPGA, each of a different length :DCan this kind of feature, FNIRSI-1014D, be done?
Long time base
https://www.youtube.com/watch?v=uS9gW6L0a0A (https://www.youtube.com/watch?v=uS9gW6L0a0A)
Can this kind of feature, FNIRSI-1014D, be done?
Do you want a battery indicator in percentages? 95...90 ...85 But the value will fluctuate.
...[attach=1]
v0.022o version only for testing the autosetup function
Do you want a battery indicator in percentages? 95...90 ...85 But the value will fluctuate.
Do you want a battery indicator in percentages? 95...90 ...85 But the value will fluctuate.
personally, i would prefer exact voltage instead of %
Do you want a battery indicator in percentages? 95...90 ...85 But the value will fluctuate.
personally, i would prefer exact voltage instead of %
With a 6 bit ADC using only half of the range it won't be very exact.
.....
that is sad :( but anyway, better than battery symbol, which is constantly jumping from full to 3/4 even after overnight charge. this is annoying....
.....
that is sad :( but anyway, better than battery symbol, which is constantly jumping from full to 3/4 even after overnight charge. this is annoying....
In mine the battery connector also is a cause of fluctuation. Has been connected and disconnected so often that it became crap.
Have not used any of these cheap two bit scopes since the reverse engineering. :-DD
I have already removed the pins and tensioned them.
Have you tried the new firmware version? :D
i have them both (fnirsi 1013 and 1014d) for a purpose - there will be no regrets in case of accidental burn :) I work with high voltage , so this could happen (and happens) sooner or later. also , galvanic isolation from AC is important. at the moment of purchase, i thought that 1014d is a "big bro" version of 1013, but the same (maybe even worse) shit in fact...
Hello, please tell me how to record firmware through a card reader without connecting the oscilloscope to the computer. The program for flashing gives a message on the photo showsI'd like you to reformat it. You must use FAT format. And it must be done in mbr mode only, not gpt mode.
Hello, please tell me how to record firmware through a card reader without connecting the oscilloscope to the computer. The program for flashing gives a message on the photo showsI suppose the card has not enough 'hidden' space. Read this message. Reformat will not do the job, you need to repartition the card.
Calibration of ch2 860 50mv value 0 fails. Tried 2 times to calibrate. And when I press the off usb screen it gives hieroglyphics. Firmware 023c
0.022f it's working fineThe same situation. The m-SD card is filled with "00", then formatted in FAT32. FW was reset to the original (Fnirsi), then filled with v0023c. Calibration was successful. But the calibration constants for ch2 50mv are zero. Channel 2, 50mv/div range does not work. The “beam” does not move, the voltmeter does not display values, and does not manually select limits. When the voltage increases to 210mV and the autoset is pressed, it switches to the 100mv/div range and starts working as it should.
I converted it to multiples of 16.
PC, you don't have a table somewhere about what the sampling frequency is if the value 2000 is written into the fpga. In the long time base mode. I assume that it is possible to change the frequency in order to achieve more uniform sampling when changing from about 100ms to 50s
...Yesterday I didn't see the binary file. Today I downloaded it and tried it. It calibrates normally. Positive and negative voltages are shown correctly on the screen.
try this:
PC: Is it possible to use the SPI interface to control the AD9833 generator?
If I remove the flash, can I use all the necessary pins? Alternative firmware does not access the flash at all?
Since I have enough other work, this project has slowed down. The plan is to divide the signal shift into the hardware part in real time, and the software part in wav mode. That should solve the automatic problem. Will anyone be interested in the assembly of the signal generator? It will also lose the ability to run flood firmware. Although there is the possibility of adding an i2c circuit to control the gain of the input amplifier for better sensitivity. What would enable, leave the flash.I want to do this. Is there anyone who can do this? Can you take me to do it?
It would also be a nice project for a bachelor's thesis. Take the flat, copy the layout, modify critical things, redo the input part, add the generator and rtc. And finally, a new program for fpga.
I was thinking of rebuilding the entire pcb of the oscilloscope.Do you have a detailed circuit diagram? I happen to have a file of one person who is Russian. But when I try to compile the file and it doesn't go through, it's stuck here.
It seems that RMS measurement implemented in the version v0.006 requires some changes for the saved WAVE files. Currently it doesn't show correct value.only 1 year and 1 day :D
Possible solutions could be: save calculated RMS value with the other WAVE file settings or recalculate RMS value from the file samples after loading.
PC:
I would say that a field[730] was created for the displayed data on the display. But is it not used anywhere? Channel1pointsbuffer and 2
hi, when i try to change the time and date, it shows ? you can't change it.Touch the buttons to set the time and date
the unit is new, i bought it, 3 days ago?Read the post linked above. It doesn't come with real time clock. It's a mod you have to do if you want it by adding an extra circuit and soldering it in. It doesn't work on base hardware without the mod.
Another problem has been discovered, the displacement of the zero level of the beam during the transition to the ACQ long period.Take a photo of the calibration data
Here is the tool plus the steps to make it work.
!! I take no responsibility if anything goes wrong !!
Steps for making the FNIRSI-1013D firmware backup on a Linux machine:
- Connect the scope to the computer via USB.
- Turn on the scope and start the USB connection via the main menu option.
- Wait until the file manager window opens. (Only if auto mount is working properly)
- Close the file manager window.
- Open a terminal window (ctrl + alt + t) and type the "lsblk" command (!do not use the quotes!) and check which device the scope is on. (~8GB disk)
- Copy the files from the card to have a backup on your computer.
- Un-mount the partition. ("sudo umount /dev/sdc1" in my case)
- Just to be more safe make a backup with dd. ("sudo dd bs=4M if=/dev/sdc of=sd_card_backup.bin" again in my case)
- Open gparted and check if the device is properly formated. (Use right mouse and information to see the sector info)
- If not delete the partition and make a new one leaving 1M free at the start. Format is fat32.
- When the partition remounts after the previous step un-mount it again.
- Use dd to place the backup package on the SD card. ("sudo dd if=fnirsi_1013d_fwb.bin of=/dev/sdc bs=1024 seek=8")
- This will re-mount the partition. Un-mount the partition again. ("sudo umount /dev/sdc1" in my case)
- Turn of the scope and turn it back on. This will start the backup process.
- Wait until it is done and the scope is mounted again. File manager window should open after a while.
- Copy the three files to the computer. (FNIRSI_1013D_full_flash_backup.bin, FNIRSI_1013D_tp_config.bin, FWB_FSI_1013.bin)
- Turn off the scope and turn it back on. It should start normally.
When the scope showed the "!! special touch panel detected !!" message please upload the "FNIRSI_1013D_tp_config.bin" file in this thread.
If your scope uses a smaller or bigger SD card be warned that this is not tested yet. Only 8GB cards have been tested.
See the attached image for info on the sd card sectors. Screen cap from gparted.
Remove the .txt extension from the firmware backup package file.
https://youtu.be/J_cZJTdngeQ?feature=sharedThis also happens on my device, although to a lesser extent.
Is there a utility to restore the tp configuation after it is saved with this tool? Somehow one of my units now has the touch screen coordinates backwards. I was able to fix this running your code with the config file but this doesn't help with the original firmware of course. I didn't have to use your config file previously either before this issue cropped up. I don't know how this came about but I compared my original FNIRSI_1013D_tp_config.bin to one that I got from the fwb tool after this issue cropped up and there are a few bytes different between the files. I would really like to get this back working with the original firmware as well.
Thanks
https://youtu.be/-eb8TvmtihE?feature=sharedThis is after manually selecting the sampling frequency and time per div or after pressing AUTO. The display with data cannot be seen well in the video
Part of the beam displays the current value, and part of the false one
Upload v0.023u. Start the Base calibration, and upload the image from the calibration with the data here.https://youtu.be/J_cZJTdngeQ?feature=sharedThis also happens on my device, although to a lesser extent.
https://youtu.be/UYh5JF16DdE (https://youtu.be/UYh5JF16DdE)
Is there a utility to restore the tp configuation after it is saved with this tool? Somehow one of my units now has the touch screen coordinates backwards. I was able to fix this running your code with the config file but this doesn't help with the original firmware of course. I didn't have to use your config file previously either before this issue cropped up. I don't know how this came about but I compared my original FNIRSI_1013D_tp_config.bin to one that I got from the fwb tool after this issue cropped up and there are a few bytes different between the files. I would really like to get this back working with the original firmware as well.
Thanks
The original firmware writes a configuration to the touch panel that should make it work correctly, as long as the two where compatible with each other from the start.
The 1013D comes with different displays and touch panels and therefore also different firmware. After repairing my initial 1013D with a new touch panel, the coordinates were also reversed. That is why I started the reverse engineering. Somewhere in this thread there is more info about it. It has been to long for me to recall the exact details.
So ask yourself if you loaded new original firmware to the flash and with that messed it up, or swapped the top halves of the two scopes. It can be fixed, but for that you will have to read through this thread. Start at page 19 or so.
Is there a utility to restore the tp configuation after it is saved with this tool? Somehow one of my units now has the touch screen coordinates backwards. I was able to fix this running your code with the config file but this doesn't help with the original firmware of course. I didn't have to use your config file previously either before this issue cropped up. I don't know how this came about but I compared my original FNIRSI_1013D_tp_config.bin to one that I got from the fwb tool after this issue cropped up and there are a few bytes different between the files. I would really like to get this back working with the original firmware as well.
Thanks
The original firmware writes a configuration to the touch panel that should make it work correctly, as long as the two where compatible with each other from the start.
The 1013D comes with different displays and touch panels and therefore also different firmware. After repairing my initial 1013D with a new touch panel, the coordinates were also reversed. That is why I started the reverse engineering. Somewhere in this thread there is more info about it. It has been to long for me to recall the exact details.
So ask yourself if you loaded new original firmware to the flash and with that messed it up, or swapped the top halves of the two scopes. It can be fixed, but for that you will have to read through this thread. Start at page 19 or so.
I have not even taken the ribbon cable out of the displays let alone take out the displays. I had not loaded new original flash nor had I even run a flash operation. The closest I came was setting up an SD card with fnirsi_1013d_startup_with_fel.bin and running your code out of RAM. The first version I found of fnirsi_1013d_startup_with_fel.bin on github did not work and left the screen magenta and many pixels blinking and no allwinner devices found using lsusb. I found another version on github that worked as expected. It was after this that the display became reversed on the x coordinate. It seems maybe that the first version that didn't work correctly may have been the culprit but I wouldn't have thought this would be the case. At this point I had never flashed any code into the scope.
After your message above I tried re-flashing the code from the backup into the scope. It behaves the same with the reversed coordinates. Additionally, I have already read this whole thread and it did not look like anyone had this experience as I have made absolutely no changes to the HW.
Thanks for your reply. I hope there is some way to get this working again...
Is there a utility to restore the tp configuation after it is saved with this tool? Somehow one of my units now has the touch screen coordinates backwards. I was able to fix this running your code with the config file but this doesn't help with the original firmware of course. I didn't have to use your config file previously either before this issue cropped up. I don't know how this came about but I compared my original FNIRSI_1013D_tp_config.bin to one that I got from the fwb tool after this issue cropped up and there are a few bytes different between the files. I would really like to get this back working with the original firmware as well.
Thanks
The original firmware writes a configuration to the touch panel that should make it work correctly, as long as the two where compatible with each other from the start.
The 1013D comes with different displays and touch panels and therefore also different firmware. After repairing my initial 1013D with a new touch panel, the coordinates were also reversed. That is why I started the reverse engineering. Somewhere in this thread there is more info about it. It has been to long for me to recall the exact details.
So ask yourself if you loaded new original firmware to the flash and with that messed it up, or swapped the top halves of the two scopes. It can be fixed, but for that you will have to read through this thread. Start at page 19 or so.
I have not even taken the ribbon cable out of the displays let alone take out the displays. I had not loaded new original flash nor had I even run a flash operation. The closest I came was setting up an SD card with fnirsi_1013d_startup_with_fel.bin and running your code out of RAM. The first version I found of fnirsi_1013d_startup_with_fel.bin on github did not work and left the screen magenta and many pixels blinking and no allwinner devices found using lsusb. I found another version on github that worked as expected. It was after this that the display became reversed on the x coordinate. It seems maybe that the first version that didn't work correctly may have been the culprit but I wouldn't have thought this would be the case. At this point I had never flashed any code into the scope.
After your message above I tried re-flashing the code from the backup into the scope. It behaves the same with the reversed coordinates. Additionally, I have already read this whole thread and it did not look like anyone had this experience as I have made absolutely no changes to the HW.
Thanks for your reply. I hope there is some way to get this working again...
Of course there is. By the sound of it your version of the 1013D does not write the configuration to the touch panel and it then indeed got screwed up by using a wrong version of code I wrote.
A bit of background. I wrote lots of test code while working on the reverse engineering to get to the bottom of it all. At some point, after noticing that there are different hardware version of the scope out there, I decided to not write the touch panel configuration, like my first version of the 1013D did and use the touch panel as is to control the scope with the new firmware. To allow for touch panels with the coordinates swapped to still work I added a configuration option to tailor for the different hardware. Same as with the different displays.
So now back to your problem. The way to solve it is to write a correct configuration to the touch panel, and this can be done with any device that has an I2C interface. Keep in mind that the touch panel works on 3.3V, so when using a MCU running on 5V use some 100 Ohm serial resistors and 2K2 to 4K7 Ohm pullup resistors to 3.3V.
The programming guide for the touch panel can be found here (https://github.com/pecostm32/FNIRSI-1013D-1014D-Hack/blob/main/IC's/GT911%20Programming%20Guide_v0.1.pdf).
In the touch panel configuration there are two ways to reverse the coordinates, but I only used the order of the scan lines to do the swap. The data in question starts on address 0x80B7 - 0x80C4 for the y direction and 0x80D5 - 0x80EE for the x direction. I might be mistaken which is for which. Doing this from memory.
When you have a bluepill lying around you can take a look at the project here (https://github.com/pecostm32/STM32F103_GT911_Conf_Writer).
Thanks for the info. Isn't it possible to use your bit banged I2C code on github to reprogam the touch panel configuration instead of connecting other hardware? It seems that is what happened in the first place. Once again thanks for the help!
PC:
Where do these numbers come from?
1800, //200ms/div 12
1800, //100ms/div
1800, // 50ms/div
1800, // 20ms/div (Was 800, but that does not yield enough samples)
1800, // 10ms/div
2500, // 5ms/div
2500, // 2ms/div
2500, // 1ms/div
Thanks for the info. Isn't it possible to use your bit banged I2C code on github to reprogam the touch panel configuration instead of connecting other hardware? It seems that is what happened in the first place. Once again thanks for the help!
Sure it is, but you have to write it yourself. The code can be small enough to do it in the bootloader. Just take that project and remove the loading of the next code and stick in the I2C bit with the needed touch panel configuration. All the needed bits and pieces can be found in what I wrote. It might even still be in the new firmware disabled with a define.
Those numbers are sent to the FPGA
//short time base
void fpga_set_time_base(uint32 timebase)
{
//Make sure setting is in range
if(timebase < (sizeof(timebase_settings) / sizeof(uint32)))
{
//Write the command to set the short time base data to the FPGA
fpga_write_cmd(0x0E);
//Table settings ranges from setting 0 (200mS/div) to 23 (5nS/div)
fpga_write_int(timebase_settings[timebase]);
const uint32 timebase_settings[35] =
{//long time base
1800, //50s/div
1800, //20s/div
1800, //10s/div
It worked until now, I don't understand why it broke. The numbers are always sent the same. It looks like the fpga has finished filling the magazine early. I don't know if they didn't feel the flood numbers because sometimes only 750 samples are taken. because 1500 samples are taken, the times are short and the collection is finished sooner. But again, it doesn't agree, so why does it somehow work when switching to a higher number and then back to sleep (however, some sampled data is still missing at the end.)
I increased the number, but that's a bad solution because I don't know where the problem actually is.
v0.023x
Thanks for the info. Isn't it possible to use your bit banged I2C code on github to reprogam the touch panel configuration instead of connecting other hardware? It seems that is what happened in the first place. Once again thanks for the help!
Sure it is, but you have to write it yourself. The code can be small enough to do it in the bootloader. Just take that project and remove the loading of the next code and stick in the I2C bit with the needed touch panel configuration. All the needed bits and pieces can be found in what I wrote. It might even still be in the new firmware disabled with a define.
Thanks for the info. Isn't it possible to use your bit banged I2C code on github to reprogam the touch panel configuration instead of connecting other hardware? It seems that is what happened in the first place. Once again thanks for the help!
Sure it is, but you have to write it yourself. The code can be small enough to do it in the bootloader. Just take that project and remove the loading of the next code and stick in the I2C bit with the needed touch panel configuration. All the needed bits and pieces can be found in what I wrote. It might even still be in the new firmware disabled with a define.
#ifndef USE_TP_CONFIG
#ifdef SAVE_TP_CONFIG
void save_tp_config(void)
{
//Create a file for the touch panel configuration. Fails if it already exists
if(f_open(&viewfp, "FNIRSI_1013D_tp_config.bin", FA_CREATE_NEW | FA_WRITE | FA_READ) == FR_OK)
{
//Write the touch panel configuration to the sd card
f_write(&viewfp, tp_config_data, sizeof(tp_config_data), 0);
//Close the file to finish the write
f_close(&viewfp);
}
}
#endif
#endif
...
Download zip. https://github.com/Atlan4/Fnirsi1013D/tree/main
Ideally, the one that contains all 3 folders for the oscilloscope. It contains parts of the code that you should be able to touch, just try to remove them or call them correctly. IF you have a backup, maybe the PC would be able to tell which part of the code needs to be loaded. Purely theoretically, I can generate a bin here, but without a guarantee. Which you write in the IO for touch panel.
fnirsi_1013d_scope/touchpanel.c
https://github.com/pecostm32/FNIRSI_1013D_Firmware/blob/main/fnirsi_1013d_scope/touchpanel.c
I'm thinking about what it's good for... Or what it could be used for. If the trigger was turned off, it would be possible to collect the set number of samples with this system. The question is what time_base_cnt the clock - does it depend on the sampling frequency?
About 0.023x works, so far no one has reported a problem. We'll see what the user does with the touchscreen, because the oscilloscope code contains things to write to the touchscreen.
Download zip. https://github.com/Atlan4/Fnirsi1013D/tree/main
Ideally, the one that contains all 3 folders for the oscilloscope. It contains parts of the code that you should be able to touch, just try to remove them or call them correctly. IF you have a backup, maybe the PC would be able to tell which part of the code needs to be loaded. Purely theoretically, I can generate a bin here, but without a guarantee. Which you write in the IO for touch panel.
fnirsi_1013d_scope/touchpanel.c
https://github.com/pecostm32/FNIRSI_1013D_Firmware/blob/main/fnirsi_1013d_scope/touchpanel.c
Hi Atlan, it would be fantastic if you could generate a bin saving me having to get the build set up :D Can you set it up to read in a fixed filename that has the touch screen config? If the filename could be FNIRSI_1013D_tp_config.bin as it is saved from the backup tool and using that format would be useful to a lot of people that wind up in my predicament.
Thanks!
I feel that the real question here is: how the hell did they come up with that brand name?
Was there a committee that sat down together in a room and said "Yeah, FNIRSI! That's the one, we'll roll with that. FNIRSI!"
It sounds like something you catch on a vacation in a jungle, or like an off brand hemroid cream.
I added some capacitors, but it seems to me that the situation has worsened :DDownload zip. https://github.com/Atlan4/Fnirsi1013D/tree/main
Ideally, the one that contains all 3 folders for the oscilloscope. It contains parts of the code that you should be able to touch, just try to remove them or call them correctly. IF you have a backup, maybe the PC would be able to tell which part of the code needs to be loaded. Purely theoretically, I can generate a bin here, but without a guarantee. Which you write in the IO for touch panel.
fnirsi_1013d_scope/touchpanel.c
https://github.com/pecostm32/FNIRSI_1013D_Firmware/blob/main/fnirsi_1013d_scope/touchpanel.c
Hi Atlan, it would be fantastic if you could generate a bin saving me having to get the build set up :D Can you set it up to read in a fixed filename that has the touch screen config? If the filename could be FNIRSI_1013D_tp_config.bin as it is saved from the backup tool and using that format would be useful to a lot of people that wind up in my predicament.
Thanks!
dfw_ee Upload your backup file here to the forum
FNIRSI_1013D_tp_config.bin
https://youtu.be/glwu0KrXKts?feature=sharedThis is a feature, the second option is to turn it off. (I decided to let the user set the limits and then turn on the sampling. (there is not enough time to sample and render the entire display) Take a WAVe snapshot and you can measure there.
A new bug on ACC LONG resets the waveform when trying to change the cursors
Actually I like that idea now that I try it but if in stop mode could it act differently( or do we need to just use the waveform)?
There are certainly differences. PC. what do you think, can I copy it directly there?
firmavare data:
uint8 tp_config_data[] =
{
0xFF, 0x20, 0x03, 0xE0, 0x01, 0x0A, 0xFD, 0x00, 0x01, 0x08, 0x28, 0x08, 0x5A, 0x3C, 0x03, 0x05,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x18, 0x1A, 0x1E, 0x14, 0x87, 0x29, 0x0A, 0x75, 0x77,
0xB2, 0x04, 0x00, 0x00, 0x00, 0x9A, 0x01, 0x11, 0x00, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x50, 0xA0, 0x94, 0xD5, 0x02, 0x08, 0x00, 0x00, 0x04, 0xA1, 0x55, 0x00, 0x8F,
0x62, 0x00, 0x7F, 0x71, 0x00, 0x73, 0x82, 0x00, 0x69, 0x95, 0x00, 0x69, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x02, 0x04, 0x06, 0x08, 0x0A, 0x0C, 0x0E, 0x10, 0x12, 0x14, 0xFF, 0xFF, 0xFF, 0xFF, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x02,
0x04, 0x06, 0x08, 0x0A, 0x0C, 0x1D, 0x1E, 0x1F, 0x20, 0x21, 0x22, 0x24, 0x26, 0x28, 0xFF, 0xFF,
0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x05, 0x01
};
backup data>
6D,20,03,E0,01,05,0D,00,01,0A,28,0F,50,32,03,05,00,00,00,00,00,00,08,17,19,1C,14,87,29,0A,66,
68,EB,04,00,00,02,00,02,11,00,01,00,00,00,00,00,00,00,00,00,5A,8C,94,C5,02,07,19,00,04,93,5E,
00,87,66,00,7C,70,00,72,7A,00,6B,86,00,6A,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,
00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,02,04,06,08,0A,0C,0E,10,12,14,FF,FF,
FF,FF,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,28,26,24,22,21,20,1F,1E,1D,0C,0A,08,06,
04,02,00,FF,FF,FF,FF,FF,FF,FF,FF,FF,FF,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,8D,00
dfw_ee try TP3 bin
Download zip. https://github.com/Atlan4/Fnirsi1013D/tree/main
Ideally, the one that contains all 3 folders for the oscilloscope. It contains parts of the code that you should be able to touch, just try to remove them or call them correctly. IF you have a backup, maybe the PC would be able to tell which part of the code needs to be loaded. Purely theoretically, I can generate a bin here, but without a guarantee. Which you write in the IO for touch panel.
fnirsi_1013d_scope/touchpanel.c
https://github.com/pecostm32/FNIRSI_1013D_Firmware/blob/main/fnirsi_1013d_scope/touchpanel.c
TP3 is exactly what you put here as a backup. That is, what was there before you tried to experiment. Only if you did the experiments without backup.
PC will find a solution :D
Download zip. https://github.com/Atlan4/Fnirsi1013D/tree/main
Ideally, the one that contains all 3 folders for the oscilloscope. It contains parts of the code that you should be able to touch, just try to remove them or call them correctly. IF you have a backup, maybe the PC would be able to tell which part of the code needs to be loaded. Purely theoretically, I can generate a bin here, but without a guarantee. Which you write in the IO for touch panel.
fnirsi_1013d_scope/touchpanel.c
https://github.com/pecostm32/FNIRSI_1013D_Firmware/blob/main/fnirsi_1013d_scope/touchpanel.c
I downloaded one of the zip files to see if I could build and many modules completed but got this error:
arm-none-eabi-gcc -Wall -Wno-write-strings -Wno-char-subscripts -fno-stack-protector -DNO_STDLIB=1 -O3 -mcpu=cortex-m3 -mthumb -c -O2 -MMD -MP -MF "build/Release/GNU-Linux/fnirsi_1013d_scope.o.d" -o build/Release/GNU-Linux/fnirsi_1013d_scope.o fnirsi_1013d_scope.c
/tmp/cckjbrA2.s: Assembler messages:
/tmp/cckjbrA2.s:79: Error: selected processor does not support requested special purpose register -- `mrs r3,cpsr'
/tmp/cckjbrA2.s:81: Error: selected processor does not support requested special purpose register -- `msr cpsr_cxsf,r3'
Any idea what I'm missing in the build environment?
Thanks!
CFLAGS=-Wall -Wno-write-strings -Wno-char-subscripts -fno-stack-protector -DNO_STDLIB=1 -mcpu='arm926ej-s' -O3 -mfloat-abi=soft
TP3 is exactly what you put here as a backup. That is, what was there before you tried to experiment. Only if you did the experiments without backup.
PC will find a solution :D
Download zip. https://github.com/Atlan4/Fnirsi1013D/tree/main
Ideally, the one that contains all 3 folders for the oscilloscope. It contains parts of the code that you should be able to touch, just try to remove them or call them correctly. IF you have a backup, maybe the PC would be able to tell which part of the code needs to be loaded. Purely theoretically, I can generate a bin here, but without a guarantee. Which you write in the IO for touch panel.
fnirsi_1013d_scope/touchpanel.c
https://github.com/pecostm32/FNIRSI_1013D_Firmware/blob/main/fnirsi_1013d_scope/touchpanel.c
I downloaded one of the zip files to see if I could build and many modules completed but got this error:
arm-none-eabi-gcc -Wall -Wno-write-strings -Wno-char-subscripts -fno-stack-protector -DNO_STDLIB=1 -O3 -mcpu=cortex-m3 -mthumb -c -O2 -MMD -MP -MF "build/Release/GNU-Linux/fnirsi_1013d_scope.o.d" -o build/Release/GNU-Linux/fnirsi_1013d_scope.o fnirsi_1013d_scope.c
/tmp/cckjbrA2.s: Assembler messages:
/tmp/cckjbrA2.s:79: Error: selected processor does not support requested special purpose register -- `mrs r3,cpsr'
/tmp/cckjbrA2.s:81: Error: selected processor does not support requested special purpose register -- `msr cpsr_cxsf,r3'
Any idea what I'm missing in the build environment?
Thanks!
That is simple. The MCU is not based on cortex-M3.
Compiler flags need to be:Code: [Select]CFLAGS=-Wall -Wno-write-strings -Wno-char-subscripts -fno-stack-protector -DNO_STDLIB=1 -mcpu='arm926ej-s' -O3 -mfloat-abi=soft
The question is how it tests it, whether it uploads the TP bin and then uploads the original firmware, and as we know, it also has 2 versions of the TP. And if by chance you try it on an alternative, there is a problem that it may have a loaded configuration in sector 709 and that will change its coordinates again.
I didn't think it was the cortex-M3 but I just did a make all on your unzipped file so I didn't set any MCU. This was the directory "v0.023m_long_mode_OK". Are there environment variables set up to select the MCU. I haven't really looked much at the make file...
For a version with a startup screen that shows PECOs sCOPE three projects are needed:
"fnirsi_1013d_sd_card_bootloader" which loads the startup screen code and executes that
"fnirsi_1013d_startup_screen" which shows the startup screen and loads and executes the actual scope code
"fnirsi_1013d_scope" this is the actual scope code
I didn't think it was the cortex-M3 but I just did a make all on your unzipped file so I didn't set any MCU. This was the directory "v0.023m_long_mode_OK". Are there environment variables set up to select the MCU. I haven't really looked much at the make file...
It is probably best to get the code from my repository (https://github.com/pecostm32/FNIRSI_1013D_Firmware/tree/main) and not Atlans, as he him self also suggests.
You don't need netbeans, but you do need linux with gnu-arm-none-eabi tools installed. Be aware that to make it work you have to compile the projects in order, but this is only needed once or when changes are made to the other projects of course.
Only three of the projects are needed, and the order to compile is given there also, but copied below for clearness.Code: [Select]For a version with a startup screen that shows PECOs sCOPE three projects are needed:
"fnirsi_1013d_sd_card_bootloader" which loads the startup screen code and executes that
"fnirsi_1013d_startup_screen" which shows the startup screen and loads and executes the actual scope code
"fnirsi_1013d_scope" this is the actual scope code
The code is not that complex. Just look at the main function and you will see the startup process. Atlan already lead you to the touchpanel.c file where all the magic happens.
Success,
Peter
TRY new TP3 and TP4 is from my oscilloscope.
Actually I like that idea now that I try it but if in stop mode could it act differently( or do we need to just use the waveform)?
Thanks Peter. I already had gnu-arm-none-eabi of course or nothing would have compiled. Lots of modules compiled correctly just not the last. Doesn't the makefile determine the order of the build? The code already makes pretty good sense to me but the build process is not working due the error above...
Thanks Peter. I already had gnu-arm-none-eabi of course or nothing would have compiled. Lots of modules compiled correctly just not the last. Doesn't the makefile determine the order of the build? The code already makes pretty good sense to me but the build process is not working due the error above...
There is no overall make file. Each project has its own make file. What is integrated in them is the copying of the output to the other project directory and the merging them together to make the needed single binary to load on the SD card.
With "project" I mean a set of .c and .h files that contain a single main function and other functions needed to make the compiled binary.
Changes to the diagnostic screen. v0.024
(Attachment Link)
Listing with cmd for dwf ee
(Attachment Link)
new TP3 and TP4 were compiled badly.
Complete projects from TP1 to TP4 are uploaded here.
https://github.com/Atlan4/Fnirsi1013D/blob/main/TP%20write%20config%20v0.023x.zip
Of course, TP3 and TP4 must be run through the compiler to generate the correct BIN.
Pay attention to deleted files in Linux, even if they are in the recycle bin. When I run make, it uses the files that are in the recycle bin, instead of those that are in the project directory
Thanks Peter. I already had gnu-arm-none-eabi of course or nothing would have compiled. Lots of modules compiled correctly just not the last. Doesn't the makefile determine the order of the build? The code already makes pretty good sense to me but the build process is not working due the error above...
There is no overall make file. Each project has its own make file. What is integrated in them is the copying of the output to the other project directory and the merging them together to make the needed single binary to load on the SD card.
With "project" I mean a set of .c and .h files that contain a single main function and other functions needed to make the compiled binary.
The only make file I see is the one in the directory with the .c and .h files. That isn't the make file for the "project"?
PC: How is a specific PIN set in the processor, should it be input or output? Are the pins open collector?
If I want to set the MISO-61-PC2 pin as an input, how do I do it?
Or is it already set somewhere as an output?
How can I load it? (if pin==1) through which register?
I am considering connecting a pull-up resistor and an optocell there. It would serve as an external trigger (max 12V input). The BNC should be placed next to the power switch, at least for the glass version...
Sometimes it's good to have it. For example, when debugging uP, ext trigger, it is possible to see a specific part of the process, e.g. i2c code
Did you see the picture? you have the complete path to the MAKEfile there.
Finally the scope touch screen is working normally again. I used the TP1 executable and a hex editor to change the 0x8047 register to a 0xBD to reverse the axis. Ran the executable and all is good. I had tried setting values in registers 0xB7 to 0x80C4 with 0x8047 set to FD but could not get it to work completely right. The axis were correct but the touch points were about 1 square below what was printed.
Thanks Atlan for writing the various TP programs! I am able to build these but when loaded on the SDCard it isn't loaded but boots from the internal flash. This is what happened with your orginal TP4 version. Any idea what is causing this? I got around it by just hacking the TP1 file with a hex editor.
Thanks Peter for all the help and pointing me to the display programming manual.
06 00 00 EA 65 47 4F 4E 2E 42 54 30 F7 6F 69 AE 00 3A 00 00 53 50 4C 02 00 00 00 00 00 00 00 00
download again, fixed
https://github.com/Atlan4/Fnirsi1013D/blob/main/TP%20write%20config%20v0.023x.zip
tp3 and tp4 work, TP4 contains all 4 data fields
firmware is: fnirsi_1013d.bin
download again, fixed
https://github.com/Atlan4/Fnirsi1013D/blob/main/TP%20write%20config%20v0.023x.zip
tp3 and tp4 work, TP4 contains all 4 data fields
firmware is: fnirsi_1013d.bin
Last uploaded TPczip. In it, all versions of bin, run alternative firmware
Do not change the names of the files in the working folder!!!
mksunxi and flashfilepacker and fnirsi_1013d_scope.elf They must be set in properties as executable.
(Attachment Link)
If the names are correct, the program that is there will combine all 3 bins from the projects into one. fnirsi_1013d.bin
The output file to look for is fnirsi_1013d.bin
the command "./flashfilepacker -o dist/Debug/GNU_ARM-Linux/fnirsi_1013d.bin -i dist/Debug/GNU_ARM-Linux/fnirsi_1013d_scope.bin -l 0x9800" takes the data from fnirsi_1013d_scope.bin and copies it to fnirsi_1013d.bin starting from location 0x9800.
There should already be a fnirsi_1013d.bin file in the directory with the boot loader and splash screen code in it, and then it adds the scope program to it. If there is no existing fnirsi_1013d.bin file it will create it and put zeros in the space before 0x9800.
When there is one with the scope program already in there it will be overwritten with the new data, so it can be reused over and over. No need to rebuild the boot loader and splash screen code as long as there is a valid fnirsi_1013d.bin file with these two in it.
Look again at the last picture I put here, you must not have any other files there. And no more files with a similar name to txt
I said TP4. No tp1 no tp2
BTW, I saw your youtube video about the touch screen issue you originally had with it not responding in certain locations. I think I read that is what sent you down this whole reverse engineering path. This work that you did on the reverse engineering is very impressive! Did you get that particular unit to ever work?
PC:
In what range can the numbers be for setting the DC offset
#define HIGH_DC_OFFSET 500
#define LOW_DC_OFFSET 1200
Zero calibration is around 860 - 870
So what are the limits if I want to use it to shift the signal. Thx
According to me, there is a mistake in the scheme, at least my glass versions of the oscilloscope have 3.3V on the operands.
Does TP work properly?
Tokar: does that mean it's good?This is better than all previous compilations. There are no very long freezes when performing autoset. The longest is 8 seconds when moving from 0.5V to 1V
...
The flood started at a sensitivity of 100mV.
Does TP work properly?
Atlan:
is the 0.024 version supposed to be fully functional firmware or only meant to test particular features
you are working on? I am asking because I tried flashing 0.024d on my device and I get a flatline on
both channels. I tried baseline calibration but it did not make any difference.
A quick check shows that 0.022g displays the 1KHz calibration signal correctly on both channels, so
I am reasonably confident that the scope is functional.
Polyman
I was testing other firmware versions, and they all had this ripple, and this small imperfection in the square wave (images attached). I tried to do the calibration in the menu, and nothing changed. The original firmware fixes this.
Hello, I hope everyone is well!
Sorry for any spelling mistakes, I'm using a translator!
Today I ventured to change the 1013D's firmware. I changed the SD card, and imported the firmware through "Loader". All very well. At this moment, I have firmware v0.024f, recently posted.
I was testing other firmware versions, and they all had this ripple, and this small imperfection in the square wave (images attached). I tried to do the calibration in the menu, and nothing changed. The original firmware fixes this.
What could I be doing wrong? Is there any procedure to be done besides updating the firmware? How do I calibrate this?
Thank you all, and congratulations on the project! The new firmwares greatly improve the equipment’s functionality!
I was testing other firmware versions, and they all had this ripple, and this small imperfection in the square wave (images attached). I tried to do the calibration in the menu, and nothing changed. The original firmware fixes this.
1) It appears you have not done proper voltage calibration. All your defaults are ending in 00000. You must provide a stable voltage in 0V3, 0V6, 1V5, 3V0, 7V5 and 15V0 levels when re-calibrating those levels
Atlan's Calibration post with video example: https://www.eevblog.com/forum/testgear/fnirsi-1013d-100mhz-tablet-oscilloscope/msg5279620/#msg5279620 (https://www.eevblog.com/forum/testgear/fnirsi-1013d-100mhz-tablet-oscilloscope/msg5279620/#msg5279620)
2) The new firmware shows actual level readings, what you are calling jitter. The original firmware averaged those out giving a fake display that did not represent the actual levels.
I posted about that way earlier in the thread, here is that post and the response from others regarding that:
My Post: https://www.eevblog.com/forum/testgear/fnirsi-1013d-100mhz-tablet-oscilloscope/msg4573744/#msg4573744 (https://www.eevblog.com/forum/testgear/fnirsi-1013d-100mhz-tablet-oscilloscope/msg4573744/#msg4573744)
PCProgrammer's Reply: https://www.eevblog.com/forum/testgear/fnirsi-1013d-100mhz-tablet-oscilloscope/msg4574389/#msg4574389 (https://www.eevblog.com/forum/testgear/fnirsi-1013d-100mhz-tablet-oscilloscope/msg4574389/#msg4574389)
The plan is to add an Average button and a long/short mode switch to the ACQ menu. Added option to display data in mA and A if a current probe is used. Adding a sun icon to toggle between maximum and set brightness. (does anyone need it?)
If possible, a software trigger for short mod will be added. Allows the use of the entire memory of 3000 samples. Suitable for tracking communications. Now the trigger is always in the middle of the memory, which means that only 1500 samples are available for the signal.
Generator sine square triangle connected to SPI, I will place the BNC connector next to the switch. It totally fits in there. I am considering whether to equip it with an amplifier regulated via i2c.
Can you think of anything else?
...I'm sorry, I understood about the clock, but I didn't have time to correct the post, you already answered.
Tokar: Default settings is RTC off. Switch on, temperature ok
...the cable checked on other devices everything is "ok"...Change the cable for complete clarity.
...the cable checked on other devices everything is "ok"...Change the cable for complete clarity.
Friend, I tried different cables, on different computers, different OS, Win7, Win 10, the result is the same, so the problem is in my device, I'll try to solder it once, if it doesn't help.
Thank you so much for such a great job. You are a genius and a miracle worker. You turn from a simple oscilloscope into a pro. Or maybe these oscilloscope files will help you. If only we could take ready-made preset settings from there. For example, injectors, ignition and so on. And to embed them in this oscilloscope, in general, would be super. I attached the files.https://drive.google.com/file/d/1FF634-UiKT6iGMONAH68AHNmDZ_gfGDl/view?usp=sharing (https://drive.google.com/file/d/1FF634-UiKT6iGMONAH68AHNmDZ_gfGDl/view?usp=sharing)upload picture, video, or text. no apk thank you
ADC comp 0 - very suspicious :D
try to calibrate again and use the 0.024q version
... Can it be fixed or is this my oscilloscope's specific?v0024p. You are not alone. On my device the situation is the same.
...
Good afternoon, everyone. Please share the factory firmware of the oscilloscope. accidentally deleted the firmware.
In firmware 0.024t after pressing autoset the actual value is still different from the measured oscilloscope, also confirm it is not possible to view the recorded image and video oscillogram.
https://youtu.be/2Tv0On6prPk
Good afternoon, everyone. Please share the factory firmware of the oscilloscope. accidentally deleted the firmware.Did you make a flash backup? then you have a problem. You will not have a calibrated oscilloscope.
fnirsi_1013d.bin v0.024tfnirsi_1013d.bin v0.024u
https://youtu.be/zgjDdCJl8MA?si=q-_W7qOnZ31SKzlc (https://youtu.be/zgjDdCJl8MA?si=q-_W7qOnZ31SKzlc)
https://youtu.be/-bo5IEjTrlA (https://youtu.be/-bo5IEjTrlA)YouTube : This is a restricted video
correctedhttps://youtu.be/-bo5IEjTrlA (https://youtu.be/-bo5IEjTrlA)YouTube : This is a restricted video
You have the 0.006 version there and it is currently 0.024s, see the back page. There is a huge difference between them.
0.024t and higer is beta verzia
Manual is on page 82
In the oscilloscope menu, click on the option Base line calibration.
The required calibration voltages for the ranges are:
100mV/div 300mV
200mV/div 600mV
500mV/div 1.5V
1V/div 3V
2.5V/div 7.5V
5V/div 15V
Use an analog voltage source, or battery voltage that has zero ripple.
Does this mean that the calibration process is no longer "self contained", and I need some "external tool" of some sort? If so, is there any more detailed explanation, in a document or video?
Added possibility to reset calibration values. (if a bad calibration occurs) Added notification of a faulty calibration if the offset cannot be set (only if there is some hardware problem, bad ad converter, missing ad converter, problem with the offset voltage setting)
Input divider calibration is enabled when the oscilloscope is turned on for the first time and baseline calibration is used.
Calling up the calibration of the input divider is possible only through the menu by resetting the calibration values. (or by deleting the data on the sd card where the configuration data is located. NEED SDCART READER No It can be done with a card stored in the oscilloscope. )
After successful calibration of the input divider and switching off the oscilloscope, the data is written to the SD card. (Unless you change the burnt components on the input circuits, it will no longer be needed - that is, if you do not erase, do not replace the sd card)
If the calibration is started again, only the base level calibration will be performed. i.e. 0 is found. (What sometimes needs to be done)
By uploading the firmware, the calibration of the input divider DOES NOT CHANGE.
https://www.youtube.com/watch?v=KK51iftmdVU (https://www.youtube.com/watch?v=KK51iftmdVU)
This is how you should do it.
Yes
I don't know, after I installed it, I did the calibration afterwards, I didn't measure it before. After installation, it asks for calibration :-//
.
A couple of batteries connected in series and a high-value potentiometer with which you can divide the voltage. You also need a multimeter to adjust the voltage.
I don't know, after I installed it, I did the calibration afterwards, I didn't measure it before. After installation, it asks for calibration :-//
.
A couple of batteries connected in series and a high-value potentiometer with which you can divide the voltage. You also need a multimeter to adjust the voltage.