String concatenation

[G. C.]

Hello,
I found a strange behavoiur of the compiler when trying to make a string concatenation with more than a number to string conversion (Str) on the same code line.. is it something known and it's not possible to be done?

dim orario as string
dim minuti as byte
dim secondi as byte
minuti = 10
secondi = 40

I mean that if i make this statement:

orario = Str(minuti) + ":" + Str(secondi)
I get an error
"Cannot handle variable construct. Please check syntax, simplify source or check use of variable types"

while doing only the first part orario = Str(minuti) + ":" gets compliled correctly..
Any suggestion? Should concatenation be done two pieces of the chain per time?

I also get an error
"Variable FOSC4 was not explicitly declared"

when trying to initialize a timer as follows (#option Explicit at the beginning of the program):
InitTimer1 FOSC4, PS1_1

Thanks for yr help,
GC

[Anobium]

I can have a look but I would need to know the chip. As each chip family has difference constrains in terms of the default string size.

[G. C.]

It's the PIC16F886.. Thanks for yr support.
What about the Timer issue?

[Anobium]

For the 16F string. It was a design decision to ensure the string concat did not fail silently when a function + constant + function was the concat. Why? The functions can return a string that exceeds the string and the two functions would be using the same temp vars and potentially you get a string concat corruption. All is not loss... the fix is so easy.

orario = Str(minuti) + ":"
orario += Str(secondi)

---

Re FOSC4. Oopps someone has removed that constant. As the Help stats OSC equates to FOSC/4. However, do this. Edit TIMER.H change 282 from #define Osc 1 to

#define Osc 1
#define FOSC4 = 1

Does this resolve?

[G. C.]

Ok, editing the Timer header file fixes it.. Thx

Also the "two lines" concatenations work, thx.

But In order to avoid to make the same (maybe annoying for you) question in the future, what's the rule about wich uC works with multiple concatenations etc and wich one do not?

I plan to move to newer, larger memory chips and bought some PIC18F27K42 and also some PIC24.. (Want to get hands on with bigger displays and the great Graphic Libs of GCB).. I guess on these there is no problem (hopefully).. But I am using what I already have in hand (the 16F886 for example) to get more familiar with GCB framework.

By the way, I saw yr video on how to debug with Terminal.. Looks quite easy, but I had to order another piece of HW (the USB/ TTL converter). Will experiment when I get the stuff.
Bye,
GC

[Anobium]

Great.

Rule. Always use the method above. string = function() + constant : string += function() it will always work. This approach also saves RAM - you can now minimise the variable length

With string length control is 44 bytes verses 79 bytes. Not the *5.

dim orario as string * 5
dim minuti as byte
dim secondi as byte
minuti = 10
secondi = 40

orario = Str(minuti) + ":" 
orario += Str(secondi) 

This wil work across all chips even the smallest.

---

GCBASIC is 8bit... we do not support PIC24.

We working on a 7inch GLCD! That will be fun to use.

---

Re TTL. Good idea.

[G. C.]

Sorry to bother again..

Now I am struggling with the Interrupt.. I used more or less the same instructions present on the On Interrupt help example1, but get no interrupt..
Questions:
1) after having used On Interrupt Timer1Overflow call xxxx, shall I enable the Timer1 interrupt? Reading the help, it seems GCB will take care of this without need to use TMR1IE=1
2) Once in handler (when it will get started!) shall I clear the Timer1 flag TMR1IF=0 ? Or GCB does it automatically?

3) After having enabled the single perhiperal interrup (i.e. Timer) shall I add also IntOn (as it was with the GIE= 1 instruction) in order to get interrupts activated?

Thanks for your patience, but it's difficult to sort out the answers even after having made several trials, and as you know sometimes reading the doc is not fully clear..
GC

Ps: if you want the see the file, I attach it here for you

[Anobium]

GCBASIC does handle all this register.bits.

I quickly put some serial debug in your code. The interrupt is firing as expected.

Can you confirm the the interrupt period you calculated? Once I know that time period then I can provide more thoughts.

[G. C.]

The timer is expected to overflow every 10 mSec.. (do not look at the comments, I started with the idea of 1mSec, but then increased to 10mSec).
At 8 Mhz, 125 nSec period x 4 (Fosc/4), the timer input clock period is set at 0.5 uSecs. So, to obtain a 10 mSec overflow it needs to count 20K pluses. As the Timer1 is a 16 bit counter, it will overflow at 65536 counts, therefore to count 20K pulse I preload it with the number 45536.

if it fired the interrupt , then I expected it to continue to show min/secs on the display.. But it does not. I also commute RA3 at a frequency of once per second, to use it as a quick check of the uC correct activity. I have'nt probed with a scope it yet as I had no time. Today will check it.

[Anobium]

Thank you. The interrupt is doing what you want.

The simulator shows the signal rising every 1 sec.

---

There is something wrong in the logic elsewhere in the program.

[Anobium]

A really good explaination. I am very grateful for the clarity of this post. :-)

[Anobium]

You are essentially overrunning the stack.

