Hi, I am new here :) about LCD, hserin, serout/serin baudrate, and optimisation

[Morganl]

Hi there
My name is Morgan Leijström
I will probably both need help as I am new to picaxe, and probably i can also give help as i was programming PICs in assembly fifteen years ago, have been designing and servicing automation hardware for 30 years, and currently program PLCs and design circuit boards.

My interest for picaxe is mainly for my son to learn programming, and build lego robots etc. Maybe also in my profession for simple projects: having the idea that the code may be readable by my customers, especially the flowcharts, which may save time on documentation. Maybe also for "home automation", several units on a RS485 network. Will see...

First exercise: hserin and 4-bit LCD mode
To get warmed up i decided to improve the AXE133 serial-to-LCD/OLED interface;
Reason: For host to be running better, it should transmit much faster, and never need to add delays, and i plan to add support for nordic characters, larger displays, animation, graphic gauges, and panel keys, knob, and status readback.

For a start I have converted it to 4-bit interface to free up 4 pins (for hserin, second enable for 4x40 displays, and i also need them to interface with panel keys and incremental knob together with the other 3 free pins and programming pins.)
It use hserin now by reading the receive flag.
Next step is to make a software buffer. (I know the X2 handle buffers in scratchpad themselves and have other useful improvements, but I try to stay with the 18M2 as in original kit so other can convert easily if anyone should like)

Two lessons so far
§ some LCD need both command 1 and 2 to really clear plus home the pointer.
§ serin/serout have some problem with speed accuracy, as i now see some other members have pointed out on this forum... it really should be in the manual, or even better get fixed...!
(Sender: 28X2, reciever 18M2; OK when using serout, serin - when changed to serout, hserin often the msbits was wrong, but adding Xtal to 28X2 fixed it. My guess is that serin speed is off a little bit, and it works or not depending on how exact the internal oscillators are in sender and receiver; if unlucky sender is off in one direction, and receiver in the other.)(I presume hser* is more exact than ser*)


Now i have some questions
__To improve reliability
§ Anyone know some trick to know if the display have got out of sync from high/low nibble in 4-bit mode?
§ some idea how to best implement checksummed serial comm?
§ Can the PIC watchdog be utilised or is it occupied by PICAXE?

__To decrease slowness
§ I read here that goto/gosub takes a nasty amount of cycles.
Do also the jump to for/do in for-next and do-loop take many cycles?
§ Is there some table of how many cycles commands take?
§ Ideas of what constructs are fastest? I guess a CASE is faster than a bunch of IF-ELSEIF? etc...
i guess that in some cases it is best to compute a variable x and use on x goto/gosub


/Morgan

 

[westaust55]

Welcome to the PICAXE forum.

I cannot immediately answer all of your questions but for some, responses are as follows:

Can the PIC watchdog be utilised or is it occupied by PICAXE?
The PICAXE firmware utilises the PIC watchdog timer.

On the topic of command operating times, have a look at this thread I started a couple of years ago:
http://www.picaxeforum.co.uk/showthread.php?17782-PICAXE-program-Size-Optimisations-and-Speed
Not all BASIC commands are covered however quite a few including GOTO and GOSUB are included.

 

[srnet]

Well ambition is a good thing .......................

Having said that its unlikely the current 18M2 setup can be improved a lot, it can be run at 32Mhz, but that would only allow operation to about 4800baud.

Try to run it any faster and the PICAXE simply runs out of time to write one byte to the display and be ready for the next one to arrive.

The main input character routine is already fairly tight;

main:

serin RX,baud,b1			; wait for the next byte

; NB keep character mode test as first item in this list to optimise speed
if b1 < 253 then
	let pinsB = b1 		; output the data
	pulsout enable,1  	; pulse the enable pin to send data.
	goto main			; quickly loop back to top

And that routine can only really keep up with 4800baud input at a clock speed of 32Mhz !!

Using a 4bit display write is going to slow is even further, as would receiving characters and writing them to a 'buffer'

One of the X2 PICAXEs running background receive at 64Mhz would be a far better choice.

 

[hippy]

As srnet notes the problem is one of processing speed; not so much the baud rate but the rate at which the OLED driver can take one byte, process it, send to the display, then be ready to receive the next. The 18M2 has only limited buffering for received characters using HSERIN so throughput improvements might not be as great as may be hoped for.

There have been a couple of projects on the forum and blog entries for projects which use 20X2 chips and their larger background receive buffers.

 

[Morganl]

Thank you for the quick replies!
And or all the work you have put into that document

Uh, I will sure try to avoid unecessary gosub; gosub+return =3ms om 18M2+@4Mhz!
Is there some nice way to inline several instances of identical code; by macros or include files?

Yes picaxe have put up a wall between the programer and the hardware... but also mostly alow most direct acess!
For the M2 devices - at least 18M2, there is a recieve flag in hardware so we can see when there is a byte recieved

My idea is to quickly switch between different tasks built like state machines doing one tiny step in one task at a time, and between each check if a byte is received.
If flag not set do another step in next task, check again etc; if byte recieved, put it in a ring buffer, do another task.
One of the tasks is read buffer to LCD, another is scan keys, another animate graphic character, etc.

Here is my current receive routine that just loops to itself until it see a flag:

getchar:
poll_RCIF:
	peeksfr $11,b11
	let b11=b11 AND %00100000 ;RCIF=bit 5 in SFR $11 bank0
	if b11 = 0 then goto poll_RCIF
	hserin b1
return

 

[inglewoodpete]

I developed an improved OLED interface, documented here: OLED interface with High Speed Serial, i2c and Mapped Screen using i2c. It is worth reading, especially if you want to use one of the alternate European character sets.

My configuration allows the 20X2 to write up to 1600 characters per second when run at 64MHz.

The WinStar OLED (supplied by Rev-Ed) is not easy to reliably synchronise in 4-bit mode. I found that power cycling was the only method that worked reliably!

Also, it is nearly impossible to determine the number of clock cycles a PICAXE BASIC command takes due the way the sub-byte program tokens a packed into the flash by the PE.

Peter

 

[hippy]

Here is my current receive routine that just loops to itself until it see a flag:

You can optimise and speed up bit access by moving bytes into the 'b0' variable and using bit0 through bit7 variables to assess the state of the bits. The general rule of thumb is the less code you have the quicker it will be. The DO-LOOP construct can make code more readable than using 'label:' and 'if then/got label' jumps ...

getchar:
  do
    peeksfr $11, b0
  loop until bit5 = 1  ; RCIF=bit 5 in SFR $11 bank0
  hserin b1
  return

There are four byte variables (b0,b1,b2,b3) which can be used with bit0 to bit31 bit variables but using b0 and bit0 to bit7 is often the easiest and most convenient to use.

Or alternatively you can simply read and check if a byte was received -

getchar:
  w0 = $FFFF
  do
    hserin w0
  loop until b1 = 0 
  return ; byte received in b0

You would have to test both to see which was quickest and most effective. For maximum speed you would probably want to replace every "gosub getchar' with the code used within the 'getchar:' routine. This will remove the overhead of the gosub/return and speed things up.

 

[Morganl]

Thanks Peter

Memory mapped display is a good idea.

Yes the 20X2 is a better chip for this, but i try modify the original kit as little as possible.
If i code in assembly it may be 100 times faster (but limited to sane bauds and LCD speed) - but now i want to learn picaxe.

It is amazing how many modules and chips of different kind ther is on the market that need power cycling if something mess up. Been bitten before, even by chips that had a non working "master reset" pin. I may add a mosfet for that, that pulls power for a second then reinitialise the LCD/OLED. Problem is how to detect it is lost. Maybe now and then try to read something back and if it fail it is definately out of sync or crashed other ways.

 

[Morganl]

Thank you hippy

Ah, i forgot i read about bit variables mapping in bytes.

