Page 6 of 7 FirstFirst ... 4 5 6 7 LastLast
Results 51 to 60 of 63

Thread: The Assembly Language Debate

  1. #51
    Senior Member
    Join Date
    May 2011
    Location
    Atlanta, GA
    Posts
    775
    Blog Entries
    24

    Default

    Quote Originally Posted by bluejets View Post
    Presently trying to work my way through this ...... http://www.gooligum.com.au/tut_baseline.html .....thinking it was a natural progression from picaxe to C ....... so you believe it is not a waste of time then ..??
    Intellectually, knowledge gained from time & effort spent is not a waste of time. The question comes down to are there other things that will advance you further toward a goal than assembly language? I would answer, "Yes."

    Spend enough time with it to learn the basics, understand the tools used, and the concepts applied. At that point, make a decision to continue because it is of interest to you or depart with the knowledge and vocabulary. Proficiency is not a requirement to have an appreciation of the technology.

    When I taught software classes to adults, I would always spend a day with a PC completely disassembled; I used an old IBM PC system board mounted on plywood and had the IDE hard drive and the floppy all connected with long ribbon cables. Students learned to recognize RAM chips, CPU, PSU, etc. This certainly was not necessary to teach them Lotus 1-2-3, but it made a world of difference in their attitude since they had an appreciation of what was inside the box that performed the magic. A little knowledge goes a long way. Some would add to this foundation over time, others would not advance beyond the visual of a PC exposed on a table. Regardless, no one left the week-long class without the mental imagery; I never had a student complain about 'wasted time' but I surely had many that would approach me on Friday afternoon and offer a note of appreciation for taking the time to provide just a weebit of foundation knowledge.

    For those who do not want to get your hands dirty and install all of the required software, libraries, and such... watch a YouTube video or two.

    Something like this is probably sufficient to help you determine if you wish to devote more time:
    PIC assembler 101

    - Ray

  2. #52
    Senior Member
    Join Date
    May 2011
    Location
    Atlanta, GA
    Posts
    775
    Blog Entries
    24

    Default

    Quote Originally Posted by boriz View Post
    Many excellent arguments. I especially liked the 'bugger off' argument. At the risk of becoming a pariah, I still think Picaxe would be much better with an inline assembler, or some other method of calling machine code subroutines. But I guess I'm alone on this one. Good luck everyone. I'm off for a drink.
    Oh, I am in full agreement. And, I suspect that as the PIC uC's become more powerful, at some point RevEd will be able to provide inline while still restricting the programmer's access to their core firmware (as stated previously, once compromised, the PICAXE has no market protection from clones.) I can envision at least two ways that it could be done today without CPU partitioning if the hosting PIC had sufficient horsepower and more internal RAM.

    For example, in a super-PIC world, RevEd hypothetically could encrypt their firmware and download it every time with the user's code; that code being either PICAXE BASIC tokenized source or assembler with the appropriate support libraries in machine language. A digital certificate inside every PICAXE chip would decrypt the RevEd firmware. Such digital certificate would be installed on a write-once basis at the time the PIC was converted to a PICAXE and so labeled.

    Another way to pull off such magic would be to have RevEd create a virtual machine within their environment in the PIC. Assembly code from the user would be processed inside this environment and not actually muck with the real hardware without inspection from the VM. In this manner, RevEd could allow assembly but still control the entire process.

    Obviously, such hypothetical thinking would require engineering and technology not currently in place. Creating such an environment would provide RevEd with what new marketing capabilities? What new user communities would jump to consume such new designs? Ultimately, would such a venture generate a neutral or positive revenue stream?

    I suspect that deep inside some room with the door closed that RevEd is considering their next move... and the next... and... They seem to be a dynamic bunch, advancing their technology across new silicon as the Microchip uC mature and can be had in quantity. I am sure they look closely at threads on the forum about assembly, but I have read no compelling reason why such a capability would be required; in a hobby or educational market. Surely they are aware of the adhesion that Arduino has in the hobby, education, and even commercial markets. Surely they are watching the proliferation of ATmega chips and open software tools. If one can program a PICAXE one can program an Arduino; albeit the investment seems to favor the PICAXE at the moment, but the breath of shields seem to favor the Arduino (my opinion.)

    In conclusion, RevEd needs to make a statement to remain relevant outside the UK and the government supported school curriculum... Do they wish a hobby market or are they satisfied with their original charter for UK education? It just may be that RevEd is not completely in control of their own destiny... such things happens when business and government converge. While they certainly have NOT asked for my opinion, I think RevEd should develop an ATmel version of PICAXE with similar tools and the identical PICAXE BASIC command set. But since this is a new effort, why not go ahead and make a full compiler with inline assembly for the ATmel. One could even envision a tool to take existing Arduino library source code and convert it to (for lack of a word, I will invent one) "ATAXE" code. Now, students learning on the easy and well design PICAXE could have a wide-open road beyond the current 'limitations' of an interpreted BASIC.

    - Ray

  3. #53

    Default

    Angie: "Is that about right?"
    - yes.

  4. #54
    Technical Support
    Join Date
    Jan 1970
    Location
    UK
    Posts
    19,831

    Default

    Quote Originally Posted by SD70M View Post
    Microchip/pic/arduino uses C or C++ (among others) which is precompiled on a PC then that is loaded to the chip. This is harder to do and requires more hardware to link the PC to the chip programmer but, as the code is precompiled it works faster once on the chip.

    Is that about right?
    Yes.

    Raw micros are often programmed using assembly languages or C, the PC converts that into compiled code, which is then loaded onto the chip using specialised programming hardware.

    Some micros can also be pre-programmed to contain a bootloader which allows some sort of serial connection to be used to load compiled programs which can be cheaper and easier to use than the specialised programming hardware.

    The PICAXE contains a bootloader that allows a standard PC COM Port or a USB-to-RS232 style serial cable to program them, and also contains an interpreter which supports the PICAXE Basic language. This allows the PICAXE compilers to generate 'tokenised executable code' which is more compact than native assembler code but it needs to be interpreted so is generally slower than if it were executing compiled native assembler.

    Not all compilers are equal though; some will generate more optimised assembler code than others, some compiled code can be rather inefficient, and some may even compile code into something that is itself interpreted so the gains of compilation over interpreted are not always as great overall as may be expected. Having to make a choice between highest speed and smallest program memory use can also come into it.

    Where the PICAXE system scores is in the ease of use and speed of being able to achieve things, a programming language that is simple to use and an integrated programming environment that is fairly straight forward, backed-up by Rev-Ed and PICAXE community support. It is ideal for those the PICAXE is targeted at and many beyond that but a downside is that you may be constrained by what it allows. To get more one has to go to something else which may not be so well integrated or supported, or not so easy to set up, configure, use or learn.

    It's probably fair to say, once familiar and competent with any micro and its tools, that all can be used without being problematic. It's just getting there which varies, some are easier to get working with than others.

  5. #55

    Default

    Quote Originally Posted by westaust55 View Post
    But underlying the variable assignments and setting up the FOR...NEXT loop are typically many commands for each BASIC program command.
    Actually, I would have to challenge this.

    Certainly whilst there may be certain constructs both in assembler and, say, Basic, that are similar, the whole point of a high-level language is that it abstracts the actual language used from the hardware level.

    This can be demonstrated quite well on the PIC front. Write a program for a PICAXE 08M2 and you can run that code on a PICAXE 18X2, even if the firmware has to generate the function differently on each chip. Your Basic program remains the same, however.The only change you would make as a programmer is to tell the compiler for which chip to generate the code.

    Take this a step further with object oriented programming. There's no direct correlation between the hardware and any of the software logical constructs; the hardware turns into a black box. Because on the PIC front we directly control the hardware the boundaries are less blurred but I do feel that trying to compare a Basic For/Next loop with its assembler equivalent just encourages people to program down to the hardware level rather than program for the function you're trying to achieve.

    A high level language doesn't just simplify the programming, it allows logical constructs and thinking that the hardware has absolutely no knowledge of. That's the job of the compiler / interpreter.

  6. #56

    Default

    How does that "challenge" what Westy has said (in your quote)?

    And what you have said there is true but I think Womai already said much the same about 2million posts ago.
    Maybe I just dreamed it.... I seem to have seen all these points before.

    If Angie hasn't realised it yet we're starting to enter Fircle mode

    PS. Please don't answer my first question - the paragraph count is getting too high
    See you later.

  7. #57
    Senior Member
    Join Date
    Jan 2012
    Location
    United Kingdom
    Posts
    115

    Default

    @Everyone who answered me politely

    Thank you all for the various explanations etc. I am now clear on microchips and the routes to them.

    The PicAxe is a fantastic item and, as has been said, programming it is easy. At the moment it does do what I need but I am now armed with enough info if and when I need to move on to a faster processor. Having said that I am sure, as with the current upgrades to various PicAxe items, that the next PicAxe series will extend it's use even further and probably keep ahead of my learning curve and requirements

    Angie
    Not-So Newbie to PicAxe, definately not new to the world

  8. #58
    Senior Member
    Join Date
    Jan 1970
    Location
    Germany
    Posts
    1,318

    Default

    Actually a great detail is that the Picaxes are just normal Microchip PICs as far as hardware is concerned (maybe with the exception of the very latest M2 series, but even they are pretty close to standard PICs). That means if you really need more speed (or want to reduce the cost for series production) then take the corresponding PIC and program it in compiled C or Basic - it's guaranteed to work if the Picaxe works, since it's identical hardware. Great for rapid prototyping!

  9. #59

    Default

    From an educational point of view all that adding inline assembler would do would be to allow people to learn about PIC assembly. It will help very little if what you need is assembler for one of the multitude of other devices that are available. I'm not sure the PIC is a particularly good device for learning assembler principles in general because it's structure is quite a lot different to other chips (memory paging for example).

    I would stick to it's current strengths - a cheap, easy to use device with an IDE that's suited to rapid development. "Rapid" in an educational environment where you need to explain a new concept, demonstrate it and give the time for the students to practice in a 50 minute lesson makes development systems such as Agile and XP look slow and clumsy.

  10. #60

    Default

    Today I hoped to tie a picaxe to a neopixel. Sad to find that the picaxe is too slow by 3 orders of magnitude to do the job, because of the absence of inline assembler. Back to my Arduino/ATTiny for this job, wish their power management was anywhere near as good as picaxe...

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •