Is firmware realy neccesary, the merits of firmware free hardware.

OK

I am entirely fed up with repeatedly discussing doing away with firmware in favor of host based software control and drivers. Especially within a thread initiated to discuss enhancing the firmware (Adding to it)

If this is what you want (And it's not for me to say that it is'nt a perfectly viable route) here is the thread especially for you.

Or maybe you disagree.

aka47

---

Necessity hopefully becomes the absentee parent of successfully invented children.

Unless you can guarantee some realtime behavior on the host; some amount of firmware will be needed, either implemented as hardware (hardware PID, for example), or software.

After I spent time evaluating current reprap firmware, I tossed it out entirely, and am writing it from scratch for my RepolaRap bootstrap project.

I prefer nice clean interfaces and classes; done properly, performance doesn't suffer. My spline stepper, for example, uses 500 bytes of C++ programming code, 20 bytes of RAM per instance, and each spline step executes in ~16 microseconds; if I were to rewrite the method in assembly, I believe I can get that down to 200 bytes of programming code, and ~5 microseconds per step method invocation, but until I exceed 8K and 100 microseconds per main loop iteration, I'm not going to worry about it.

Where I believe the question of what belongs in firmware lives at the level of protocol / parser. My current plans stop at a very simplified protocol, since I'm effectively writing this myself, and I'd rather spend time getting the hardware working that implementing fancy firmware. I still consider adding a full turing complete language as 'protocol' a desirable feature as well, just one I won't get to for a while.

You can't use a language as a protocol, just the top layer of it. You always need an integrity check and a timeout / retry mechanism at the transport layer.

I once designed a dot matrix plasma display controller that processed packets of Forth compiled to byte code. That meant rather than having a Forth compiler in the controller it just had the inner interpreter and the primitives. I implemented stack based raster operations and it all worked very well doing complex animations over a 19.2Kb serial link.

I can't see how this application warrants that sort of complexity though. HydraRaptor only has 4 commands, one of which forwards to the extruder controller which has 12 commands. My firmware is tiny because all it does is real time control of the motors and heater from binary packets. All the rest is on the host in Python where it is much easier to modify and debug. Adding the ability to do splines would probably only need one more command.

Having a Turing complete command language is neat but I think it is much more important to keep things small, simple and efficient. The skill level to write decent realtime embedded firmware is much higher than that required to hack on a bit of Python so I think it is better to keep the firmware as small as possible.

Using Python on the host has all the advantages of Forth, i.e. flexibility and interactiveness, but is much easier to write and more accessible.

So the answer to questions is firmware necessary is yes, but only enough to do the low level real time control, no more.

---

[www.hydraraptor.blogspot.com]

It's interesting mentioning the need for determinism in hardware control.

This is exactly one of the key issues that has caused problems for the EMC2 project.

I think their solution thus far has been to implement their environment using the Real Time Linux Kernel. (RT Linux)

Even so I think it often struggles to do too many things at once all competing for the "now" that hardware control insists upon.

It would certainly struggle with running much in the way of PID and servo loop control unless as Nophead suggests it was offloaded to a subsystem.

Now on subsystems, do we actually need firmware at all......

Here is the rub.

Programmable logic is not considered to be firmware, and offers full concurrency for sub parts of the subsystem that it uses.