Yes i will try to avoid unnecessary jumps (especially gosub) and inline as much as possible.

Is there some aiding functionality to inline chunks of identical code, like macro or include?

Yes do-loop looks better. Is it also faster than goto?

 

[MartinM57]

Is there some aiding functionality to inline chunks of identical code, like macro or include?

Not at the moment - it's copy-and-paste if you have identical code I'm afraid.

Are you already needing to uwrap loops/repeat code inline to avoid GOSUBs etc - I'm not sure I'd start with PICAXE if you really, really need to write your own RTOS and expect superfast performance as well.

 

[hippy]

Yes do-loop looks better. Is it also faster than goto?

No. The DO-LOOP and other block structured commands create the same code as if GOTO and IF-THEN commands were used. They help program structure and readability but don't usually improve speed.

Sometimes maximum speed is gained from using only GOTO and IF-THEN commands; block commands may add some additional overhead. For example an IF-THEN-ELSE-ENDIF has a hidden GOTO for the ELSE which leads to after the ENDIF. If used within a loop a 'GOTO loopstart' makes the THEN clause execute a little faster ( one GOTO executed to get to the loop start rather than two ).

; Most readable
  Do
    If b0 = 0 Then
      Gosub DoAction0
    Else
      Gosub DoAction1
    End If
  Loop

; Faster IF-THEN handling
LoopStart:
  Do
    If b0 = 0 Then
      Gosub DoAction0
      [b]Goto LoopStart[/b]
    Else
      Gosub DoAction1
    End If
  Loop

; Slightly less memory used than above
LoopStart:
  Do
    If b0 = 0 Then
      Gosub DoAction0
      Goto LoopStart
    End If
    Gosub DoAction1
  Loop

Usually, at the experienced level, the block structured commands and avoidance of GOTO would be recommended for readability and ease of use, particularly for multiple options where IF-ELSEIF and SELECT-CASE work well, but for maximum speed it is sometimes necessary to sacrifice code elegance for speed. In most programs however maximum speed is not all that important.

 

[Morganl]

Thirteen years ago i made a fast "RTOS" on a PIC16 20MHz, it concurrently handled precision AD and DAC chips through SPI, ran several software timers, and managed 17 k states per second from an incremental counter, while running a main program.

Now i want to learn picaxe as i think it is a good entry to learn programming to teach my 7 y old son.
And maybe for me to whip up test or simple projects into.
(I may revise that statements but still want to give it a try)

Unrolling loops is a standard strategy to speed up any language.
Picaxe is extremely slow in jumping so here it is a good example when it is needed.

 

[Morganl]

Great info, hippy, thanks.

 

[MartinM57]

If you want to "learn PICAXE" with a view to teaching your 7 year old son (good idea ) then I can't see why RTOS techniques/unrolling loops etc are of any relevance at all - leave those to your late night playing by yourself, and let him enjoy LEDs, servos, robots etc using the simple PICAXE basic commands

<<Picaxe is extremely slow in jumping>> ... yes, compared with an assembly program running on a 20MHz PIC. But not for the educational market that the PICAXE is aimed at.

 

[Morganl]

I agree RTOS is not first lesson
However i started hacking the LCD driver to learn myself, and concurrent multitasking by using state machines is what i am comfortable with, and it works optimal in almost every programming language. If i find it good enough i might use it for homa automation, and I actually have a simple commercial project a friend asked me about last week, that i think i can solve easiest by picaxe.

I also think it is a good thing to teach early, so programmers do not get caught up in the idea of the program should wait here and there - it is much better learn multitasking is the natural thing.

He also already do some simple PLC programming using blocks, and there *everyting* executes every scan cycle.

 

[Morganl]

I was continuing playing with this.
But Axepad crashed (windows popup said it encountered a problem and asked to report to MS) after i opened another instance using menu->New put some code in, then changed back to first window and did some more there.
Is this a known problem? Is any log available and wanted?
Running on MS XP SP3 Swedish 32 bit, in Virtualbox 4.2.16 on 64 bit Linux Mageia 3.

 

