noobie needing advice

davehouston

New Member
I'm totally new to PICAXE but have a bit of experience with PICs and AVR.

I'm developing a Home Automation system (as well as general purpose hardware) using Arduino form-factor PCBs with a combination of AVRs (using ZBasic) and PICs (using PicBasicPro/ds30 loader).

The distributor who will manufacture/distribute these has a very open sores, educational philosophy so I am exploring using PICAXE chips both on the above referenced shields and on the system boards.

I've done some preliminary reading of PICAXE literature but have additional questions that I hope the folks here can answer.

Are there datasheets that detail the amount of memory and register addresses for the newer PICAXE 8, 14, 28 & 40 pin chips? Are they cross-referenced to the underlying PIC model?

Since PICAXE 8 & 14 pin chips cannot be I2C slaves, I'll need to manage the same function via peek/poke, bit-banging. Is this possible? Could the approach used in the PBP code in post #7 to this thread work with PICAXE?

I need to handle both IR and RF input/output but cannot be limited to what PICAXE supports. For output I need to generate both the carrier (~38kHz) and data envelope. I am assuming I can use PWM and high/low/pauseus for these. Do you forsee any problems?

For RF/IR in, I need to capture the time between rising edges and I see no native methods for this. Is it possible to access the capture/compare hardware using peeksfr/pokesfr?
 

westaust55

Moderator
On the topic of using M2 parts as i2c slaves, I do not recall any past threads indicating this has been done before - keep in mind that the M2 parts are relatively new.
Forum member hippy and others have posted PicAxe BASIC code to enable earlier parts (eg 08M) to act as an I2C Master which occupied about 100 bytes. Obviously for a slave there are further complexities. Tentatively can be done but no guarantee.

As you are looking to a commercial venture, maybe you should set up a couple if PICAXE on a breadboard and develop the code.

On the topic of IR and generating your own carrier, I have in the past posted a tutorial on IR which includes this capability. Rather than me search via iPhone, I leave it to you to search for the tutorial.
On other aspects, you are going to have to provide more specific and clear details on what you are trying to do - good description, pseudo code and schematics.
Your project may be a commercial venture but even hobby and educational orientated members here need something clear to work with.
 

davehouston

New Member
On the topic of using M2 parts as i2c slaves, I do not recall any past threads indicating this has been done before...
The newer chips have I2C built in but only the 28X2 and 40X2 can be master/slave, the others master only. I referenced some code which works on a PIC using PBP and was merely asking whether it might be adapted to PICAXE.

On the topic of IR and generating your own carrier, I have in the past posted a tutorial on IR which includes this capability. Rather than me search via iPhone, I leave it to you to search for the tutorial.
Had already seen it - beyond a simple schematic showing using PWN for carrier, it doesn't address my question of whether there are any issues I should be aware of.

Your project may be a commercial venture but even hobby and educational orientated members here need something clear to work with.
I have no problem doing all the above and more in the commercial venture. It's porting it to open source for the benefit of the hobby and educational orientated where I hoped for some assistance but it appears I am wasting my time here.
 

mrburnette

Senior Member
@davehouston,
I have no problem doing all the above and more in the commercial venture. It's porting it to open source for the benefit of the hobby and educational orientated where I hoped for some assistance but it appears I am wasting my time here.
If you will just give the forum an opportunity, I truly believe you will find value here. WestAust55 routinely works via his mobile as his day job takes him away from a real keyboard... I can attest that he is more than capable of generating large quantities of directed response when he has a PC at his disposal. He is just pointing you in some various areas which he thought useful we do not know your skill level or background and much of he forum work goes to answering questions for school projects.

The above being said, it is standard practice to ask for as many details as possible, design goals, schematics, caveats... our forum is extensively diverse as are the backgrounds of the members. Unfortunately, we are not the Borg and do not work as a collective being... it is more shotgun than surgical, but you take away the wheat with the chaff.

It appears that you link in post #1 to your own website with Parduino 28/40 board product... www-davehouston... anyway, I going to leave it to a moderator to address this usage. It is generally acceptable to link to products specs which are utilized in a project but self-advertisement is a weebit sneaky. There is a fair amount of interest for AVR/Aduino in the forum but most members realize the limits of such posting on a site RevEd foots the hosting bill.


- Ray

UPDATE... useful info on Dave's website davehouston.org
 
