Are there problems with SEROUT?

[lewisg]

In another thread I promoted using serial LCD displays instead of cluttering up pins and code:

If you need to save pins (and/or code space) use serial displays like the AXE133Y instead of driving the display with your project Picaxe.

Another forum member begged to differ:

If you need more pins, use a PICAXE-40X2. Serial LCDs can will cause problems with interrupts, timers, servos, background i2c, background hardware serial and others so it's best to avoid them if there is the possibility that one of those will be needed or they are needed.

Using the serout command to control the LCD will disable all interrupts and cause problems with any interrupt-based things like background hardware i2c slave mode, timers and background hardware serial.

I'm still puzzled:

I have never experienced any of these problems even though I have used timers and the DS1307 via i2c extensively with serial for LCD and data logging to SD cards. I don't want to drag this thread off course so your insistence should quickly provide proof via a code sample, reference to documentation or relevant forum posts. Failing that this discussion needs to move to another thread.

Good idea - some relevant forum threads:

• i2c port lockups in 20X2 Slave
• 18M2 Timer problem

The first link seems to be about SERTXD. While handy for debugging I can't imagine running an LCD that way.

Hippy's reply to the second link seemed to refute the notion of SEROUT and HSEROUT problems:

Both of these work for me. Run for 1000 PICAXE 'time' seconds (16:40) results were as follows -

SEROUT : 1007 real seconds, approx 0.7% accuracy
HSEROUT : 999 real seconds, approx 0.1% accuracy

Since I use SEROUT a lot I'm interested in what others have to say about this.

 

[russbow]

I have only ever used serout for lcd display.

I don't think any other method / interface gives me any perceived advantage. Aint broke, don't fix

I await the deluge to prove me wrong.

 

[srnet]

The manual has it right;

Appendix 4 - Possible Conflicting Commands

Serout can be disrupted (resulting in corrupted output on a serial LCD) if your using any of the commands listed, as Nick pointed out.

I your not using the commands specified, its not an issue, seems straightforward to me ......

 

[hippy]

SEROUT and SERTXD are commands which tie-up the PICAXE firmware while it is sending data, and while doing that it cannot be doing something else. In some cases this may cause problems and HSEROUT can be a means to overcome those problems.

Using SEROUT to drive a serial LCD or OLED is usually best for most programs because it is easy to use, uses only one I/O line, simplifies the program code and there are usually no adverse consequences through using SEROUT commands.

In cases where SEROUT interferes with other things the PICAXE has to do it can be better to use HSEROUT or directly drive an LCD.

There are advantages and disadvantages in using serial and parallel LCD control and there is no right or wrong only what is appropriate to what you are trying to do or want to achieve.

 

[westaust55]

IMHO we need to be careful that we are not spreading the wrong message that if one uses a serial LCD then problems will definitely occur.
As suggested above by hippy, problems may occur depending upon what combination of commands are used.

As srnet indicated the Appendix 4 heading states "Possible Conflicting Commands.

At the end of the day, how many PICAXE projects (maybe IinglewoodPete excluded ) really do use background i2c comms at the same time as blocking commands.
The parallel LCD/OLED interface will get around the SEROUT conflict when the the situation arises but what about the other blocking commands ?

Again, my opinion, but there are enough newcomers with limited electronics and programming skills that we should not be "hammering" the concept that parallel interfaces for displays is best at all times.
it is far easier to debug a 1 signal line and one command (SEROUT) problem that having to try and verify IO allocation for 6 or 10 pins matching the program code and that the code is functional (has it been obtained from a site with guaranteed working code in the first place). A number of people have arrived at this PICAXE forum site with code and/or hardware based on information on other sites that has been flawed.

From what I had seen in the past years, parallel was often promoted as much for the cost saving when folks wanting an LCD module found a hefty cost penalty to buy one with or separately procure a "backpack" serial interface board.

Not every project needs the higher speed of a parallel interface either.
If running a PICAXE at default speed (say for SERVO control reasons where default and 4x are the options) then is a parallel interface faster than say the Rev Ed FRM010 serial interface chip or the sparkfun Serial LCD module both of which can handle 9600 baud if so desired.

