PIC like Arduino

[cr0sh]

Hi, i second your point that we should take the positives out of the Arduinos popularity. Dumping the training wheels hasn't worked over here(our uni). About the open source bit, Amicus 18 does provide a schematic in its manual

https://www.electro-tech-online.com...cus1820Hardware20Manual20-20Revision201-1.pdf

the software's free as well.

Yes, but is it supported under Linux? Seems like it is only supported under Windows. Where's the OSX support? Free software isn't the same thing as open-source software, either. That's the main thing about the Arduino; it is open-source all-the-way (ok, maybe not the processor - but most people don't own their own fabs, either).

Something else to keep in mind is that the Arduino is very international in scope, and Linux support in that area is seen as a "needed thing" (it reminds me of the Amiga in that regard).

 

[cr0sh]

I understand that. I started one group of students with a flow code like product. They were unhappy to move to C. Thinking of it I do not know anyone here who has moved from flow code to C.

For some time I have been thinking of starting students with a subset of C with a few macros to reduce the visual complexity. I have never played with the arduino but expect that is what they have done.

Part of it is macros, but the bigger part of it (besides the bootloaders that everyone plays with - but the bootloader isn't required) is the vast interface library, which the build process uses to hide a bunch of the complexity from the end user. It supplies a ton of functions and other useful bits to hide the complexity of manipulating the ports and such to do anything useful (you don't have to use the library, though - but it is always compiled in when you use the Arduino's IDE - you'd have to modify the Java source of the IDE to change this - a lot of us on the Arduino forums hopes this changes, and that advanced users will be able to bypass or alter this behavior). On top of this base, other users have built other interface libraries (which if the library become very popular, it will get incorporated into the "standard" library base in a later release of the IDE) which help for various tasks and such.

I honestly don't have a problem with simplifying coding; if that was really such an issue, we would've never moved past the ENIAC's plugboards (ok, that's severe and untrue - but the fact is, this is the normal and historical progression of computing - plugboards to direct machine code to assemblers to compilers to object orientation to ???).

We should be doing everything possible to make programming a simpler task for humans, not a more complex task. The Arduino is one of these kinds of projects, making programming and hardware development accessible and easier to understand for non-programmers and non-hardware people. I think the project has done a very admirable job of this...

 

[3v0]

@cr0sh

The problem with an open-source PIC design is the compiler;

The PIC 16 and 32 bit both use gcc based compilers. I expect one could make the 16F and 18F work too in that microchip will or has ported these compilers to linux and mac. The days of microchip being a windows only development system are nearing an end with MPLAB X.

Atmel has nothing to do with the Arduino

I understand that. Even if they were willing to provide free arduinos I would end up buying atmel chips once the students left the arduino's behind.

I am not sure what the complaint is about bootloaders;

Even back in the days of the Z80 we had ROM monitors for debugging. With PICs you can get an ICD (in circuit debugger) for about $35. Debugging with run control and the ability to examine data without modifying the code and recompiling is faster and more transparent. Printf still works if it is all you have but is dated. I have no problem with people using and liking printf debugging. For teaching no.

I honestly don't have a problem with simplifying coding;

I think you have misunderstood my meaning here.

Assemblers, procedural compilers, and OO compilers each add a level of abstraction to the coding process. In theory this abstraction makes programming easier and more productive. I love it.

But embedded programming is about controlling the world. When you restrict the student programmer (person who is learning) to a fixed set of drivers his hands are tied. Embedded systems also tend to be real time which is somewhat complex in itself.

If you go with some simplified language like flowcode the complexity comes back to haunt you. Once you have enough skill to make the tricky bits work you are at the same complexity of understanding as a guy working in c.

When the student is transitioned to c prior to running into these complexities he is better able to deal with them.

Please do not take from this that I think c is the language to end all languages. I do think it is the right tool for the job in this case.

 

[Wond3rboy]

Part of it is macros, but the bigger part of it (besides the bootloaders that everyone plays with - but the bootloader isn't required) is the vast interface library, which the build process uses to hide a bunch of the complexity from the end user. It supplies a ton of functions and other useful bits to hide the complexity of manipulating the ports and such to do anything useful (you don't have to use the library, though - but it is always compiled in when you use the Arduino's IDE - you'd have to modify the Java source of the IDE to change this - a lot of us on the Arduino forums hopes this changes, and that advanced users will be able to bypass or alter this behavior). On top of this base, other users have built other interface libraries (which if the library become very popular, it will get incorporated into the "standard" library base in a later release of the IDE) which help for various tasks and such.

I honestly don't have a problem with simplifying coding; if that was really such an issue, we would've never moved past the ENIAC's plugboards (ok, that's severe and untrue - but the fact is, this is the normal and historical progression of computing - plugboards to direct machine code to assemblers to compilers to object orientation to ???).

We should be doing everything possible to make programming a simpler task for humans, not a more complex task. The Arduino is one of these kinds of projects, making programming and hardware development accessible and easier to understand for non-programmers and non-hardware people. I think the project has done a very admirable job of this...

I will try to add what 3v0 just said. I am an ardent supporter of not tyring to reinvent the wheel. Using libraries are really good for students in the sense that they can get things done, but the question is about utilization of resources as a professional. I am all up for the Arduino for playing with stuff, but when you are working for a company, they wouldn't let you spend say 34.99$(for the Arduino UNO) which can be done with a single chip(Atmel or MC or anyone else... doesn't matter) and some hardware, most of them have manufacturing houses anyways so it doesn't make sense either. Also, from a students point of view, if something goes wrong they should be able to deal with it and not show the slackiness that i described in my previous post.


Edit: About the debugging part, i have seen students doing custom debugging by using serial transmission, bet it would make the code a lot more complex and difficult to navigate.

 

[3v0]

About the debugging part, i have seen students doing custom debugging by using serial transmission, bet it would make the code a lot more complex and difficult to navigate.

Printf or serial port debugging can quite complex.

There are several major drawbacks.

• The program has to be edited and compiled more frequently.
• The resulting HEX file is larger.
• The program with and without it are similar but not identical.
• The debug code can introduce errors.
• It slows down the program when it is active.
• The chances for finding a timing related error are small.

Having said that serial port debugging can be very helpful, but a in circuit debugger gives you the same approximate functionality without the drawbacks.