Then the answer is no.Hi, is there is some possibilities to create a compiled .HEX (or like...) file from a .BAS file, email it to a customer, who then uploads it to PICAXE?
this is very interesting... how?You should have asked :
Then the answer is no.
There is way of transferring a compiled file to another PICAXE, but it needs a specific circuit and a bit of VB or C program on a PC.
Cheers,
Buzby
The PDF does not document any facility in the compiler that creates a binary or hex file from the PICAXE program. You will have to program a PICAXE while 'sniffing' the data lines to see what is being transmitted with the assistance of a second COM port. The transmitted data can be dumped to a file and a program which you'll have to make yourself can recreate the rest of the download process.yes but I must supply another people to upload the program in the picaxe without give him the source .bas code...
so I must give him only the compiled version of the software (hex version), not the source code (bas version)...
So the assembler is great for educational use, ( that's what PICAXE is designed for ), but not much use for keeping your IP safe.And that code is specifically written to be user readable -
Does it mean that PE would not be any more a free software?Correct...
Does this mean an inexperienced user could 'brick' a real Rev-Ed PICAXE ?.... Obviously compiled BASIC will be quite different ... but can also be modified to merge assembler libraries (e.g. floating point) etc.
If I've understood things correctly (not that easy as I think a whole raft of posts here have been deleted recently) then the compiled code from the new PE6 will have to be downloaded to a bare PIC, using a PIC programmer, rather than a Picaxe with the built-in interpreter.Does this mean an inexperienced user could 'brick' a real Rev-Ed PICAXE ?.
( I'm not bothered about people 'bricking' knock-off clones, but I wouldn't want to see the forum filling up with even more 'program won't download' questions. )
That's a big question. Just because it's in assembler doesn't mean it is always faster.... Depending on the performance difference ...
We think you're missing the point, nothing is actually new and it is not a 'PICAXE' feature. So "'new' PICAXE" is not a good description. Nothing with regards to PICAXE use changes.My concern is that if the 'new' PICAXE is too open
It's not assembler for PIC that I want to see most in PE6, just better tools to work with the PICAXE we have now.The main problem is that this thread has now got me fired up and very keen to see PE6!
Somewhat off topic, but I would like to reflect that sentiment entirely. Rev.Ed. is a superb company to deal with. Their products are so well supported; it is quite astonishing just how much resource they commit to that aspect. When I started getting into PIC technology some years ago I went through the well-tramped pathway of starting off with an off-the-Maplin-shelf programmer; waded through books on assembler; looked at range of higher level languages with compilers; bought another programmer because I thought it might be a bit better but then regretted it because I misunderstood what it could do...and so forth. Then along came PICAXE and I moved forward suddenly with astonishing speed in what I could achieve. Educationally, economically, sales, support, documentation, just about in every respect, I have found the PICAXE route unparalleled. Long may it continue and the sooner we get our new toys (PE 6) the better. (That is one thing that RevEd perhaps should not do; keep us all on tenterhooks for so long... Like many others on this forum I almost wish that they had not told us of PE6 so long ago - patience and anticipation just give way to frustration).The more I read, and the more I see Rev. Ed. actually DO, the more I'm impressed with the PICAXE line and the the company as a whole. You guys really do care. That's a rare business model these days, and one that requires sheer genius to maintain. My hat's off to you. I think I'd better buy some more "stuff."
Ah, but they invited all of us to submit suggestions for PE6 improvements. Things have moved on a lot in the past 10 years and to be given an opportunity to contribute to the changes is another mark of customer service.(That is one thing that RevEd perhaps should not do; keep us all on tenterhooks for so long... Like many others on this forum I almost wish that they had not told us of PE6 so long ago - patience and anticipation just give way to frustration).
Only if it leads to actual change. It's been 15 months since the Wishlist thread was started, and there hasn't been much change.Ah, but they invited all of us to submit suggestions for PE6 improvements. Things have moved on a lot in the past 10 years and to be given an opportunity to contribute to the changes is another mark of customer service.
I keep seeing these posts anticipating a new M3 or X3 line and wonder what all you're wanting that isn't currently offered in the existing line? Faster speeds? Decimal math?What I would really like to know is if there is going to be an X3 addition to the PICAXE family, introduced at the same time as PE6.
The length of time since PE6 was first mentioned has been plenty enough to write an assembler and tweak the editor and simulator, so I've got a suspicion that the long time is because PE6 is being built to support a new PICAXE generation, as well as the M's and X's we have now.
Dont start ....If a firmware wishlist was added, then my first request would be strings !.
I think it is clear that RevEd/Clive know they need to change.In a minute or two, the doomsayers will chip in saying how completely wrong the Rev Ed business model is and how they must compete with the well known "A" product or we all doomed ......
More code memory and better power management together (ie >4kB in one segment + nap + wake-from-nap interrupts maybe): I've currently filled an 18M2+ to bursting even with all my code ticks of nearly 30 years and I'm having to start on AVRs at least for a parallel stack.I keep seeing these posts anticipating a new M3 or X3 line and wonder what all you're wanting that isn't currently offered in the existing line? Faster speeds? Decimal math?
What current consumption were you getting in NAP on the 18M2 and what were you getting if you ran the 18M2 as normal but with the clock speed reduced to 31khz ?More code memory and better power management together (ie >4kB in one segment + nap + wake-from-nap interrupts maybe): I've currently filled an 18M2+ to bursting even with all my code ticks of nearly 30 years and I'm having to start on AVRs at least for a parallel stack