Just as an experiment on the "it should be possible, so try it principle" I built an interface using some shift registers and needing only 2 wires/IO pins (and 3 wires gained some speed improvement).
Cheaper than a commercial to parallel interface needing only two IO pins, it worked, could control the backlight without more wires but relatively slow.
A you get what you pay for proportion between $, speed and pins.

 

[srnet]

IMHO we need to be careful that we are not spreading the wrong message that if one uses a serial LCD then problems will definitely occur.

Absolutely.

There is no 'problem' with Serout and LCD displays as long as you use them as described and intended.

 

[nick12ab]

uses only one I/O line, simplifies the program code

It sounds like Rev-Ed's intention is for everyone to use serial LCDs whenever possible. Most other microcontroller platforms have built in libraries to make using a parallel LCD as simple as using a serial LCD but PICAXE does not.

I will not say that parallel LCDs are better than serial LCDs in all cases but on serial LCDs with low baud rates like the AXE033 I can actually see each character appear in quick succession and this looks incredibly unprofessional so if a parallel LCD can be used, I use one.

It is true that it uses only one I/O line but the extra I/O line responsibility gets handed down to a second microcontroller which consumes extra power but the advantages are that you can have the display some distance away from the main PICAXE without having to use a lot of wires plus if you have almost maxed out a PICAXE-40X2, you cannot use the parallel interface but you can use the serial interface.

The first link seems to be about SERTXD. While handy for debugging I can't imagine running an LCD that way.

The sertxd command is like the serout command except you can't choose what pin it operates on or the baud rate (unless you use the setfreq command). The problem caused by the sertxd command will also affect the serout command.

There is no 'problem' with Serout and LCD displays as long as you use them as described and intended.

Where in the AXE133 or AXE033 datasheets does it state that using the serout command can interfere with hardware i2c slave mode/servos/timers/hardware serial receive/interrupts?

 

[hippy]

It sounds like Rev-Ed's intention is for everyone to use serial LCDs whenever possible.

That is pretty much correct; we would recommend serial controlled LCD whenever possible. We have even gone to the extent of producing budget serial display drivers for LCD and OLED in order to help facilitate that.

The rationale is that it is far easier for PICAXE users to use serial than it is to use parallel LCD interfaces. That is confirmed by the threads which arise when people try to use parallel LCD interfaces and the difficulties they run into.

Most PICAXE users want to get to an end result and a serial LCD is the easiest way for them to get there.

Most will not be doing anything that makes using a serial LCD problematic.

 

[Goeytex]

How you choose to interface a display to a microcontroller can be a matter of cost, performance, easy of use, or other factors, such has how many pins are available on the micro, or simply what you have laying around at the time. Aside from these, some folks seem to have a personal favorite regardless of the application. Some can even get downright dogmatic or even religious about which way is is "best". Personally, I don't think any one way is better than another. The "best" way is the way that adequately does the job within with your skill level, application requirements, and budget.

Are there problems with serout? That seems to be a matter of opinion. But any serout problem can be worked around, usually by changing the system clock, baud rate, or adding a ms or two between bytes. But this can hurt overall speed performance if speed is an issue. Many times it is not.

Not all serial displays are the same. Some can only reliably receive data at up to 4800 baud and may even require that extra time be added between bytes sent. Others can operate at much higher data rates. I have some here that can operate at 115,200 baud. I2C serial enabled displays can receive data pretty fast, many times faster than the actual display can use the data. SPI (serial) enabled displays also perform quite well.

Displays with a parallel controller such as the HD44780 give excellent speed performance & generally cost much less than serial displays, but at the expense of 4 to 8 extra I/0 pins and added code complexity. But once you get the hang of it, it's no big deal.

As you can see, I do not promote and am not dogmatic or religious about any particular interface method. I think that's silly and unprofessional, kinda like trashing MIPS processors because I think ARMs are superior or vice versa. Just silly nonsense. I believe folks should pick the method that works for them and makes good sense for the application. And by all means if someone has a favorite they want to use all the time, that's fine, just don't try to make other folks proselytes.

If I need performance, I am not gonna use a budget serial display. I'll pick something else like a parallel interface or a higher end serial device. If I don't need the speed and want good bright OLED display then I might use an AXE133Y ( a good bargain). If I just need something for kiddie project I might get an AXE133. If I am broke, I might hack a display out of an old Fax machine or something.

