Hi,
I have written some gcc-port of the (old open-source version) firmware, more later when the spam-detection system has relaxed a little bit.
Cheers,
Claus
Hi Claus,
I assume youāre talking about the SSC32? What processor(s)? Iād like to see how you handled the very tight ISR code!
Yes, keep us advised, Iād like to hear more!
Alan KM6VV
Yes, about the SSC-32 (this is the SSC-32 forum). I was a little bit short because the anti-spam features of the Lynx forums somehow prevented me from writing anything more useful. Guess from tomorrow on that will be relaxed.
About the processor: I was talking about the open-source firmware, and this is still for the Atmega8. I have ported the boot-loader to the Atmega168, though. It was a little bit of a challenge to keep it smaller than 256 bytes.
If Lynxmotion decides to release the source-code for the new firmware for the Atmega168 Iāll probably try to āportā that as well to the GNU compiler chain.
I am not permitted to post URLs until tomorrow; Iāll post download links for my stuff when my anti-spam ban-time is over.
Cheers,
Claus
HI Claus,
Yeah, the āwait timeā for the spam filter can be puzzling at first, but itās useful. Tomorrow you should be good.
True, itās still for the ATMega8. Many are waiting for the new '168 version, as am I.
I started to port the boot loader over to '168, but had to get on with other projects first. I could use it!
Cheers!
Alan KM6VV
The mega 8 firmware (1.06XE / 1.1gbeta) are done, put a fork in them. 
We are not posting the latest versions of them because some really twisted code was required to make the GP firmware work. The 1.06XE is solid and we are not aware of any issues with it. We are no longer supporting these old firmwares. The mega168 bootloader and both firmwares, normal and GP will be posted on the website soon. The versions are as follows.
2.01XE -> Works like 1.06XEand has register support.
2.00GP -> General Purpose firmware with EEPROM sequence storage and sequencer engine āplayersā and register support.
Register support means you can store the servo offset, min and max limit positions, etc.
I was hoping to get some major documentation done for this over the break, but sigh, I was not sucessfull.
Very soon we will be adding the source code for these new firmwares, along with the documantation, and the preprogrammed chips so people can upgrade their older boards.
That sounds great!
Isnāt that the way; I had planned to get more done over this vacation as well. Family came first!
That will be very welcome!
Thanks,
Alan KM6VV
Yes, I understood that already. However, āporting the firmware to GNU compilerā really just meant to understand the differences between the CodeVision and the GNU compiler; also, I had to learn a little bit about programming the Atmel 8bit RISC MCUs. In particular, porting the boot-loader to the m168 was a very instructive experience. I think it will be quite straight forward to change the source code for the new firmware versions s.t. they will also compile with gcc.
Personally, the costs for the CodeVision compiler are not the limiting factor; however: there is a freeware compiler, so why not at least try it. Also: usually I do not use MS Win, and I would not like to maintain another operating system on my computer just to change something in the firmware of some servo controller. BTW, there is also a project called āWinAVRā which contains the GNU AVR cross-compilation tool-chain specifically packed for MS Win.
Iām looking forward to the release of the source-code for the new firmware.
Cheers,
Claus
Hi Claus,
I run the CodeVision compiler for a couple of small projects; itās a hassle as it only runs on one machine! It is currently running on my notebook computer, but can be moved. Iād like to try the WinAVR sometime.
Porting to 40-pin AVR chips would also allow the inclusion of a few more analog or digital inputs.
Iām also interested in porting SSC32 to a PIC (Hitec C), which would then be VERY convenient for me. I still have a lot to learn about the AVR RISC chips. The ASM code in the ISR of SSC32 along with the counter flags is a little different!
Alan KM6VV
Iām still a little unclear as to why Iām supposed to be excited about people porting my SSC-32 code to other processors. How does that help my company?
True,
Probably only of use to LM if you decided to offer a PIC based board. PIC users might be more interested in it.
However you could probably get a free schematic/PCB design out of it. ;>)
Alan KM6VV
Does the Lynxmotion sources have an appropriate license attached that specifies how the code can be used, such as non commercial use only? If it doesnāt, it should. 
Porting of code just something that happens when you make source code available. It will get used in ways you may not like sometimes. People should be strictly on their own if they undertake a port like this. If people do port your code, they should always keep appropriate attributions in the sources. Itās only fair and common courtesy. Ideally, they would also offer you the new port of the code to do with as you want.
Source code is a great example to learn with if it is well written and commented. If I were doing a port like this, I would always offer anything new I created back to the originator (i.e. Lynxmotion, in this case). There are not enough good examples of well written and commented source code examples available. I hope I will still be able to look at the SSC-32 code as examples when I get ready to work with the Atmega MCUs.
If there is a well supported version of a product with the code, like the SSC-32, I will use that rather than mess with something that would not be supported. I donāt want to mess with something that works, and works well.
It could be seen as a form of free advertising, assuming all attributions to Lynxmotion remain in any of the SSC-32 code used by others. You might consider it a gesture of good will toward the Open Source community also. Itās an additional reason for folks to come and explore Lynxmotion. If I have to choose between two companies that make products that would be equally useful in my projects, source code might be the factor that tips me toward one company over another if both are even. It could potentially be a tiebreaker.
Thatās just my take on all this.
8-Dale
This is what is on the website.
āThe servo controller is Open Source which means we are posting the source code for the bootloader and firmware. The goal is to have an affordable platform that many people will provide firmware for. It should also help many aspiring programmers learn some tricks. Anyone can use the source code to write specialized firmware, providing you allow Lynxmotion, Inc. to publish it for others to enjoy, and it is not used in a commercial product. As it is, this servo controller will outperform controllers costing two or three times as much. Having several āflavorsā of the firmware will make this an even better value.ā
Probably not worth the pixels used to display it as far as keeping it from being used in a competing product.
Mike D and I have discussed it. The official stance is, Lynxmotion, Inc. does not authorize the mega8 or mega168 SSC-32 firmware to be ported to any processor that is not a drop in replacement chip for the SSC-32 PC board. We will not look the other way if it is discussed on this forum. Iām really sorry, but it just does not fit the original criteria for making it open source. I hope you can see the reason for our position.
However itās not all doom and gloomā¦ The NG SSC prototype is completed and itās working well. This is where the C programmers will be able to really do some cool things. Itās going to have all of the SSC-32 functionality with a C library ease of use. It will use GCC for development. We are pushing the development as fast as we can.
I can understand the decissions made regarding the source code. I donāt think I have seen any user enhanced firmware made available for download which was the main goal of making it available in the first place.
Jim will be posting the M168 bootloader in the next few days. If you are planning to program your own ATmega168 processor with the bootloader, be aware that it has expanded from 256 bytes to 512 bytes. There were 3 things that pushed it over:
- Some registers that used to be in I/O space have become memory-mapped, so each access to these registers requires an additional 2 bytes (ouch!).
- The flash page size doubled from the M8 to the M168, but I wanted the read/write commands to work the same, so I changed the code to buffer the bottom half of the page and perform the write only when the top half is received.
- I added a new command to return the bootloader version number. Type āvā and the bootloader will return ā2ā. The old bootloader (version 1) will ignore āvā. This can be used to prevent installing M8 firmware on an M168 or vice-versa.
If you are programming the new bootloader into an ATmega168, you will need to set the flags to indicate a 256 word (512 byte) boot block.
There is a new version of the .abl file generator also, that can generate M8 or M168 files. The differences between the M8 and M168 files are
- For the M168, write commands must occur in pairs to program an entire page. Even if the .hex file doesnāt have anything in the top half of a page, the .abl file must have 2 lines for the page.
- Fewer erase commands are needed for the M168 files since the pages are larger.
Mike
Anyhow, here are the links with the gcc āportā of the old firmware. BTW, it was not my intention to use the stuff for anything else but the SSC32 board.
What follows is just the message I wanted to post as a start of this thread. Do with the stuff whatever you like:
At least this can be counter-balanced. Iām using the Y pointer and indirect addressing: after loading the Y pointer the access to the I/O ports again only requires one instruction. Also, it is (at least for the M168) not necessary to move the interrupt table to the application section; it is there by default. Also the I/O ports are programmed as input ports by default which spares another instruction.
Those two points cannot be implemented in only 128 instructions, of course. My version of the bootloader is only 126 instructions in length, has no āvā command and expects the write commands to provide an entire page in one run, and the ārā commands also returns an entire page in one run.
BTW, the bootloaders could also be distringuished by looking at the length of the reply to the ārā command. But so what. The 16kb flash of the M168 are probably plenty, so there is maybe no reason to put too much effort in reducing the size of the boot-loader back to 128 instructions.
Cheers,
Claus