Displaying Letters via lookup command

matchbox

Senior Member
Hi guys, I there a way to display Letters, when using lookup / pulsout. Rather than using a Serout command?

I know of using -

serout OLED, baud,(254,131,"",#hour,":",#minute,":",#second,"AM")


But what I am wondering. Is there a way to place a Letter in the lookup variable. So that variables data can be changed and then pulsed to the display.
The reason being. Is that I am relying on the Time variable having higher accuracy. And the serial commands effect its accuracy to much.


bintoascii HOUR, D1,D1,D2
bintoascii MINUTE, D3,D3,D4
bintoascii SECOND, D5,D5,D6
bintoascii MERIDIAN, D7,D7,D8

for b3= 0 to 10
lookup b3,(D1,D2,":",D3,D4,":",D5,D6,$20,D7,D8),send_data
GOSUB Display
next b3


Thanks
 
Last edited:

Buzby

Senior Member
Can you switch to using 'hserout' ?.

This does not upset the timer, and executes faster then 'serout' if used properly.

Another option is to just update the OLED with the changed digits.

A further option is to use a timer interrupt to run the clock.

Whether this is possible depends on which chip you are using.

Cheers,

Buzby
 

AllyCat

Senior Member
Hi,

Yes, you can put variables within a LOOKUP command, for example:
Code:
b5 = "T"
b6 = "E"
b7 = "X"
LOOKUP b3, ( b5 , b6 , b7 , b5 ), b4
but I'm not sure if it helps; AFAIK it is the SEROUT command that will "slow" the time variable. As Buzby indicates, the HSEROUT command may help with single characters, but I'm not sure about using HSEROUT with strings, e.g. HSEROUT ( "TEXT" ) which may still be "blocking", but perhaps doesn't disable the (M2) system timer interrupts?

However, the "lost" time should be quite predictable, so it might be compensated for within the program. Or if you want a more "technical" solution, it might be possible to compensate the "prescaler" (T1) for the time variable. Timer 1 is arranged to "tick" (overflow) each 20 ms (it's also used for the Servo pulses) so if you know that you have "lost" 20 ms whilst the SEROUT was outputting data, you could increment the prescaler (Special Function Register TH1), unless it is just due to overflow (i.e. from 255 to 177).

Cheers, Alan.
 

matchbox

Senior Member
Thank you guys, Buzby. Unfortunately the 18M2 is hard wired, so using the Hserout isn't possible for me.

Alan, I forgot about the prescaler. I haven't used it before. But it sounds like it maybe the only option for lost command time.

Just for reference. This is for a clock of sorts. Most people would say... why not use a RTC.
This is a different project that will use three phototransistors on an outside unit, to log and RF transmit Sun intensity and location at parts of the day to assist and update time keeping accuracy.
 

AllyCat

Senior Member
Hi,

Don't necessarily discount the HSEROUT, there is the "Alternate Pin Function" option, the "Data Signal Modulator" and of course the two Comparators on that chip, which may allow you to "switch" its output to another pin by software.

I don't know what accuracy you're looking for (or over what time period) but even the "unaffected" accuracy of the "time" variable is hardly suitable for any serious time measurement. I know that logging daylight levels (in particular near to sunrise and sunset times) is used for tracking the paths of small birds (where a GPS is too large or heavy), but I believe only by "post-processing" the logged data. The calculations are quite complex; I know because I've posted a PICaxe Sunrise and Sunset calculator, but haven't yet succeeded in converting the "reverse" algorithm to calculate the (expected) sun position (Altitude/Elevation and Azimuth) at a given time. IMHO a tiny RTC module like the "DS3231 for PI" is a much more practical solution.

Cheers, Alan.
 

matchbox

Senior Member
Thanks Alan. I appreciate your insight into the concept. I know it is a wild idea. But if I told you why i'm going down this path, you would think I was loopy;)
I do agree this will be difficult. Especially the logging in the outside unit. It too will back up the time information. I am planning on only updating the main clock unit after a week of consecutive Sun light intensity changes.
It will also use the third sensor (pointing upwards) as a middle of the day marker. This will log the three main events of the day.

Seconds and Minutes accuracy are less important to me than Day, Month and Year. But the accuracy of the first two is still needed to help with the others:).

I'm only in the early stages of the write. I will just add as I go and hope I don't hit a dead end.
 

matchbox

Senior Member
I got around to just doing the clock part based around the Time Variable. It has turned out to be reasonably accurate with the 18M2. Although the biggest inaccuracy comes at night, where we are getting frosts.
Through the day its lucky to loose a second @16Mhz. While at night the Picaxe's resonator changes and the time variable gains up to 30seconds over 9hrs.
If the ReadInternalTemp work correctly I could fix this. But it appears the boost regulators ripple makes the supply voltage fluctuate(+- 15deg) enough to make the readIntTemp inaccurate.
I will have to move to an X2 with this because i've run out of variables.
 

Attachments

AllyCat

Senior Member
Hi,

Hmm, I'm surprised that / if the PICaxe can achieve that degree of accuracy over a longer term. I'd be extremely happy to achieve within 1 minute a day and the Microchip data sheet indicates figures at least ten times worse than that. However, 1 min/day seems nowhere near the accuracy needed to "infer" the date from the changes in sunrise / noon / sunset times, which I believe you are attempting? I gave the idea much thought a few years ago and largely abandoned the project because I thought the calculation was "too difficult", even assuming a crystal-controlled clock reference (in my case, the precisely-timed 48-second period of transmitter messages from a commercial weather station). That was for here in the UK where the day length swings by around 9 hours a day over the year; it must be much less in Australia? Also the (essential) "Equation of Time" (noon) swings over a range of just over half an hour, but the maximum change is always less than a minute a day.

Yes, (IMHO) the PICaxe READINTERNALTEMP feature is absolutely useless, as I've written many times before. But have you looked at my CHIPTEMP Code Snippet / algorithm that can reliably get within a few degrees (only with M2s, I think)?

Also, I don't believe you have remotely "run out of variables" yet. You haven't used the 12 available bytes in the SW_1 to SW_6 registers and there's no need to "waste" direct variables on the date, etc.. These can be easily stored in the (almost 500) indirect RAM locations (e.g. @BPTR , or SYMBOL MONTH = 100 : PEEK / POKE MONTH , variable , etc.) or the "slower" ones (Day, Month, Year, etc.) in EEPROM (READ / WRITE) memory. The extra cost / space of an "X2" chip could be much better spent on adding for example a "DS3231 RTC for Pi" module (which happens to also measure the temperature) ? And of course the X2s don't support the TIME variable.

Cheers, Alan.
 
Last edited:

matchbox

Senior Member
Thanks again Alan,
I must admit, I wasn't expecting it to hold time that well, from past experience with M2's. I was more surprised that it was gaining time though. I expected it to loose it. I assume it must be a hardware variance.

I decided to take your advice anyway and purchase DS3231 module a couple of days back.

This is my first project in dozens that isn't electro mechanical in nature. So its taking me some learning. I have taken a good look through the forum in the last week and notice code that yourself and others have written. And only wish I could understanding that level of syntax.
With respect to the DS3231. I only really need the seconds. Not the rest. I got the impression that shouldn't be a problem?
 

AllyCat

Senior Member
Hi,

It's a neat chip, with its built-in clock crystal and with the (3 volt Lithium) battery fitted to most modules it should be virtually "Plug and Play". I particularly like the small ".... for PI" (Raspberry) version where the largest component is the 5-pin header socket! But it's one example where I would prefer to have had the header supplied UNsoldered - it needs some courage to take a soldering iron to remove the socket from the double-sided board, if you want a really tiny module. Also, (if the breakout module doesn't have a battery-holder) try to obtain a version with the battery included; it can be very difficult to obtain an "aftermarket" solder-tag type of button cell.

Like most RTCs, the DS3231 does use the I2C bus which may have a few "gotchas" for novices; however, if you do have problems, don't struggle but ask for advice here, or recently I re-posted an "I2C diagnostics" program in #14 of this thread . Also, don't overlook that most RTCs use the Binary Coded Decimal (BCD) number format, and the (PE6 only) ppp_date{time} directive can be very useful for setting the full time / date, if required.

Cheers, Alan.
 

matchbox

Senior Member
Another question guys, when I'm on the same project.
With respect to an OLED display and driving it via Pulsout instead of serout.
With the 18M2, the pinsB are used to drive pins D0 to D7 on the display.
My question... Is it possible to use different pins from another group.

dirsb = %11110110
dirsc = %11100000

And pulse both sets together to the display? So far I have had no luck.
Also...In the case of the 18M2 and Pinsb. How exactly are the pins pulse to the OLED. i.e. the order of data sent? Is order important etc? b.0 > b.7.
I can't find anything about this and have often wondered.

Thanks
 

AllyCat

Senior Member
Hi,
driving it via Pulsout instead of serout.
That's rather like comparing apples with oranges (or perhaps apples with cider). :)

When you use SEROUT... ("Hello World") in a PICaxe program, that data is sent to another PICaxe (18M2) inside the AXE133/4 module. That PICaxe does all the "hard work" in setting up the OLED, converting the serial data to "Parallel" format, extracting each character in turn from the "Text String" and then generating each PULSOUT. There wouldn't be much point in changing all the pin connections inside the AXE133 and in practice it might be "not possible", because it's important that that PICaxe writes the data very quickly, so that it can be ready to receive another SEROUT - SERIN character.

However, if you just have an OLED display with the 14 "parallel" pin connections, then yes it is possible to drive it from (almost) any pin arrangement. But there are (at least) two caveats: Firstly the OLED controller needs to be "initialised", so you will need to learn how to do that. Then, yes, it is important that all the PICaxe PORT pins are correctly "mapped" to the OLED display pins (which are driven by the PINSB/C= commands, not DIRSB/C). Using the correct connections applies just as much to the 8 data lines and the Strobe, and Enable, etc., as it does to the Supply and Ground (except that you won't actually destroy anything by just getting the data lines wrong) !

There is a vast number posts on this forum and I believe hippy (or perhaps inglewoodpete) have posted a program which allows any combination of pins to be used, but all I could find quickly is this "Tutorial" . See in particular post #3 where nick "removes" the I2C pins from the LCD/OLED parallel interface port. It's also possible to use less than the "normal" 8 data lines (4 to be precise) which is the method used by the displays that use an "I2C backpack" with an "I2C Expander" (which has 8 pins, but some are needed to drive the Strobe and Enable, etc.). Again there are numerous threads on the topic, because you are entering well-trodden territory.

Cheers, Alan.
 

matchbox

Senior Member
Thanks again for your explanation and the link.
The reason I'm entertaining this approach is because I have found that using two processors (18M2 and the main 28X2) are drawing more current collectively, that I prefer.
While I could run the OLED from the 28X2, but I have two pinsB that are broken out on other devices, which I also want to use in this application.
The 18M2 which I started with doesn't have enough IO's to complete this project. That why I moved to another picaxe.
 

AllyCat

Senior Member
Hi,

Yes, I've always considered it rather "inefficient" to use an 18M2 (in the AXE133) just to run a few hundred bytes of program, and at elevated frequency (16MHz) to give reasonable serial performance, but increased power consumption. However, the PICaxe power probably is still far lower than that consumed by the LCD (backlight) or OLED.

So, driving the OLED as a parallel device from a single PICaxe could be more power-efficient and you might even drop an X2 from its default 8 MHz to 4 MHz, if power drain is an issue.. But I would still expect the display to use (much) more power than the PICaxe. OLEDs have the advantage that only the "lit" Pixels drain current, but they're less easy to "dim" than the backlight (LED) of the old LCD type.

I was tinkering with the (AXE133) parallel-driving code a few weeks ago and it struck me how little additional software "overhead" there is in driving the "4-bit" mode; Probably less instructions than splitting the 8 data bits across the pins of two different ports. But the initialisation of the LCD/OLED is more complex and the debugging could be a pain if the display doesn't initialise correctly for some reason. Also, a really "messy" mapping of pins within a single port can be solved with a single READ of a customised TABLE - for hardware convenience I completely "twisted" the whole data port D0 <--> D7, etc..

Cheers, Alan.
 

matchbox

Senior Member
However, the PICaxe power probably is still far lower than that consumed by the LCD (backlight) or OLED.
OLEDs have the advantage that only the "lit" Pixels drain current, but they're less easy to "dim" than the backlight (LED) of the old LCD type.
Cheers, Alan.
I was surprised how well the OLED "Internal Power mode" command works. #23 On/full brightness and #19 Off/dimmed.

When I was just using the 18M2 on the OLED 16 x 2. It was draining 22mA @ 5v, 16Mhz. But when I went to internal power mode OFF, the current dropped to 3.7mA (with the 18M2).
But after testing again with the 18M2, 28X2(4Mhz), DS3231 and OLED. It was using 35mA with OLED On/full brightness. And would only go as low as 16mA with OLED internal power mode OFF .

From what I can gather. The OLED display must shut off its switch mode boost regulator and run on a lower voltage to save juice.
 

AllyCat

Senior Member
Hi,

Ah yes, I was thinking in terms of a "continuously variable" brightness control. Switching off the boost voltage is indeed a useful trick.
.... when I went to internal power mode OFF, the current dropped to 3.7mA (with the 18M2).
But after testing again with the 18M2, 28X2(4Mhz), DS3231 and OLED...... would only go as low as 16mA with OLED internal power mode OFF .
I'd expect the PICaxe (18M2) core to drain about 2 mA at 16 MHz (it's about 0.7mA at 4 MHz). So the OLED current had probably fallen to about 10% of its "full" value (which subjectively might look like "half as bright"). Don't forget that the OLED power consumption is proportional to the number of lit pixels, so you need to "standardise" the character display before making measurements. I was particularly impressed with the little SSD1306 OLED displays, where a simple "Clear Screen" reduced the drain to virtually nothing, even without a "Display Off" command.

The PICaxe (cores) and RTC shouldn't be taking a total of more than about 3 mA, but I've never actually measured a 28X2 chip. So I suggest you either had a lot of characters displayed on the OLED, or perhaps there are other power-draining components on some of the 28X2 pins?

Cheers, Alan.
 

matchbox

Senior Member
The PICaxe (cores) and RTC shouldn't be taking a total of more than about 3 mA, but I've never actually measured a 28X2 chip. So I suggest you either had a lot of characters displayed on the OLED, or perhaps there are other power-draining components on some of the 28X2 pins?

Cheers, Alan.
I think it might be the 78M05. I forgot that I measured the 18M2 current with a switching regulator.
Although the project will be running off a single 18650 cell. With a boost regulator to take it up to 5v. Could run it at lower voltage. But the little board I have is a CV CC charger, LVC/OVP and boost regulator all in one.

The clock works fine, by just extracting the Seconds from the DS3231. While the rest of the program isn't much different from the one a few posts back.
I know anyone that has looked at the code would noticed it has 16hrs mentioned. That's what makes this clock different.
Its only disadvantage is that the time can't be saved in the RTC. I'm sure many of you guys could do it with much work and math. But it's not within my abilities.
The 18650 should be able to keep it going for over a week, without DC input. So that's enough backup. Plus I have the external module unit still to go. And finishing the Enclosure for them both.
 

Attachments

Top