My 2 cents .....

 

[nick12ab]

That is pretty much correct; we would recommend serial controlled LCD whenever possible. We have even gone to the extent of producing budget serial display drivers for LCD and OLED in order to help facilitate that.

The rationale is that it is far easier for PICAXE users to use serial than it is to use parallel LCD interfaces. That is confirmed by the threads which arise when people try to use parallel LCD interfaces and the difficulties they run into.

Most PICAXE users want to get to an end result and a serial LCD is the easiest way for them to get there.

Most will not be doing anything that makes using a serial LCD problematic.

PICAXE is one of only two (I think) microcontroller systems in the world where the intended type of alphanumeric LCD display is a serial one. Why do most other microcontroller systems use parallel LCDs as the primary display type and include libraries to make their use no more difficult to use than serial LCDs?

The AXE133Y is a good buy relative to the price of Winstar OLEDs elsewhere and the best thing is that you can reprogram the 18M2 to be a parallel LCD driver plus do the rest of your project.

 

[eclectic]

Not quite a hypothetical question.

I own a 08M.

I want a simple circuit to measure something,
(say readADC),
and then display on an LCD / OLED.

What's the quickest, simplest and cheapest?

AND, me and my teacher
don't know much about programming
or building circuits.

e

 

[Buzby]

Not quite a hypothetical question.

I own a 08M.

I want a simple circuit to measure something,
(say readADC),
and then display on an LCD / OLED.

What's the quickest, simplest and cheapest?

AND, me and my teacher
don't know much about programming
or building circuits.

e

Buy one of these : http://www.ebay.co.uk/itm/Digital-Multimeter-Power-AC-DC-Current-Tester-Indicator-19-Ranges-DVM-Test-Leads-/170755313471?pt=UK_BOI_Electrical_Test_Measurement_Equipment_ET&hash=item27c1cf4f3f

 

[westaust55]

PICAXE is one of only two (I think) microcontroller systems in the world where the intended type of alphanumeric LCD display is a serial one. Why do most other microcontroller systems use parallel LCDs as the primary display type and include libraries to make their use no more difficult to use than serial LCDs?

