Home
JAQForum Ver 20.06
Log In or Join  
Active Topics
Local Time 02:30 30 Apr 2024 Privacy Policy
Jump to

Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me.

Forum Index : Microcontroller and PC projects : Lets all move to ARM, or not?

Author Message
matherp
Guru

Joined: 11/12/2012
Location: United Kingdom
Posts: 8584
Posted: 11:45pm 28 Nov 2014
Copy link to clipboard 
Print this post

Last year I did the Edx course "UT.6.01x Embedded Systems - Shape the World" This uses the TM4C123 Texas development board as the learning platform. This is based on a Cortex M4 processor. The TM4C123 is available at a very reasonable price through RS, Farnell etc. It is a very powerful little board and includes a second ARM processor that acts as a JTAG programmer and debugger as well a LEDs and switches for experimentation. A development environment similar to MplabX is available free from TI.
The course is excellent and when they run it again I can recommend it highly.
However, it always amuses me when people suggest things like "just port MMBasic to ARM"
I've attached the very first program we developed on the course, flashing an LED. We, the students, got a good chunk given to us as a start but it is interesting to see the amount of code needed just to set up a single pin on the chip as an output. Remember on Micromite we just go "SET PIN x DOUT", Geoff hides all this stuff from us and on PIC it is very much easier anyway.

Enjoy

// main.c
// Runs on LM4F120 or TM4C123
// C2_Toggle_PF1, toggles PF1 (red LED) at 5 Hz
// Daniel Valvano, Jonathan Valvano, and Ramesh Yerraballi
// July 21, 2013

// LaunchPad built-in hardware
// SW1 left switch is negative logic PF4 on the Launchpad
// SW2 right switch is negative logic PF0 on the Launchpad
// red LED connected to PF1 on the Launchpad
// blue LED connected to PF2 on the Launchpad
// green LED connected to PF3 on the Launchpad


#define GPIO_PORTF_DATA_R (*((volatile unsigned long *)0x400253FC))
#define GPIO_PORTF_DIR_R (*((volatile unsigned long *)0x40025400))
#define GPIO_PORTF_AFSEL_R (*((volatile unsigned long *)0x40025420))
#define GPIO_PORTF_PUR_R (*((volatile unsigned long *)0x40025510))
#define GPIO_PORTF_DEN_R (*((volatile unsigned long *)0x4002551C))
#define GPIO_PORTF_LOCK_R (*((volatile unsigned long *)0x40025520))
#define GPIO_PORTF_CR_R (*((volatile unsigned long *)0x40025524))
#define GPIO_PORTF_AMSEL_R (*((volatile unsigned long *)0x40025528))
#define GPIO_PORTF_PCTL_R (*((volatile unsigned long *)0x4002552C))
#define PF4 (*((volatile unsigned long *)0x40025040))
#define PF3 (*((volatile unsigned long *)0x40025020))
#define PF2 (*((volatile unsigned long *)0x40025010))
#define PF1 (*((volatile unsigned long *)0x40025008))
#define PF0 (*((volatile unsigned long *)0x40025004))
#define GPIO_PORTF_DR2R_R (*((volatile unsigned long *)0x40025500))
#define GPIO_PORTF_DR4R_R (*((volatile unsigned long *)0x40025504))
#define GPIO_PORTF_DR8R_R (*((volatile unsigned long *)0x40025508))
#define GPIO_LOCK_KEY 0x4C4F434B // Unlocks the GPIO_CR register
#define SYSCTL_RCGC2_R (*((volatile unsigned long *)0x400FE108))