PID, Microstepper and Servo Loop can be implemented solely as programmable logic (a bunch of CPLD's and or an FPGA) that are then in turn driven from a Host where determinism then becomes less of an issue.

Bringing us back to the question is firmware really necessary.

I agree there needs to be something beyond simple dumb electronics. Whether that is Microcontroler and Firmware or not though is worth the discussion.

---

Necessity hopefully becomes the absentee parent of successfully invented children.

> You can't use a language as a protocol, just the top layer of it.

Well, sort of. The 'protocol' would be ASCII characters transmitted over USB/Serial, with 'packet' separators consisting of a set of whitespace characters. Each packet would correspond with a particular forth word, and would execute the logic for that particular word upon reciept which can also consume subsequent 'packets' instead of interpreting them in some scenarios.

I label it 'protocol' with quotes because of the fuzzy nature of the concept; It lives at the same layer as GCode. Call it the level 3 protocol, if you prefer, where level 2 is the usb/serial characteristics for sending octets, and level 1 is the usb/serial hardware description.

And for the most part, I agree that one does not need turing completeness for board interaction once you have a static and working printer, connecting to a static and working host driver (or flash card transfer, etc.). The feature would more likely find use from a development perspective, where you've just plugged in some new wires into your firmware motherboard, and want to test it, or want to try out competing algorithms, quick and dirty. Certainly, you could go plug in your laptop, launch vi, compile, link, download test, edit, compile link, download, test, repeat 10 or 20 times (effectively, what I've been forced to do as I don't have the quick and dirty forth environment I'd really prefer when testing out my prototyping ideas... I imagine I'd spend about 1/3 the time messing with software with that kind of model to the point where I had confidence in my hardware or algorithm working correctly, at which point, I could make a design decision to change firmware if the forth compiled code lacked the performance needed.)

FPGA route sounds interesting- try it and tell us how you went I can see them being most excellent at very tight signal timing, but simply don't have enough experience with them to have the slightest idea of how well they'd handle a serial command stream affecting that timing.

Remember, you need enough abstraction that the host no longer needs deterministic timing, so I think a machine-specific translation of the gcode like nophead uses is the closest you can safely get to processing everything on the host.

In my firmware, each move in the buffer takes 69 bytes of ram, so the gcode command actually takes less space than the internal binary representation of it. setup cost is still significant though, and could be greatly reduced by some preprocessing on the host- but that's not the project I've taken on.

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware

Triffid_Hunter Wrote:
> In my firmware, each move in the buffer takes 69
> bytes of ram, so the gcode command actually takes
> less space than the internal binary representation
> of it. setup cost is still significant though, and
> could be greatly reduced by some preprocessing on
> the host- but that's not the project I've taken
> on.

That beats my own code estimates.

In my case, the 'active' move command will consume about 150 bytes.
I'm thinking an 8 spline buffer at 100 bytes per segment, so another 800 bytes.
And an input buffer of 50 bytes (After I tweak my protocol to allow sending each controller cubic step spline as a separate line rather than all of them at once.)

So.. hmm.. 1000 bytes exactly. Cool. Funny how everything adds up so fast.

For code, so far, the step spline is 508 bytes; I've not written comms, temp PID, or step driver, but I imagine those will come in at around 4K-7K or so. That's all I need, I believe? (Seems awfully small.. I must be missing something..)

@BeagleFury,
Yes you should be able to rely on the transport layer in USB, but in practice I have found it can't be relied on. It has poor noise immunity and poor realtime performance (just look at the MakerBot forums and see the issues they have with an unsuppressed DC motor and US. It would also seem that PC implementations have bugs in them, not surprising as it is a ridiculously complicated protocol. That is why I avoided it for HydraRaptor and use Ethernet, which is a lot simpler and I have found it a lot more reliable than USB on other projects. It is also electrically isolated, which is a good thing.

I actually use Forth at work on a daily basis and have implemented it on several processors and platforms. My firmware is so small though, and the tools I use are such that compile and download is one button and a few seconds, so just as fast as trying things in Forth. All my trial and error stuff is done in Python on the host. When I change the hardware, like DC motor to stepper, the firmware changes but otherwise it stays the same.

@AKA47,
Yes we could do it all in VHDL on a FPGA. Again, I design with FPGA's at work but it is much harder than writing firmware and I see no benefits in this application. By the time you get to implementing things like serial protocols it is easier and more gate efficient to create a little cpu on the FPGA and program that. It just makes it more complicated and inaccessible to people. Are there actually any OS synthesis tools?

---

[www.hydraraptor.blogspot.com]

I could be entirely wrong about this but I seem to have read somewhere that there is a soft virtual forth processor and of course forth for the soft processor.

Certainly going with something like Open Cores is an option even if you need to lodge your designs with them to make sure it gets wider uptake.

Programmable logic designs do have the added advantage that you are not tied to individual silicone vendors and can port your processor, firmware and programmed IO to another gate array vendor if one of them goes belly up for some reason.

Certainly from HDL upwards (soft processor & IO, microcode, machine code, firmware etc) the design stays exactly the same.....

Other than forth (which benefits from being considered as running on a virtual processor, much like Java) I don;t know of any.

That is'nt to say that they don't exist though.

aka47

---

Necessity hopefully becomes the absentee parent of successfully invented children.

nophead Wrote:
-------------------------------------------------------
> @BeagleFury,
> Yes you should be able to rely on the transport
> layer in USB, but in practice I have found it
> can't be relied on. It has poor noise immunity and
> poor realtime performance (just look at the
> MakerBot forums and see the issues they have with
> an unsuppressed DC motor and US.

I couldn't find anything online very quickly, but I wrote a test to confirm. The out of box serial at 115K appears to drop bytes, and the serial line to/from UNIX is very chunky, at least, with the simple unistd.h open/read/write calls I performed.

My test consisted of a simple echo engine:
1. Firmware checks for available bytes
2. if bytes available,
2.A. read a character.
2.B. If {cr}, send buffer contents back to server, and clear buffer.
2.C. Otherwise, add character to buffer content (up to 50 characters, ignore anything beyond that).

I wrote a simple unix C++ program, using unistd.h open/read/write.
I sent blocks of data 16 bytes long.

Results for this testing:

115200 baud
1. system queues up 1425 bytes into write stream before first response returned.
1.A. Pretty sure this unix buffering primary cause; board/firmware latency should not give numbers this large.
2. Read side loses data; of 149970 bytes written, only 102176 make it thru.
2.A. Probably no or inadequate XON/XOFF processing in firmware; data appears to be dropped in blocks.
2.B With such a huge buffers on the host, it could get tricky trying to do any kind of efficient round trip throttling and/or control.

I reduced the baud rate to see how that affected the test:

38400 baud
1. still pretty chunky on send blocks. 735 bytes written before first byte recieved.
2. Data still dropped, but more made it thru: 147252 bytes returned (2K lost)

I reduced it further:
9600 baud
1. 736 bytes written before first byte recieved.
2. No data appeared to be dropped, but recieved data did not appear correct in every case?

Yuck.

Thanks for the heads up. Time to see how others solve this problem. Have any links to the makerbot discussions you mentioned?

I have a serial and ringbuffer library in my firmware that works beautifully. I haven't tried it at 115200 baud, but it doesn't drop anything at 57600 unless the loop reading the buffer chokes and the buffer overflows, or you dump too much stuff into the send buffer from interrupt context.

also, have a play with open() options like O_DIRECT and O_NONBLOCK and note that read() and write() don't buffer, but printf does. All functions that take a FILE* rather than an integer file id do buffering on top of any vfs stuff, so sprintf() to a buffer then write() instead of using printf(). when reading data back, you can't read a line until a \n appears, so read one char at a time and pick out your own lines.

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware

Triffid_Hunter Wrote:
-------------------------------------------------------
> I have a serial and ringbuffer library in my
> firmware that works beautifully. I haven't tried
> it at 115200 baud, but it doesn't drop anything at
> 57600 unless the loop reading the buffer chokes
> and the buffer overflows, or you dump too much
> stuff into the send buffer from interrupt
> context.
>
> also, have a play with open() options like
> O_DIRECT and O_NONBLOCK and note that read() and
> write() don't buffer

They don't buffer at the application level, but will frequently buffer at the kernel level (streams or device driver, etc.). It appears O_DIRECT may circumvent that.

I used O_NONBLOCK in my testing. I did not use O_DIRECT.

Quote
aka47
Now on subsystems, do we actually need firmware at all......

Firmware is much easier to replicate, than using FPGA or CPLD type logic. Some level of firmware is necessary.

Given that this is the firmware sub-forum. I would expect the argument to be for some level of firmware. If nothing else it would be needed to process the messages between the controller sub assemblies, Especially if multiple head or tool-types are required.


As for comms, most of my experience has been with MIDI note or the indirect task of optically reading player piano rolls.

This actually relates as my optical roll scanner is based on the same Atmel ATmega88 used in the Arduino. As I wanted to transfer the data quickly The solution was to use the FT245 parallel chip. The scan array is clocked at 1Mhz so there is not a lot of time to read the comparator and shift the bits for return to the host. The line of data packs into about 800 bytes.

The USB I/O is handled with the same sort of ring buffer used on the serial chips, There is not a lot of data coming in from the host, Mostly a request for the next line of data. There are options to scan a line and step or just scan a line. A few other options return some of the chip states.

To attempt to stay somewhat on topic. I do not think it is relevant if the comms between devices are parallel, async serial (RS232/US, or sync serial (like I2C.)

I2C was designed for comms inside of Televisions. It is a protocol which will be with us for a long time, as there are 100s of millions, if not billions of implementations. So even simple devices like TVs need some sort of firmware. If nothing else to decode the remote control for changing the channel.

Perhaps, what needs to be considered, is the difference between something that can be coded as a state machine compared against more complicated logic which requires more processing decisions.

Most user interface, can be programed as a state machine. Press a button change a state. Simple state machines can be implemented with pure logic.

This week I have been upgrading a 20 year old desktop CNC machine, I have owned for at least 15 years. The successful goal was to make it run under Mach 3. I had to replace the fans on the motor controller, while it was apart I traced out the interface to the parallel port.

No Google search returned any hits on the manufacture of this board. A search on the chips used indicated the design was standard and compatible with the latest low cost software. While these chips went end of life about a year and a half ago, the replacements are pretty much the same with more features (like micro-stepping.) The current reprap electronics use the replacement chip.

The CNC is an example of a system that requires no firmware, yet the newer systems do add that option. There is a hidden cost to this simplicity. With the exeption of EMC which requires linux, the low end software has been created and sold and controlled by a few individuals who were clever enough to create stable time-bases inside of the Windows kernel. They are also clever enough to give this part of the system away and sell the ability to run larger data sets.

So firmware free hardware, is not really free. I spent hours this evening looking for a way to build a discreet H-Bridge, capable or running the 3V 4 amp steppers on my CNC that I plan to use as a repstrap. I found a design I liked, but the implementer did not post a distribution package. There were lots of promises of boards and kits for sale, but stale dates and market fluff does not a practical solution make.

What I think we are missing here is that Arduino is something new. A way to distribute firmware in a self replicating way, where anyone who can write a perl script, can blink LEDs or read a temperature sensor. Controlling a stepper motor, then becomes second nature.

I have been working with Atmel AVR micro's for close to 10 years now. What impressed me, was that the early versions could be programmed by bit-banging a PC parallel port, and connecting the program lines to the port with wires bent from a paperclip. This made these processors popular in the developing tech centers of eastern Europe and India.

All that is needed with something like the Arduino concept, is the initial loader. Enough to get the chip, to take on what is needed to expand.

-julie

@BeagleFury,
I don't have any specific links but when I used to follow the RSS feed from the MakerBot Google groups many people had lots of pauses and hangs that spoilt the build. It seemed to be a mixture of noise affecting the USB cable and crappy FDTI USB drivers at the PC end.

When I use USB I don't use the serial port emulation idea. I write my own driver on the PC end using libusb and send packets to my device, rather than a stream. Stream based comms is not good for real time control. When I use Ethernet I use UDP to send packets for commands rather than TCP. Although TCP has guaranteed delivery that is good for transferring files, it suffers from delays due to buffering, etc.

So I use UDP with sequence numbers, timeouts and retries for Ethernet. With USB packet level comms I should not need that, but I have found when using WINXP embedded some packets go missing, very rarely, but once would be a spoilt build, so I would advise a protocol on top.

---

[www.hydraraptor.blogspot.com]

- creating new message topic

Edited 2 time(s). Last edit at 02/04/2010 11:21AM by BeagleFury.

On firmware free.

I personally am fully signed up to the super enhanced firmware model. Indeed it is perhaps debatable that this is likely to be the route that is most likely to find success for the Humanitarian Prize, for no other reason that it states quite clearly printing without host.

That said I can recognize that there are those for whom a reduced firmware, host based model is desirable. Whilst I will do what interests me, I fail to see why I should do it in a way that blocks or excludes others from doing their thing.

Extending this further in response to comments from Sebastien about engaging other communities ie EMC2. It is possible to create a mechanism/machine that has no firmware. Consider that from an EMC point of view it wants/needs to see machinery with a fairly simple interface. In most cases bit bang controlled from a host parallel printer port (even these are dwindling as legacy interfaces)

The stepper interfacing that is currently done using step/dir is pretty close to being ready to go from an EMC2 perspective. EMC2 has inbuilt ladder logic and PLC style capabilities so standard digital IO is easy as well. What is needed is a way to control heating (most PC's don't have analogue capabilities). This can be done with hardware based closed loop control. (When I studied industrial electronics back in the 70/80s that was the only way available) or even as a logical process using simple CPLD's. The route is'nt important. Only that it is doable.

Rather like from EMC2 or a CNC controller you would request a spindle speed of X through the frequency or pulse width of a digital signal, you would do the same for the temperature you wanted to request. Then pause an appropriate time for your command to have made to become fact.

In the same way that driving steppers is commanded but the controller has no real way of knowing if it has actually happened or not. You just wait a bit and assume it has.

In the same way that driving the spindle speed on a CNC milling machine from EMC2 you command it and wait a bit and assume it has done what you commanded.

As a person who is Pro Servo Motor in preference to Steppers. I am an acknowledged control freak. I like my technology to do as I ask and I like to know when it has achieved it.

If it is sufficient to command and wait with stepper technology in a RepRap Machine it is similarly sufficient to command and wait with heating technology.

The machine there fore is eminently do-able firmware free.

Writing firmware has a cost that is a hidden cost and it is expensive, this is an argument used in the other thread.

The endgame in firmware reduction is a firmware free machine with everything directed through software control on the host.

The endgame in firmware enhancment is a firmware rich machine that can be liberated from it's host.

For the poor of the industrialised nations where power and host's are plentiful and cheep (particularly if they are reused legacy kit) Firmware free is as good as it can get in terms of cost reduction when designing and building the machinery that we are doing.

For the poor of the non industrialized nations where power is a liability and hosts are expensive to keep (arguably a community item as opposed to personal)
Firmware rich and standalone is as good as it can get in terms of cost reduction when designing and building the machinery that we are doing.

Over all then the firmware rich model can also be used in the industrialized world. Whereas the firmware free can not be used in the non industrialized world.

I think on that argument alone Firmware Rich has it.

Anything anywhere in between then is simply personal preference. On personal preference you can't expect folk to let you have yours if you cannot live with them having theirs......

---

Necessity hopefully becomes the absentee parent of successfully invented children.

aka47 Wrote:
-------------------------------------------------------
> Humanitarian Prize, for no other reason that it
> states quite clearly printing without host.

I suspect a cheap flash card reader/writer should suffice for host free printing. I do not believe anything in the rules specifies that a host cannot be part of any part of the system.

As nophead indicated, send all the GCode commands to a flash card device, plug that into an autonomous printer that replaces serial IO comms and reads flash as if it had been sent over serial.

I am unsure how the rules would consider a host used to write flash cards, since it could be amortized over many many printers (On computer could write 1000+ flash cards, so technically, you could divide the cost of the computer by 1000+ on a per printer cost.)

It also states volume of printed components.

If your host is part of your print machine. IE it can't print without it. You may struggle to get the required volumes.


Flash cards are fine. SD/MMC is going to be about the best. High Capacity, low cost and has a SPI interface available on card. Easy Peasy. With Firmware.

Quite difficult without.

aka47

---

Necessity hopefully becomes the absentee parent of successfully invented children.

aka47 Wrote:
> If your host is part of your print machine. IE it
> can't print without it. You may struggle to get
> the required volumes.

Under this setup, just amortize one host across the print volume of 1000 printers. Again, the host is not a part of the printer, it is a tool to create the flash cards used by the printer. For the prize, the printer would have no serial comms at all, let alone the firmware to communicate with a host.

aka47;

So what you are proposing is to run something equivalent to EMC2 as the firmware?

Would this be expected to run on the currently popular cheap Arduino concept of hardware?

Or would you expect something like an AVR32 or Arm7 32 bit processor to be the next step in the evolution of the Arduino concept?

aka47 Wrote:
-------------------------------------------------------
> Flash cards are fine. SD/MMC is going to be about
> the best. High Capacity, low cost and has a SPI
> interface available on card. Easy Peasy. With
> Firmware.

just be aware that the SD spec states that SPI mode is optional for micro-sd, so may not be as future-proof as we'd like

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware

Yup noticed that.

I have a hand full of 2GB micro SD's here to hook up and play with in readynes.

And a SD to Micro SD adapter with pin strip bodged on as a connector.

In all reality I think they will be keeping it for a bit. If you access the card as SPI you don't have to pay licensing for the SD interface.

I have a vague suspicion that a no unsubstantial number of manufacturers may have gone the SPI route. The first vendor to drop SPI looses market share.

Will they risk it under the current levels of competition in the market, I don't know. But it is a good incentive not to try.

aka47

---

Necessity hopefully becomes the absentee parent of successfully invented children.

Interestingly enough, on the subject of one machine being able to program another's firmware.

The version 18 arduino IDE now has the AVRISP code to use an Arduino as an ISP for another Arduino, in the examples section. Along with some multi serial stuff for the Mega.

How good is that.....

---

Necessity hopefully becomes the absentee parent of successfully invented children.

I'd like to remind you all that traditional baud rates 9600/19200/57600/115200 are NOT optimal for an arduino, and require extra code in the core libraries to handle it.

If you have a look at the arduinoscope/macduinoscope project by gabebear ( see [gabuku.com] ) he says he is able to get up to ~1.6Mbit throughput streaming data from the arduino through the USB to the host with just 0.05% data loss or less ).


// intially set the speed to 1Mbaud and then double it to 2Mbaud with U2X mode
Serial.begin(1000000);
UCSR0A |= 2;


Buzz.

Just tried my setup with 1MBaud and I drop a few characters, only about 1 in 200 but still far too many for reliable comms. The FTDI driver won't use 250k and I think 500k is still to high. 230.4k has too much error, so I think I'll stick with 115.2k

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware

BeagleFury,

----------------
At 115200 baud
1. system queues up 1425 bytes into write stream before first response returned.
1.A. Pretty sure this unix buffering primary cause; board/firmware latency should not give numbers this large.
2. Read side loses data; of 149970 bytes written, only 102176 make it thru.
2.A. Probably no or inadequate XON/XOFF processing in firmware; data appears to be dropped in blocks.
2.B With such a huge buffers on the host, it could get tricky trying to do any kind of efficient round trip throttling and/or control.
------------

that behavior is completely logical and is due to the tty logic on the USB serial; you can avoid this by using:

-----------
serial_fh = open(device, O_RDWR | O_NONBLOCK, 0);
if (serial_fh == -1) {
fprintf(stderr, "Can't open serial device `%s`\n", device);
return errno;
}
flags = fcntl(serial_fh, F_GETFL);

tcgetattr(serial_fh, &serial_ios);
cfsetspeed(&serial_ios, baud);
cfmakeraw(&serial_ios);

serial_ios.c_cflag &= ~(CSIZE | PAREN;
serial_ios.c_cflag |= CS8;
serial_ios.c_cflag |= CLOCAL;
serial_ios.c_iflag &= ~(ISTRIP | ICRNL);
serial_ios.c_oflag &= ~OPOST;
serial_ios.c_lflag &= ~(ICANON | ISIG | IEXTEN | ECHO);
serial_ios.c_cc[VMIN] = 1;
serial_ios.c_cc[VTIME] = 0;
tcsetattr(serial_fh, TCSANOW, &serial_ios);
-----------

The c_cc[VMIN] specifies the minimum bytes that should be present before sending and the c_cc[VTIME] specifies the timeout before sending it anyway. The rest sets up for 8N1 and other goodies like no byte translations, no echo etc.

With regards,
Reinoud