14M and D18B20

[Simmicht]

Can someone tell me which pins on the 14M can be used for readtemp command when hooked to the lovely D18B20 temperature sensor?
What is the syntax to use them?
READTEMP 1, B0


As for the 14M2, I assume it will work on all the pins,
C.0 to C.5 and B.0 to B.5
READTEMP B.1 B0

Thanks

 

[Pauldesign]

This command cannot be used on pin0 or pin3 of the PICAXE-08M/14M, or pin6 of the 20M.

The above in quote is extracted from the PICAXE BASIC command manual under the readtemp command section. Refer to it for readtemp code example.

 

[MartinM57]

I trust you mean DS1820B - there are many variants and only one type is plug'n'play with the PICAXE...

 

[westaust55]

Firstly the 14M2 is a future product.
as indicate in PICAXE manual 1 at the bottom of page 9

(14M2 and 20M2 are future parts, check availability)

The same is also stated on page 27.

The only temp sensor that the READTEMP command will work with is the DS18B20 (not D18B20 or DS1820B or DS18S20 or other variants)

For the currently available 14M PICAXE chip, the pin for the one-wire DS18B20 devices must be one that is designated as a standard input pin.

From PICAXE manual 2 page 175:

READTEMP pin,variable
- Pin is the input pin.
- Variable receives the data byte read.

PICAXE manual 1 on page 8 and page 89 has a diagram which shows the 5 inputs (physical legs 3 to 7).


Note also that the READTEMP command only functions at 4MHz.

 

[lbenson]

As indicated in westaust55's post, READTEMP on a 14M works only on input pins, and as in pauldesign's post, pin3 is excluded (because of Microchip hardware limitations). For the 14M2, we await real chips.

 

[MPep]

As indicated in westaust55's post, READTEMP on a 14M works only on input pins, and as in pauldesign's post, pin3 is excluded (because of Microchip hardware limitations). For the 14M2, we await real chips.

Well, technically, 1-wire devices require a bi-diretional pin to operate through.

 

[lbenson]

Well, technically, 1-wire devices require a bi-diretional pin to operate through.

