Jump to content

Peter Trypsteen

  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About Peter Trypsteen

  • Rank

Profile Information

  • Gender
  1. Dear developers of sourceboost: Please take a look at these requests for easier working with worksspaces and projects in them. It would be very convenient to be able to have an overview of all available workspaces. Being able to choose to view all workspaces and show them integrated into the treeview or not, current system, keep zoomed in on the current workspace. An option in View to toggle between the two treeviews would be nice. (Something like a selection box with the text Workspace) This would allow easier changing things from workspaces when reoganizing things. Being abl
  2. Bug description: When going to Workspace>Stand-Alone Project>New Project... Workspace>New Workspace or going to: Workspace>Stand-Alone Project>Quick Project... Sourceboost gives me an open file dialog instead of an save file dialog. Steps to reproduce: Start Sourceboost and go to the menu: - Workspace>Stand-Alone Project>New Project... - Workspace>New Workspace - Workspace>Stand-Alone Project>Quick Project... Expected behaviour: Opens an Open file dialog. How a fixed program should behave. Opens a save file dialog. Is the problem 100% reproduceable:
  3. Other functions in that file add the else too so maybe it's necessary or just good programming practice to do this. Please implement this small improvement.
  4. Didn't take a good look at your example code and you're indeed right about the control flow. Was thinking about some other code. Somehow it seems to make a difference in something I'm using it in.
  5. It does change the code execution quite a bit: The current code structure always executes the do something else part, whether if(something) evaluates to true or not.. The code structure with my change only executes the do something else part.if the if(something) evaluates to false. In my microcontroller project, things onlly worked after I made and used my proposed structure. The other functions also follow the changed structure. EDIT: did not take a good look, see my next reply for a better answer
  6. Support for inttypes.h from the C99 standard. http://en.wikipedia.org/wiki/Inttypes.h#Fixed-width_integer_types The biggest advantage from the types is their more well-defined behaviour. Avoiding nasty surprises which can be very important in embedded design. The inclusion of inttypes would allow writing shorter and more self-explanatory code. The new types would allow more stability (and portability) since the sizes are not implementation defined. Encourages reusable and stable code for e.g. drivers. Minimally the exact width integer types is all that's needed.
  7. Bug description: The function _I2C_TEMPL unsigned char i2c_WRITE(unsigned char i2c_data) Does not work. Steps to reproduce: The bug can be reproduced with getting information from a physical connection or a detailed simulator. Including the i2c_driver.h letting the use_i2c_SW undefined and then calling the function i2c_write with a valid argument triggers the bug. It silently fails. Expected behaviour: Correctly outputs datapulses on the pins. Is the problem 100% reproduceable: Yes. IDE version: 7.20 Compiler: BoostC Compiler version: v7 C Compiler for PICmicro Tar
  • Create New...