LeafLabs Garden » User Favorites: ratho

LeafLabs Garden » User Favorites: ratho 3746 A place to share, learn, and grow... en-US Fri, 22 Jan 2016 00:11:28 +0000 http://bbpress.org/?v=1.0.2 <![CDATA[Search]]> q http://forums.leaflabs.com/search.php menecken on "Libmaple + Windows" http://forums.leaflabs.com/topic.php?id=2618#post-104802 Mon, 21 Oct 2013 03:32:37 +0000 menecken 104802@http://forums.leaflabs.com/ Any progress on this one? Still getting the MS-DOS style warnings as well as a "build\\.\\libmaple: No such file or directory" error... Thanks in advance Ben lostinspacebar on "Libmaple + Windows" http://forums.leaflabs.com/topic.php?id=2618#post-13201 Wed, 05 Sep 2012 20:11:15 +0000 lostinspacebar 13201@http://forums.leaflabs.com/ I've put my changes here: <a href="https://github.com/lostinspacebar/libmaple/tree/windows_build" rel="nofollow">https://github.com/lostinspacebar/libmaple/tree/windows_build</a> What's there DOES NOT compile correctly obviously. The thing comes to a halt at libmaple/rules.mk. That's the first place make encounters paths in the target definitions that have colons in them. Would love to work together to get this stuff working on Windows. Do you have any ideas so far? P.S. I dunno if my first post sounded hostile. It wasn't meant to. Partially just pissed off at make for doing stupid shit and windows for having colons in its paths. mbolivar on "Libmaple + Windows" http://forums.leaflabs.com/topic.php?id=2618#post-13003 Thu, 30 Aug 2012 14:44:30 +0000 mbolivar 13003@http://forums.leaflabs.com/ This is a problem that we have to solve as well. The Wiring people are also having issues with Make on Windows; it's a show-stopper for the next IDE release, so it's going to be getting lots of attention. I'm going to try to keep a single, make-based build system to avoid that redundancy. Can you share your patches so we can work together? lostinspacebar on "Libmaple + Windows" http://forums.leaflabs.com/topic.php?id=2618#post-12984 Wed, 29 Aug 2012 11:04:02 +0000 lostinspacebar 12984@http://forums.leaflabs.com/ Hi, I've started some work on making libmaple compile on windows with codesourcery (or similar GNU tools on windows). I'm getting close, but the only problem right now is that GNU make doesn't support colons (':') in path names for targets. Escaping them doesn't seem to make a difference (still gives me a "multiple targets" error). This is kind of a show stopper for me right now. I was wondering what everyone thought about me doing something specific for windows. Like making makefiles for nmake instead of GNU make. I can take the responsibility of keeping them up to date with changes to libmaple. I know there is some redundancy there but the current state of windows buildage of libmaple is annoying at best. - Aditya gbulmer on "Serial1.print decimal places" http://forums.leaflabs.com/topic.php?id=844&page=2#post-5798 Fri, 29 Jul 2011 14:19:30 +0000 gbulmer 5798@http://forums.leaflabs.com/ robodude666 <blockquote>By omitting the f, you are stating to the compiler that this number is a double. </blockquote> Agreed. But it may be "worse than that Jim" :-) It was true for several versions of C, starting at K&R, that mixed arithmetic had to be carried out in <code>double</code>. So it can get quite costly (in CPU time). (I just tried to check, but the ISO standards are not public! Why do we accept standards that are not published for free?) I looked at the compiler documentation, but it refers to the standards :-( gbulmer on "Serial1.print decimal places" http://forums.leaflabs.com/topic.php?id=844&page=2#post-5797 Fri, 29 Jul 2011 13:44:47 +0000 gbulmer 5797@http://forums.leaflabs.com/ samtal - <blockquote>(although my opinion is that the compiler should have understood that division of any two numbers is by default float) </blockquote> It often trips people up at first. C and C++ have always used '/' to mean integer division when both operands are integers. This is enshrined in all versions of the language from the original K&R definition through to modern ISO standards, so it isn't something recent :-) It has several benefits: 1. operations on integers always yield an integer result. IMHO, this is a very easy rule to remember. 2. Integer division is a 'cheaper' operation than floating point division (especially on a microcontroller where these concerns matter more), so the lowest-cost operation is the default 3. It is easy to get floating point divide, for example <code>float number = 1234.0f / 53.0f;</code>, or <code>float number = 1234 / 53.0f;</code>, <code>float number = 1234/(float)53;</code>, <code>float x = 1234; number = x/53;</code> which all have the benefit of being more explicit and with less ambiguity. 4. There is no requirement for an extra 'integer divide' operator. Some languages have both a floating point divide and an integer divide operator (let's call integer divide 'div'). That can then get a bit weird if the programmer writes <code>1234 div 53.4</code>. In this sort of case, I think it is clearer, because it is more explicit, to write something like <code>1234 / trunc(53.5)</code> or <code>trunc(1234 / 53.5)</code> (or the other options using <code>round()</code>) 5. Floating point operations are inexact, for example, <code>int i = (int)(1.0/3.0+1.0/3.0+1.0/3.0);</code> does not give 1, but integer operations are exact (noting that overflow stops that being true), so a default which is exact has significant advantages. What operator would you use to show integer division if '/' means floating point division? The operator would need to be non-alphanumeric characters, preferably in the ASCII range, to keep the language parser 'consistent' (i.e. not have to use even more powerful grammar mechanisms). Edit: Division, like all float and double operations, should be carried out with <code>double</code> precision if either operand is a float or double and the other integer. I believe it can be carried out in <code>float</code> if both operands are <code>float</code> (I think that was a C90/C99-ism, but might have been a GNU extension.) HTH robodude666 on "Serial1.print decimal places" http://forums.leaflabs.com/topic.php?id=844&page=2#post-5794 Fri, 29 Jul 2011 13:08:41 +0000 robodude666 5794@http://forums.leaflabs.com/ Not completely correct. By omitting the <code>f</code>, you are stating to the compiler that this number is a double. If you're storing a double in a float variable, a conversion may take place reducing overall performance. By including the <code>f</code>, you are stating this is a float making the compiler's job easier. While it's not needed, it's good to have. If you're casting from an int to a float, a <code>(float)</code> works too: <code>float number = (float)1234/(float)53;</code> -robodude666 samtal on "Serial1.print decimal places" http://forums.leaflabs.com/topic.php?id=844&page=2#post-5793 Fri, 29 Jul 2011 12:51:47 +0000 samtal 5793@http://forums.leaflabs.com/ Indeed it works that way! (although my opinion is that the compiler should have understood that division of any two numbers is by default float) I also noticed that one does not need both the decimal and the 'f'. Either is sufficient. Here is how I read dual adc and break it down to volts: (I know there are other ways as well...) void loop() { int read_result = ADC1_BASE->DR; int adc1_data = (read_result & 4095); int adc2_data = (read_result >>16 & 4095); SerialUSB.print("ADC1_data: "); SerialUSB.print((float)adc1_data / 4095 *3.3,3); SerialUSB.print(" ADC2_data: "); SerialUSB.println((float)adc2_data / 4095 *3.3,3); SerialUSB.println(); delay (1000); } robodude666 on "Serial1.print decimal places" http://forums.leaflabs.com/topic.php?id=844&page=2#post-5789 Fri, 29 Jul 2011 09:18:54 +0000 robodude666 5789@http://forums.leaflabs.com/ As far as the compiler knows, you're dividing two ints and then casting that to a float. You must show that you're using floats: <code>float number = 1234.0f / 53.0f;</code> You will end up with the following results: <pre><code>23.283 23.2830181122 23.28 23.28</code></pre> just as the println statements suggest they should be. No reason to abandon your Maple =]. It's a brilliant little board. -robodude666 samtal on "Serial1.print decimal places" http://forums.leaflabs.com/topic.php?id=844&page=2#post-5788 Fri, 29 Jul 2011 08:11:46 +0000 samtal 5788@http://forums.leaflabs.com/ Hi, After wasting half day trying to print a simple result such as 1234/53=23.283 I keep getting 23.00. I have tried everything I know from any possible programming language print formatting (Basic, C, C++, Fortran, Java, C#.....) and only got errors. Eventually, I searched the form and found out that the Maple does not have that VERY BASIC capability of simple decimal fraction number printing...... Well, I found out that there are new print.cpp and print.h from June 8, 2011 that are supposed to make it Arduino compatible (Arduino has all kinds of formatting) which I copied (NO download?) and replaced my older files, but for no avail. Now I can get 23.0000000 which is 'better precision', but still worthless. Is there a real solution or do I have to abndon my 2 new Maple boards? I need math functions with readable results!! #include <stdlib.h> void setup() { } void loop() { char buf[10]; float number = 1234/53; //=23.28301886792452830188679245283 SerialUSB.println(gcvt(number,5,buf)); //=23 SerialUSB.println( number,DEC); //=23.0000000000 SerialUSB.println(number,2); //=23.00 SerialUSB.println((float)number,2); //=23.00 delay(1000); } samtal ratho on "Serial1.print decimal places" http://forums.leaflabs.com/topic.php?id=844&page=2#post-5101 Thu, 09 Jun 2011 12:01:56 +0000 ratho 5101@http://forums.leaflabs.com/ Thank you! This works as desired :) snigelen on "Serial1.print decimal places" http://forums.leaflabs.com/topic.php?id=844&page=2#post-5080 Thu, 09 Jun 2011 02:33:34 +0000 snigelen 5080@http://forums.leaflabs.com/ Well the 5 means you want 5 decimals ;-) You can use, for example, gcvt, which is a little smaller than sprintf. Like <pre><code>#include <stdlib.h> void setup() { } void loop() { float x = 3.1415; float y = 0.0021; float z = 1.234e6; char buf[20]; if (SerialUSB.available()) { SerialUSB.read(); SerialUSB.println(gcvt(x,5,buf)); SerialUSB.println(gcvt(y,5,buf)); SerialUSB.println(gcvt(z,5,buf)); } }</code></pre> From the man-page (in linux): <pre><code>DESCRIPTION The gcvt() function converts number to a minimal length null-terminated ASCII string and stores the result in buf. It produces ndigit signifi‐ cant digits in either printf(3) F format or E format.</code></pre> ratho on "Serial1.print decimal places" http://forums.leaflabs.com/topic.php?id=844&page=2#post-5064 Wed, 08 Jun 2011 15:59:25 +0000 ratho 5064@http://forums.leaflabs.com/ Hi, thank you! Now it works :) Is there a posibility to cut the 0? If I use print(0.002, 5) I get 0.00200 -> always 5 positions after the decimal point. mbolivar on "Serial1.print decimal places" http://forums.leaflabs.com/topic.php?id=844&page=2#post-5062 Wed, 08 Jun 2011 15:42:31 +0000 mbolivar 5062@http://forums.leaflabs.com/ ratho, Thanks for the heads-up. Our Print implementation is adapted from an earlier version of Arduino's, which didn't specify a way to print out more than 2 decimal digits. I have updated our Print implementation to better track changes made to the Arduino version: <a href="https://github.com/leaflabs/libmaple/commit/5c847fda31d956cc62c511a5fe277d197777de39" rel="nofollow">https://github.com/leaflabs/libmaple/commit/5c847fda31d956cc62c511a5fe277d197777de39</a> You can now give an optional number of digits argument when printing floating-point values. If you're using the IDE, you'll have to make the changes in that commit yourself or wait for the next version to come out. If you're using the Unix toolchain, just pull the latest libmaple and let us know how it goes. snigelen on "Serial1.print decimal places" http://forums.leaflabs.com/topic.php?id=844&page=2#post-5061 Wed, 08 Jun 2011 15:03:12 +0000 snigelen 5061@http://forums.leaflabs.com/ Yes, you're right. On Arduino it works that way, but I forgot the Maple isn't compatible in that point (I discovered the same thing about six months ago but forgot). But there's sprintf and probably others from newlib you can use. But they will eat a lot of flash :-(