The driver is available in the beta SDK, which can be found here in the first post: http://www.tinyclr.com/forum/topic?id=7187
If you have it already installed, or have trouble installing it, let us know.
@ Steven - Thanks for the reply…got it working. Fun little module. I’m working on some utility code to make bitmap creation a little easier…will post a link to it tomorrow.
@ Steven - I put together a little helper class for the LED Matrix module to make it easier to do basic letter/number output, and posted it on Codeshare:
Gus;
I have a real need for a hardware watchdog device. I’m currently using the Muilt-LED as the primary UI on a gadgeteer project that may go commercial.
A big problem with this is, if the Spider suffers a fatal error, the Muilt-LED remains in last state. With a little effort, you could add the following to the Multi-LED API:
bool IsHardwareWatchdog
int HeartbeatInterval
void HostHeartbeat
If IsHardwareWatchdog && heartbeatTimeout > set to ‘Watchdog_Timeout_State’ (Solid-Red)
This could be added to any/all of the MultiLink devices, adding considerable value to them.
Nick
We will see how we can improve it.
BTW, the code is open so you can do any changes you see fit your needs. GHI consulting is also available to make any changes as well. Something to keep in mind fot future.
Where can I find schematics and hardware details on the OpenDaisyLink protocol. For the most part I can follow the software. I would like to know how to implement the hardware using a ChipworkX.
Thanks
Each module has a tutorial with info and link to source code. Schematics are linked under “downloads” on each module.
Note, ChipwotkX is not “gadgeteer” and so there is no drivers done for it but you can always take any of the other work we did (spider fro example) and port to chipworkx. Should be able to get it going in about a week of work.
Welcome to the community.
Hi
I have ordered a DL40 and want to use it for a project.
I have read the tutorials etc but can’t find any info on how to create my own driver.
Specifically I want to use a dl40 to be reading a number of rotary encoders and ordinary switches and feed this information back to the main board without the mainboard having to poll the dl40 continuously to see if anything has changed. Is this sort of thing possible with opendaisylink?
mwebit
You could have your driver handle the polling and raise an OnChanged event so that the user only has to add code to be executed when a state change has occurred. Polling will have to be done somewhere, though.
@ mwebit - The Daisy Link protocol supports raising an interrupt back to the main board. You can use this to notify the main board that you have some data and that it should read the data.
To get started you might want to take a look at the code I put on codeshare that demonstrates creating a simple pulse counter. This does not use the interrupt feature, but it will give you a working sample to start with.
http://www.tinyclr.com/codeshare/entry/610
Once you have that working, raising an interrupt is as simple as calling the DL_Interrupt() function. The trick is handling the interrupt, you will need to derive a class from the DaisyLinkModule and attach an event handler to the DaisyLinkInterrupt which in a protected event, infact what I did initially was to just take the code for GenericDaisyLink and and expose the event publicly.
Thanks for help I have created a test app for the Dl40 that looks at 2 pins that are connected to a rotary encoder. I have used the interrupt function to be called when the function that increments or decrements the register changes. This all builds OK.
I have been looking around for the generic daisy link code, can only find assemblies no source. Can you point me to the link?
Once I have the source do I need to change the code to handle the Reg_t new structure?
Also is it just a matter of of making the event public for the interrupt?
Thanks in advance
Did you check http://wiki.tinyclr.com/index.php?title=OpenDaisyLink where there’s apparently a zip of the source plus the dl40 specific source at http://wiki.tinyclr.com/index.php?title=DL40_Module
Thanks, have tried that link it has program to download the code you write for the DL40. But doesn’t have the source for the generic daisylink.
But it explicitly says you need the source for each module, and the dl40 page has the link to the source for dl40… am I missing something?
@ mwebit -Just to make sure we are all on the same page. There are 2 parts, the DL40 firmware and the GenericDaisyLink module driver, the firmware I assume you have already since you say that you have been able to make the required changes and compile.
Have you successfully loaded the firmware onto the DL40, there were some issues with the loader due to changes MS made to the NETMF serial port, I do not now if the code on the wiki has been updated accordingly. Just in case here is a link to the post on the issue, with the code changes I made to get the loader working
http://www.tinyclr.com/forum/jump/9195/91739
Next the GenericDaisyLink driver, the best place to get the source is from codeplex, the code for the gadgeteer framework and modules is hosted there
https://gadgeteer.codeplex.com
I keep a local SVN working copy of this repository on my machine
https://gadgeteer.svn.codeplex.com/svn/
Tip: Gus pointed me to the J-Link EDU and I use that to program the DL40 directly rather than use the loader. If you are planning on doing much work on the DL40 firmware I would highly recommend it. Here is a yet to be completed wiki article that I started putting together on working with the J-Link
Thanks for help
I found the source for all the modules from the link posted and downloaded to my pc. Read the module bulders guide and got a better understanding of it all
I’m now at a stage to download the dl40 code I built.
I note the relasher example code is for a FEZHydra. I have a FEZCerberus,
I created a Cereberus project copied all the reflasher code across e.g. NXP.cs UUCoding.cs and program.cs.
It built OK but after dowloading to cerberus it printed out the following:-
A first chance exception of type ‘System.NotSupportedException’ occurred in Microsoft.SPOT.IO.dll
The thread ‘’ (0x2) has exited with code 0 (0x0).
Using mainboard GHI Electronics FEZCerberus version 1.1
A first chance exception of type ‘System.ArgumentException’ occurred in mscorlib.dll
An unhandled exception of type ‘System.ArgumentException’ occurred in mscorlib.dll
Does anyone know of issues relating to cerberus not be able to reflash dl40?
is there a working project around for reflashing with a cerberus?
@ mwebit - IIRC the reflasher code is for the FEZ Spider which uses the premium libraries. You will need to make sure that you are only referencing the open source libraries for the cerb. I have only ever used the reflasher on the spider so I do not know off hand what will need to change for this to work on the cerb. If you do not come right, let me know here and I will see if I can get a few moments to test this on the cerb.
hi
have checked references I don’t have any premium libraries.
If you could check it on the cerberus I would appreciate it.
many thanks
@ mwebit - Sorry for the delay, I did not get a chance to get to my PC with the gadgeteer equipment last night.
I did a quick test and I have mixed results. First the conversion to use the loader on the Cerb went flawlessly, here are the steps I followed
[ol]Opened the project
Replaced the Spider board with the Cerb mainboard in the designer
Added a button module to socket 7
Replaced the touch event with a handler for the ButtonPressed event
Commented out all the writes to the T35 module, fortunately the messages are all written to the debug window so you still see the messages there
Changed the serial comms and control lines to use socket 6 (Interesting note: I first tried socket 2 but that did not work, it might be because of that analog pins on that socket)
Ran the code and pressed the button all seemed to work.[/ol]
But, while everything worked, there is a snag. The cerb does not have enough memory to have the raw buffer as well as the UUEncoded buffer. One thought I had was to maybe perform the UUEncoding in a separate application on the desktop and then try to minimize the memory allocation required at runtime for the actual falshing and verification.
So unfortunately as things stand the memory constraints on the cerb pose a bit of a problem, I suspect that with some imagination we can work around those however.
We built the open daisy link project so it can be used by everyone and on every device.
If there are memory constraints on some devices, that is a different story.