Last edited:

davehouston

New Member
@mrburnette
It appears that you link in post #1 to your own website with Parduino 28/40 board product... www-davehouston... anyway, I going to leave it to a moderator to address this usage. It is generally acceptable to link to products specs which are utilized in a project but self-advertisement is a weebit sneaky. There is a fair amount of interest for AVR/Aduino in the forum but most members realize the limits of such posting on a site RevEd foots the hosting bill.
Surely, RevEd will not object to my trying to increase their PICAXE sales. And, if they had a 40-pin version of their Shield Base, I would not have bothered with designing one.

Anyway, I need to capture an incoming bitstream from RF or IR receivers. The following PBP code will capture X-10 RF which uses PPM (Pulse Position Modulation) but a far more universal and useful method would measure between rising edges (shown in the code snippet in the second example below) which can capture PPM and PWM (Pulse Width Modulation). PPM & PWM cover more than 90% of the codes in use (about everything except the various Philips RCx codes). Doing this requires µS timing routines which require lower level access. My question is whether this is possible with PICAXE 08M2/14M2. If it is not, I'm wasting my time trying to port the application. I'm 70 years old and dealing with a couple of major medical issues so have little time to waste.
Code:
'-----PIC12F629 using MPASM-----
'USE PIC12F675 if you need to measure linear output (e.g. to tune) 
'Receives 32 bits of NEC protocol RF with initial lead-in of 8.8mS
'outputs received codes as hex string via RS232 @ 9600bps on GPIO.2

@ __config _INTRC_OSC_NOCLKOUT & _WDT_OFF & _MCLRE_OFF & _CP_OFF

DEFINE PULSIN_MAX 968				'>968 RETURNS 0
DEFINE DEBUG_REG GPIO
DEFINE DEBUG_BIT 2				'GPIO.2
DEFINE DEBUG_MODE 1 				'Inverted
DEFINE DEBUG_BAUD 9600
DEFINE OSCCAL_1K 1

RF      VAR     byte[4]
space   VAR     byte
i       VAR     byte	         	
stx     VAR     word            		'start of transmission

        CMCON = 7                   		'comparators off
        Debug "RF NEC PROTOCOL",10,13
init:   RF[0]=0:RF[1]=0:RF[2]=0:RF[3]=0:i=0
        PulsIn GPIO.1, 1, stx	
        If (stx<792) Then init           	'too short or > PULSIN_MAX
        While GPIO.1=0:Wend			'wait pulse
        Repeat
          PulsIn GPIO.1, 0, space
          If ((space<40) Or (space>180)) Then init
          If (space>75) Then
            RF.0(i)=1				'set bit
          EndIf
          i=i+1 
        Until (i>31)
        'next two lines are optional - depends on tx codes
        If (RF[0]+RF[1]<$FF) Then init		'corrupt so discard
        If (RF[2]+RF[3]<$FF) Then init		'corrupt so discard
        For i=0 To 3
          Debug IHEX2 RF[i]
        Next  
        Debug 10,13
        GoTo init

        End
Code:
    ' PIC18F242 @20MHz
    DEFINE OSC 20
    DEFINE DEBUG_REG PORTC
    DEFINE DEBUG_BIT 6 
    DEFINE DEBUG_BAUD 115200
    DEFINE DEBUG_MODE 0 ' 1 = inverted, 0 = true

    Symbol    Capture = PIR1.2 ' CCP1 capture flag
    T1        VAR WORD         ' capture value
    PERIOD    VAR WORD         '	

    TRISC.2 = 1          ' CCP1 input pin (Capture input)
    INTCON = 0           ' Interrupts off
    
ReLoad:
    CCP1CON = 000101     ' Capture mode, capture on rising edge
    T1CON = 0            ' TMR1 prescale=1, clock=Fosc/4, TMR1=off (200nS per count @20MHz)
    TMR1H = 0            ' Clear high byte of TMR1 counter
    TMR1L = 0            ' Clear low byte
    T1CON.0 = 1          ' Turn TMR1 on here

    Capture = 0         ' Clear capture int flag bit
    While !Capture      ' Wait here until capture on rising edge
    Wend
    
    ' Rising edge detected / stuff Timer1 value in T1
    T1.HighByte = CCPR1H
    T1.LowByte = CCPR1L

    ' Convert to uS for 20MHz osc with 200nS Timer1 ticks
    PERIOD = (T1 * 2)/10

    DEBUG dec PERIOD,"uS High",13,10    ' Output to RS232 display
    GOTO ReLoad
 