[hippy]

Using multiple code windows with AXEpad should not cause crashes.

It is a little unclear what your configuration is; you appear to be running AXEpad for Windows under XP in a virtual environment on a Linux system. It would seem better to run AXEpad for Linux directly under Linux and not use any virtual machine.

 

[srnet]

One thing to remember that if you want speed, you should be reading the display busy flag. The various display writes and commands take different amounts of time to complete, and this varies between different types of modules, the OLEDs for instance seem to be quite a lot faster in operation than the plain LCDs. So you need to access the module R/W line.

I did produce a plug in replacement for the 18M2 using compiled Mikrobasic, running on the native PIC. A PCB mod allowed the R/W line to be read. The resultant modified AXE133Y ran at 38400baud, no problem.

Now if you were to use a 20X2 and do a PCB for it, it would run faster and there might be a market for it.

 

[Morganl]

Well yes i run XP in a virtual computer. We use Linux both at home and work whole family.
Reason why i use MSWindows is because i wanted to try all your software, and most is MS only, and i already had MS installed in virtualbox for another win-only PLC app.
I should try winaxepad.
EDIT: *LIN*axepad! /EDIT
I decided i prefer it over the other editors anyway.

The only LCD command that is slower than task cycle time between LCD writes is CLS and home,plus init, and for them code just idles a safe time, easiest... For normal operation it would just slow down to check a flag that is never set

On my plan to learn is to get back to PIC assembly and learn to integrate with C/Basic/Pascal/whatever so i can make agile assembly-only interrupt background services and easy handle strings and floating point math in main.

I think picaxe have its uses for learning and some mockups, even some commercial low volume things, but other tools for other uses...

I am not interested in the workload selling and support will cause, but may post code if i get it to some usable state...
That said i can also probably refine it, document, and design and have PCB:s produced so if some have an interesting proposal...

 

[srnet]

On my plan to learn is to get back to PIC assembly and learn to integrate with C/Basic/Pascal/whatever so i can make agile assembly-only interrupt background services and easy handle strings and floating point math in main.

On a PICAXE ?

 

[Morganl]

On a PICAXE ?

No, assembly+compiled language on plain PIC chips.

 

[Morganl]

So I tried your different editors.
Here follow some feedback regarding different charsets they use, and short bug reports, i.e PE should not substitute characters!

A problem with winaxepad is that for me (swedish XP) i can not type AltGr keys (@ and $ etc, need to copy-paste them...) but it works in other windows programs including PE. (and these keys work in linaxepad)

Winaxepad and Linaxepad use same charset, but PE (Programming Editor) use another (seen when outside a-z letters)

Using winaxepad on a file which i opened, edited, saved using PE, i see PE actually destroyed many comment by mangling not only nordic characters, but also the paragraph sign. Here is a real bug: it shold not substitute characters in users source without telling him!! (destroys comments and string data)

Using Linaxepad, it outputs "Invalid UTF-8 string passed to pango_layout_set_text" (seen when started from terminal) when it encounters such chars entered in the opened file by PE.

There is a slight bug in Linaxepad syntax highlighting as a line that starts with semicolon is black (not green) when such chars are later in that line.

Another: in Winaxepad the line "case 214: lcddata = 1" is correctly coloured, but all black in Linaxepad.
(possibly colon there is not officially supported in this dialect, but syntax pass on both versions, have not run program yet...)

Linaxepad is rendered as beautiful on modern Linux as other apps (much nicer to look at text than in WinXP), but why is it many times slower in scrolling than other native apps, and also several times slowe than winaxepad on xp in virtual machine on same computer?! (if i spin the scroll wheel it takes near one second for it to finish scroll after i stop the wheel) But it is fast enough when using the scroll bar instead.

