Monday, July 10, 2006
Interrupt-driven serial comms no real challenge
When I finally sat down and started writing code it took about five minutes to write a test program for interrupt-driven serial comms for the 16F628A and test it on the simulator. It took another five minutes to program an actual chip, stick it in the test board and make sure that it could do a "hello world" echo. That was a lot faster development cycle than I expected last Friday.
That's the last piece in the puzzle for producing a control board for the Frankenmotors. Further progress now depends on receiving the relevant chips and actually putting one together and testing it. According to Randy that should be tomorrow or Wednesday at the latest.
I think I've now got quite a decent development suite for firmware. I program in BASIC with an integrated development environment and PIC chip simulator from Oshonsoft. Oshonsoft is run by a physics professor who lives in a little village outside of Belgrade. He charges US$67 for an individual license. That's about 25% of the price of most other entry-level commercial, high-level language compilers. It works well.
One bit of supporting evidence that the Oshonsoft BASIC compiler is worthwhile came in at the pic_sim_ide users group at Yahoo a few days ago. Somebody has taken the trouble to write a crack that gets software pirates past its license requirement. From my experience having a crack for your app appear in the peer-to-peer filesharing world is as good as a certificate of merit. :-)
After a lot of stress and strain with my home-built JDM programmer, which I estimate cost me about US$20 in parts and maybe US$5,000 in distress at the end, I finally settled on a MELabs USB programmer. Their USB programmer bundled with a 40 pin ZIF socket and software cost about US$115. It's a very "smart" PIC programmer built around a PIC18F chip. Smart is what I need. It very forgiving of my clumsiness and foibles. For example, I get a nice error message if I get the PIC chip in backwards. I once also accidently put a SN754410 chip in the thing and it politely told me that it definitely wasn't a PIC chip. I need that sort of backup.
While I understand completely the desire and need for using open source software and technology for RepRap in the longer run, I think that if you want to get a lot of eyes and hands on firmware development this is a fairly decent route to take.
As I said some time ago I expect that for every potential developer out there who is useful in the C language there are probably several hundred who can tinker in BASIC who might find firmware development for as focussed a piece of technology as RepRap a lot of fun. :-)
That's the last piece in the puzzle for producing a control board for the Frankenmotors. Further progress now depends on receiving the relevant chips and actually putting one together and testing it. According to Randy that should be tomorrow or Wednesday at the latest.
I think I've now got quite a decent development suite for firmware. I program in BASIC with an integrated development environment and PIC chip simulator from Oshonsoft. Oshonsoft is run by a physics professor who lives in a little village outside of Belgrade. He charges US$67 for an individual license. That's about 25% of the price of most other entry-level commercial, high-level language compilers. It works well.
One bit of supporting evidence that the Oshonsoft BASIC compiler is worthwhile came in at the pic_sim_ide users group at Yahoo a few days ago. Somebody has taken the trouble to write a crack that gets software pirates past its license requirement. From my experience having a crack for your app appear in the peer-to-peer filesharing world is as good as a certificate of merit. :-)
After a lot of stress and strain with my home-built JDM programmer, which I estimate cost me about US$20 in parts and maybe US$5,000 in distress at the end, I finally settled on a MELabs USB programmer. Their USB programmer bundled with a 40 pin ZIF socket and software cost about US$115. It's a very "smart" PIC programmer built around a PIC18F chip. Smart is what I need. It very forgiving of my clumsiness and foibles. For example, I get a nice error message if I get the PIC chip in backwards. I once also accidently put a SN754410 chip in the thing and it politely told me that it definitely wasn't a PIC chip. I need that sort of backup.
While I understand completely the desire and need for using open source software and technology for RepRap in the longer run, I think that if you want to get a lot of eyes and hands on firmware development this is a fairly decent route to take.
As I said some time ago I expect that for every potential developer out there who is useful in the C language there are probably several hundred who can tinker in BASIC who might find firmware development for as focussed a piece of technology as RepRap a lot of fun. :-)
Comments:
<< Home
** As I said some time ago I expect that for every potential developer out there who is useful in the C language there are probably several hundred who can tinker in BASIC who might find firmware development for as focussed a piece of technology as RepRap a lot of fun. :-) **
On the other hand, I've encountered several people who had to use a microcontroller BASIC to run a competition robot (because the use of the provided controller was required for participation in the competition); I've even looked at the associated code. It ended up looking like assembler with a thin veneer of basic on top; mostly because that's what it was. There were two people on our team who had a hope of comprehending it and even they had issues with glitchy behavior. For the 2004 competition, they finally swapped over to C; suddenly, things like people being able to exchange code and have it work happened. I remember one call for, I think it was a "sqrt" function implementation that a team needed, at the competition; they got it, too.
Essentially, what I'm saying is, I've seen the BASIC route go unpleasantly, and lock people out of tinkering a lot more than it brought people in, especially if it got the least bit sophistocated. C started out with the goal of being easier to deal with than assembler, without losing the low-level access and also making it easier to move code across platforms; it's pretty good at it.
Just my opinion on the subject, -JonoRED.
(now, if maybe on the third try the system will accept my interpretation of it's silly mangled-words-in-image bit...)
On the other hand, I've encountered several people who had to use a microcontroller BASIC to run a competition robot (because the use of the provided controller was required for participation in the competition); I've even looked at the associated code. It ended up looking like assembler with a thin veneer of basic on top; mostly because that's what it was. There were two people on our team who had a hope of comprehending it and even they had issues with glitchy behavior. For the 2004 competition, they finally swapped over to C; suddenly, things like people being able to exchange code and have it work happened. I remember one call for, I think it was a "sqrt" function implementation that a team needed, at the competition; they got it, too.
Essentially, what I'm saying is, I've seen the BASIC route go unpleasantly, and lock people out of tinkering a lot more than it brought people in, especially if it got the least bit sophistocated. C started out with the goal of being easier to deal with than assembler, without losing the low-level access and also making it easier to move code across platforms; it's pretty good at it.
Just my opinion on the subject, -JonoRED.
(now, if maybe on the third try the system will accept my interpretation of it's silly mangled-words-in-image bit...)
***It ended up looking like assembler with a thin veneer of basic on top; mostly because that's what it was.***
I looked at a LOT of compilers before I decided to try the Oshonsoft BASIC. I've seen a lot of the veneer phenomena that you refer to and I hate it, too.
So far I haven't had to do any assembler code inserts. Mind, the compiler allows for them but I haven't needed them yet.
I looked at a LOT of compilers before I decided to try the Oshonsoft BASIC. I've seen a lot of the veneer phenomena that you refer to and I hate it, too.
So far I haven't had to do any assembler code inserts. Mind, the compiler allows for them but I haven't needed them yet.
I can see Jonored's point but for me, since I learned BASIC and machine code first and C much later I definitely fall into plaasjaapie's catagory of happy tinkerer. As soon as winter rolls around and I have the time to tinker, that is.
Super awesome progress you folks are making, by-the-way. I am totally impressed.
Post a Comment
Super awesome progress you folks are making, by-the-way. I am totally impressed.
<< Home
