gnupic: Thread: Re: [gnupic] terminal simulation on gpsim?

Hi Bill,

you have two possibilities:

- use the usart module (already a part of libgpsim_modules), which uses 
the GUI. See the example in the directory gpsim/examples/modules/usart_gui
- use the usart_con module, which doesn't use the GUI: it displays the 
received characters directly to the console: gpsim/extras/usart_con

Borut


bill sack wrote:

> my usual devel loop as an inexperienced/uneducated pic programmer is 
> to write code that includes a lot of debugging output via rs232, burn 
> a chip, move the chip onto my evaluation board, type commands to it 
> and look at the output with minicom or possibly PD, fix the code based 
> on observations, burn the chip again, etc. is it possible at this 
> point to do something similar purely through simulation with gpsim? 
> i've loaded the uart simulation examples provided with the gpsim 
> distro, and the output on the program's terminal shows that something 
> is being transmitted ... if i'm not mistaken, this is a feature of 
> some of the non-opensource simulators out there.
>
> is this a reasonable feature request? or is it already possible and 
> i'm just too backward to figure it out?
>
> thanks,
> bill

Borut Razem wrote:
> Hi Bill,
> 
> you have two possibilities:
> 
> - use the usart module (already a part of libgpsim_modules), which uses 
> the GUI. See the example in the directory gpsim/examples/modules/usart_gui
> - use the usart_con module, which doesn't use the GUI: it displays the 
> received characters directly to the console: gpsim/extras/usart_con

Bill,

I'll second Borut's comments; gpsim does have a terminal emulator that 
will accept RS232. An example of its usage can be found in 
regression/usart_test/

The key things to note is that there are four attributes in the Usart 
module. For example, suppose you name the usart module U1:

module load uart U1

Then there are 4 attributes named: U1.rxbaud, U1.txbaud, U1.rx, U1.tx. 
The first two are the receiver and transmitter baud rates. The last two 
are the receiver register and transmit register. The receiver register 
holds the last byte that was received (and if the module is tied to a 
PIC then this should be last byte that was transmitted by the PIC). 
Similarly writing a value to the transmit register will initiate a transmit.

You can also get a description of an attribute via help:

gpsim> help U1.tx
TxBuffer: U1.tx=0
UART Transmit Register


Borut,

The usart_con module slipped by without me noticing! Why did you add a 
whole new module instead of adding a way for the existing one to direct 
its output to a console?

Scott

Hi Scott,

> The usart_con module slipped by without me noticing! Why did you add a 
> whole new module instead of adding a way for the existing one to 
> direct its output to a console?

The background is that I was going to add the sdcc pic16 port to the 
regression test suite, so I needed a way to display characters from the 
compiled and simulated C code (putchar()) to the standard output 
(console). The gpsim usart module was already there, but:

