Yep. Add the 0x before the numbers and put them in the "uint8 tp_config_data[]" array.
Then have dfw_ee test it.
It might be needed to change the first byte to 0xFF. This is a version number and needs to be higher or equal to what is in the touch panel flash memory.
dfw_ee try TP3 bin
TP3 oddly enough still has x reversed. TP1 has y reversed and TP2 has x reversed. TP1 actually works best in that the touch points although reversed in y work on the right hand side of the screen where the squares are located. TP2 and TP3 have to be touched about one square to the left to register the touch.
Many thanks for working on this!
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!
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
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
Yes, I know that's why I said oddly enough
I did no experiments before the backup. With TP1 and running the original flash firmware y is reversed but running the pecos software both x and y are reversed and I have to put 00 in both positions in the reversal file.
TRY new TP3 and TP4 is from my oscilloscope.
Linux had fun again, no one noticed that the size didn't fit, who knows what he actually compiled there
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:
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
It has to do with the two ranges in the data. One is for the y and the other is for the x.
In version 2 there is an error in the first range that starts with 0x18, 0x16, 0x14 etc. It should start with 0x14 down to 0x00. Also the data of the second range looks off. So this version will no work very well.
These values depend on how the IC is connected to the glass panel. It is a bit strange that the one supposed to be the original one still has some range reversed.
Lookup the meaning of the data in the programming manual I linked to in a previous post. That might clear thing up.
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.
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:
CFLAGS=-Wall -Wno-write-strings -Wno-char-subscripts -fno-stack-protector -DNO_STDLIB=1 -mcpu='arm926ej-s' -O3 -mfloat-abi=soft
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...
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.
Well to make sure the data is written correctly to the touch panel, I would make another backup with the correct version of my backup program, and then see if it is the same as what it is supposed to be.
Take a couple of SD cards, and load one with the backup software and one with the new firmware and one with the write touch panel code. Mark them properly to know which is which and swap them for doing the tasks. Saves re-writing the card over and over.
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 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.
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
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 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.
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
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...
TRY new TP3 and TP4 is from my oscilloscope.
The new TP3 worked the same. TP4 does not boot as it goes straight to the internal firmware. I spent the last 2 hours thinking the card wasn't getting written correctly but I can load any other TPx or other pecos software and they all load correctly.
Thanks!
Use files from pecos. Because mine have manually edited Make and other related files.
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)?
Long mode should only display the signal. That's what he was meant for. The original can't do anything. The possibility to save a wave and carry out the measurement in the browsing mode has been added here, as well as to move the signal from the memory to up to 3000 samples.
The signal is displayed and buffered, so it is possible to redraw the screen with the buffered signal when stopped and cursors will be available. We should think about whether it would be possible to do it this way. It would be a bit strange.
The priority is to finally solve the shift of the DC level, then I need a brain and a lot of time.[/quote]
Yeah, I only saw the reset on cursor movement after seeing it reported. I originally didn't see it since saved the wave first before measuring. I did see an offset between long and normal mode of around 400mv without signal or probes applied.
Youve done great!
The shift should not be there, give a picture of the calibration data. V0. 023x
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
Listing with cmd for dwf ee
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.zipOf 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"?
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 Atlan. Hopefully I can get it to build
Did you see the picture? you have the complete path to the MAKEfile there.
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