The sim. I am showing the timer on the serial terminal. To make the code work, change the many subs you have to macros. The code will be inline and you can keep the structure.

---

Consider your program.

When the interrupt is called the program could be in a routine called FnLSL ( this sets the bit in the display buffer). The Stack would be... ( my rough study of the program.. I think the you may be at 10 stacks deep).

1. Main
2. visualizza_ore_minuti
3. Max7219_LEDMatrix_GLCDPrint
4. GLCDDrawChar
5. PSet
6. FnLSL
7. interrupt .... then the interrupt fires...
8. int_conta_10millisecondi
9. carica_timer1
10. settimer

According PICInfo the 16F886 has 8 stacks.... overflow.

Macros resolved for me.

But, I would change the chip to something a lot newer.

[Anobium]

My hack at your code.

And, this is useful... I just added here...

    orario = leftpad(Str(minuti), 2, "0" )+":"
    orario += leftpad(Str(secondi),2,"0")

Evan

[G. C.]

Really interesting... I am learning a lot (even if rather slowly)..
First, I cleared the point about interrupt enables etc.. Using On interrupt (as described in the help) enables the specific peripheral interrupt.
Second, I do not need to clear the int flag (not specified in the help, but being not present in the examples, one should get it).

I checked with the scope the RA3 pin and it shows the expected 0.5 Hz.. Therefore, I told myself, the Int fires correctly.. But then, without your suggestion to use macros I would have given for granted that a 10 mSec interval (between two interrupt) should be more than enough for any subroutine to refresh the display..

And by the way, I would have never tought to change a sub with a macro (and frankly speaking still have not very clear what's exactly the difference, but I grasped the idea of the stack etc.). Never used a 'macro' statement before, but all the programs I have done in the past where with VisualBasic on the PC - surely never needing to spare some Ram location.. :)

See, here come a fundamental philosopyical point of the use of an high level compiler versus do it yrself code: if you use libraries to simplify your coding life, you do not expect to have to get deep into their functionnement and check their behaviour.. This would require (at least for me) more time than using a pre-cooked solution.. Nor can I pretend to get precise indication on execution times for each command in each library etc.. I know you're already providing much.

This does'nt change my gratefulness to people like you that are offering such experience to others, be sure of it.. Keep on doing such great job.

Back to the project/experiments:

Yes, I will switch to a 18F27K42 that I just received. I ordered them thinking to expand the 16f886 capabilities on the same 28 pin package.. And there is also PPS if needed.
As i said, I also have an NTC that requires LOGs to calculate, and foreseen that adding MATH lib would eat up quickly all the memory available on the old 16F886 guy.
I was just experimenting on it to get familiar with GCB..
I have been using a lot the interrupt that counts 10's of mSec in my boards programmed in C, it's a sort of mini OS, or better a little Task scheduler useful for many timed purposes.. And setting the 10mSec I tought I had plenty of time to service various devices connected to my boards..

But while C is powerful, fast and compact (but awful), Basic is much more preferrable. When I found GCB It was like the holy grail.. But I am now getting the limitations of a much faster code writing phase with the (much?) slower debugging.. Mostly because I am not experience yet with GCB, nor I can use the HW debugger (ICD3) as I was used to.

Waiting for my USB/TLL adater to do some more debugging on my side, without bothering too much. I'll stop chasing you for a while, as without a debugging capability is like driving blindfolded..
Bye,
GC

PS: I'll get a look also to the simulator you shown up here..

[Anobium]

A good set of comments from you.

The big difference for this project was the stacks. Other compilers probably have a stack counter... if someone wants to add to GCBASIC then the compiler could do the same. :-)

Re Sub v Macro. Sub is call to the code in the sub, therefore using one Stack. Macro put the code in the macro inline where the Macro call is. So, a Sub is reusable code and a Macro will add an instant of the same code every time you call it.

The Simulator.... I am working with the Developer so that we can rebadge the Sim as part of the GCBASIC tool chain. Meanwhile. it is downloadable on the web.

And. ICD. I think you can still walk the GCB program in the debugging tools. Have a look at https://youtu.be/8ATjVEZwGxI?si=2ZzsE7LeO7ErdjoM You can load the GCBASIC into MPLAB--X and use the MPLAB-X debugger.

:=)

[G. C.]

Thanks for the macro explaination, and seen the video..
However this time I will not follow your advice - that would mean to get back to MPLAB and Assembler debugging.. see my "philosopical " comment above".

It's like for a woodworker with power tools that wants to move to CNC's and laser cutters etc, but instead has to go back to handsaw and hand drill.. No way.

As a joke, that would mean that instead of moving to GCBasic, one goes back to basics..!

I left assembler at the times of 8080/85 and HP64000, that's why I became an Analog guy! :) :) . The first Basic experiences with an Olivetti P6060 and later with the Tandy TRS80 were my first programming loves. Then Quickbasic/ Visual Basic.

So, thanks a lot, I will stick to your first suggestion: GCBasic and Terminal debugging during my learning steps.

Have a good day!
GC

[Anobium]

I like your feedback.

You have many options with GCBASIC.

And, I can always think of another. ... :-)