- it is a part of libgpsim_modules, but for regression testing the other 
modules are not needed
- it produced a lot of debugging info on the console, so it was not 
usable for regression test purposes (you already corrected that by 
commenting out the #define DEBUG in usart.cc)
- it has a GUI, which means that it can not be compiled on systems 
without GTK+ and it's family. This is important because I plan to 
include the pic16 regression tests to sdcc nightly builds on SF CF 
(allready done on x86-linux2 machine), but the CF machines usually don't 
have GTK+ libraries installed. I know that there is the #ifdef HAVE_GUI 
which generates a GUI-less libgpsim_modules, but I don't like the idea 
to have two files with different functionalities having the same name 
(libgpsim_modules with and without GUI).
- the usart module handles both input and output, but the regression 
tests needs only the output. Actually I don't have an idea how the input 
would (should) work from the console: who should capture the characters: 
gspim or the usart module?

Yes, you are right: all of quoted reasons (or excuses ;-) can be solved, 
but I needed a quick solution and I did it in a dirty way :-(

But anyway: the usart_con module is nothing else but a modified usart 
module:
- without GUI
- disabled debugging messages
- without the TXPIN

If / when all the previusly listed issues will be implemented in usart, 
usart_con won't be needed any more and can be removed.

P.S.: sdcc pic16 regression test are working quite well. Currently there 
are many failures, but I think they will be quickly solved by pic16 sdcc 
gurus. The results can be found at:
http://sdcc.sourceforge.net/release_wiki/index.php?page=RegTestRes
Usualy is more difficult to find a bug then to fix it, but now we have a 
tool :-)

Thank you for the gpsim and sorry for my negligence,

Borut

Borut Razem wrote:
> Hi Scott,
> 
>> The usart_con module slipped by without me noticing! Why did you add a 
>> whole new module instead of adding a way for the existing one to 
>> direct its output to a console?
> 
> 
> The background is that I was going to add the sdcc pic16 port to the 
> regression test suite, so I needed a way to display characters from the 
> compiled and simulated C code (putchar()) to the standard output 
> (console). The gpsim usart module was already there, but:

<snip>


> Yes, you are right: all of quoted reasons (or excuses ;-) can be solved, 
> but I needed a quick solution and I did it in a dirty way :-(

I understand all of those reasons and probably would've done something 
similar given the same circumstances and goals.

> If / when all the previusly listed issues will be implemented in usart, 
> usart_con won't be needed any more and can be removed.

I think it'd be possible to use the same gui-based usart console for 
non-gui applications. The module already examines whether or not the gui 
is being used and will selectively inhibit gui calls. In fact, in the 
gpsim regression tests (which run in non-gui mode) already takes 
advantage of this feature for the usart_test/ regression test. I think a 
simple change would be to direct the module's output to stdout if it's 
determine the gui is not being used.

> 
> P.S.: sdcc pic16 regression test are working quite well. Currently there 
> are many failures, but I think they will be quickly solved by pic16 sdcc 
> gurus. The results can be found at:
> http://sdcc.sourceforge.net/release_wiki/index.php?page=RegTestRes
> Usualy is more difficult to find a bug then to fix it, but now we have a 
> tool :-)

I saw this and was quite impressed! Fixing bugs is easy. Finding them is 
harder. Designing tests and tools to find them is harder still!

> Thank you for the gpsim and sorry for my negligence,

? I don't see any negligence here. But I have seen your contributions to 
gpsim and sdcc, and they've been enormous and very professional!

Scott

wow, it would be truly life-altering to have these capabilities. these 
are only on the cvs version, right? none of the tarballs i've gotten so 
far seem to contain these things.

i've tried the cvs a few times today and only gotten errors:

cvs [checkout aborted]: unrecognized auth response from cvs.sourceforge.net: M P
serverBackend::PserverBackend() Connect (Connection refused)


maybe a bad day in sourceforge-land? i will keep trying.

thanks for your replies, though. i can't wait to actually try it out.

best,
b


Scott Dattalo wrote:

> Borut Razem wrote:
>
>> Hi Bill,
>>
>> you have two possibilities:
>>
>> - use the usart module (already a part of libgpsim_modules), which 
>> uses the GUI. See the example in the directory 
>> gpsim/examples/modules/usart_gui
>> - use the usart_con module, which doesn't use the GUI: it displays 
>> the received characters directly to the console: gpsim/extras/usart_con
>
>
> Bill,
>
> I'll second Borut's comments; gpsim does have a terminal emulator that 
> will accept RS232. An example of its usage can be found in 
> regression/usart_test/
>
> The key things to note is that there are four attributes in the Usart 
> module. For example, suppose you name the usart module U1:
>
> module load uart U1
>
> Then there are 4 attributes named: U1.rxbaud, U1.txbaud, U1.rx, U1.tx. 
> The first two are the receiver and transmitter baud rates. The last 
> two are the receiver register and transmit register. The receiver 
> register holds the last byte that was received (and if the module is 
> tied to a PIC then this should be last byte that was transmitted by 
> the PIC). Similarly writing a value to the transmit register will 
> initiate a transmit.
>
> You can also get a description of an attribute via help:
>
> gpsim> help U1.tx
> TxBuffer: U1.tx=0
> UART Transmit Register
>
>
> Borut,
>
> The usart_con module slipped by without me noticing! Why did you add a 
> whole new module instead of adding a way for the existing one to 
> direct its output to a console?
>
> Scott
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
>
>
>

All the fuctionalities required for running the sdcc regression test are 
now supported by the usart module, which is a part of the 
libgpsim_modules library. I introduced the "console" boolean attribute 
to echo the received characters to the terminal window:

console = true

The usart_con module is not needed any more so I removed it from svn.

Borut


Borut Razem wrote:
> Hi Scott,
>
>> The usart_con module slipped by without me noticing! Why did you add 
>> a whole new module instead of adding a way for the existing one to 
>> direct its output to a console?
>
> The background is that I was going to add the sdcc pic16 port to the 
> regression test suite, so I needed a way to display characters from 
> the compiled and simulated C code (putchar()) to the standard output 
> (console). The gpsim usart module was already there, but:
>
> - it is a part of libgpsim_modules, but for regression testing the 
> other modules are not needed
> - it produced a lot of debugging info on the console, so it was not 
> usable for regression test purposes (you already corrected that by 
> commenting out the #define DEBUG in usart.cc)
> - it has a GUI, which means that it can not be compiled on systems 
> without GTK+ and it's family. This is important because I plan to 
> include the pic16 regression tests to sdcc nightly builds on SF CF 
> (allready done on x86-linux2 machine), but the CF machines usually 
> don't have GTK+ libraries installed. I know that there is the #ifdef 
> HAVE_GUI which generates a GUI-less libgpsim_modules, but I don't like 
> the idea to have two files with different functionalities having the 
> same name (libgpsim_modules with and without GUI).
> - the usart module handles both input and output, but the regression 
> tests needs only the output. Actually I don't have an idea how the 
> input would (should) work from the console: who should capture the 
> characters: gspim or the usart module?
>
> Yes, you are right: all of quoted reasons (or excuses ;-) can be 
> solved, but I needed a quick solution and I did it in a dirty way :-(
>
> But anyway: the usart_con module is nothing else but a modified usart 
> module:
> - without GUI
> - disabled debugging messages
> - without the TXPIN
>
> If / when all the previusly listed issues will be implemented in 
> usart, usart_con won't be needed any more and can be removed.
>
> P.S.: sdcc pic16 regression test are working quite well. Currently 
> there are many failures, but I think they will be quickly solved by 
> pic16 sdcc gurus. The results can be found at:
> http://sdcc.sourceforge.net/release_wiki/index.php?page=RegTestRes
> Usualy is more difficult to find a bug then to fix it, but now we have 
> a tool :-)
>
> Thank you for the gpsim and sorry for my negligence,
>
> Borut