fix OV flag calculation for addwf
Missing files from SVN trunk
Merge changes in from SVN trunk
Fix bugs in regression test
Update Changelog
Add LCD registers to p16f193x processors
Hi @roy_r_rankin, I tried the simulator and everything seems to be working fine. I'm still learning to use gpsim but I'm now able to move forward with the PIC16F1937. Thank you for the quick resolution!
fix compiler warnings about create()
feature request 66 Support PIC16F1938 processor
This request fell through the cracks. As I have just done the p16f1933, 16f1937 and 16f1939 (currently missing LCD registers and functionality) adding the 1936 and 1938 should be forth coming shortly.
The current SVN now includes p16[l]f1933, p16[l]f1937 and p16[l]f1939. However, the LCD functionality and it's registers are not currently included and will be my next project to include.
Bit set/clear on ANSEL registers do not always do the correct port
ANSEL_P class has been modified to solve the issue for a2d channels not changing in and out of analog state. If addition as required by p16f193x processors, ports with ANSEL registers but not a2d ports are now handled.
add p16[L]F193x, with compile related cleanups
Bit set/clear on ANSEL registers do not always do the correct port
Here are the functions that I'm using: 40-pin versions of PIC16F1937 and PIC16F1939 Features: Internal clock oscillator (8MHz) PORTS A,B,C,D,E EUSART EEPROM I2C ADC WDT (Watch Dog Timer) TIMER0, TIMER1, TIMER2 PWM INTERRUPTS * EUSART * TIMER0 * PORTB (Interrupt on change) Thanks
Let me know what functionality you require. It will take some time to add some of the modules which are currently supported.
Add support for PIC16F1937 and PIC16F1939 MCUs
Hi Roy, I think C bit should be set, but not OV bit since it does not overflow in signed arithmetic. I could not try on hardware, but used MPLAB and it does not set it. See attached shot. Regards, Alvaro
Current operation looks correct to me, 0x3e + 0xd7 = 0x115 so bit 7 has overflowed and therefor I would expect the OV bit to be set. Can anyone check on the real hardware what the processor does?
STATUS OV flag being set when it should not
conftest.c: command not found
I do not see either of your configure.ac issues in Fedora, but also your patches also work fine in Fedora. So your bug should be fixed in svn 2647
fix bug 297
conftest.c: command not found
segfault at startup
-lm added to link flags svn 2646
fix bug 296
segfault at startup
solved downstream with another configure.ac fix, see https://bugs.gentoo.org/show_bug.cgi?id=949813
the problem shows when building with --disable-gui
the package is configured as ./configure --prefix=/usr --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --datarootdir=/usr/share --disable-dependency-tracking --disable-silent-rules --disable-static --docdir=/usr/share/doc/gpsim-9999 --htmldir=/usr/share/doc/gpsim-9999/html --with-sysroot=/ --libdir=/usr/lib64 --disable-static --disable-gui
segfault at startup
Add a detach command as a counterpart of the attach command.
Document the i2cmaster module.
Detach a stimulus from its current node when attaching to a different one.
Switch PIC16F818/819 to EEPROM_EXTND to handle flash program memory latches.
Add support for devices with flash program memory latches but no LWLO bit.
Fix the COUNT REMAIN value for a DS18S20.
Implement i2cmaster read communication.
Fix issues on font change
rewrite gui_menu changes to build process
Cannot set GPIO for scope on 10F202
Closing as not a bug. Will look at making build requirements better reported in configure.
Ahh right, sorry. Your syntax works - user issue 😅. Thank you, this can be closed :) Like Yacc and Lyx, Flex is not checked by configure so I didn't know it was required. A lot seems to have changed for the GTK3 version. Looking forward to the next stable release :)
I think the issue with scope is in your syntax. try : scope.ch0 = 'gpio0' Note that scan.cc is generated with flex from the scan.ll file.
I built the latest GTK3 version and it's the same. Notes regarding the latest build: -> configure is not in the source so I needed to run autogen.sh (I'm not familiar with autotools) -> I needed Yacc (Bison) and Lyx installed, maybe these could be checked by configure? -> scan.cc is missing from the /cli directory - I copied in the version from the release tarball and it compiled but it's odd that it's gone. Thanks
FYI my version is: gpsim-0.32.1 I compiled it from the from the release source tarball. I'll try the latest code in case it's already fixed
Cannot set GPIO for scope on 10F202
Source Browser window preferences now set in that window
GTK3 update
gtk3 build
Hello. If the CPU load does not go through the roof during the simulation, then does the PIC work in real time? So the pins are twitching at a real speed?
Remove module fails is module selected in breadboard
Fixed in svn 2633
fix bug 294
It works, thanks.
Remove module fails is module selected in breadboard
Yoric, The first number in the stimlus data is a gpsim cycle number and must be always increasing. I am assuming what you have done is used the number of cycles between changes rather than the cycle number. Attached I changed your data to be what is expected by the stimuli according to my understanding of what you are trying to do. Roy
The first stimulus D1, once triggered, remains at a low level, and the second D2 does not work at all.
Yoric, The FileStimulus model is a very different input file format as compared to asynchronous_stimulus. The stimuli modules drive the node high and low, so a pullup resister servers no purpose. As you stimulus files were not in the FileStimulus file format, the file was being rejected and the output always driven low. The best way to use the asynchronous_stimulus modules is either do is in an .stc file or in the .asm file using .sim commands so it does not have to be entered into the cli by hand....
Why is the level on RA2-3 low? What's with pullup, what's without?
Why is the level on RA2-3 low? What's with pullup, what's without?
pulsegen module. You would use one for each input. Or for perfect antiphase a single pulsegen module driving one input and also the input of an inverter module which then drives the second input. This is true only for the meander, but not for short pulses. stimulus asynchronous_stimulus initial_state 1 start_cycle 200 #period 5000 {<----->4500, 0, <------>100000, 1, <------>4000, 0, <------>75000, 1, <------>3000, 0, <------>50000, 1 <------>2000, 0, <------>40000, 1 <------>1600, 0, <------>30000,...
Yoric, If you are doing this for a fixed but adjustable frequency, look at the pulsegen module. You would use one for each input. Or for perfect antiphase a single pulsegen module driving one input and also the input of an inverter module which then drives the second input. If you are looking for a fixed frequency sweep you may be able to do it with the FileStimulus module. Roy On 20/7/24 21:06, Yoric wrote: Is this impossible, precisely because of the requirement of synchronicity? And if you attach...
Is this impossible, precisely because of the requirement of synchronicity? And if you attach one after the other, and take the exit from the first one too? Will it work like this?
Hello, sorry for my bad English. Please help me create synchronous antiphase stimuli for two inputs with a fill factor of 0.04 (short negative pulses) with a frequency from 5 to 150Hz.
fill factor = duty cycle=95%
Hello, sorry for my bad English. Please help me create synchronous antiphase stimuli for two inputs with a fill factor of 0.04 (short negative pulses) with a frequency from 5 to 150 hertz.
gpsim-0.32.1: false setting of the INTCON bit
Ok
gpsim-0.32.1: false setting of the INTCON bit
Yoric, This looks like normal behavior to me. All the portb pins are floating. When you write 0x7 to OPTION_REG you are clearing bit 7 which enables weak pullup on port B. This causes the port B pins to go high causing the INTCON:RBIF bit to be properly set as at least one portB pin has changed state. Roy Rankin
gpsim-0.32.1: false setting of the INTCON bit
fix some spelling
Add support for MPLAB XC8 output with source debugging.
Patch added with additional changes to load cmf file from cli and std file in svn 2631.
Patch 54 Add support for MPLAB XC8 output with source debugging.
Add support for MPLAB XC8 output with source debugging.
Fix a direct memory leak.
OK, You convinced my to fix the issue in gpsim svn 2629. When OSCCAL is set, such as in initialization, gpsim will check the last program memory address for a retlw instruction and create it if it is anything else.
Infinite loop due to OSCCAL value
fix bug #292 Infinite loop due to OSCCAL value
Remove GTK2 deprecations and unnecessary code and modernise
Infinite loop due to OSCCAL value
reopening for discussion.
Read the datasheet again : "Microchip Development Tools maintain all calibration bits to factory settings." It's not developer responsability to preserve this value. It's a factory setting that must be backup and rewrite by the programming tools. So the emulator MUST do the same as the real world MCU/programming tool when it load the Hex file. Valid opcode range is 0x3400 to 0x34FF, not the 0x3FFF like in a erased/bricked MCU. Gpsim already detect invalids opcodes (see the assembly debugger) so it's...
Infinite loop due to OSCCAL value
I think you meant to refer to program address 0x3ff rather than 0x3fff. Your code must contain something like that in example 9-1 of the reference manual in section 9.2.1.1. This example expects program location 0x3ff to contain a "retlw 0xXX" instruction in it. This program location is set at the factory, However, the note in this section says erasing the device will erase this value and it should be read before programing and then reprogrammed. Gpsim has no way of knowing if the 0x3ff location...
Infinite loop due to OSCCAL value
LCD module not displaying characters
New GCC 13.2.1 compiler dose not process raw font data structure the way old version of the compiler did. New structure should work with all compilers.
fix bug #291 LCD module not displaying characters
LCD module not displaying characters
I have verified your complaint with the SVN code, but it works with the latest release.I will be looking into the issue when I get a chance. Roy ----- Original Message ----- From: "[gpsim:discussion]" To:"[gpsim:discussion]" Cc: Sent:Mon, 04 Mar 2024 03:06:14 -0000 Subject:[gpsim:discussion] LCD Display module Hello The LCD Display module need some rectify. It doesn't print the Latin characters, stays blank, and prints only the custom characters if they are made. All the examples doesn't works too....
Hello The LCD Display module need some rectify. It doesn't print the Latin characters, stays blank, and prints only the custom characters if they are made. All the examples doesn't works too.
Use the same rules as gpasm for recognizing labels/symbols