 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : New CAN Commands for MMBasic 4.0
| Author | Message | ||||
| jdh2550 Regular Member  Joined: 16/07/2012 Location: United StatesPosts: 62 |
OK, attached is the first beta release of the new CAN commands. Included in the zip file are the following items: - DMCAN2.hex - flash this onto your DuinoMite. It's built from the latest MMBasic 4.0 files and the hex is distributed with permission of Geoff Graham (overall author of MMBasic). - CAN_Commands.pdf - documentation for the new commands - Example[0-2].bas - example files. These should get you started. A couple of notes: - it's still in beta so if you find bugs then tell me - it's open source and provided as-is - don't expect oodles of support but obviously I want to make sure it works properly - this code is not backwards compatible with the original CAN implementation. However, an enterprising sole could make a simple compatibility library by implementing Frank's original commands as subroutines. - the documentation refers to an additional 3 examples (one of which is the backwards compatibility subroutines). I haven't gotten around to them yet - but I figured you'd want me to distribute stuff sooner rather than later. - Geoff has indicated that he'll include this implementation into the official MMBasic code base. This will allow inclusion in future releases from Geoff. - The documentation file refers to "license X" - I'm still deciding on which license to use for the source code. The compiled hex is licensed in the same way as the original MMBasic hex. Use it in any way you want but it's provided as-is with no warranty expressed or implied. - One bug I just noticed (but am too lazy to fix right now) is that although CAN FREE does free all memory it doesn't appear to clear the filters properly (so you'd need to reboot your DM between running example1.bas and example2.bas to see the differences) Comments welcome. DMCAN2_Distro.zip |
||||
| Bugs2 Newbie  Joined: 18/05/2012 Location: United KingdomPosts: 29 |
Great work! The current compliment of analog and digital interfaces already makes the Maximite a better choice for many dedicated instrumentation and control projects than the usual pensioned-off PC option, but adding CAN to MMBasic would create an even more powerful alternative. |
||||
| jdh2550 Regular Member Joined: 16/07/2012 Location: United StatesPosts: 62 |
Thanks - and I agree with you about increasing the usefulness. One thing to clarify though - at present the CAN hardware only exists and confirmed to work on the DuinoMite Mega. Specifically the CAN hardware is not on the "Maximite" board (nor the Colour MaxiMite). You may have been using "maximite" in much the same way as one uses "pc" to describe a generic group of hardware. Or not. I think Geoff Graham (original MaxiMite creator) would probably prefer a clear distinction. Now, having said all that (and no one ever accuses me of being too brief!) it wouldn't be a big job to add a CAN transceiver chip to a UBW32 - and probably pretty straightforward on a MaxiMite as well. Adding that would make CAN available to those platforms - but at the cost of reduced I/O in whatever other area might conflict. I'd love to see someone come up with two hardware modules on small PCBs: 1) A CAN Transceiver with opto-isolated inputs (simple serial RX/TX should suffice) and a suitable wiring on the output (the side that attaches to the CAN bus - the existing DM Mega is fine). 2) As above but have a CAN Controller chip as well as a CAN Transceiver with the opto isolation between CAN chip and CAN Transceiver. Option (1) would allow folks to add the necessary Transceiver hardware to a PIC chip (or any other) that already has a CAN Controller. Option (2) would allow folks to add CAN to a chip without a CAN Controller already implemented. Option (2) exists in various forms as an Arduino Shield etc. (Best value I've seen is $23 at Seeeduino) - I'd just like something in a more compact form factor (yes shields are good but the components required should fit on a postage stamp). Just my 2 cents worth (inflation adjusted) |
||||
| KeesZagers Newbie Joined: 04/09/2012 Location: NetherlandsPosts: 3 |
Good to have CAN commands which support the buffers now. However still not enough for my applications. I use the Duinomite as a blackbox for analysing CAN networks. Therefore I want control of all filters and also the masks. Also important that I can control the bit timing register and read the error counters. In fact this is all supported in the CAN module. As I bought my first Duinomite before there was any Basic support for CAN I started to PEEK and POKE in the CAN module and also used a DIM for a dummy array to read and write the CAN messages. I must say this works quite well. I allready made programs for automatic bitrate detection, testing of the stability of a network, error registration, busload etc. In fact I ran in only one serious problem and that is bitrates below 25 kb/sec. Because the hardware is using a 80 MHz Xtal I did not succeed in getting bitrates of 20 kb/sec and 10 kb/sec. I did not have the time yet to install the new firmware, but from the documentation I read that the bitrate is in the range of 10 kb/sec up to 1000 kb/sec. I'm wondering if this is really true, because I don't believe that this can be achieved without a hardware modification. Just wondering ... |
||||
donmck Guru  Joined: 09/06/2011 Location: AustraliaPosts: 1313 |
DuinoMite-MEGA and the CAN commands. Posted with a view to promoting the CAN Bus commands on the DuinoMite-MEGA. I have written a small blog post with John Hardings permission (and comments), which is a summary of the progress of the CAN bus commands on the DuinoMite-MEGA: http://www.duinomite.com/duinomite-mega-and-the-can-commands / This will be updated when more detailed information is available. Don... https://www.dontronics.com |
||||
| jdh2550 Regular Member Joined: 16/07/2012 Location: United StatesPosts: 62 |
To be honest I'm not sure - and I'll change the documentation to be a little more forthcoming in this area. If you can test it at different speeds and let me know your results that would help. Otherwise I'll simply change the documentation to say "theoretically this can work between 10kps to 1Mbps - but it has only been confirmed to work at 500kbps - I have received unsubstantiated reports of 25kbps being the physically achievable lower limit". Your post kind of makes me feel like this: 
But never mind - it's not life or death. |
||||
| jdh2550 Regular Member Joined: 16/07/2012 Location: United StatesPosts: 62 |
Thanks Don - I appreciate you spreading the word - I didn't quite realize my email would be posted verbatim in your blog. I think that's OK though (not everyone likes my humor - heck, even I don't like my humor sometimes!). Peace, love and plug-ins!  |
||||
| donmck Guru Joined: 09/06/2011 Location: AustraliaPosts: 1313 |
What humor? I thought you were serious John! P.S. That's a joke. 
I love a good sense of humor, sure beats
Don... https://www.dontronics.com |
||||
| KeesZagers Newbie Joined: 04/09/2012 Location: NetherlandsPosts: 3 |
Sorry John, This was certainly not my intention. Good that guys like you invest time to help others by implementing such CAN commands. I think my introduction was just too long to come to my last question: How did you implement a 10 kb/sec bitrate, but as I understood now you did not test it at all bitrates. Just at 500 kbit/sec. I hope to found some time during coming weeks to test the bitrates. To give you some more background information about my background and intensions: I'm not a programmer. I can read a C program, but have no experience in programming in C. I like to use a simple language as Basic to program. In fact I'm a hardware guy and specialised last years in CANbus systems. I have a lot of experience with all kind of PC interfaces (last years mostly USB) and use the low-level drivers of the suppliers and applications in both automotive as in industry. Unfortunately a PC + CAN interface is too expensive for a lot of applications and that is why I started with the Duinomite Mega. I like to introduce the embedded CAN analyser for 100 EURO/Dollar. However until the product is not ready I will not publish any code as you can imagine. Maybe in the end I will convert all code into C anyway. I hope you feel better now ... |
||||
| jdh2550 Regular Member Joined: 16/07/2012 Location: United StatesPosts: 62 |
Hi. Thanks I do feel better & I apologize for coming on too strong. But believe me- if you can achieve what you did with the POKE command you can handle C no problem! Let me know if you want to see my code |
||||
| KeesZagers Newbie Joined: 04/09/2012 Location: NetherlandsPosts: 3 |
I found some time to implement your implmentation. It consumed some more time, because my systems still ran the DMBASIC on the Duinomite Mega and I also had to update the USB driver, etc. I tested your software on the standard bitrates and it seems you only implemented the 1MB/sec, 800 kb/sec, 500 kb/sec and 250 kb/sec of all the standard bitrates. If you enter a lower bitrate the screen stays clear. When I did a dirty "PEEK" on the CAN configuration register I saw that the register stays on the value you used for 250kb. You entered also values which I (as CAN expert) would not advise. This however goes much to far for this platform. I can send you a separate email about this, if you want. Concerning your last post of writing this in C, I agree that this would be possible, but my problem is, that depending on my CAN application I need to read or write to any register in the CAN module and this can be easy achieved by peeking and poking. My first priority is to see if I can achieve with the Duinomite Mega what I like to do and if I run in timing problems I probably will start to program some C-routines to speed it up. |
||||
| jdh2550 Regular Member Joined: 16/07/2012 Location: United StatesPosts: 62 |
Thanks for taking the time to do this. Your input is very helpful. I am using a routine to automatically calculate the timing values - rather than the normal table look-up approach I've seen in the past. It looks like my approach was too simplistic to cope. I'll probably switch back to a table driven approach. I'll also have to make sure I issue the proper error response if a value can't be set. I'd love it if you could send me an email: jdharding at comcast dot net As well as help with the timing values I'd also like to implement auto-detection of baud rate. Any pointers you can give me there would be gratefully received. Many thanks. As far as PEEK/POKE vs. C - I guess it's just a question of what we're each comfortable with, right? I'm sure I'd get into a lot of trouble if I used direct register access rather than going via the Microchip plib routines! 
|
||||
| jdh2550 Regular Member Joined: 16/07/2012 Location: United StatesPosts: 62 |
Hi I don't know if anyone is using this? However, here's a new beta version (b2) - it fixes CAN TX. I haven't changed the CAN timing setup - which I still plan on doing. So, it really only works with a very limited set of bit rates (see KZ posts above). 2012-10-06_011807_DUINOMITE-canb2.zip |
||||
 Print this page |
