MikroElektronika Forum

These are the wishes we've gathered so far:

• -- MIDI support
  -- I2c slave mode
  -- Overloading routines
  -- Bit variable + bit operations
  -- Build utility (compile all units in project)
  -- Possibility to rotate fonts on GLCD
  -- Smart card library
  -- Support for 10Fxxx PICs
  -- DTMF library
  -- BANKSEL command for assembly
  -- Table with common register setup for most used chips.
  -- ORG directive to work with library routines
  -- Regular (slower) mode for I2C
  -- PS2_Write routine
  -- File transfer in terminal tool
  -- Recompile if needed during simulation
  -- Selection ident with TAB key (Editor)
  -- Indicators in IDE for compiled/programmed project
  -- Code folding feature in Code Editor
  -- Option to switch off animated menus- sets as default in windows
  -- Editor: TAB as spaces
  -- Sound routine
  -- PORT.Variable = ...
  -- USB routines
  -- Pulse_In/Out routine (done as sound routine)
  -- Show procedures stack depth in Statistics
  -- Programming chips from IDE
  -- Software protocols: uart, spi, i2c
  -- Flexibile LCD configuration
  -- Driver for 8-bit LCD
  -- 5ms delay in LCD library is not needed
  -- FAT16 read file function
  -- Floating point support
  -- LCD_Out to write at current position
  -- User defined tools
  -- IRDA driver+example
  -- Reading and writing program flash
  -- BMP editor for graphic LCD
  -- Variable delays
  -- Constant declarations with constant expressions
  -- Comments in assembly
  -- Auto save option in IDE
  -- Inverted soft_uart output

Italics mark what has been resolved.

Can't wait....

What about support for the "new" 20 pin chips as the PIC16f690 ? please !!!

malife wrote:What about support for the "new" 20 pin chips as the PIC16f690

It will be added.

HI MP team

Its is possible to add in the spi_expand library, support for the mcp23S17 ? The support for the MCP23S08 work great but its only 8bit...

Another thing... its is possible to add in the Eternet library, support for the microchip ENC28J60 ? That will be great to work only with microchip componant ))))

THX

piort wrote:Its is possible to add in the spi_expand library, support for the mcp23S17 ? The support for the MCP23S08 work great but its only 8bit...

We received samples last week. This week we start to work on the library, but I do not believe it will come out in the incoming release, which is more-less already packed and ready.

Another thing... its is possible to add in the Eternet library, support for the microchip ENC28J60 ?

We are working on it too.

The 12F675 map in exempel map move too a "12F" map.
Some exampels for the 16F88.

One thing that would be useful is a set of routines that converts time (as in RTC) between BCD HH:MM:SS DD/MM/YY format and 32-bit longint based on an arbitrary base time (00:00:00 on 01/01/00 would be usable in most cases). Thus, the longint would be the number of seconds since the base time (which would give about 63 years; the libraries would have to be adjusted in 2063).

This could be useful for timestamping files (takes 4 bytes instead of 6), and also for use with binary RTC chips. It would also facilitate time arithmetic.

So, for example, you might have a function Seconds(longtime:longint):byte Which would return the BCD justified seconds digits corresponding to the time in the argument, and you'd have a function longtime(seconds, minutes, hours, days, months, year : byte):longint to assemble the BCD digits into the binary time.

lgrfbs wrote:The 12F675 map in exempel map move too a "12F" map.
Some exampels for the 16F88.

We will work on it.

LGR wrote:One thing that would be useful is a set of routines that converts time (as in RTC) between BCD HH:MM:SS DD/MM/YY format and 32-bit longint based on an arbitrary base time (00:00:00 on 01/01/00 would be usable in most cases).

Great idea, just we do not have time to do it now. If anyone voluntiers to do so, please let us know.

I don't know what other think, but in my opinion all conversation procedures (such us ByteToStr) better would be functions not procedures: Usart_Write_Text(ByteToStr(x)) then can be used. And also the string+string should be implemented and Usart_Write_Text improved: Usart_Write_Text(txt1+txt2,' ',txt3)

Text concatenate is a must in pascal compilers.

Also i STILL have troubles initializing records types (dont initializate) and with medium complexity if, by example :


if (a> 250) and (B=0) fails to work.

Sadly, theres no way to debug it, so you must imagine what is happening. I say imagine because many times the output code dont make wich you do in pascal.

The possibility to make custom GLCD fonts more than 8 pixels tall would be really helpful. Not only would this allow large numeric and text displays, but you could create wingding - like icons.

It would be be acceptable to make them in increments of 8 pixels, i.e. 8, 16, 24, 32......

It would be really nice to have a Visual Initializer tool (similar to Microchip´s One) so one could configure ports, timers, interrupts and the sort via a graphical tool and then just generate an "InitializePic" procedure.

I agree about the visual initialization tool, and that concept can extended to any an all initializations. For example, the CAN library would be a lot easier to use if there was a page full of radio buttons and check boxes that automatically generated the init procedure call. Or as another example, a wizard that allows you to define which GLCD control pins go to which I/O pins, and automatically generates the custom initialization call.

But I think I ask for too much....

LGR wrote:But I think I ask for too much...

We rather accept such challenges than something easier.

We might work on it... Can't promise.