PIC -> ATMEL

I found this reprap the other day and thought this is a cool project, and so I wanted to make it, but as usual I want to use stuff I have and know. So the thread. I want to use ATEMLs uc (microcontroller) since they are the best ... (hehe). Anyways I downloaded the pic source code from svn and had a look to see how things are. And I just want to say when coding please, pretty, pretty please write comments, and not just comments but good comments.

1. write function description in the header files. so by scanning the header you can understand what it does.

2. write better comments. this is important people.

Anyways I searched the forums to see if someone wanted/asked/did this, apparently nothing.

So I was wondering if this is a option anybody wants or have been looking for. If not I just do this for my self and no fuss, if someone wants this then I might spend some more time and do it a little more professional and so on.

I am also thinking about looking in to doing something with this for my master theses.

ps. atmel just released a new uc I dont have this at hand right now, but XMEGA the new uc is promissing really versatile (just for example it even has a quadrature decoder).

so input people, hate it? love it?

Sverre Hamre.

the arduino is an atmega168 on a breakout board. its code should be easily adapted to any atmel you care to use

yo.

yeah, atmels are great! we've been doing alot of work on creating a system based on the Arduino (as triffid said above, its basically an atmega168)

anyway, check out the main wiki page about it: [make.rrrf.org]

we've even created a simple GCode parser for the Arduino which will allow you to use GCode on your reprap machine. i finished writing about 1/2 the code this weekend.

read up on it, download the code from sourceforge, and then come back with questions. i didnt write the PIC stuff, but i wrote most of the Arduino stuff. i love comments and i think you'll find my stuff much easier to read.

I see, I will read through it.

but I will use the atmel stk500, stk501 or hopfully the stk600 (XMEGA) if I can get it soon. And so use the atmel avr studio for debugging and winAVR (gnu gcc).

I have already ported most of the snap serial interface, hopefully i will finish it up today and test if it works. I will try to get most of the code on one uc as you have done, but still have the possibility to expand with more uc for extra hacks (hehe).

I can say that the reason I want to use atmel controllers is that I work part time for them, so I have some experience using them. and can get answers to questions from the source.

ps. I am a student not a professional, so don't assume I know too much about atmel uc.

hey sverre,

i would suggest porting from the Arduino stuff instead of the PIC stuff. i've fixed a bunch of bugs, and have dealt with the whole 'how do you emulate 4 snap devices on a single avr' problem.

plus, the code should be much easier to understand, as well as being written for the same architecture (not a big deal, but it certainly does help. also, the PIC stuff has lots and lots of hacks that are specific to PICS.

hey Zach.

tnx for the advice, the arduino code is much better yes, dont know to much c++ but that should not be a problem.

I must say the pic code seemed a bit buggy, or has strange ways of doing stuff, at lest for the SNAP.

Anyways I will continue my work and code along. I think this will be a nice project

thanks =)

to be honest, the v1 of the SNAP protocol is going to be obsolete on Arduinos soon. the GCode stuff fixes lots of problems (see: [blog.reprap.org]) and is just generally awesome.

i would suggest porting the gcode stuff. either will work, but you'll get better results and have more flexibility with gcode. also, its 95% procedural. there are a few OO remnants i need to remove (extruder code) and then it will all be 100% procedural and able to be distributed as a single arduino sketch.

however, looking to the future, perhaps if we made a v2 of the snap protocol to address the issue of buffering line segments, it would be great. now i'm just thinking out loud..

I see, but just a question you use .pde files for the gcode files, newer seen that before what language is that?

Anyways for the snap v2 protocol for supporting line segments it could be implemented as SNAP is supposed to, with number of data bytes not working like currently but like the standard states, thus using the user defined state 1111 (for the NDB(number of data bytes)) it could be set up to brake at new line and there you have it more or less.

This approach is better than current. reducing the overhead of creating snap packet, and passing it along. (not reducing the overhead, but reducing its implication.)

I guess only reason for this is to be able to have more than one controller, You are just using one with the arduinos and gcode right?

I have many ideas for usage of this project, and some of them the ability to have more than one controller working in parallel would be nice.

hey, .pde is the file suffix that the Arduino host saves its files as. Its all C code, with a tiny bit of C++ in there as well.

the SNAP protocol itself is solid. it works well, has low overhead, and is fast. plus, we already have lots of code written around it.

however, the problem with our current stuff based on SNAP is that we've outgrown the protocol we designed around it. sending individual line segments as they are needed is the wrong approach, and we need to implement a way to queue line segments.

i'm not quite at the point where i am able to work on the 2nd gen SNAP protocol, but i'd like to start it in the next month or so as soon as i finish this gcode stuff. most of the gcode work has been putting into place the ability of the software to support multiple output drivers... which will make it really easy to add SNAP v2 when desired.

What about if we let the arduino use a flash fob (Thumbdirve) as a larger cache. I understand that this could only be implemented in a 2 arduino setup, but you would be able to load immense amounts of g-code onto the thumbdrives

---

Jay

Hey I was just wondering, maybe I misunderstand then I am sorry but. the SNAP is just the protocol for transferring byte/data to the correct device right? so right now it just takes in one message and process that.

But the gcode right now don't use addressing, just fill up a buffer directly from the serial interface. when there is a newline it will be processed.

so I don't see that this is the same thing, SNAP is just a mens of transferring data. whilst the gcode is just processing that data.

so using gcode with SNAP should be no problem (maybe I misunderstand here), and thus changes needed to be done with current snap is fix the processlockbit (fill up a buffer, sett processlocbit when buffer is full, when newline command happens or what ever).I just think that having a standard like SNAP that includes error checking is nice to have.

jay: its alot easier to interface directly with an SD card instead. all we have to do is upgrade the processor and it will be no problem. the next time i take a crack at the electronics, i'll probably look at a beefier uC like an atmega32 or an atmega128 (or one of the ones with USB built in) however, the electronics work well now, so i'm going to let them be for probably 6-9 months.

sverre: its fuzzy. gcode is sort of a protocol, but is really just data and the microprocessor parses it as it gets it. snap is a protocol for transferring data.

there are a couple reasons for making a v2 of the SNAP protocol.

1. the GCode stuff still has a bit of latency, especially for lots of short line segments (ie: small circles, complex curves, etc) the reason for this latency is that it has to parse each gcode command, determine the feedrate, and then execute it. with predigested values, it would be much easier, faster, and smoother.

2. the arduino software controls the serial buffer size (128 bytes), and gcode seek commands are big (ascii, generally about 25 bytes = ~4 commands in queue) with our snap code, we implement our own internal buffer with ints and we'd be able to have much larger point queues (>16 points)

3. the arduino gcode firmware is doing all the processing and must know stuff about the steppers. (step size, steps/rev, etc.) this stuff should really be stored on the host, processed, and pre-digested values get sent to the Arduino. that way, nobody has to edit firmware at all... just upload and set configs in the host software.

dont get me wrong... i love the new gcode stuff, it serves a very important purpose, and i've contributed my share to it. however, there is still definitely much room for improvement in the system.



i think that having the SNAP standard is great... we just need a protocol that is robust enough to handle what we throw at it.

aaa finished implementing the SNAP on my atmega128, uses 2.2% of the uc so I Have a little extra space. now then to test if it works well, anybody made a python program or something for testing the snap interface?

Maybe I will make a test software to test different scenarios. and get some timing on transfer so that I can optimize.

an easy way to test teh SNAP stuff is to use the host software... fire up the stepper exerciser and it will tell you pretty quickly if it works or not.