My Duinomite Mega Canview V4 equivalent Project

Converter temp: In the frame 21, byte 3. (This is the most important in OOG mode.)
Inverter MG1 in the frame 23 byte 8.

 

CAN Commands update:

Commands are written, compiled and debugged up to the point where it runs as expected on the bench (with no CAN hooked up!). i.e. all the parameter handling is working and the rcv command correctly states "no data".

Next up is to hook it up to the Prius and see if it actually collects data. Chances of it working "out of the box" are no more than 1 in 100! Chances I can make good progress and debug it with 1 more evening of work - about 50/50...

Watch this space...

 

Is this based on the open dmbasic or closed mmbasic?


-Htc Tapatalk ( sorry for auto spell correct )

 

Recommend moving this project to the free Atmel Studio 6 IDE. Built-in compiler, debugger, and emulator would allow the use of complete instruction set and hardware features of your chosen MCU. This should fix your speed and error problem. Atmel is in the CAN market so there are app notes and software tools available.

Just a suggestion for ver. 2.0 of your project.


Atmel Studio- Atmel Corporation


Networking - Automotive Application- Atmel Corporation


CAN/VAN Networking Automotive Solution- Atmel Corporation


TI/National is also a good source of Automotive MCU/CAN implementation information.

I use both TI and Atmel IDE's, Eagle PCB design, and Autocad LT on an Atom based netbook. No 3D of course.

 

I got it the wrong way around? Dmbasic is the closed one?
I tough mmbasic was the closed one

-Htc Tapatalk ( sorry for auto spell correct )

 

I think planetaire take 21 as byte 1 so byte 3 should be correct. In Torque, that byte location is 'F'. Perhaps you should check your formula? 1.8 * F - 58 is in Fahrenheit, for Celsius you should use F - 50.

Working your no. backwards, 108 = 1.8 * F - 58 => F = 92
If you use F - 50,
92 - 50 = 42

Vincent

 

Hi James,

I'm using exactly those tools for my YaPIP project (also documented on this site) - I'm using an eval kit with two CAN ports and an LCD screen.

However, the goal of this thread is to use the DuinoMite Mega because it's so cost effective and feature ready right out of the box. CAN, VGA, USB, Sound, SDCard - right out the box for only $40. BASIC makes it easier for the non software engineers on this thread to write the high level code.

If you want to get to the "bare metal" then it's a PIC32 and you can use any appropriate IDE for the Microchip range. However, it comes with a choice of two flavors of BASIC and the ability to add new commands to the interpreter - so it's relatively straightforward to fix all the timing issues by moving appropriate processing down into the interpreter and leaving the high level commands in BASIC. It's actually a good division of labor - lopez is working on what he wants to achieve in BASIC and I'm doing the bits that need to be speeded up in the C-code.

To answer FWD's question: both - but mmbasic isn't "closed".

Longer answer:

The two flavors are:

DMBasic - this is Olimex's version that they ship on the DM Mega. It works with CAN out of the box. It's an older "flavor" of BASIC and requires line numbers and GOSUB/RETURN for function-like calls. It's open-source and licensed via GPL. It's hosted on GitHub.

MMBasic - this is Geoff Graham's original version that Geoff created for his MaxiMite design. MMBasic 3.2 is a more modern implementation of basic and implements "proper" functions and subroutines as well as dropping the need for line numbers (it's backwards compatible with line numbers).

The DuinoMite hardware is a clone of the MaxiMite plus extra features. There's some disagreement between the two camps and Geoff was unhappy with their using MMBasic. So, as of version 3.2 he created a more restrictive license. However, it is not a "closed" license as some folks state. The source can be requested and can be modified in any way for personal use - but can't be distributed without Geoff's permission. The source can be requested from the MMBasic website.

MMBasic doesn't have CAN out of the box. However, it's straightforward to port the CAN commands (copyright of another party). However, I'm told by the copyright holder of the CAN implementation (Frank Voorburg) that GPL licensed code can't be included in the MMBasic distribution. So, to add the CAN commands one has to request the source code from Geoff, retrieve the CAN source from GitHub and then use the freely available tools to put them together (that's what my instructions describe). If you do that then you have a perfectly legitimate copy of MMBasic for private use.

Clear as mud, right?

Bottom line is that any CAN commands that I write that are based off of Frank's original will be GPL'd and thus you'll have to build 'em yourself for private use. The commands will work in either DMBasic or MMBasic - I prefer MMBasic and the instructions that I distribute are for MMBasic.

In the future (when I get a round tuit) I'm planning on rewriting a CAN implementation from scratch. At that time I'll be copyright holder and can license it in such a way as to allow it to be rolled into an official MMBasic distribution. Not sure when/if I'll actually do this - because there's more pressing needs for my overall goal (see YaPIP).

Peace, love and plug-ins!
John H.

 

i got it working already but thx anyway

 

Yes, byte 1 = 21 so temp is your rxdata(2)

I have already read more then 55°C (see picture using 22 kW) and more then 60°C in an other test, using full EV power

 

I think you're misunderstanding what I meant by "flavor" (which I confess is a non-technical term!). Branches would be more appropriate.

DMBasic started from MMBasic 2.7 and several changes were made to support DM (it's not just the CAN commands that are different). Thus, one would say, DMBasic forked to it's own brance at MMBasic 2.7. The branches are now separate and are unlikely to merge back together.

Thus the DMBasic interpreter is functionally equivalent to MMBasic 2.7 interpreter. However, MMBasic 3.2 is a major upgrade to the BASIC interpreter. It's the updated interpreter that gives us structured programming.

It's easy to add CAN to MMBasic 3.2. I'm not sure it would be easy to add the BASIC interpreter upgrades back into DM. So, I think DMBasic is likely to remain "stuck" at 2.7 whereas MMBasic has a version 4.0 coming out soon (although that's mainly to support the new color MaxiMite).

I tried to join the "official" forum for DMBasic but never got a response from the board administrator (99% of boards I use automate sign-up stuff). I prefer the style and capabilities of the 3.2 interpreter so I'll be concentrating on adding DM unique functions (such as CAN) into the MMBasic source tree.

Here's what I know:

1. Both DMBasic and MMBasic work and meet the goals of the authors. I make no claim as to which is "better" or "worse".
2. DMBasic requires line numbers and has CAN built in out of the box.
3. MMBasic provides structured programming but the individual user has to compile their own version for CAN support.
4. DMBasic programs that access CAN will run on MMBasic as long as step 3 has been completed.
5. MMBasic programs that use functions and subroutines but don't use line numbers will not run on DMBasic.

 

even in mmbasic i now stil use line numbers because that possble and i think better if anywone would go beack to Dmbasic with line numbers and use the same program code
i also like line numbers -)

 

I'm happy for you

It's not that I don't like line numbers. I don't even mind GOTO!

It's that I miss being able to write functions and subroutines and have those functions be clearly named and have local variables...

But to each their own.