I2C inter-PICAXE smulation ?

dgc188

New Member
I may be hoping for the impossible here, but is there any means of testing under PE6 simulation inter-program I2C comms?

I've written a couple of programs that interact with each other via the I2C comms and it would make life a whole lot easier if there is some method of simulating how one program communicates with and reacts with another program (or more).

Or is PE6 a basic, only-one-running-program-allowed simulator?

I have noticed on a couple of occasions that my PE6 will appear to go totally unresponsive when in simulate mode, yet if I go to another tab (another program) and hit "run simulation" the first (hung) program springs back into life when I return to that tab. Could this be what I'm looking for, namely the possibility of two running programs (on one PE6)? And could this also, more specifically, simulate the I2C comms between the (possible) two running programs?

Or, as I asked at the top, am I hoping for the impossible?

Using Win10 Pro 1909, PE6 v6.1.0.0 running under Win8 compatibility.

TIA
 

inglewoodpete

Senior Member
From my experience, communication software has too many "real world" issues to go through the motions twice (the simulator's "real world" followed by the actual hardware "real world"). If you have to test your comms software before the real hardware is available, put your minimal circuit on a breadboard and develop your essential comms routines there.
 

Buzby

Senior Member
There is no way I know of to make two programs interact in one instance of the PE6 simulator.

The closest I've got is to run two instances of PE6, both outputting to their own PE6 serial terminal.

I can then 'cut & paste' from the RX in one terminal to the TX in the other.

It's very clunky.

Much easier to do with a couple of 'real' chips,
 

dgc188

New Member
Many thanks guys for your valuable comments.

I did rather think I was expecting TOO much from PE6 - but there may have been another program in the wider world that might have had that capability.

If you don't ask, you'll never know.

Thanks again - so it's back to the drawing (bread)board.
 

tmfkam

Senior Member
Proteus, with the PicAxe simulation files *might* be able to do that? I've not tried as sadly I can't justify the cost of Proteus to my boss, but it can simulate PicAxe devices if you have the PicAxe modules installed. Then it should be a case of drawing a circuit diagram in Proteus with the relevant devices, "loading" the software into them and running the simulation.

Revolution Education sell PicAxe VSM a circuit simulator that was based on a version of Proteus. Perhaps it can do what you need? I thought a limited demo version was available.
 

roho

Member
Proteus, with the PicAxe simulation files *might* be able to do that? I've not tried as sadly I can't justify the cost of Proteus to my boss, but it can simulate PicAxe devices if you have the PicAxe modules installed. Then it should be a case of drawing a circuit diagram in Proteus with the relevant devices, "loading" the software into them and running the simulation.

Revolution Education sell PicAxe VSM a circuit simulator that was based on a version of Proteus. Perhaps it can do what you need? I thought a limited demo version was available.
It is possible, but be careful before you go down that route. Firstly, you should check with RevEd which version of Proteus VSM runs under. When I purchased VSM at the end of 2015, it ran with v7 of Proteus. My understanding is that VSM still runs under this version, but check with RevEd to be sure. The problem here is that Proteus v7 is obsolete (it was that, in fact, even at the end of 2015) and unsupported by Labcenter, its manufacturer. This will become a problem for you if you need new or modified models for your simulations, general help in overcoming any problems, etc. I got around this by buying v8 of Proteus, and can indeed run simulations with PICAXEs in it.

Sadly, this brings me to the second problem, which is that the models used in the VSM simulation are nowhere near as good as the models used in the PE digital environment. A number of commands are unsupported, and this and other limitations can mean that code often has to be hacked to get simulations to run, and on occasions simulations do not run at all. A great pity in my opinion, because it is a very useful environment when running properly.
 

tmfkam

Senior Member
As I said, I've not tried it. I had a trial of Proteus with some of the PIC models that I use. Of course for the PICs it was possible to load a pre-compiled .hex file into the device, for PicAxe I could see that requiring the use of a compiler module could be a major hurdle, especially if it is outdated.

I went no further with the trial, firstly as I thought it was very expensive for my needs, but also I hated how the circuits were drawn! Very unintuitive for someone who uses Eagle daily. Back to prototyping on breadboard or VeroBoard.
 

Flenser

Senior Member
PICAXE VSM a version of Proteus that supports the PICAXE chips and which from the RevEd page for VSM has:
- latest X2 & M2 models
- Support for multiple PICAXE chips on same design"

I haven't tested that you can run I2C inter-PICAXE communication between two picaxe chips in simulation so you would need to ask this question before purchasing.

PICAXE VSM from RevEd with all the latest PICAXE chips is 1/10 of the price for a single family of PIC chips. (PIC12, PIC16 or PIC18) from the Proteus site.

For the PICAXE chips you don't need a compiler, you load the .BAS file into the simulation (of course) and not a hex file.

Of course, to test I2C between two PICAXE chips it is still going to be a lot cheaper to buy two PICAXE chips and a solderless breadboard.
 
Last edited:

tmfkam

Senior Member
For the PICAXE chips you don't need a compiler, you load the .BAS file into the simulation (of course) and not a hex file.
Perhaps I wasn't explaining myself clearly. As PicAxe is an interpreted language, if the "interpreter" used within the VSM is not an up to date one, it might not have the latest features included. I was thinking of things like Macros that were only introduced in the more recent versions of the PicAxe editor. These are not available in PE5, or MacAxePad. They may also not be present in VSM. With a PIC simulated in Proteus this would be less of a problem as it would be possible to compile a program using any (up to date) compiler of choice and then load the resultant .hex file into the simulation.
 

Flenser

Senior Member
tmfkam,

You make a very good point. I hadn't considered how old the current version of VSM is.

I've just checked the contents of the vsm_models_405.zip update which adds "The latest X2 & M2 models" and the dates on the files range between 2012-05-01 and 2013-09-09 which is quite a long time ago.

The revision history file for PE does not include dates against the releases.
The file https://picaxe.com/docs/pe6.pdf "PE6 BETA TESTING BRIEFING" that describes the new PE6 features, including the precompiler directives, is dated Sept 2013 which doesn't really help confirm whether or not the vsm_models_405.zip file includes the PE6 updates or not.

It would be inconvenient if VSM doesn't have the latest pre-processor features but you might be able to workaround this by using the PE6 diagnostic option "Display Pre-processor Output" to generate a BASIC listing to use in VSM. This is something to confirm before buying VSM.

Prior to the current hard lockdown for COVID-19 here in Melbourne Au I was doing most of my PICAXE coding on Saturdays and Sundays while spending a couple of hours in a coffee shop and after writing post #9 I had convinced myself I should buy VSM because it would allow me to also do most of my testing in these coffee shop sessions as well.

I've downloaded PICAXE VSM and running it it demo mode allows you to run the simulation for 5 demo files provided. It doesn't allow you to change the schematic but I'm pretty sure you can choose a different .BAS file so I'm going to checkout whether or not it supports the current pre-processor directives to inform my own decision to buy VSM.
 

tmfkam

Senior Member
I like your idea of showing the pre-processor output. That sounds like a reasonable workaround. Clever!
 

dgc188

New Member
Very interesting comments guys, thank you all very much.

From what Pete way saying back on post #3 - "If you have to test your comms software before the real hardware is available, put your minimal circuit on a breadboard and develop your essential comms routines there." And as there doesn't appear to be any freebie programs that will do what my original question posed, I took the plunge and tried the breadboard methodology - not that I have a lot of faith in my breadboard (loose/ill fitting pins, etc.) - and with the simple test program I cobbled together it all worked back and forth between an 18M2 and a 40X2. So I'm well pleased.

I certainly don't profess to fully understand the workings of the I2C protocol and how it gets implemented within the processors (between each of their respective RAM/scratchpad/etc.), but having got the two chips to "talk" back and between each other, it gives me faith that I can now move forward with what I actually want to achieve from my project using the (basic) knowledge so far grasped.

So thanks again one and all for the interesting comments - seems like I opened up a bit more than I had anticipated.
 

lbenson

Senior Member
Excellent progress. Once you have back and forth communication working, there's not much you need to understand about the specifics of the implementation--just treat it as a black box where you input certain conditions and you get back other conditions as expected.
 

inglewoodpete

Senior Member
I've just implemented i2c comms between two 28X2s working in tandem as RGBW lighting controllers.

In the slave, you have to avoid using commands that hog processor time. This can be quite annoying when you're trying the debug your slave code using SerTxd (or Debug) commands. The SerTxd command outputs serial data using timed "bit-banged" highs and lows, so i2c and other 'internal' (PICAXE internal operating system) interrupts have to be disabled. This results in i2c bytes being lost by the slave.
 
Top