Please point me to some step by step basics to code the PICAXE using Blockly.

hippy

Technical Support
Staff member
So this is a plea to enhance the PUT and POKE commands to take strings the way WRITE does for eeprom. (Still wouldn't be backwards compatible with PE5, I guess.)
I am guessing you mean like DATA / EEPROM or SEROUT, HSEROUT etc, do because WRITE doesn't support that.

It is possible to achieve the same as -
Code:
Poke 20, "abcdefghi"
By writing it as -
Code:
Poke 20, "a", "b", "c", "d", "e", "f", "g", "h", "i"
While it might be desirable to allow separate characters to be represented as a single string the two would be the same as things currently stand, just easier to type and more convenient to use..

The difference between POKE, PUT and WRITE, and SEROUT etc, is that the former were only designed to have a single data item so multiple data items generate multiple separate commands. SEROUT and similar were intended to have multiple data items so generate a single command with 'another item follows' flags within them which means they are encoded differently and use less memory.

For example SERTXD("abc") is approximately one byte more than SEROUT("a","b"), size only increases by about one byte for every character added. That's not the case for the single data item commands. POKE 20,"abc" would be POKE 20,"a" : POKE 21,"b" : POKE 22, "c", so increases by more than one byte per character added.

Edited: Clarified above.

The above POKE "abcdefghi" example uses36 bytes on a 40X2, a #MACRO version uses only 33 and allows the single string representation -
Code:
#Macro MacroPut(loc,text)
  bPtr = loc
  b0 = 0
  Do
    LookUp b0, ( text, 0 ), @bPtr
    b0 = b0 + 1
  Loop Until @bPtrInc = 0
#EndMacro

MacroPut( 20, "abcdefghi" )
True, the #MACRO version uses more than the POKE version for less than seven characters. But the use case we are considering is when using more data than less.

To have memory efficient multi-data item POKE, PUT and WRITE commands requires a change in the PICAXE firmware and it would only be available for new chips with that firmware. Given that, and that the problem can easily be overcome using #MACRO, there is likely not a compelling business case to make such a change.
 
Last edited:

Gramps

Senior Member
Mine doesn't look like that but we found a small wrench in"workspace explorer " that listed the compiler and checked "use pre-processor "
still get the same syntax error...........
 

lbenson

Senior Member
What does yours look like? Are you on the HOME tab? Are you using PE6? Macros, which this program needs, are not supported in PE5.
 
Last edited:

Gramps

Senior Member
Are you on the HOME tab?
Yes.
Editor version 6.0.9.3

PICAXE-40X2 Compiler
Version 3.4
Copyright (c) 1996-2016
Revolution Education Ltd


#Macro writeStringToPad( string )
^
line# 7, col# 1

Error: syntax error

When we check the use pre-processor box and say "ok" then go back and check it and it's unchecked again!
 
Last edited:

lbenson

Senior Member
You're on the Home tab in Editor version 6.0.9.3 and you don't have an Options button (crossed wrench and hammer)? You should have, and if you click it you get a "Picaxe Editor Options" window with selectible items down the left side, including "Compiler". Click that and the first checkbox option should be "Use pre-processor". Make sure that is checked.

If you don't see these things, press necessary keyboard buttons for Print Screen (sometimes a single button, sometimes something like Fn (function key) + PrntScrn (usually along the top row). You can then paste this into the Microsoft Paint program (which will be somewhere on your windows PC). Then you can save it as a .jpg file and insert it in a forum post so we can see what you see. The program will compile and run if set to allow macro definitions.
 

Gramps

Senior Member
I found a customize tool bar option and added the option button above the regular tool bar. Checked and sure enough the pre-processor box will not stay checked.
Working on a screen shot.........
 
Last edited:

lbenson

Senior Member
Glad you got us a screen shot. Hmmm ... no options button, like you said. I seem to recall that I had to do some magic to set up "new style" PE6 behavior, but I don't remember what it was. Try this.
PE6 preprocessor2.jpg
 

hippy

Technical Support
Staff member
Checked and sure enough the pre-processor box will not stay checked.
Unless you can get the Pre-Processor option to remain checked you won't be able to get past the Syntax Error failure.

It is the Pre-Processor which handles #MACRO and #DEFINE statements and their expansion within source code; the compilers themselves do not understand those statements by themselves which is why they give an error when the Pre-Processor isn't executed. Which it won't be unless the option is checked.

It is not at all clear why the option is not remaining checked. I have never known it to not work myself and I do not recall having seen any other reports of such behaviour.

It might be possible to force the option through the settings files held outside outside PE6. I will take a look to see what could be done.
 

hippy

Technical Support
Staff member
Mystery solved ...

BLOCKLY-.jpg

You are launching PE6 in Blockly mode which disables the Pre-Processor.
 

lbenson

Senior Member
Until I found one in a drawer, I had forgotten that you can hook a speaker to a picaxe pin as well as a piezo (see Manual 3). Much better sound (though still not winning any awards).
 

lbenson

Senior Member
Yay! Not sure when the root cause would have been found without the screen shot. Kudos for persisting.
 

hippy

Technical Support
Staff member
Yay! Not sure when the root cause would have been found without the screen shot. Kudos for persisting.
Yes that was very useful so thanks for posting it.

I didn't expect a screen shot to have been much use at all by showing the error itself - we usually take it as read that people are getting what they say they are seeing - but it turned out to hold the key to the mystery.

It was somewhat 'by chance' I happened to spot that hiding up there, noted it was different to what I had expected to have seen while looking at the image for clues. I launched my own PE6 in Blockly mode and had the same experience you did. Hence, 'that explains it'.

With hindsight, in a thread about using Blockly, it is not surprising you might have been launching the Blockly version but I don't think anyone had appreciated that as the reason.
 

Gramps

Senior Member
Don't know when will get a chance to try lBenson's code, it's Christmas, rainy and cold here in Fort Myers Florida, tonight.
My wife and I are part of the live-in staff at the Fort Myers Rescue Mission Home to 84 homeless men.
We're filled up to the roof so we've been pretty busy the last few weeks.
 

lbenson

Senior Member
Thanks for keeping us posted. Merry Christmas to you and to them. I'll have some non-Christmas tunes and an LCD and a couple of buttons tested soon--but likely not all worked out until after Christmas. Rainy and cold (Florida cold) here in Crystal River too.
 

Gramps

Senior Member
Beautiful pic! I came to Florida in "78" and have been here at the Rescue Mission for 40 years except for 10 years ( "99" to "09") in Mongolia where we ministered at a children's home.
Sigh, a new problem. While installing the 40 pin picaxe in an enclosure I must have bumped a wire. After a reset the proper LED lights for 3 notes and then everything goes out. Must have a loose wire or a short someplace20181222_094607.jpg
I just can't imagine how this happened🤔
 
Last edited:

hippy

Technical Support
Staff member
At post 135 lbenson used a 28x2 pic to code the accelerometer. Will that work with an 08M chip?
It always helps to include a link to a post to save people searching through pages of posts to find which one that's on -

https://picaxeforum.co.uk/threads/please-point-me-to-some-step-by-step-basics-to-code-the-picaxe-using-blockly.30716/page-4#post-320049

That code seems to be for an 08M2.

The easiest way to see if code for one PICAXE works with another is to change the #PICAXE type and see if it compiles, see what errors are generated.

In this case it does compile for an 08M without error so should work.
 

Gramps

Senior Member
Okay, thanks for the tip how about posting the link to an old thread.

Yes, the 08 M2 does compile the code.
It also downloads properly.
 

lbenson

Senior Member
Now that you have an LCD working, here is something to do with it.
hammerLCD.jpg
This has the same 9 tunes as the last version, but with a serial LCD on C.3 and two pushbuttons on C.0 and C.1, you can play without a connection to the PC. (If those pins don't match your connections, change them in the program. Make sure you have the pushbuttons wired as in Manual 3 so as not to have random button presses from floating pins.) Pressing the button on C.0 cycles to the next tune; pressing the button on C.1 plays the tune. After a tune is played, again pressing the C.1 button will replay the tune.

Not yet tested on a real picaxe. As before, too big for a code box; remove the ".txt" from the attached program to get the basic file for loading into PE6.
 

Attachments

lbenson

Senior Member
when I move the accelerometer nothing happens. Any suggestions?
What variety of nothing and what kind of movement? It took a fairly hard snap. What pin do you have the z-axis tied to? Can you post a photo? And your code.
 

Gramps

Senior Member
' 08accel_xl335 ' accelerometer

#picaxe 08M2 ' 20M2
#terminal 4800

do
readadc10 C.1,w1 ' read "Z" axis of XL335 accelerometer
if w1 < 380 then ' acceleration towards a strike
sertxd(#w1," ")'Serial output via the serial out programming pin
pause 200 ' reduce/eliminate double reports
endif
pause 5
loop
Z-axis is tied to pin C.1
1546130721340.png
 

lbenson

Senior Member
You may need to comment out the "if w1 < 380 then" so you can see what values you are getting when resting and when striking. You may see different values from what I saw.

In your screen shot of the serial terminal, where are the numbers in brackets coming from? Or had you had the wrong baud rate and didn't clear the display when correcting it? (Re this kind of shot--it would be good to drag the serial terminal to the right so we can see the actual code being run.)

Not sure what the lower photo is showing. I had the accelerometer strapped to the end of a pencil, with wires running back to the 08M2.
 

Gramps

Senior Member
All that gibberish in the serial terminal appeared when we first downloaded the program to the chip.
After clearing it we struck the accelerometer on the table as if it were a hammer on the dulcimer. The serial terminal just shows a numeral one.
 

Gramps

Senior Member
comment out the "if w1 < 380 then" so
When we did that the serial Terminal displayed this screen shot: The numbers just keep rolling out.
Waving the Z-axes around and tapping it on the table (it's taped to a stick)
did not seem to effect the readings.

1546224064423.png
 

lbenson

Senior Member
Can you provide a photo of your striker+accelerometer? Is the accelerometer fairly horizontal when the striker is horizontal? Are you sure you have the Z-axis wired, plus power and ground? Are you sure you have the z-axis wired to C.1?

Even vigorous air strikes showed up for me. I'd test again--it's right beside my chair--but I'm a thousand miles away from that chair.

(Good screen shot, by the way.) Hmmm--comment out the PAUSE 200 as well--then you'll get numbers even faster.
 

hippy

Technical Support
Staff member
One way to reduce the number of results produced is to only print when things have changed -
Code:
#Picaxe 08M2
#Terminal 4800

Do
  ReadAdc10 C.1, w1
  If w1 <> w2 Then
    SerTxd( #w1, " " )
    w2 = w1
  End If
  Pause 200
Loop
 

lbenson

Senior Member
One way to reduce the number of results produced is to only print when things have changed
Very good point. I thought there was some jitter in the reading, which would reduce the effectiveness of this technique (though it would still be very worthwhile), but in fact, the numbers only increase gradually--from 938 to 945. That's odd. I wonder what would cause that?
 

AllyCat

Senior Member
Hi,

The screenshots don't show up well on my little netbook screen, but values around 940 seem far away from the expected (?) half-way bias level (512). I'd be looking for a hardware (interface) problem first. ;) Maybe try an X or Y axis output?

Cheers, Alan.
 

lbenson

Senior Member
... values around 940 seem far away from the expected (?) half-way bias level (512). I'd be looking for a hardware (interface) problem first.
Right. This is what I found in the original post: "Typical "resting" ADC value is 480-620. A strike is below 380 (an "air" strike--no string hit--is the same). This might miss some light strikes, so adjustment could be needed. "
 
Top