Could be that the parallel interface is cheaper to impliment (don't need to buy/include an interface backpack board).

I did a quick Google search last night for Serial LCD + Ard***** and got about 3 Million hits.
Some businesses selling serial LCD, some a combo serial/parallel interface with both serial + parallel libraries provided, some forums discussing serial vs parallel where the saving of IO was often the feature.

Also Google found some websites where folks posting their native PIC projects and their own serial interfaces featuring.

By way of an example from other sites:
http://playground.arduino.cc/Learning/SerialLCD

The main advantage of serial LCD's is that they are easier to wire up, since the Ard**** talks to the LCD over a single pair of wires

http://playground.arduino.cc/Code/SerLCD

This is my attempt at porting LiquidCrystal library for use with serial displays. It implements most all functions from LiquidCrystal and added a few functions of my own. This library subclasses NewSoftSerial.

http://www.electrojoystick.com/tutorial/?page_id=9

Tutorial for Robokits Serial LCD with Ard****

http://liudr.wordpress.com/2011/12/16/which-serial-lcd-to-buy/

Every once in a while on the arduino forum, people ask about which serial LCD to buy so today I saw such a post again and wrote this reply. I am certainly biased towards this serial LCD issue as I make and sell the phi-panel family of serial LCDs and keypad panels myself but take whatever you consider as fair argument:

 

[inglewoodpete]

me and my teacher
don't know much about programming
or building circuits.

e

Are you still trying to get your 'O' levels eclectic?

Not quite a hypothetical question.

I own a 08M.

I want a simple circuit to measure something,
(say readADC),
and then display on an LCD / OLED.

What's the quickest, simplest and cheapest?

e

I agree. Most of a microcontroller's running life is spent in a loop waiting for a changed input state. In most cases the time overhead required to output a few serial characters to an LCD is not significant.

The PICAXE is not the Ferrari of microcontrollers. However, it does an adequate job for > 98% of the tasks where I need a microcontroller: with or without an LCD.

...and in the rare cases where you need a fast serial (or i2c) LCD, try my 20X2 LCD/OLED driver here.

 

[srnet]

Its just a matter of selecting the right tool for the job.

If you want a simple LCD display, character only, not more than 20x4, then the PICAXE products are ideal.

If you need more performance (speed) or cant use SEROUT because other stuff can conflict, and you want to avoid non-PICAXE products for some reason, then drive the LCD in parallel mode.

However there are products out there that will turn a graphics LCD into a character display (20x7 character from a cheap 128x64 graphic display) and provide high speed serial, I2C and SPI interfaces. Plus multiple font sizes, graphic functions etc.

I think Rev Ed would do well to introduce such a product themselves and make it compatible with the AXE133Y stuff.

 

[nick12ab]

I own a 08M.

I want a simple circuit to measure something,
(say readADC),
and then display on an LCD / OLED.

What's the quickest, simplest and cheapest?

AND, me and my teacher
don't know much about programming
or building circuits.

Don't know anything about building circuits? Then you can't attach a serial LCD to a PICAXE-08M2 because you might make the newbie mistake of using separate power supplies and not connecting the 0Vs together. Not knowing anything about programming doesn't matter because you can simply assemble the AXE133 according to the instructions then use my 'Newbies' guide' to learn how to use the parallel interface.

However there are products out there that will turn a graphics LCD into a character display (20x7 character from a cheap 128x64 graphic display) and provide high speed serial, I2C and SPI interfaces. Plus multiple font sizes, graphic functions etc.

This is different. Graphic LCDs like those support nothing more than allowing you to set pixels in groups of 8. Using a serial controller for these brings a lot of benefits. Serial LCDs like the AXE133 do not contribute anything other than predefined messages and you still need to know about the HD44780 command set.

 

[srnet]

This is different. Graphic LCDs like those support nothing more than allowing you to set pixels in groups of 8.

Not really, you use the adapters in the same way as you would an AXE133Y backpack, except in this case it goes on the back of a graphic LCD.

Then you use them in much the same way as the AXE133Y, write text to the display using SEROUT.

It can run at 115,200 baud, or I2C, or SPI, although I have not tried those.

 

[hippy]

Serial LCDs like the AXE133 do not contribute anything other than predefined messages and you still need to know about the HD44780 command set.

What AXE133 and the like contribute is ease of use.

It is far easier to get a serial LCD interface working than a parallel interface working with less things that need to be understood by the programmer to do that.

The programmer has very little need to understand anything about the LCD itself to use it, primarily only needs to know how to connect it and what to send via a SEROUT command to achieve the result they want.

It 'lowers the bar' for first time LCD users and they can then go on to explore LCD display capabilities further if they wish.

 

[ValueAdd]

Don't know anything about building circuits? Then you can't attach a serial LCD to a PICAXE-08M2 because you might make the newbie mistake of using separate power supplies and not connecting the 0Vs together. Not knowing anything about programming doesn't matter because you can simply assemble the AXE133 according to the instructions then use my 'Newbies' guide' to learn how to use the parallel interface.

This is different. Graphic LCDs like those support nothing more than allowing you to set pixels in groups of 8. Using a serial controller for these brings a lot of benefits. Serial LCDs like the AXE133 do not contribute anything other than predefined messages and you still need to know about the HD44780 command set.

but the original post by eclectic included the comment:

I own a 08M.

that is an older chip than the 08M2 you mention.
only 255 bytes to put all the program and messages into but potentially do-able.

eclectic does not indicate if there is an existing board available. An AXE021 or perhaps better a breadboard could be used.

AND, me and my teacher
don't know much about programming
or building circuits.

so if assembly and soldering was not an existing skill, might it not be better to recommend the partially/substantially complete assembled AXE033 where an absolute minimum of soldering was involved. I might have recommended the fully assembled Sparkfun serial LCD but seems a few newbies have difficulties getting those going due to higher default baud rate.
The datasheet shows how to connect to the power supply and PICAXE, what commands to use and the control commands.
A breadboard could be recommended onto which to plug the PICAXE chip, an AXE029 breadboard adapter and the display plus a few wires and good batteries and eclectic could be away.

Do not forget the possible need for some resistors as a potential divider to scale down the voltage to the ADC input if it it is greater then the picaxe chip power voltage.
would be worth asking what the signal is to be measured. Heaven forbid, it might be 240 volts ac!

 

[nick12ab]

that is an older chip than the 08M2 you mention.

That was only referenced when dismissing the idea. The AXE133 serial LCD module uses a PICAXE-18M2 and this would be what would be programmed to drive the LCD using the parallel interface. As an 08M is being used (not an 08M2), the parallel interface has an additional advantage that the microcontroller with a lot more memory is available for the user program.

 

[lewisg]

I'm glad that no significant problems in SEROUT have been pointed out. As I expected the best course of action is to use serial unless there are financial, educational or problems that arise the indicate otherwise. I have used serial displays for years without encountering any of these problems, lucky me...

Thanks to all.

that is an older chip than the 08M2 you mention.
only 255 bytes to put all the program and messages into but potentially do-able.

That was only referenced when dismissing the idea.

You missed ValueAdd's point...

Using your example code it takes 96 (of 255) bytes to say HELLO WORLD:

#picaxe 18m2
symbol lcddata = pinsB
symbol rs = C.7
symbol enable = C.6

start:
  dirsB = 255                                 'Set pinsB as outputs
  low rs                                      'instruction mode
  output enable                               'set enable pin as output

  lcddata = %00111011 : pulsout enable,16     'Function Set: 8-bit, 2 lines, font 11
  lcddata = %00000001 : pulsout enable,608    'Clear display
  lcddata = %00001100 : pulsout enable,608    'Display on/off control: Display on, cursor off, blink off
  lcddata = %00000110 : pulsout enable,16     'Entry mode set: Increment, cursor shift


main:
  low rs
  lcddata = 128 : pulsout enable,1
  high rs
  lcddata = "H" : pulsout enable,1
  lcddata = "E" : pulsout enable,1
  lcddata = "L" : pulsout enable,1
  lcddata = "L" : pulsout enable,1
  lcddata = "O" : pulsout enable,1
  lcddata = " " : pulsout enable,1
  lcddata = "W" : pulsout enable,1
  lcddata = "O" : pulsout enable,1
  lcddata = "R" : pulsout enable,1
  lcddata = "L" : pulsout enable,1
  lcddata = "D" : pulsout enable,1

Using a serial display takes 38 (45 if you want the system timer displayed):

symbol LCDpin  = B.3                 'AXE133Y

pause 1000                           'pauses are important!

main:

  serout LCDpin, n2400_8,(254,1)     'clear display
  pause 30
  serout LCDpin, n2400_8,(254,128,"HELLO WORLD")
  serout LCDpin, n2400_8,(254,192,#time)

  'ADM1602U is faster...
  'serout LCDpin, t9600_8,(254,124,"<control>r")
  'serout LCDpin, t9600_8,(254,1,  "HELLO WORLD")
  'serout LCDpin, t9600_8,(254,192,#time)

Get it now?

The AXE133 serial LCD module uses a PICAXE-18M2 and this would be what would be programmed to drive the LCD using the parallel interface.

Who cares what processor drives a serial LCD? From the standpoint of getting work done it is not relevant.

As an 08M is being used (not an 08M2), the parallel interface has an additional advantage that the microcontroller with a lot more memory is available for the user program.

Can you even run a parallel interface on a 8 pin chip? From your instructions a parallel interface takes 10 pins.

OTHO with a serial LCD using ONE pin you still have THREE pins on an 08 chip to use for your project without fiddling with the programming pins. Perfect for small readout devices like tachometers, thermometers, liquid level indicators and the like! Same thing with 7 segment LEDs, they are available in serial versions, greatly simplifying their use.

 

[srnet]

What I like about SEROUT and serial LCDs, is the combination goes together rather well.

You can develop a program by writing output to the PE terminal, and if for terminal writes you use;

serout TX, baud, ("Hello World",CR,LF)

With the TX symbol pointing at the normal sertxd pin, by changing the assignment of the TX symbol, you can send the same output to a serial LCD or OpenLog logger.

I have been doing some work on a project that requires the PICAXE unit, that has a GPS attached, to be outside. I can have the serial LCD, that tells me what in going on, on my workbench connected to the PICAXE unit by a simple 3.5mm stereo extension lead. A 10M extension cable at 9600 baud has been error free.

 

[nick12ab]

I'm glad that no significant problems in SEROUT have been pointed out. As I expected the best course of action is to use serial unless there are financial, educational or problems that arise the indicate otherwise. I have used serial displays for years without encountering any of these problems, lucky me...

That is an opinion which is supported by Rev-Ed because they chose to not develop a parallel LCD library for PICAXE (which could be implemented entirely in the PICAXE Compiler and converted into something similar to the stuff in my tutorial) plus they make money from selling serial LCDs. They were a good idea 10 years ago when PICAXEs were limited but the PICAXE platform is now quite advanced.

You missed ValueAdd's point...

No, I'm talking about the use of a PICAXE-08M and AXE133 serial LCD. An AXE133 serial LCD contains a user-programmable PICAXE-18M2. If you reprogram this PICAXE-18M2 for your project you have to use the parallel interface and you get 2048 bytes of program memory. If you choose the serial option you have to use the 08M that you also have which only has 256 bytes of memory.

You do get a few predefined messages with the serial option, but in this example it doesn't entirely compensate for having less program memory.

[hr][/hr]

I'm not totally against serial LCDs - I'm only against them when they are unnecessary.

 

[Goeytex]

I'm glad that no significant problems in SEROUT have been pointed out.

I think there were some significant problems pointed out, not with the serout command itself, but how using it can affect other timing sensitive commands. FWIW, I don't see why hserout is not used more with Serial LCD/OLED displays. The baud rate is more accurate and it is less likely to interfere with other commands.

As I expected the best course of action is to use serial unless there are financial, educational or problems that arise the indicate otherwise.

I would expect no such thing. That is your opinion and you are entitled to it. But it is not a fact nor does it represent any kind of general consensus in the embedded world. There is life beyond Picaxe. Nick could say the same thing about using parallel and be just as "right" as you are.

Sounds to me like you are getting as religious and dogmatic about the use of a serial interface as Nick is about the use of a Parallel Interface. You both have your opinions, but there is no right or wrong here.

 

[Buzby]

... You both have your opinions, but there is no right or wrong here.

They are either both right, or both wrong !.

Take a look in any commercial micro+LCD product, such as a digital clock or fancy remote control.
You will find usually that the LCD glass is directly controlled from the MCU.

This is difficult to code, and has lots of strange waveforms and timing constraints.

So why do they do it this way ?.
Simple answer - cost.

Any type of interface, serial or parallel, would add a huge extra cost.
It's far cheaper to pay a software engineer for six months.

So the argument as to which is 'best' is a bit irrelevant.
There are pros and cons for each, and each needs different resources from the MCU, but each has it's place in different scenarios.

There is no 'best'.

Cheers,

Buzby

 

[Goeytex]

Any type of interface, serial or parallel, would add a huge extra cost.
It's far cheaper to pay a software engineer for six months.

Not always.

When I was doing contract work back in 2005..... The CTO of the company, (a MIT guy), decided that about $2.00 per unit could saved by writing a driver for for a really cheap bare LCD module used in a lighting system for Industrial/ Military use. A really cheap Micro was selected for firmware. It took the procurement guy over a week to source the components needed, with much of the time quibbling with vendors over a few cents in price. Once the stuff arrived ( development kit / micros) It took the programmer, (an MIT guy), 2 weeks get "up to speed" on the Cosmic IDE / Compiler and another 2 weeks to write & debug the code.

Procurement Guy - $20.00 per hour x 40 hours = $800.00
Programmer Guy - $80.00 per hour x 160 hours = $12,800

Mind you that this was part of a system that sold for $7,500 each (huge markup) at relatively low volume - less than 200 units per year.

Not only did the changes cheapen the system, there was absolutely no cost savings at all. This is beside the fact that the buyer rejected the design change and the company had to re-spin boards and source a good quality HD44780 16 x 2 type display for the final product. BTW, I charged them over $2,000 for the required prototyping and testing work.

Sometimes being "cheap" doesn't pay off. And sometimes really smart people do really stupid stuff.

 

[Buzby]

Sometimes being "cheap" doesn't pay off. And sometimes really smart people do really stupid stuff.

I once worked for a major company building a MCU based device that would sell about a million a year.

They used a 4-bit MCU, with horrendous bank switching and other nasties. I asked why not use a more powerful MCU, like a PIC.
Price was the king. An increase of 50p per item led to a £500,000 dip in profit per year. Profit on this item was already low, fierce competition ensured that.
So in this case spreading the upfront cost of software over millions of units made sound economic sense.

On the other hand, I also did work for a company making *very* high profit, very low sales volume ( < 10 per year ) devices. They could have put in a couple of dual CPU servers, with gold plated cases, and hardly dented the profit. But the Director was adamant that the brains of the whole shebang was to be a PIC. Suffice to say, no amount of software effort was ever going to make a PIC do the job of a Pentium. The only good outcome of that project was that I discovered PICAXE !.

So again we are back to 'horses for courses'.

Cheers,

Buzby

 

[lewisg]

What I like about SEROUT and serial LCDs, is the combination goes together rather well.

You can develop a program by writing output to the PE terminal, and if for terminal writes you use;

serout TX, baud, ("Hello World",CR,LF)

With the TX symbol pointing at the normal sertxd pin, by changing the assignment of the TX symbol, you can send the same output to a serial LCD or OpenLog logger.

My point exactly. Simple to use and gets results quickly.

Symbols are the way to go! I like your shorter TX and baud than what I'm using currently. Might have to change...

OpenLog is something I use all the time. On control type projects that react to sensors (light,temp...) I tend to let a logger run for several weeks on a "finished" project just to see if everything works out like I expected. While it does not have the accuracy of a RTC including the timer in a log line and recording times when the log started and ended can go a log way in determining when a line in the log was recorded.

If it wasn't for OpenLog and DPScope I would not be able to do half of what I do with a Picaxe.

I have been doing some work on a project that requires the PICAXE unit, that has a GPS attached, to be outside. I can have the serial LCD, that tells me what in going on, on my workbench connected to the PICAXE unit by a simple 3.5mm stereo extension lead. A 10M extension cable at 9600 baud has been error free.

Very slick! I like the LCD and the box. Might have to make something like that. What LCD is that?

 

[srnet]

OpenLog is something I use all the time.

Me too, I have been testing the satellite stuff today, for once its been very sunny in the UK.

I setup the serout format as comma delimited, so I can load it into a spreadsheet for later analysis.

Very slick! I like the LCD and the box. Might have to make something like that. What LCD is that?

Cant say, but its a product that Rev Ed might consider selling.

Much the same ease of use as the AXE133Y, but many more features, more text on screen and graphics too.

 

[bpowell]

Very slick! I like the LCD and the box. Might have to make something like that. What LCD is that?

Looks like a 128x64 Graphics LCD...I see them on ebay for around $17...Here is an example...

 

[srnet]

Well, I am sure you know the quote from Francis Urquhart ..............

 

[nick12ab]

like the AXE033 I can actually see each character appear in quick succession and this looks incredibly unprofessional so if a parallel LCD can be used, I use one.

Here's the evidence!

FWIW, I don't see why hserout is not used more with Serial LCD/OLED displays. The baud rate is more accurate and it is less likely to interfere with other commands.

I've set up a circuit for testing and so far it seems that using hardware serial for an LCD connected to an i2c slave is working OK.

A PICAXE-28X1 was used as the i2c slave and an Arduino as an i2c master.

The Arduino would not lock up even if serout was used, but for all interfaces writes would not be saved to the PICAXE scratchpad unless the PICAXE was ran at a clock speed of at least 8MHz.

The timer is severely slowed down when using serout on the slave but not when hserout or the parallel interface is used. The operation of the Arduino was indicated by two rapidly flashing LEDs and 'interruption' of these flashes (where the i2c commands took longer than usual) only happened when the serout command was used and not when hserout or the parallel interface was used.

The previously mentioned i2c port lockups may only apply when using the PICAXE-20X2 as an i2c slave so I'll do some more testing once I have a spare one of those. If it turns out to be PICAXE-specific, then which PICAXEs can be safely used for driving a serial LCD as an i2c slave and which can't.