void PortF_Init(void){ volatile unsigned long delay;
SYSCTL_RCGC2_R |= 0x00000020; // 1) activate clock for Port F
delay = SYSCTL_RCGC2_R; // allow time for clock to start
GPIO_PORTF_LOCK_R = 0x4C4F434B; // 2) unlock GPIO Port F
GPIO_PORTF_CR_R = 0x1F; // allow changes to PF4-0
// only PF0 needs to be unlocked, other bits can't be locked
GPIO_PORTF_AMSEL_R = 0x00; // 3) disable analog on PF
GPIO_PORTF_PCTL_R = 0x00000000; // 4) PCTL GPIO on PF4-0
GPIO_PORTF_DIR_R = 0x0E; // 5) PF4,PF0 in, PF3-1 out
GPIO_PORTF_AFSEL_R = 0x00; // 6) disable alt funct on PF7-0
GPIO_PORTF_PUR_R = 0x11; // enable pull-up on PF0 and PF4
GPIO_PORTF_DEN_R = 0x1F; // 7) enable digital I/O on PF4-0
}
unsigned long Led;
void Delay(void){unsigned long volatile time;
time = 145448; // 0.1sec
while(time){
time--;
}
}
int main(void){
PortF_Init(); // make PF1 out (PF1 built-in LED)
while(1){
Led = GPIO_PORTF_DATA_R; // read previous
Led = Led^0x02; // toggle red LED, PF1
GPIO_PORTF_DATA_R = Led; // output
Delay();
}
}









// Color LED(s) PortF
// dark --- 0
// red R-- 0x02
// blue --B 0x04
// green -G- 0x08
// yellow RG- 0x0A
// sky blue -GB 0x0C
// white RGB 0x0E
// pink R-B 0x06

 
JohnS
Guru

Joined: 18/11/2011
Location: United Kingdom
Posts: 3659
Posted: 01:47am 29 Nov 2014
Copy link to clipboard 
Print this post

That CPU won't run MBasic, but in any case there are MUCH better value ARM chips from ST and especially AW.

Where a chip has various alternate features multiplexed onto a pin you have to expect a bit of extra set-up code but who cares as you only run it once, normally.

Once set up there's little to do and at 1GHz the AW chips work well.

With 1GB RAM and 4GB NAND you can still get a board for almost free. OTOH these are not typically hobby-solderable etc (may be 8 layer and BGA.)

Even RPi has "only" 512MB RAM and "only" runs at 700MHz for $35. You can flash a LED in a tight loop with 2 instructions (1 to invert the LED and 1 to jump back) at 22MHz. Not useful but shows it's not crippled and doesn't need complex code.

My PICkit-replacement using an RPi programs in a few seconds, about 10 times faster than a PIC32 doing it. Code ported with no troubles except adding a few delays as the target PIC32 could not keep up.

Depends whether Geoff fancies a re-write of all the lower level stuff.

JohnEdited by JohnS 2014-11-30
 
viscomjim
Guru

Joined: 08/01/2014
Location: United States
Posts: 925
Posted: 02:25am 29 Nov 2014
Copy link to clipboard 
Print this post

Hi Matherp, for me personally, I'll go with the "or not" option in your topic. Geoff has really done a great job making this type of thing mindless and it just "works". I know there are a lot of options out there, but for what I have been doing, the uMite has fit the bill soooo many times. I appreciate all the posting you are doing on this forum and hope you continue to do so. Your code examples are very helpful and I am learning a lot from them. That goes for all the active members here too!!!!
 
basicchip

Newbie

Joined: 25/11/2014
Location: United States
Posts: 9
Posted: 06:11am 29 Nov 2014
Copy link to clipboard 
Print this post

As the author of ARMbasic running on many different ARMs from NXP, Freescale and TI, I will throw my 2 cents in here.

While I haven't dug into MBasic source, it is an interpreter. ARMbasic is an evolution of an interpreter that we moved from 8051 to Z80 (where it became a compiler) to ARM where it was both an interpreter initially and transitioned to compiler. Interpreters are usually pretty portable, with the main effort expended on handling initialization, IOs and interrupts. A large percentage of the code should move directly to the ARM. The disadvantage is speed of interpreters in general is about 50-100 times slower than compiled code, though if you spend a lot of time trying to optimize the interpreter you can get to less than 30:1 difference.

