Getting started with DaisyLink

@ ian

VB is a good language; TONS of people use it. I happen to prefer curly braces, but not everyone does :slight_smile:

As to arduino: you can’t really just remove an arduino AVR and use it elsewhere; it’s still an arduino. What you want is an AVR (or PIC) development board with an in-system programmer OR a dedicated programmer. The board I had is just for prototyping, as that specific chip isn’t available in DIP.

Check out the other things that MikroElektronika has on their site. You’ll probably find a dev board that works for you.

It’s a whole other world, and not as beginner-friendly as Gadgeteer/NETMF.


Geeze… I knew better than open that can of worms… Yea, I made a living off VB for most of the '90s. The day C# was announced was one of the happiest days of my life, though… I remember, it was a Tuesday and I was at PDC with 10,000 geeks (and two women) in a cram packed auditorium… :wink: (back to reality)

I’m going to have to study what this really means a little closer. I know I’ve read samples where they programmed a chip with an Arduino and then removed it and placed it in a circuit. There must be a step I’m forgetting or didn’t quite understand at the time. More homework…

“Arduino” is just an AVR+bootloader+IDE+Wiring

Pull the AVR out of an Arduino and you have a regular old AVR that has the Arduino bootloader on it, which is running software that uses the Wiring library.

It’s a normal AVR at that point.

He programs the chip in an Arduino then “pops” it into a PCB with a clock, couple caps, & resistor and it works as it did in the Arduino. Am I missing something?

As godefroi says, an “arduino” is really only a platform that allows for the programming. At it’s heart is the atmega and the USB chip; if you load your program, take the atmega out and put it in its own circuit (minimal power plus clock ) then you still get to use the atmega in “arduino” mode but just not reprogrammable.

Maybe I misunderstand, but when you pull the AVR out of an arduino, the code you wrote still uses Arduino pin /connector locations etc. Wouldn’t that be non-intuitive once you yank out Arduino board infrastructure? I didn’t think Arduino shield/board pins were 1:1 with MPU pins.

That’s really what I was getting at. If you’re coding for a chip with a different destination board, you really want to do so in something that either imposes no abstraction and surfaces all the pins as pins, or has the same structure as your final board.

Check these out. The EasyAVR6 is tempting. You pop in the AVR you want to use (DIP only) and program against it. When done, you can pop it out and use it elsewhere.

You don’t have to use their tools. Atmel supplies AVR Studio which is based on the Visual Studio 2010 isolated shell and GNU C/C++. You code in C, typically.


Are the arduino pins 1:1? I’d be surprised if they weren’t - but don’t know. I have an ATMEGA32 dev board with 4x 10-pin .1" headers, and while it doesn’t have an arduino bootloader it could, and then it becomes an arduino. The abstraction that an arduino gives is similar to the way netmf does, you don’t need to know that digital pin 6 is C.4 on the atmega, but that’s what it is… The compromises the arduino makes are similar compromise that GHI must have faced, what pins to put on a pinout when there are actually more available to start with, but wanting to keep cost down and flexibility high.

Personally for really simple projects such as a DaisyLink sensor or actuator my weapon of choice is always a 8-bit PIC microcontroller programmed in assembler. An ARM chip really seems like over-kill in an application like this! The PIC chips can be easily bread-boarded as they are available in DIP packages and have really simple external requirements. Programming in assembler means you always know exactly what is going on and can seriously optimise your code. PIC chips are really low cost both per chip and to get set up for development, with Microchip’s excellent MPLAB and very simple hardware programmer/debugger.

The PIC16F1824 would be an ideal chip for DaisyLink with hardware I2C and all the peripherals you could want including support for capacitive touch sensors.

Atmel may well offer as good or better alternatives, it is just that I am familiar with PIC.

I guess it depends on what all the module would be doing. For something like a sensor that’s just transmitting a value and passing along DaisyLink info then it might be OK to do assembly. But, for a more complicated module that has a lot of software functionality I can’t imagine how I would even get started in assembly.

Yes, but why put “a lot of software functionality” into a module when you’ve got a powerful ARM chip with C# programming at the other end of the DaisyLink? If such a case arrises, perhaps it is worth considering basing the module on a USBizi chip? The DaisyLink protocol itself is nice and simple, particularly if you have hardware support for I2C, and it should not be difficult to write a general framework in PIC assembler from which a multitude of specific devices could be derived.

I’d like to see stuff like GPS, accellerometers and compasses implemented on DaisyLink to avoid specialised serial resource contention on the mainboard, but even here the microcontroler is probably just a simple converter between the serial link technology used by an off-the-shelf chip or module and DaisyLink.

Ironically I have been pestering Microchip to produce 8-Pin controllers with multiple serial peripherals specifically for smart sensors with UART, CAN, LIN, I2C or SPI interfaces (2-pins for the sensor/actuator, 3 for the serial link, reset and power). Now they have finally done this, I encounter DaisyLink which solves two knarly problems with such smart sensors: address assignment and non-polling event generation. However DaisyLink requires 6 pins for the bus (2 for the I2C channel, 2 for the neighbor bus and 2 for the programmable I2C pull-up resistors) so an 8-Pin device is not enough! However 14-pin is more than adequate leaving 5-pins free for the sensor/actuator interface.

@ ransomhall

I finally decided to follow your lead on this. It will make for a rather large module having to fit that big ATMega328 on it but I think this is the simplest solution for getting started. Besides, I’ve been wanting to add an Arduino to my collection…

The boarduino is going to be my “Proto DuinoProto”. Once I get a design nailed, I’ll scale the chip and other components down to only include just what is needed (ATTinyXX or similar) on a second DuinoProto (e.g. contest submission).

I went this way because I have a bunch of Arduino code running various components that I have not yet ported to NETMF. For example, I have a VFD that is begging to be ported. The DuinoProto “bridge” lets me procrastinate doing so even longer :slight_smile:

The available code samples and info on the internet were also a big factor in my decision. Is it possible to program an ATTiny using the Arduino programmer or is something else required? This is a question I tried to find an answer to when researching but couldn’t find a good example. I definitely like the chip size better and it will probably satisfy most of my needs.

I haven’t personally tried this approach, but here’s a blog that goes through all the steps for an ATTiny45 based BlinkM LED. . There are a few hoops to jump through, but nothing too crazy.

That’s very cool interesting… :slight_smile:

Here’s a tutorial on going from Arduino to ATTiny

Trouble with using ATTiny or similar PIC chips is you need 6 IO pins just for DaisyLink so there would be nothing left over for the specific IO function. I suppose you could use two external FETs for the pull-up switches and save one IO pin for specific IO, but it would likely be lower cost to go for a 14 pin microcontroller (unless anyone makes 10 or 12 pin ones).


The lowest cost of entry might just be the STM32F4 Discovery kit. It’s $15 for a big CPU plus debugger. Can’t beat that…

I personally like Microchip, but their cheapest debugger is around $60 to $80.

I’m working on daisylink on a 14-Pin PIC at the moment, but I already had an ICD3 from a previous project.