FNIRSI-1013D "100MHz" tablet oscilloscope

[Atlan]

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.

[pcprogrammer]

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.

I wrote an emulator and someone else hooked qemu into it to make it faster. My code is here. The only problem for you might be that it is written for Linux using X11.

Probably there is also some linker output information about memory usage, but can't say what tools to use for that. Maybe something in the .elf file that can be dumped.

[Atlan]

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

[Atlan]

I upload v0.019d, shift the image.
I upload 0.020d and the image remains shifted. How is it possible that it remains shifted when it obviously does not load the data from the 710 because it cannot be reversed. I also noticed that v0.020 is shifted, but at start-up the opening image is correct.

uploading any data to the 710 has no effect on the TP xy or the screen.

How is it possible

[boojum]

I just tried this firmware. I see a lot of good things. Thanks a lot!
Just a couple of notes:

1. Hangup during calibration

System Settings -> Baseline calibration -> press OK

I hear once relay click. And it's all. I waited about 10 minutes - no result.
The device hangs until a power reboot.

2. Not entirely correct BMP files format

Screenshots are currently 768070 bytes size (instead of the original 800000) and are not recognized by some programs.
I've tried a few app - MS Explorer and Edge browser everything displays fine, but Firefox only displays "cannot be displayed because it contains errors", Paint Shop Pro says "Not valid BMP", and the Python Pillow image library crashes on it with the exception "Unsupported BMP header type (56)"

Is it possible to return the .BMP to its original format? Оriginal .BMPs displays correctly everywhere.

Version 0.20e

[Atlan]

Does V0.019d have the correct images?

[boojum]

I tried 0.019d and 0.020e - no diffs for me except version number at top right corner.

[pcprogrammer]

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

The way it works is that the F1C100s boot loader checks sector 8 of the SD card to see if there is an eGON header there. If so it loads the code found to the boot RAM, which is only 32K. The it jumps to this code to execute it.

This is the "fnirsi_1013d_sd_card_bootloader" code. It initializes the DRAM in the F1C100s and then loads the next program from the SD card, which starts at sector 48. It also loads the data from sector 710.

Code: [Select]

//----------------------------------------------------------------------------------------------------------------------------------

#define PROGRAM_START_SECTOR      48
#define DISPLAY_CONFIG_SECTOR    710

The next program is "fnirsi_1013d_startup_screen" to show the PECOs SCOPE screen. This is loaded to memory address 0x81C00000. The boot loader jumps to this address to execute that code.

This bit of code loads the final program from sector 92 into memory starting at address 0x80000000 and executes it after showing the startup screen.

Code: [Select]

//----------------------------------------------------------------------------------------------------------------------------------

#define PROGRAM_START_SECTOR              92

The binary that is loaded to the SD card contains all three bits of code such that the starts correspond with the given sectors. To do this I wrote the flashfilepacker program, but that is setup to run on linux.

I don't think the problem is with the data on the SD card, but with the allocation of the data in the scope program.

Try to find the differences between 19d and the version where it started to fail.

[pcprogrammer]

Is it possible to return the .BMP to its original format? Оriginal .BMPs displays correctly everywhere.

Except on Linux. The original version placed some data between the header and the actual bitmap, and used a pointer in the header to point to the image data. The default programs on linux do not use this pointer and assume the data to follow directly after the header.

Quite strange that the header is not found to be correct, because it is based on the guide lines given here.

[Atlan]

Linux is a very fun system, just that fun cost me 3 hours of my life.
It should be fine now.
try v0.020f working display shift for ONEDIY

All compiled versions from 0.019d to 0.020e are poorly translated from Ccode to BIN format

[facekim]

Are times per division of 1 or 2 seconds implemented in the future?
It is important in some automotive things.
Thank you

[boojum]

Quite strange that the header is not found to be correct, because it is based on the guide lines given here.

Maybe this will help fix the problem:
I look Pillow code. It check header size and raise error because header size is 56 bytes.

[pcprogrammer]

Linux is a very fun system, just that fun cost me 3 hours of my life.

Welcome to the club. 

Good that you solved it. I'm busy with my own projects. Happy to reply now and then with some recollection about the development, but I'm not going to spend time on it looking into more serious problems.

[Atlan]

Quite strange that the header is not found to be correct, because it is based on the guide lines given here.

Maybe this will help fix the problem:
I look Pillow code. It check header size and raise error because header size is 56 bytes.

0.020f Did it solve the calibration problem?

Are times per division of 1 or 2 seconds implemented in the future? YeS

[boojum]

0.020f Did it solve the calibration problem?

No. It hangs like before.

[Atlan]

Switch trigger to AUTO.  Fix later...

[boojum]

Switch trigger to AUTO.  Fix later...

Yes! Trigger was in "Normal" mode. In "Auto" mode, calibration works without freezing.
Thanks!

[Atlan]

It already works in every mode v0.020h, thanks for reporting the error. if only they were such easy mistakes.

[facekim]

With version v0.020h, those numbers appear on the screen above the trigger, and the entire rounded area flashes.

Autoset freezes often
Thank you

[Atlan]

 
Only DC mode?

[boojum]

It already works in every mode v0.020h, thanks for reporting the error. if only they were such easy mistakes.

In v0.020j first step of calibration now working - i hear several clicks of relay and green text Calibration successfull.

But it turns out that at next step Сalibration still hangs
After clicking OK on the “Set 300 mV DC and press OK” item, I hear the relay click once - and that’s all before the power restart.
(300mV DC is connected to CH1 at this moment, trigger set Auto CH1)

[Atlan]

Follow the instructions for calibration.  You must have the notification confirmation option turned on. Calibrate without usb and probes.  In the next step, when prompted, connect the required voltage to both channels at once.  After finishing the calibration, close the menu and turn off the oscilloscope to save the data.

[boojum]

..connect the required voltage to both channels at once..

Sorry, it's my mistake! Calibration now works fine. Thank you!

[boojum]

Quite strange that the header is not found to be correct, because it is based on the guide lines given here.

Maybe this will help fix the problem:
I look Pillow code. It check header size and raise error because header size is 56 bytes.

After add value 56 to check header size 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.

[Evi]

fnirsi_1013d.bin v0.020j.bin
Something wrong with CH1 below 500mV after calibration