Now that ARMs are taking over the low end embedded world, we don't see much reason to move to other architectures. Our initial version was a self hosted compiler on the LPC2106 which was a limited BASIC that mimicked PBASIC as a language and in a Stamp form factor. We still have a version of the compiler running on LPC1756/LPC1768 that we use for handling BASIC code that can be embedded in web pages for our web products. That code is actually compiled by the ARM during web page servicing and acts as a link to user program. So an ARM hosted compiler can run on fairly small chips.

Geoff has done a great job tailoring a tool for the hobbyist community, and I don't know if he wants to take on another project. However we would be willing to work with him to port to an LPC4330 which has dual 204 MHz CPUs camera and VGA capable interfaces. So I'll invite him to contact me if he wants to pursue this.
 
Dylan
Regular Member

Joined: 17/06/2013
Location: Netherlands
Posts: 81
Posted: 08:16am 29 Nov 2014
Copy link to clipboard 
Print this post

  basicchip said  Now that ARMs are taking over the low end embedded world, we don't see much reason to move to other architectures.


ARM has taken over the mid end to some degree. The low end remains 8 or 16 bit and mostly programmed in C.

My first language was BASIC (on ZX 81 and Spectrum) and it is a decent choice for an embedded interpreter. Those were 4 MHz Z80s with 8k/1k and 16k/16k ROM/RAM respectively.
 
basicchip

Newbie

Joined: 25/11/2014
Location: United States
Posts: 9
Posted: 01:20pm 29 Nov 2014
Copy link to clipboard 
Print this post

I can now buy an ARM running 16 MHz with 8K of Flash and 1K of RAM for less than anything but PIC10 devices, and I expect that to change next year. And that is 2-4x the speed and memory of those PIC10s

Yes the typical programming language is C. At 25 cents in volume which should happen in 2015, you would have to have either a significant software investment in older architectures or something else not to switch.

A clean sheet design started now will use an ARM in the low-mid range. (period!)
 
JohnL
Senior Member

Joined: 10/01/2014
Location: Seychelles
Posts: 128
Posted: 03:30pm 29 Nov 2014
Copy link to clipboard 
Print this post

  Quote  Geoff has done a great job tailoring a tool for the hobbyist community, and I don't know if he wants to take on another project. However we would be willing to work with him to port to an LPC4330 which has dual 204 MHz CPUs camera and VGA capable interfaces. So I'll invite him to contact me if he wants to pursue this.


MMbasic is Geoffs baby. Statistically, not many basic interpreters have survived over the years. Where is MMbasic for Maximite at the moment, well behind with upgrades and not being discussed much publicly?

More people are expressing issues about use of Cfunctions. MMbasic compiling option would solve most problems and maybe attract more users. Compiled hex for other ucontrollers, particularly popular low cost 32bit ARM would not hurt.

How long can Geoff keep the MMbasic show going by himself?
 
robert.rozee
Guru

Joined: 31/12/2012
Location: New Zealand
Posts: 2289
Posted: 04:02pm 29 Nov 2014
Copy link to clipboard 
Print this post

to me, the micromite (both MX150 and MX170 versions) represent an extremely versatile and cost-effective tool. the big pluses are (1) the BASIC being interpreted, and (2) the DIP package. while cheaper chunks of silicon certainly exist, the ancillary components quickly overtake any cost savings - it is hard to beat one capacitor, a regulator, and a scrap of veroboard for low-cost computing. while the only software tool required is teraterm.

at the moment, i see the biggest problem being folks expecting a micromite to become more than it is. when one wants to bolt on VGA output and a PS/2 keyboard to make a complete system, a far more sensible route to follow is the long-neglected minimite. the death of the minimite was due to it being so expensive for what it contains. really, a populated minimite PCB should have been available for around us$15 or even less. i believe that someone is currently looking at addressing this.

with the colour maximite, i see the way forward as also being a cheapening of the hardware along with more robust design. a better power supply solution, driverless USB interface, shoring up the PS/2 keyboard interface, etc.

one common weakness of both minimite and maximite seems to have been the SD slot. i'd like to see a switch over to a 0.1" 2-row header that matches up with the SD daughterboards that are a dime-a-dozen on ebay. similarly for the 5v PSU.

all the above requires no change in processor. the micro/mini/maxi ranges already have more than enough resources (and are fast enough) for each of their intended niches. the microchip processors are relatively cheap, readily available in large and small quantity, and likely will all be available for many years to come.

there simply is not much of a case for moving over to a compiled basic that sucks up onboard resources. and if one were to want to go that way, then why not just get a raspberry pi?


just my 2 cents worth...
rob :-)
 
G8JCF

Guru

Joined: 15/05/2014
Location: United Kingdom
Posts: 676
Posted: 05:31pm 29 Nov 2014
Copy link to clipboard 
Print this post

@JohnL

  JohnL said  More people are expressing issues about use of Cfunctions.


This is the third time at least that you have expressed a pejorative opinion about CFunctions; what have you got against CFunctions ?

Are you volunteering to create/write a MMBasic compiler and make it available for free, (as in USD/AUD/GBP/EUR 0.00), to the MMBasic community ? If you are, count me in as a supporter. We are all waiting for you to step up to the plate.

As I said before, there are plenty of excellent compiled Basics for ARM out there, eg Bruce's Coridium; if people want compiled 32 bit Basic, then all power to their elbow and off they go. If people want ease of use, simplicity, immediacy and low cost, then stick with MMBasic and CFunctions.

Put up or .... ..

PeterEdited by G8JCF 2014-12-01
The only Konstant is Change
 
robert.rozee
Guru

Joined: 31/12/2012
Location: New Zealand
Posts: 2289
Posted: 06:34pm 29 Nov 2014
Copy link to clipboard 
Print this post

i must admit that at first i too was highly sceptical of exposing the level of access that CFunctions affords to all and sundry, preferring to see us all depend upon geoff to make the numerous MMbasic enhancements requested. the failure here is in the depending upon geoff for everything. it is simply not fair. with CFunctions available, the workload of adding features to MMbasic is shared with the wider MMbasic community, in a way that preserves the integrity of the MMbasic core.

i would agree that writing CFunctions poses a challenge for most MMbasic users, it does after all require learning C, setting up a complex environment, and some trial and error. but one must note that actual use of fully debugged CFunctions written by other people is relatively painless. and the pool of publicly available CFunctions is slowly expanding - from where i am it seems that if someone requests a useful CFunction, someone else is likely to be happy to write it for them.

the one thing i would like to see is someone maintain a library of well-tested CFunctions, with C source included, as a branch of geoff's website. and i would imagine that over time the functionality of the most popular CFunctions will end up being implemented within MMbasic by geoff (space permitting).


rob :-)Edited by robert.rozee 2014-12-01
 
MicroBlocks

Guru

Joined: 12/05/2012
Location: Thailand
Posts: 2209
Posted: 03:15am 30 Nov 2014
Copy link to clipboard 
Print this post

I have looked at the CFunctions and as long it is to speed up some simple stuff it is great. Once you want to have something a little more difficult then access to some standard C libraries would really open it up. As those libraries are already used by the firmware not much extra flash is needed.
It would enable CFunctions to be a test ground for future basic commands/functions.
A hook to interrupts would be another nice to have.
I think most can be available by having a pointer table in flash.

I am not complaining! I see a powerful future in using them.
It is just that most of the C programming I did was on a desktop system and was heavenly depending on the standard libraries. So often I use strcmp, strcat, and of course malloc/free, (s)printf and lots of others. Without them I feel a little lost.
The strxxx are however easily replaced with some own code.


Microblocks. Build with logic.
 
robert.rozee
Guru

Joined: 31/12/2012
Location: New Zealand
Posts: 2289
Posted: 03:40am 30 Nov 2014
Copy link to clipboard 
Print this post

the problem with trying to expose the standard C routines used within the MMbasic firmware is that the firmware itself is not 'self-aware' of these functions. only the C compiler used to build MMbasic knows about the entry points to the routines. it is a little bit like trying to perform brain surgery on yourself. not strictly speaking impossible, but ill advised and fraught with caveats.

what would be more practical, but not simple, would be to allow a CFunction to access a subset of MMbasic commands like print, setpin, etc. but even this would be difficult to implement, and even more difficult to make use of within a CFunction. one might just as well use MMbasic code directly.

rob :-)
 
Goeytex
Regular Member

Joined: 12/05/2014
Location: United States
Posts: 74
Posted: 03:59am 30 Nov 2014
Copy link to clipboard 
Print this post

The thread title is: "Lets all move to ARM, or not?"

My answer is an emphatic "Or Not!"

This is not because I think ARM is less capable or inferior in any way. It is not. It is because (for lack of a better cliche) there is no "one size fits all" solution for embedded systems whether it be for commercial or hobby projects.

Why would anyone want to limit themselves to only one type or platform? Seems silly to me.

If a Micromite suits my needs I might use that, particularly if that is what I like and have experience with. Same goes for Picaxe, Arduino, ARM or any other type/platform.

From a commercial prospective, why would I consider an 32-bit ARM device in a system where a 14-Pin, 8-Bit PIC, ATMEL or 8051 is more than adequate?

To address another point. This forum (Microcontroller and PC Projects) seems to have evolved into a "Maximite/Micromite dominated support group. For the lack of existence of dedicated "Mite" forum all of the mite fans come to this forum.

May I kindly suggest a dedicated Maximite/Micromite forum and another for folks who may also use things other than mites? I think all will be better served with a dedicated Micromite/Maximite forum.Edited by Goeytex 2014-12-01
 
WhiteWizzard
Guru

Joined: 05/04/2013
Location: United Kingdom
Posts: 2794
Posted: 10:45am 30 Nov 2014
Copy link to clipboard 
Print this post

  Goeytex said  To address another point. This forum (Microcontroller and PC Projects) seems to have evolved into a "Maximite/Micromite dominated support group.


May I suggest thats because the MicroMite is attracting more attention now than all the others!!!

Guess I'm going to get some 'abuse' now from 'C only' members . . .


For everything Micromite visit micromite.org

Direct Email: whitewizzard@micromite.o
 
G8JCF

Guru

Joined: 15/05/2014
Location: United Kingdom
Posts: 676
Posted: 12:28pm 30 Nov 2014
Copy link to clipboard 
Print this post

Also, the others tend to have a dedicated forum for their products - aka 'Support'. MMBasic is a non-profit activity for Geoff, so the incentive to setup, maintain, and police a dedicated forum must be very low compared to commercial enterprises where such a forum is an essential requirement in the furtherance of sales of their product(s).

Peter
The only Konstant is Change
 
Goeytex
Regular Member

Joined: 12/05/2014
Location: United States
Posts: 74
Posted: 01:23pm 30 Nov 2014
Copy link to clipboard 
Print this post

  WhiteWizzard said  
  Goeytex said  To address another point. This forum (Microcontroller and PC Projects) seems to have evolved into a "Maximite/Micromite dominated support group.


May I suggest thats because the MicroMite is attracting more attention now than all the others!!! [/Quote]

Well, not generally, but at this forum it does. But that stands to reason, since this is the only open forum that I am aware of where the the designer/author announces updates and where where experienced users share their wisdom/advice and support is offered. So it stands to reason that the popularity HERE is high. It is a logical stretch to conclude or suggest that the popularity/interest here are indicative of interest in general. But I think you know that.

My point was that MMBASIC/Micromite/Maximite need and deserve z dedicated forum due to the popularity HERE. I also think that could also lead to even more interest.

  Quote  
Guess I'm going to get some 'abuse' now from 'C only' members . . .


Not from me. I prefer BASIC to C where and when it serves the purpose.

Edited by Goeytex 2014-12-01
 
Print this page


To reply to this topic, you need to log in.

© JAQ Software 2024