hippy

Ex-Staff (retired)
PPM & PWM cover more than 90% of the codes in use (about everything except the various Philips RCx codes). Doing this requires µS timing routines which require lower level access. My question is whether this is possible with PICAXE 08M2/14M2. If it is not, I'm wasting my time trying to port the application. I'm 70 years old and dealing with a couple of major medical issues so have little time to waste.
On the I2C Slave front it is unlikely you will be able to get an M2 to operate as an I2C Slave except by bit-banging and running the bus at a speed that is likely too slow to be practically useful. I haven't tried it with an M2 but did not get very far in trying to do it on older PICAXE. Given some time to commit to investigating, prototyping and testing it may prove possible.

On IR and PPM; I believe there is example code on the forum for receiving RCx codes, and the means of using the timers as in the PBP code may be achievable with the correct PICAXE depending on which hardware pins are used for the timer on the particular device. Similar techniques have been used using PEEKSFR and POKESFR commands but I do not know if the technique you are using here has been tested before or will work with any particular PICAXE.

Unfortunately it is often the case that while some things may look possible, or even not, there is no definitive answer until someone has tried that, failed or succeeded.
 

westaust55

Moderator
I have not looked into the timing intervals involved but have a look at the work done here by forum member InglewoodPeter for the NEC IR code:
http://www.picaxeforum.co.uk/showthread.php?16576-Background-Infrared-Receiver-for-32-bit-Codes
It differs from the Sony SIRC protocol used PICAXE and many consumer devices.

With an M2 part at 32 MHz, the typical/average time for one BASIC instruction will be of the order of 30 usec. PEEKSRF and POKESRF will have these sorts of durations.

However, now that you have clarified the duration between two rising edges as of the order of usec intervals, I suggest that since the PICAXE uses an interpreted basic you goal cannot be met.
 

davehouston

New Member
I have not looked into the timing intervals involved but have a look at the work done here by forum member InglewoodPeter for the NEC IR code:
Thanks for that link. It shows that this might be possible. The question is whether the same low-level access to a timer is available on the 08M2 and whether it has sufficient memory. I would need to study the code but suspect it can be pared down substantially for my application. But, I also need an answer on simulating I2C slave mode on 08M2/14M2 chips.

I think you misinterpret my use of the term µS. Most IR/RF protocols have pulse/space widths of 250µS or greater and measuring them with 20% accuracy is usually adequate - remember that IR remotes (and associated protocols) date back 40+ years when techniques/hardware were primitive by today's standards. And, I'm measuring between rising edges which are usually 500µS-2200µS durations.

I am quite familiar with the various protocols. Early PDAs had CF slots and I designed an IR transmitter on a CF card that, in conjunction with PDA software (written by someone else), turned it into a programmable remote control. It had >30m range with the 3V PDA supply and a single IR emitter.

I wrote other Windows software that allowed capturing IR/RF codes with a PC soundcard, automatically trimmed them to a single copy of the code and could translate between .WAV, Pronto CCF and a few other formats.

Also, with some PICs you can send IR using a single pin for the carrier by toggling it between input/output - I'll need to dig thru my code archive for a PBP example to post here.
 

davehouston

New Member
On the I2C Slave front it is unlikely you will be able to get an M2 to operate as an I2C Slave except by bit-banging and running the bus at a speed that is likely too slow to be practically useful. I haven't tried it with an M2 but did not get very far in trying to do it on older PICAXE. Given some time to commit to investigating, prototyping and testing it may prove possible.

On IR and PPM; I believe there is example code on the forum for receiving RCx codes, and the means of using the timers as in the PBP code may be achievable with the correct PICAXE depending on which hardware pins are used for the timer on the particular device. Similar techniques have been used using PEEKSFR and POKESFR commands but I do not know if the technique you are using here has been tested before or will work with any particular PICAXE.

Unfortunately it is often the case that while some things may look possible, or even not, there is no definitive answer until someone has tried that, failed or succeeded.
Thanks very much for your input. It helps to communicate with someone well versed in the basic capabilities of the chips.

