Giter Site home page Giter Site logo

makecontroller's People

Watchers

avatar avatar

makecontroller's Issues

More flexible serial i/o via OSC 

Functions to implement:

 * readByte( )
 * Serial_ReadBuffer( )
 * Serial_ReadBufferUntil( someChar )
 * Serial_FlushBuffer( )

(From Trac issue #2)

Original issue reported on code.google.com by [email protected] on 1 Jul 2009 at 4:53

mcbuilder on linux 

Building mcbuilder (specifically qextserialport) on linux requires the
include path of HAL which is not set correctly.
It should be set to the output of :
$pkg-config --cflags hal

Once this is done (by brutally modifying the Makefile), mcbuilder will
compile correctly but won't link because we also need to link to HAL. This
is easily corrected by adding -lhal to the mcbuilder.pro (next to -lusb)

Don't know how this can be cleanly added to mcbuilder.pro but this prevents
from building properly mcbuilder on linux with the current state of the
sources.

Comments welcome!

Original issue reported on code.google.com by [email protected] on 30 Jul 2009 at 1:58

Fasttimer iterrupt enble issue with Interface board. 

What steps will reproduce the problem?
1.Calling FastTimer_SetActive(true), in a task crashes controller when hooked 
to an interface board.
2.
3.

What is the expected output? What do you see instead?
The same frimware runs on the application board V1, but freezes when run on the 
Interface board.

What version of the product are you using? On what operating system?
Have tested this issue with controller V1.1, and firmware 1.51 through 1.62

Please provide any additional information below.
Replacing line 370 of fasttimer.c 
  AT91C_BASE_AIC->AIC_IECR = mask;
with
  AT91C_BASE_AIC->AIC_IECR = 1<<AT91C_ID_TC2;

appears to fix the problem.

Original issue reported on code.google.com by [email protected] on 30 Aug 2010 at 4:46

XBEE_TX64 ApiId WRONG FRAME TYPE 

What steps will reproduce the problem?
1.Trying to send a 64 bit packet formatted for simple transmission.
2.
3.

What is the expected output? What do you see instead?

The expected output has a frame type of 0x10

Without changing the XBEE_TX64 value from 0x00 to 0x10 the frame type is
incorrect in the sent packet.
Found under enum XBeeApiId

What version of the product are you using? On what operating system?

XBEE ZIGBEE PRO SERIES 2 operating in API mode. Windows XP

Please provide any additional information below.
Not sure if this is the correct location to post this issue but hopefully
you found it if you are trying to solve it!!!


enum XBeeApiId
{ 
//  XBEE_TX64 = 0x00,               /**< An outgoing data packet with a
64-bit address. */ WRONG!

CORRECTION
enum XBeeApiId
{ 
//  XBEE_TX64 = 0x10,               /**< An outgoing data packet with a
64-bit address. */ Correct frame type for transmission.

Original issue reported on code.google.com by [email protected] on 12 Jan 2010 at 4:14

consolidate serial ports into single serial API 

(from Trac issue #76)

There are 3 UARTs on the Make Controller - we should provide a more 
comprehensive API to 
control all 3 of them. There's some half-baked code in serial2.c for the 2nd 
one and nothing for the 
3rd one.

Perhaps the serial API should be altered to include an index to which serial 
port each call is referring 
to.

The 2 uarts are integrated - just need to add the debug port, which is a bit of 
a different API 
internally.

Original issue reported on code.google.com by [email protected] on 1 Jul 2009 at 5:07

Osc.cs:PadSize is computed in a wrong way resulting in badly formatted messages 

(From Trac issue #51 by joreg)


my suggestion for the implementation of PadSize is:
{{{
private static int PadSize(int rawSize)
{
   return rawSize + 4 - rawSize % 4;
}
}}}

it is then important to ''not'' include the ending \0 in rawSize for 
0-terminated strings. this is 
simple because for strings you can simply call PadSize(string.length()). 

the current implementation somehow leads to problems when sending messages with 
3, 7, 
11,...parameters as padsize seems to be computed wrong when called with strings 
of lengths of 
multiples of  4 (in this case the typetag string e.g: ,iii or ,iiiffff)

also a similar change is necessary in InsertString. my suggestion:
{{{
private static int InsertString(string s, byte[] packet, int start, int length)
{
  int index = start;
  foreach (char c in s)
  {
    packet[index++] = (byte)c;
    if (index == length)
      return index;
  }

  int pad = 4 - (s.Length) % 4;
  while (pad-- > 0)
    packet[index++] = 0;

  return index;
}
}}}

attached is a version of Osc.cs that works for me so far.

Original issue reported on code.google.com by [email protected] on 1 Jul 2009 at 5:01

Attachments:

DipSwitch reads same value for two different settings 

(from Trac issue #85 by kpratt)

Observed Behavior: '/dipswitch/value' returns 220 for two different settings of 
the dipswitch.

Expected Behavior: Should return 192 in one state and 220 in second state.

Steps to recreate:

--Set bits 7 and 8 high on dipswitch

--Read value using /dipswitch/value in mchelper

--Returns 220 as value (128 + 64 should be 192)

--Set bits 3,4,5 high

--Read value using /dipswitch/value in mchelper

--Returns 220 as value (This is correct: 128 + 64 + 16 + 8 + 4 = 220)

Note: The dipswitch contacts on the back of the board read correctly with a 
multi-meter: ie bits 
set on read 0.0V (connected), and bits set off read 3.258V (not connected), 
indicating this may be 
a firmware issue, rather than a hardware problem.

Repeatability: 100%

System Details: /system/version Heavy 1.5.1 MCHelper Version 2.2.0 (Windows XP)

I'm not using the dipswitch in any of my projects, so it's not a big issue for 
me, but if there is 
anything I can do to help debug or track this down for other people, just let 
me know.

Cheers-- --Kevin




Neglected to specify that the first tests were all on the USB connection. 
Checking again, the 
dipswitch values read correctly when accessing the board with an ethernet 
connection, but 
display the original error when using USB. This behavior is seen on both XP and 
OS X 10.5.

Original issue reported on code.google.com by [email protected] on 1 Jul 2009 at 5:11

mc.usb SLIP decode bug 

As reported by Andy Schmeder -

"In the SLIP decoder, when you encounter a SLIP_ESC character, you have to 
check the buffer 
position again before you dereference the next character because you might be 
at the end of the 
buffer. Currently, it crashes with a segmentation fault if a SLIP_ESC is the 
last character in the 
buffer.

To fix this you have to add a state variable to the object struct to track when 
the decoding state 
machine is in "escape mode" or not."

Original issue reported on code.google.com by [email protected] on 1 Jul 2009 at 5:13

More flexible RPC system 

It would be nice to be able to route messages around the board via a single 
mechanism for different 
transports and protocols - generalize the current OSC system to support things 
like JSON over 
HTTP, etc.

This would entail some kind of centralized entity that can expose resources for 
reading/writing and 
can describe what's available, and can then delegate transport and protocol 
specific issues to 
adapters.

Original issue reported on code.google.com by [email protected] on 1 Jul 2009 at 5:10

svn external in mchelper makes anomymous checkout fail 

What steps will reproduce the problem?
1. svn co http://makecontroller.googlecode.com/svn/mchelper/trunk mchelper

->
Fetching external item into 'mchelper/source/qextserialport'
Authentication realm: <https://makecontroller.googlecode.com:443> Google Code 
Subversion 
Repository
-> asks for username and password -> checkout fails.

This appears to be related to an external added to mchelper/trunk/source/ a few 
days ago (r1336)

Original issue reported on code.google.com by [email protected] on 6 Jul 2009 at 3:19

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.