One big Picaxe or several smaller ones?

[John Geddes]

I am designing a controller that uses several inputs (including a hand-turned Rotary Encoder and a DS1820 temperature sensor) and outputs to an OLED and to other control units.

My first experiments with M2 chips suggest that I might be better using separate PICAXE chips to:
A) watch the Rotary Encoder, and calculate the current value to be displayed
B) output to OLED using the value from A (multiple binary pins or i2C)
C) read temperature and do other decision-making using inputs from A and elsewhere

rather than have one larger/faster chip try to do it all.

Do others agree?

The downside is clearly that more chips means more power and more wiring between them. But the speed at which an enthusiastic twiddler can twiddle a Rotary Encoder means that if the same chip is writing to the OLED or reading the DS1820, I don't think the user is always going to enjoy a smooth OLED response (where each click of the Rotary Encoder reliably increments/decrements the setting on the OLED). Using separate chips makes it easy for the OLED to catch up on any increments it has missed whilst updating the display (so three clicks clockwise will see the display increment from 10 to 13 even if the display actually only increments 10,11,13 because there had been two clicks in the time it took the OLED to update)

Am I on the right lines, or could I get the responsiveness I need using a single 28X2 (plus of course the 18M2 in the AXE133 for the OLED)?

John Geddes

 

[westaust55]

Welcome to the PICAXE forum.

While the latest X2/M2 PICAXE chips do have a lot more program space, more flexible IO and higher speed capability than earlier chips, some tasks can still be better handled by a separate chip.
Tentatively you could use interrupts to monitor for encoder inputs but as this is your first post and thus presuming you are relatively new to PICAXE chips it is warranted to consider a dedicated chip for monitoring the encoder.

Even long time PICAXE stalwart, forum member hippy, promotes breaking down functions over several chips under certain circumstances.

Have you done a search of the PICAXE forum based on “Encoders”?
There have been a number of threads in the past on monitoring rotary encoders. Certainly don't ignore the work others have already put in on this topic.

Is the OLED a graphic or text based display?
If text based, I would suggest that a second PICAXE chip would be ample to handle sending alphanumeric data to a OLED display, reading temperatures from a DS18B20 and various other functions.
If the display is of the graphic kind where it can require extra programming to transfer the data to the display for updates then a dedicate chip could certainly be warranted.

With respect to a forum search, as a start:
Here is one thread about encoders:
http://www.picaxeforum.co.uk/showthread.php?20273
This thread gives links to several other threads:
http://www.picaxeforum.co.uk/showthread.php?19545

 

[srnet]

Well the M2 parts can run at 32Mhz, and an the 28X2 and 40X2 can run at 64Mhz, so only twice as fast.

The OLED displays are capable of running fast, but the 18M2/AXE133 does not drive the display very quickly at all.

I had a similar problem with the morse decoder, standard AXE133 was just not fast enough. So I programmed a drop in 16F1827 replacement for the 18M2 in the AXE133 that drives the display 16 times faster than the standard 2400baud. It was programmed in compiled Mikrobasic.

It would be good if Rev Ed were to offer such an upgrade for the OLED.

 

[MFB]

As your not using a native PIC I assume your not designing a high volume product. For a one-off design hardware costs are normally less of a consideration than development effort, and a multi-PICAXE approach will probably be easer to debug than a more complex software intensive one.

 

[inglewoodpete]

I'll go against the flow and say that I would do the 3 basic tasks in one PICAXE chip. The only task that is critical is the rotary encoder. Reading the temperature is a simple exercise and writing to the oled display can be done in a couple of subroutines. If I were doing the development, I would start with the decoder and output my debugging data to the Programming Editor terminal. Once satisfied that this is working OK, I would add the oled driver routines and debug them. Finally, add the code for the temperature sensor.

Having said that, I would reenforce what WA55 has said regarding skill level: It depends on where you are on your learning curve: have you worked with microcontrollers before and/or what is you experience with PICAXEs? A project like this could be quite challenging if you are a beginner.

 

[mrburnette]

<...>
My first experiments with M2 chips suggest that I might be better using separate PICAXE chips to:
A) watch the Rotary Encoder, and calculate the current value to be displayed
B) output to OLED using the value from A (multiple binary pins or i2C)
C) read temperature and do other decision-making using inputs from A and elsewhere

rather than have one larger/faster chip try to do it all.
<...>

I would agree, but perhaps from a different viewpoint: The interpreter/firmware in the PICAXE is single-threaded and while there are some workarounds with some chip models (background I/O), the "blocking" nature of those instructions that do block (many) makes it very difficult to near impossible to maintain a properly timed state machine. It comes down to an architectural decision to move various work functions out to dedicated PICAXE's and then aggregate communications as needed. The 08M2 is a quiet competent little chip and will handle most single-tasks very well and it is very inexpensive and is therefore an ideal candidate for outward nodes.

Try and design in an async mindset and then bring everything into the "hub" to aggregate and feed the output device. If you are using the AXE133x OLED display, you may find that reworking the 18M2 driver code may be advantageous as the baud rate can be increased immensely, if necessary. Or, you may prefer to keep the display generic to allow for substitution to market brands.

- Ray