I am using multiple 8 and 14 pin PICs (13 max) to interface with external devices (RS232, IR/RF I/O, DIO,DAC, ADC) and use I2C to communicate with the main 28/40 pin µC which functions mostly as traffic cop/switchboard operator. I would prefer to use 400kHz bus speeds but could go slower as this is all PIC-to-PIC. The only standard I2C device in the system is an RTC chip @400kHz. Sending to the main µC should not be a problem - it's receiving that presents the need for (pseudo)slave mode. I might be able to use half-duplex serial communication for that but would need to study the details as pins are in short supply. I would prefer I2C. I have some flexibility in pin assignments as everything is still in prototype stage - I'm investigating this to see whether it's possible before committing to a final design for the various PCBs.

On IR/RF, can I access the low level timer in the same manner as the 20X example by InglewoodPeter? Being able to start/stop read any high resolution timer is all that's needed.

I have a AXE401 (as yet unassembled) that I can use with my shield boards for testing although pin flexibility may be limited a bit that way. And, I can breadboard if needed.
 

hippy

Ex-Staff (retired)
The question is whether the same low-level access to a timer is available on the 08M2 and whether it has sufficient memory ... But, I also need an answer on simulating I2C slave mode on 08M2/14M2 chips.
I don't think you are going to get a definitive answer as stated earlier ( post #7 ). My feeling is probably for the timer, for I2C slave it depends on what the full requirement are, what throughput and transfer speeds are acceptable.

One thing I am not clear on is what the second code example in post #6 is measuring; it seems to only be approximately measuring time between one rising edge and next rising edge, so I don't really understand the 'uS High" in the debug Command. The code seems to free-wheeling rather than synchronised. I believe the 08M2 can do what you have there but that may not be what you actually want.
 

davehouston

New Member
One thing I am not clear on is what the second code example in post #6 is measuring; it seems to only be approximately measuring time between one rising edge and next rising edge, so I don't really understand the 'uS High" in the debug Command. The code seems to free-wheeling rather than synchronised. I believe the 08M2 can do what you have there but that may not be what you actually want.
That example is taking the approach of the first example but making it more universal as it can handle both PPM and PWM which covers about 98% of all RF/IR protocols, measuring the time between rising edges of a bitstream. It needs to be done with 25µS accuracy although the example, which uses the capture/compare hardware, does it with more precision. The DEBUG commands are merely reporting results via RS232 to a terminal program or to the IDE. DEBUG is a software UART that can be assigned to any pins and can handle true or inverted data.

I guess the question is can I access the low-level registers to configure/read the capture/compare hardware or lacking that can I start/stop/read any of the hardware timers.
 

westaust55

Moderator
I guess the question is can I access the low-level registers to configure/read the capture/compare hardware or lacking that can I start/stop/read any of the hardware timers.
Since you have previously mentioned 8 and 14 pin M2 parts, there is the ability to access some but not all SRF registers in the PICAXE chips using the PEEKSRF and POKESRF commands.

Have a look at the SRF data map for M2 parts (title indicates 18M2 but Technical at Rev Ed has later in the thread indicated other M2 parts are the same for all intents)
that I posted a while back. Post 13 here: http://www.picaxeforum.co.uk/showthread.php?11514-PICAXE-Memory-Map-and-SFR-Details-Chart/page2
Armed with that table as a guide, you may still need to read the full PIC datasheets to fully understand the functionality.
 

davehouston

New Member
Thank you - as my shields were designed to use PIC12F1822, PIC16F1823 & PIC12F1840 I'm already familiar with some datasheets that I'm sure are similar to those for the 08M2/14M2. I'm just trying to determine how much of the native functionality is exposed with PICAXE.
 

davehouston

New Member
Thanks, again. I already had that link.

The pinouts are the same so I just need to analyze things to be sure I can use the 08M2 were I was planning on the PIC12F1822 and the 14M2 where I was planning on the PIC16F1823.

It will be a couple of months before I actually try writing code and testing. I first need to get everything working using PBP3 (and maybe Mikrobasic for PIC) At this point I'm merely trying to be sure that I'm not foreclosing the possibility of using the 08M2/14M2. I need to make sure my PCB layouts will work with either mix of chips and, at least preliminarily, that looks OK.

I will need to make a few changes to compensate for the lack of I2C slave mode for these chips but think that's possible as well.
 
Top