@ taylorza I tried and everyting compiles without problems.
Thank you for letting me know. I look forward to your contribution. Can you drop me an email, chris@ .com
@ taylorza: I just want to let you know, I almost finished AD on your DL40-IO. Your architecture is amazing and I wasnât very difficult to integrate new functionality.
How can I add new source to the source control? Do you want me to send you patch, or you will give me permissions on your codeplex repository? My codeplex username is jernejk.
@ jernejk - That sounds great, thank you. I am really excited to see what you have been able to do, I have added you as a developer on the project.
The family and I are heading out for the weekend so I will probably not see this until Sunday evening, so please excuse my absence this weekend.
I just commited my first version. For now it support only three pins and I need to check why other three are not working. I guess there is something about internal VS external signals settings.
I also reorganized SVN a little bit (added some folders and files to ignore list). In case you get any three conflicts on update, please select remove files.
Please check the code when you have some spare time. And have fun out with your family.
@ jernejk - That is outstanding. Just got back home, so I will take a look tomorrow evening. Thank you very much for contributing this, I really appreciate it.
I could not resist, I took a quick look at the code. The reason that AD channels 5,6,7 are not working is because these channels are controlled by bit 1 of the IO Config for the relevant pins rather than bit 2 as with the other channels.
So the following line in SetupADC
*IOCON_PIO[pin] = ((*IOCON_PIO[pin] & (0x7)) | 0x2) & (~(1 << 7));
will need to be
*IOCON_PIO[pin] = ((*IOCON_PIO[pin] & (0x7)) | 0x1) & (~(1 << 7));
For the last 3 channels.
I will take a more detailed look tomorrow evening, and probably contact you via codeplex for further discussions.
Thanks again!
Hi, I also found that, but thx for help. New version is already on SVN.
Now working on test project refactoring.
Now I also did some test refactoring. I moved code for each type of test to the separate class. I hope its ok with you.
No problem at all, I am happy to have better tests.
Can someone please confirm, that the interrupts works. I am currently using IO60P16 module for interrupts, but I am having a really hard time with this module(http://www.tinyclr.com/forum/topic?id=6860&page=37#msg106468).
I need interrupts to capture switches to turn the lights on/off.
@ Makla, interrupts work and if they do not we can make them work. If you do not require a very high interrupt rate then you should not have any problems, I have not implemented interrupt queuing but if that is required then I will happily implement it.
I am planning on finishing the PWM support this weekend, but if there is something pressing that someone wants to use or requires I will change priorities.
Like I said I just need to intercept interrupt when someone pull the light switch, which automatically goes to 0 state. (Like the bell switch). And also some output to open relay.
Thanks.
I already order the module.
There is a new update to DL40IO firmware. The new features include
Analog Input - Thanks to the contribution from @ jernejk
PWM Output
The code is no longer uploaded to codeshare as it is all available on codeplex
http://dl40io.codeplex.com/
Until we start releasing binaries on codeplex I will continue to upload binary builds to codeshare for those that do not want to bother with building the firmware yourself.
Future developments:
@ jernejk and I have been just started discussing adding SignalGenerator and SignalCapture functionality for DL40IO. If you have any ideas, comments please let us know.
2 Likes
Outstanding! One suggestion is to set up GCC makefile for the build.
Will have to give that a try, it will definitely help me to get a better understanding of GCC and the ARM build environment, so far I have been winging it 
It shouldnât be hard. I might give it a try soon if you wonât have it by then. The only hard part would be to translate asm code from ARM to GCC notation.
Perfect.
You might not even have to port the asm code, one thing that I have found is that the Cortex cores are designed to be C friendly. If you take a look at the CoIDE project, they support the LPC111x family of processors and they have a startup_lpc11xx.c which should do the trick and the assembly version could be dropped.
@ taylorza - Even better!