![]() |
Forum Index : Microcontroller and PC projects : MMbasic 5.3 Requests.
![]() ![]() ![]() ![]() |
|||||
Author | Message | ||||
MicroBlocks![]() Guru ![]() Joined: 12/05/2012 Location: ThailandPosts: 2209 |
Maybe a PORTA(), PORTB() etc.. could give direct access to the pic's pins. Or maybe a variable MM.PORTA, MM.PORTB, etc... could retrieve the bits directly. It would give fast access to the PIC's ports for when parallel manupulation is needed. Microblocks. Build with logic. |
||||
kiiid Guru ![]() Joined: 11/05/2013 Location: United KingdomPosts: 671 |
I would suggest the function INKEY$ to become INKEY$(count), where "count" will define how many characters should be removed from the input buffer. Almost every time when I am using this function I end up storing the input into a temporary variable, then checking with it, and then if necessary reading into another one, merging the two, and that forms the input. It would have been much cleaner solution if there was a line IF INKEY$(0)<>"" then ...<take the full input> http://rittle.org -------------- |
||||
Geoffg![]() Guru ![]() Joined: 06/06/2011 Location: AustraliaPosts: 3282 |
If I have it right, you want to see if there are any characters in the buffer without removing them. Sort of like a LOC() function for the console? Geoff Geoff Graham - http://geoffg.net |
||||
kiiid Guru ![]() Joined: 11/05/2013 Location: United KingdomPosts: 671 |
That's right. Every time I use INKEY$ it has been exactly for that purpose. In fact I can't think of a logical reason why it forcefully removes the first character. PS. Or maybe LOC(#0) would be a more appropriate solution? http://rittle.org -------------- |
||||
Geoffg![]() Guru ![]() Joined: 06/06/2011 Location: AustraliaPosts: 3282 |
Sounds good. I will add it to the list for possible inclusion in the next version. Geoff Geoff Graham - http://geoffg.net |
||||
redrok![]() Senior Member ![]() Joined: 15/09/2014 Location: United StatesPosts: 209 |
Hi Geoff; I researched others working with the SERVO command. matherp http://www.thebackshed.com/forum/forum_posts.asp?TID=7888 My problem with the SERVO command is a bit different. I get it, I have to use 1A if I want to use 1B. matherp wanted to disable 1A. So do I, sort of, but I want 1A still active yet outputting zero pulse widths. I'm wanting to use SERVO as a slower version of PWM. I want to alternately output pulses on 1A vs. 1B to drive a motor forward, on 1A, and reverse, on 1B. The problem is the minimum pulse width allowed is 0.01. Not good. Is there a way to make SERVO output zero pulse width without it complaining I am out of bounds. I understand that SERVO was designed to be used with real RC servos which must have a recurring pulse. (BTW, some digital servos don't need this requirement as they hold position in the absence of pulses.) I guess the first question is is SERVO capable of outputting zero pulse width? Anyway, I was thinking that there would be a way to give SERVO a clew that the width could be zero and still be compatible with normal RC servo users. I thought that the use of negative pulse widths would work. But -0 evaluates to 0 which doesn't work. ( the STR$() function allows - space padding, the negative value appends the + symbol.) How about using a width range of -100.0 to -118.9 to represent 0 to 18.9. (for a 50Hz freq) Any thoughts? I did get my light sensor to motor driver to work using the PULSE command but this is not very satisfactory an the cycle time is tied into the rate the sensor operates which is a bit slow. redrok |
||||
Geoffg![]() Guru ![]() Joined: 06/06/2011 Location: AustraliaPosts: 3282 |
I think that I can figure out what you are trying to do - but it is a rather specialised requirement. The simplest answer would be to have a pair of AND gates to switch the PWM signal from one lead of the motor to another. Another possibility would be to use both PWM channels with 1A driving one side of the motor and 2A driving the other. Geoff Geoff Graham - http://geoffg.net |
||||
Nathan Regular Member ![]() Joined: 10/01/2016 Location: GermanyPosts: 49 |
Hi Geoff, I have a small wish for 5.3. I'm looking for something like the following for c-function development. // the following vectors are for function implementation #define Vector_userFunc_1 (*(int*)0x9D0000D8) // user function 1 #define Vector_userFunc_2 (*(int*)0x9D0000DC) // user function 2 #define Vector_userFunc_3 (*(int*)0x9D0000E0) // user function 3 #define Vector_userFunc_4 (*(int*)0x9D0000E4) // user function 4 #define Vector_userFunc_5 (*(int*)0x9D0000E8) // user function 5 #define Vector_userFunc_6 (*(int*)0x9D0000EC) // user function 6 // the following vectors are to store GetMemory(a) addr info #define Vector_userFuncMem_1 (*(int*)0x9D0000F0) // user function memory 1 #define Vector_userFuncMem_2 (*(int*)0x9D0000F4) // user function memory 2 #define Vector_userFuncMem_3 (*(int*)0x9D0000F8) // user function memory 3 #define Vector_userFuncMem_4 (*(int*)0x9D0000FC) // user function memory 4 #define Vector_userFuncMem_5 (*(int*)0x9D000100) // user function memory 5 #define Vector_userFuncMem_6 (*(int*)0x9D00010A) // user function memory 6 The above would allow me to smooth my developments a lot. any chance? ![]() Nathan |
||||
Geoffg![]() Guru ![]() Joined: 06/06/2011 Location: AustraliaPosts: 3282 |
Hi Nathan, I cannot see how this could be useful, it is just a collection of pointers. What are they pointing too and how are they set? Can you use something like CFuncRam instead? If I add something to MMBasic I try to make sure that it will have wide appeal, otherwise the language would become too cluttered to be useful. I am not sure that this qualifies as having wide appeal. Geoff Geoff Graham - http://geoffg.net |
||||
Nathan Regular Member ![]() Joined: 10/01/2016 Location: GermanyPosts: 49 |
Hi Geoff, they are like a template class. You can bind a function to it as you did it already. The benefit it is is not predefined, yet. At the moment I'm working on a ST7735 tft driver. It will have the following access points in adition. void writeVideoRam(unsigned char *bitMap, unsigned char *cPtr, unsigned short mode ,short x1, short y1, short width, short height) int DefineRegion(int xstart, int ystart, int xend, int yend) void readVideoRam( unsigned char * cPtr ,unsigned short cNum) I want to make the three functions available to other of my c-functions. So I want to add them to the cfunctions.h file. the driver make the followings intialization: Vector_userFunc_1= (unsigned int)&writeVideoRam + libOffs; Vector_userFunc_2= (unsigned int)&DefineRegion + libOffs; Vector_userFunc_3= (unsigned int)&readVideoRam + libOffs; So I can use readVideoRam from an other c-function on the following way: #define readVideoRam(a,b) ((void (*)(unsigned char *,unsigned short)) Vector_userFunc_3) (a,b) Sometimes I'm thinking a little bit around the corner. Does the explanation helps a little bit??? Nathan |
||||
matherp Guru ![]() Joined: 11/12/2012 Location: United KingdomPosts: 10201 |
That is clever ![]() |
||||
erbp Senior Member ![]() Joined: 03/05/2016 Location: AustraliaPosts: 195 |
Hi Geoff, Would it be possible to have a new Read Only Variable included - suggested name MM.PINCOUNT - which would return the number of pins on the CPU chip? Currently MM.DEVICE$ will identify for example if the chip is a MX170/270 or a MX470, however there is no way I am aware of to programmatically know whether code is running on a 28 or 44 pinner in the case of Micromite MkII or 64 or 100 pinner in the case of Micromite Plus. Knowing the CPU pin count would allow code to be written that could assign the correct pin numbers to use for certain I/O pins thus allowing the same code to be run on a number of different devices without requiring any modification (within the limitations of the capabilities of each device of course). e.g. if I needed to use a Count input, I could assign pin 15 on a 28 pinner, pin 42 on a 44 pinner, pin 52 on a 64 pinner or pin 34 on a 100 pinner and so be able to run my code on any of the 4 devices. Thanks for considering this. Phil. |
||||
Geoffg![]() Guru ![]() Joined: 06/06/2011 Location: AustraliaPosts: 3282 |
Hi Phil, There is a CFunction module called CPUType which will return the type of CPU that MMBasic is current running on. Would this do what you want? It is included in the "Embedded C Modules" folder in the firmware zip file. Geoff Geoff Graham - http://geoffg.net |
||||
MicroBlocks![]() Guru ![]() Joined: 12/05/2012 Location: ThailandPosts: 2209 |
Maybe MM.DEVICE$ can return the number of pins as well. like: [code] MX170-28 MX170-44 MX270-28 MX270-44 MX470-64 MX470-100 etc.. [/code] Microblocks. Build with logic. |
||||
robert.rozee Guru ![]() Joined: 31/12/2012 Location: New ZealandPosts: 2428 |
what if MM.PINCOUNT returned the number of pins? this might incur less coding overhead. cheers, rob :-) |
||||
JohnS Guru ![]() Joined: 18/11/2011 Location: United KingdomPosts: 4034 |
Pincount etc are all OK if there's plenty of flash free. Otherwise, why not put some code into just the programs that need it? I suppose you'd decode the value the CPU has burned into it (such as by Mchp - is DEVID enough or would another small table be needed?). John |
||||
robert.rozee Guru ![]() Joined: 31/12/2012 Location: New ZealandPosts: 2428 |
good point. perhaps MM.DEVID would suffice. or is the relevant location already accessible using PEEK? rob :-) |
||||
JohnS Guru ![]() Joined: 18/11/2011 Location: United KingdomPosts: 4034 |
I expect/hope PEEK works. John |
||||
erbp Senior Member ![]() Joined: 03/05/2016 Location: AustraliaPosts: 195 |
@Geoff, actually the CPUType CFunction will handle my requirements just nicely - Thanks. Phil. |
||||
Geoffg![]() Guru ![]() Joined: 06/06/2011 Location: AustraliaPosts: 3282 |
Nathian/Peter, I still don't see the need. Could you store the pointers in the RAM pointed to by CFuncRam? There are 256 bytes there, more than enough. Geoff Geoff Graham - http://geoffg.net |
||||
![]() ![]() ![]() ![]() |
![]() |
![]() |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |