cant tell about code, but...
if you have 20 MHz, that you will get 5 asm instructions pec 1us
if you wan wait 1 us then add 5 nop instructions in asm
if you add 2 nop instructions, tahe You will get 0,5 us delay.
instead od nops You can yse domething like this for asm
declare dummy as byte
main:
mowvf dummy,w ;1 istruction
goto main
or similar 1 cicle commands for waiting.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So far I have used the internal 4 mhz and 8 mhz, also with PLL and it seems spot on. The wait command "us" and "sec' seems to be real accurate but have not tested with a scope so I cannot verify real-world values besides what I have done.
I am using the old GCB from the nochipdata file, new one will not work with old bitbang XMIT_RS232 as the clk timing seems off now. If the wait timing changes with cpu mhz then we got a bigger problem.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Santiago, I like the mentioned nop approach for really short timing, although not so good if you are using 4xPLL, on the newer devices, for 40, 48, & 64 Mhz clocks.
Will the gc simulator give you breakpoints or stopwatch like MPLAB? Having put your 20Mhz 1-9 us delay instances in MPLAB simulator/stopwatch, the results are well....interesting.
It looks like you have gotten off the Microsoft bandwagon, I commend you for that. Congratulations on the Gedit work too. If I understand correctly you are using Python; would like to revisit Python myself some day soon.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Interesting the PICLIST delay code generator. But in my case i needed something like this:
for delay=2 to 12
for pulse=0 to 30
set led on
wait delay us
set led off
wait delay us
next pulse
next delay
There are a lot of delays, then the error will be multiplied.
Anyway the accuracy i need is not so critical.
What's the gc simulator?
Gedit... yes, the plugin is written in Python. I like this... you can add any gtk widget to the bottom or side panel of gedit, or add new menu or toolbar items... then is possible transforming Gedit in anything you can imagine... :) and don't need to re-compile, just write the plugin, add to the plugins folder and you can activate or desactivate it in any moment.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
On the delay issue there have been put forth a couple of macro's on the web. One is on the Microchip forum, and the other is on the electro-tech-online forum here http://www.electro-tech-online.com/micro-controllers/94452-delay-code.html Have not tried them, but for multiples of 4Mhz clocks, and above the minimum number of instructions, should be very good?
These macros seem to suffer from the bloated code you talked about, when multiple calls are involved.
O.K. it's called gpsim and is on Sourceforge for downloads, but the web site is here http://gpsim.sourceforge.net/gpsim.html#shots Hard to discern what state of development the project is in, although there seem be some very recent file versions. Have not downloaded or read all documentation. Could be incomplete or limited number of devices, don't know.
Don't have a Linux distro, so can't see Gedit in action. Sounds great, and looks nice from the screenshots. Python (Windows version for me) seems very powerful, and dabbled just a little bit in an attempt at parsing GCBasic .dat files.
Need to get a dual boot setup going on the old laptop. Linux seems to be getting more and more support in terms of development tools out there, so there is hope of making me a convert yet.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
GPsim.. Ok.. yes, it is in development but is useful, as you say there are a limited number of devices supported and the grafical simulation is very basic. Of course you can insert breakpoints, run at diferent speeds, step by step; watch any register, view the grafical simulator or the osciloscope. Here is a screenshot: http://docs.google.com/Doc?id=ddvgzjtz_28c2spkhfv
Ktechlab is also in development, but is a powerfull tool... very easy to use electronic simulator and a PIC development IDE with flow-kind programming, basic and C (sdcc).
I like Python, i just know the very basic, but with a little patience is possible take some pieces of other programs and build interesting things just from scratch, this is the good thing about open source. For the grafical interfaces you can try WxGlade (for example) that uses WxWidgets or Glade + Gtx, this way you don't need to write the GUI's code... :)
The dual boot is a good chance, just try it and see what happens.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello again.
i would like to know how accurate is the "wait us" delay with a 20MHz clock.
I want to use it with very short delays, as "wait 2 us".
Thanks in advance.
cant tell about code, but...
if you have 20 MHz, that you will get 5 asm instructions pec 1us
if you wan wait 1 us then add 5 nop instructions in asm
if you add 2 nop instructions, tahe You will get 0,5 us delay.
instead od nops You can yse domething like this for asm
declare dummy as byte
main:
mowvf dummy,w ;1 istruction
goto main
or similar 1 cicle commands for waiting.
So far I have used the internal 4 mhz and 8 mhz, also with PLL and it seems spot on. The wait command "us" and "sec' seems to be real accurate but have not tested with a scope so I cannot verify real-world values besides what I have done.
I am using the old GCB from the nochipdata file, new one will not work with old bitbang XMIT_RS232 as the clk timing seems off now. If the wait timing changes with cpu mhz then we got a bigger problem.
Thanks Anonimous and J Olson for the informations.
By now wait us is working very well, i don't know the real accuracy, but as you said looks to be more than enought.
Regards.
Santiago, I like the mentioned nop approach for really short timing, although not so good if you are using 4xPLL, on the newer devices, for 40, 48, & 64 Mhz clocks.
If you are still with the midrange 16f''s there is a auto delay code generator on the PICLIST forum or http://www.piclist.com/techref/piclist/codegen/delay.htm
Will the gc simulator give you breakpoints or stopwatch like MPLAB? Having put your 20Mhz 1-9 us delay instances in MPLAB simulator/stopwatch, the results are well....interesting.
It looks like you have gotten off the Microsoft bandwagon, I commend you for that. Congratulations on the Gedit work too. If I understand correctly you are using Python; would like to revisit Python myself some day soon.
Hi Kent.
Interesting the PICLIST delay code generator. But in my case i needed something like this:
for delay=2 to 12
for pulse=0 to 30
set led on
wait delay us
set led off
wait delay us
next pulse
next delay
There are a lot of delays, then the error will be multiplied.
Anyway the accuracy i need is not so critical.
What's the gc simulator?
Gedit... yes, the plugin is written in Python. I like this... you can add any gtk widget to the bottom or side panel of gedit, or add new menu or toolbar items... then is possible transforming Gedit in anything you can imagine... :) and don't need to re-compile, just write the plugin, add to the plugins folder and you can activate or desactivate it in any moment.
Hi Santiago,
On the delay issue there have been put forth a couple of macro's on the web. One is on the Microchip forum, and the other is on the electro-tech-online forum here http://www.electro-tech-online.com/micro-controllers/94452-delay-code.html Have not tried them, but for multiples of 4Mhz clocks, and above the minimum number of instructions, should be very good?
These macros seem to suffer from the bloated code you talked about, when multiple calls are involved.
O.K. it's called gpsim and is on Sourceforge for downloads, but the web site is here http://gpsim.sourceforge.net/gpsim.html#shots Hard to discern what state of development the project is in, although there seem be some very recent file versions. Have not downloaded or read all documentation. Could be incomplete or limited number of devices, don't know.
Don't have a Linux distro, so can't see Gedit in action. Sounds great, and looks nice from the screenshots. Python (Windows version for me) seems very powerful, and dabbled just a little bit in an attempt at parsing GCBasic .dat files.
Need to get a dual boot setup going on the old laptop. Linux seems to be getting more and more support in terms of development tools out there, so there is hope of making me a convert yet.
GPsim.. Ok.. yes, it is in development but is useful, as you say there are a limited number of devices supported and the grafical simulation is very basic. Of course you can insert breakpoints, run at diferent speeds, step by step; watch any register, view the grafical simulator or the osciloscope. Here is a screenshot: http://docs.google.com/Doc?id=ddvgzjtz_28c2spkhfv
It can be used directly, but GPsim is used inside another programs, for example Piklab (no grafical simulations) or Ktechlab: http://pic-linux.foroactivo.net/ktechlab-f6/pantallazo-ktechlab-t17.htm#17
Ktechlab is also in development, but is a powerfull tool... very easy to use electronic simulator and a PIC development IDE with flow-kind programming, basic and C (sdcc).
I like Python, i just know the very basic, but with a little patience is possible take some pieces of other programs and build interesting things just from scratch, this is the good thing about open source. For the grafical interfaces you can try WxGlade (for example) that uses WxWidgets or Glade + Gtx, this way you don't need to write the GUI's code... :)
The dual boot is a good chance, just try it and see what happens.
Thanks for the WxGlade tip, that should prove useful down the road.