Linaxepad configurations dialog button "AXE027 modprobe" fail: popup say sudo need tty.
Manually modprobing using sudo in a virtual terminal (KDE Dolphin) works, and then i can select /dev/ttyUSB0 in the dropdown.

 

[Morganl]

A couple minor bugs when dragging text:
When moving text by i.e "painting it" with mouse drag, release button, hold down mouse button on text an d drag it:

In Winaxepad, it is dragged as expected. If i hold down Ctrl key there appear a "+" in mouse pointer so one would guess the text to be copied, BUT it is still moved, not copied!

In Linaxepad it is *always* copied, even if i want to just move it!

Are the issues i have something about my setup, or is this normal?

Regarding my LCD project I will be back in some days, when time permit. But i got a request for a simple paid project where i can use a picaxe

 

[Morganl]

Yesterday i finished my first PICAXE project, a little program that randomly twinkles many LEDs, for a present for my daughter

Sorry to continue the nagging, but:

I have found Linaxepad also (once) just "dissapeared" (crashed), like winaxepad did for me once.

Other issues they both share are that copy and cut often fails (more often on linux version, but also happens on mswindows version, so i guess the core of the problem is internal) ; when pasting what should have been copied either something earlier copied is pasted, or - most often _nothing_ is pasted (paste buffer got _cleared_!). Regardless of i use right click menu or Ctrl-C/X to copy/cut.

Easy workaround: Double-copy / Copy+cut ( Ctrl-{C,C} respectively Ctrl-{C,X} )

Nobody else notice? Known bug? Just my system, if so why?

Almost everybody use Program Editor instead?

BTW, Program Editor 5.5.5 say syntax error on my #picaxe 18M2 lines , which Lin&Winaxepad accepts. Bug?

When is next version due?

 

[SteveT]

I use LinAXEpad but have never had any problem with copy and paste or cut and paste.

 

[Morganl]

Than you for the reply
OK something in my setup that triggers it then. That i use 64 bit? Localisation?
If Revolution wants to dig into it, tell me if you want me to test somnething.

I went back to PE in WinXP in Virtualbox, as i guess PE is getting more development, and more people use it and it use another character than the *axepad (visible on non-a-z letters), when exchanging code i think it is good to have the same.

But why do PE not like #picaxe statements?

 

[hippy]

But why do PE not like #picaxe statements?

PE should be accepting the #picaxe commands. Perhaps post your code then people can compare results. It may be that you have an out of data PE ?

I have made note of the issues relating to AXEpad.

 

[Morganl]

Now you really made me scratch my head, because today it worked!!
After while i realise i had changed the comment on that line. What do a comment have to to with syntax?
Well it sem to boil down to that on this specific command PE but not *axepad need whitespace before the ";" comment.
#picaxe 18M2;Syntax error
#picaxe 18M2 ;Syntax OK

 

[Morganl]

In case anyone is interested, here is the proogram.
Depending on a pin level, it blinks or twinkles (very different speed) a bunch of LED.
Very nice effect on white leds.
Connection etc are described in the program.

Updated syntax, UTF8 encoding, Unix linefeeds, PE 6.0.6.4: View attachment GlitterTwinkle5.bas

 

[hippy]

Well it sem to boil down to that on this specific command PE but not *axepad need whitespace before the ";" comment.
#picaxe 18M2;Syntax error
#picaxe 18M2 ;Syntax OK

It appears PE is parsing the PICAXE name and including the semi-colon with that, only terminating on white space or end of line, rather than on a start of comment character. Please accept our apologies for this.

I have made a note of the issue and it will be fixed in future. I guess most people either add no comment to the #picaxe line or put spaces before comments when after a command or directive so no one had noticed this behaviour before. Adding a space before the semi-colon is, as probably guessed, the workaround we would suggest.

AXEpad is separate product to PE with a different lineage and they may sometimes differ in behaviour, even when both are run under Windows.

 

[Morganl]

As we found the solution, all is well, no problem
(It is more beautiful to have whitespace before comment anyway, but i had too much hurry)


Any idea when PE6 will be out?