And pin3 ("leg4") is input only, so that's why it doesn't work. Other 14M input pins ("input" in Rev-Ed's designation) are bi-directional, so they work. Output pins 3, 4, and 5 are also bi-directional, but given the syntax (ReadTemp pin, variable), there's no way to differentiate between an "input" and an "output" pin, hence, I suppose, Rev-Ed's choice of one of the options--input pin (given the limited firmware space).

At least that's my take on why things are the way they are.

 

[lbenson]

Maybe I'm blind, but I didn't see on the READTEMP command page for manual 2, downloaded from the "PICAXE Manual" link on the forum bar, the statement quoted by pauldesign, "This command cannot be used on pin0 or pin3 of the PICAXE-08M/14M, or pin6 of the 20M."

Is is true that input 0 on the 14M cannot be used with a DS18B20? Or should it be "cannot be used on pin0 or pin3 of the PICAXE-08M, pin3 of the 14M, or pin6 of the 20M"? Actually, clarification of the input/output pin applicability for this command would be helpful.

 

[eclectic]

Maybe I'm blind, but I didn't see on the READTEMP command page for manual 2, downloaded from the "PICAXE Manual" link on the forum bar, the statement quoted by pauldesign, "This command cannot be used on pin0 or pin3 of the PICAXE-08M/14M, or pin6 of the 20M."

Is is true that input 0 on the 14M cannot be used with a DS18B20? Or should it be "cannot be used on pin0 or pin3 of the PICAXE-08M, pin3 of the 14M, or pin6 of the 20M"? Actually, clarification of the input/output pin applicability for this command would be helpful.

And see post#2
http://www.picaxeforum.co.uk/showthread.php?t=16743&highlight=readtemp+input


e

 

[Dippy]

I couldn't see that quote either in the online Manuals , so I'm blind too.

It's a confusing place.
And judging by the interrogations in the Forum over the last > 6 years I'm not the only one dazed and confused.


The Manuals have "pinout" drawings but a number of people go on about "legs".
So, confusion Number1: Rev-Ed= Pins and Hippy= Legs.
I'm a "pin" person because the rest of the world is
I've yet to see a 'legout' diagram for a PIC chip.


Conventions are a bit wobbly too.
The Manual 2 PICAXE drawings show, for example, "Input1" and "In1" against PICAXE (pins or legs).
And in code: "pin1"
So immediately we have a confusion of the code terminology versus genuine chip numbering convention.


Result: massive confusion when people post questions.
14M. Do I connect my wijit to "Input1" , "In1" or "pin1" - hang on, "pin6" (accepted convention RoW).
If people kept connection descriptions to those PINOUT pin descriptions shown in Manual it would be easier.


And then in Manual 2 we see the ReadADC referring to "- Pin is the Input pin"
Confirmed by the sketch on Page 175
But no mention that there are restrictions.

Thank goodness they're moving over to the traditional PIC Port.bit convention.


I fully understand the reasons for the older descriptions but the lack of standardising/harmonising made things confusing and you had to keep rattling between Manuals to follow it.
It's OK when you know it... usually


Good memory Ec; but why should people have to HUNT for this information in a Forum? Should be in the Manual as it is fundamental.

 

[westaust55]

The above in quote is extracted from the PICAXE BASIC command manual under the readtemp command section. Refer to it for readtemp code example.

Paul,
you are obviously not reading from the latest V7.0 of PICAXE Manual 2.

The statement does exist in prior versions such as B6.3 and 6.9.


I often consider that one of the documentary omissions to the PICAXE manuals is a clear table of limitations and bugs. By way of one example, the limitations with the 14M for SEROUT on some output pins and some firmware revisions. Not everyone has or always uses the latest and greatest chip or even the latest version of a given chip.

 

[BCJKiwi]

When the port.pin convention arrived with the later chips, I did ask/suggest that the PE be equipped with the ability to use this convention across the entire PICAXE range.

As per usual it just passed by without comment from Technical/RevEd.

Interestingly my oft repeated call for the #PICAXE xxx directive to be required in all programs has recently been taken up by another - but this has also passed by without comment or action from Technical/RevEd.

How about it RevEd?

 

[Dippy]

Re: That last point.

In another Editor/tokeniser , that originally stamped it's authority many years ago, the directive is put in automatically.

Instead of View > Options > Mode you simply click an icon and directive is plonked in there for you.
It was stamped , sorry, inserted on line one.

However, I shall refrain from mentioning the other Editor.
Nice idea, half a dozen lines of code.

 

[hippy]

I am sure forced use of the #PICAXE directive has been commented on because I'm sure I commented upon that. The question is what advantages would it have and what disadvantages.

The biggest advantage would be that it would be clear what PICAXE it was for when code was posted, as long as posted in its entirety.

The disadvantage is for people who only use one PICAXE type it's unnecessary typing having to enter it every time they create new code.

Another disadvantage is for code which is written to run on a number of different PICAXE chips using #IFDEF depending one which PICAXE has been selected in View->Options.

It's debatable whether forcing #PICAXE is advantageous or not.

 

[Technical]

When the port.pin convention arrived with the later chips, I did ask/suggest that the PE be equipped with the ability to use this convention across the entire PICAXE range.

Have you actually tried using, for example, 'high b.1' on an old chip like the 18A? It's not mentioned in the manuals as it was not the recommended way of working with the old parts, but it does work with recent versions of the compiler if you really want to work that way.

Programming Editor release notes
5.3.0
...
Older part compilers now support port.pin labels on their predefined inputs/outputs
...

There are arguments for and against a forced #picaxe directive. It's something we will consider again in the future.

 

[BCJKiwi]

Port.pin
@ Technical
No, did not try using port.pin on earlier chips as I was unaware it was now available as no mention had been made that was obvious. A more overt mention that the PE release notes might have been useful.

Great news that it is now available as one can now use a single programming convention/style across all chips.

#PICAXE xxx
@Hippy/Technical
Apologies Hippy If I missed your comment.
I accept there may be an issue with common programs for multiple chips.
How many chips can actually run the same program without any alteration? - It would of course depend on the complexity / features used in any given program.
Perhaps the the PE setting should be removed from view options, and/or, the #IfDef functionality could be extended to include #PICAXE xxx?

The main reason I see in favour of #PICAXE xxx being enforced is that the PE does not know which chip the code is for if it is not specifically stated in the program, or, unless the PE default is changed.

The lack of a #Picaxe xxx directive results in posts on the forum which would not be required if the directive was included.
Also it means that the PE is working on whichever chip is set as its default.
So if this is not changed AND the #Picaxe directive is not used, then syntax may be flagged in code and simulator issues may arise where code is right for the intended chip but does not match the PE current default.
Also, the lack of the directive also allows for the program to be developed and simulated for the wrong chip and then finding it won't work in the chip one wants to use!
Another interesting factor in the mix is that the PE runs on the default until a syntax check or download is attempted at which time the default is changed to match the #Picaxe directive is in the current program being checked/downloaded.

 

[BCJKiwi]

OK,

Just tried the Port.Pin syntax on an old 08M program.

1. The X2 conversion Wizard only allows X2 chips to be selected - perhaps all chips could be added - OK, OK I know its a lot of work - just a suggestion.

2. Perhaps the Chip pinouts in Manual 1 could have the port designations added for ALL the chips (not just the _2 variants) to enable the port.pin method to be used without having to do a lot of research on port naming of older chips. I have not been able to find anywhere what the port configuration of the 08M is - (even looked at the Microchip datasheet).

Syntax checker seems to accept;
B.0 for Out0 (Leg 7)
C.2 for pwmout on Out2 (Leg 5).
Without wiring up another circuit have no idea if these would actually work on the hardware.

Thanks