Multi core BASIC being tested

What products would you like to see?
basicchip
Posts: 985
Joined: Fri Oct 19, 2012 2:39 am
Location: Lake Tahoe, CA
Contact:

Multi core BASIC being tested

Post by basicchip » Sun Oct 13, 2013 12:39 am

In addition to the LPC43xx series, which have M4 and M0 cores, we have seen some ARM cores with IO processors.

And we have some proto boards of both examples. In fact some simple code examples are running.

Our approach is to KISS, and it will be as simple as main: is where the M4 starts and main2: where the M0 starts. Something similar for the IO processors.



olzeke51
Posts: 369
Joined: Sat May 17, 2014 4:22 pm
Location: South Carolina

Re: Multi core BASIC being tested

Post by olzeke51 » Fri Jul 04, 2014 1:19 am

so multi-core implies multi-tasking, with the associated symaphores/mutexs;
round robin or co-operative scheduling --
**
how is this progressing ?? - we are getting to the point of a OS almost-
Well Pi and Beaglebone Black are there with LInux --
Is FreeRTOS in the wings??
**
enlighten us , oh wise one !!!

basicchip
Posts: 985
Joined: Fri Oct 19, 2012 2:39 am
Location: Lake Tahoe, CA
Contact:

Re: Multi core BASIC being tested

Post by basicchip » Sat Jul 05, 2014 9:26 pm

Multi-core means multiple CPUs, we are using an LPC4330 which has 2 ARM CPUs and 1 IO-handler. All three can run at 200 MHz and each has memory areas that don't interfere with each other, so they really do run at 200 MIPs. There are also versions that have a third ARM CPU, and while they don't come in the package we need to use, we do have a few engineering sample parts.

Right now we have BASIC running on both ARMs, and running some subsets on the IO-handler. We just have been too busy to finish off the BASICtools side of it, but expect to in the next month or two.

I don't really expect to do anything in the RPi or BBB area, but we do have both of those here, having evaluated them for a custom project. So who knows...

olzeke51
Posts: 369
Joined: Sat May 17, 2014 4:22 pm
Location: South Carolina

Re: Multi core BASIC being tested

Post by olzeke51 » Sun Jul 06, 2014 11:30 pm

Yes, multi-core means several mcu.s - but unless you load each one separately with a program,
there is the sense of multi thread -- the main M4 passes off a routine or command [ie thread]to the M0
or the IO processor. the programmer has to keep the result and it storage location in mind to use in the
main program (usually). the videos from NXP refer to this interaction between the M4 and M0. I assume
there is a shared memory block - although there has been no real mention of it in a hard & fast way.
'
so - are you still looking at the 4330 version ?? your 1st post would imply that.
'
are there going to be two terminal/usb outputs - one from each M-core, or will it all be through the
IO processor??? -- don't let the cat out of the bag-though. there might be a ______-spy out there.
one of your 'custom design' pages showed what looked like a stripped/minimal 4330.
'
NXP in a short demo video indicated "FreeRTOS-style" interprocess communication -- that is kind of
where my comment about mutexes and semaphores was coming from. [ I haven't looked at the
FreeRTOS site - but I did notice you did an ARM port to it - of some sort ]
'
not real serious yet - more thinking out loud - the ARMweb will most likely be my next jump.- network
capability seems to be rather important these days. -- I don't know about the manufacturing floor --
I kind of assumed they used RS-485 type stuff. -- re: the minimal 4330.
' olzeke51 - hope you had a good 4th of July !!!!
'
oh, I just learned that there is no real stack pointer mechanism - just 4 pointer registers for
subroutine or interrupt vectors !!!!! hopefully they have improved that in the M4 !! (more research needed)

olzeke51
Posts: 369
Joined: Sat May 17, 2014 4:22 pm
Location: South Carolina

Re: Multi core BASIC being tested

Post by olzeke51 » Thu Jul 10, 2014 2:58 am

which of the 3 interprocessor communication methods are you going to use?
interrupt & flag bit
message queue
semaphore

basicchip
Posts: 985
Joined: Fri Oct 19, 2012 2:39 am
Location: Lake Tahoe, CA
Contact:

Re: Multi core BASIC being tested

Post by basicchip » Thu Jul 10, 2014 3:27 am

Wé just write thé compiler, that is up to you. I like KISS, which to me means some simple mailboes

olzeke51
Posts: 369
Joined: Sat May 17, 2014 4:22 pm
Location: South Carolina

Re: Multi core BASIC being tested

Post by olzeke51 » Fri Jul 11, 2014 2:37 pm

a)so, by implication, __ASM__ will be around so the "SendEvent instruction (SEV) to raise the signal TXEV." pg21 of UM
can be used,
b)printing will be off-loaded to the M0, ??and protected from the user in Main2:, with a corresponding performance hit -
(although at 200Mhz ..!!)
---JUst some questions that come to mind, multi-core intrigues me with the ability to do two things at once, not just
time-slice sharing of cpu.

basicchip
Posts: 985
Joined: Fri Oct 19, 2012 2:39 am
Location: Lake Tahoe, CA
Contact:

Re: Multi core BASIC being tested

Post by basicchip » Fri Jul 11, 2014 2:54 pm

PRINT which uses UART0 will be done with the M4 as is now, and it really is there for debug. But both the M0 and the IOH will be able to send characters out UART0, but both will wait for UART0 to be idle. And both of those will send out a "compressed" character set, which means capital letters, numbers and some punctuation. What that does is to allow BASICtools to figure out where the character came from as 0-127 from M4, 128-195 from M0 and 196-255 from IOH, and then it can indicate that in the debug screen (maybe by color). At least that is today's thinking.

But either the M0 or M4 will have interrupt driven access to the other UARTs, but obviously can't be shared. The IOH while it can access them won't at first have interrupt driven code for them, I'm not sure how that may work in the long run.

There are lots of mechanisms for interprocessor communication, including interrupts that each can trigger.

basicchip
Posts: 985
Joined: Fri Oct 19, 2012 2:39 am
Location: Lake Tahoe, CA
Contact:

Re: Multi core BASIC being tested

Post by basicchip » Sun Jun 21, 2015 6:14 pm

From the info mailbox, a user asked these questions about the DATAlogger board

>I have used the ARMmite controller on and off for the last few years. It has worked quite well but has fallen short on user RAM for Data. I noticed that the new 200 MHz data logger has a lot more RAM & program space in addition to the on board SD storage as well. I have a few questions about this product.
>All of these questions relate to using the BASIC.

>1 Out of the 264K RAM how much is available for Data, especially large Arrays

The first processor has 16K available for data. All code is run from RAM and it has 64K for code. The second CPU has 2K for data and 48K for code. There is also 16K reserved for the IO processor. If you don't use the second CPU or IO processor you could access this space through pointers.

>2 How much of the 8MB Flash is available for code

Code is run from RAM, but loaded from 8MB of Flash at startup. The remaining Flash (about 6MB can be used through the Flash WRITE commands

>3 How fast can data be written to files on the SD card in short bursts, e.g. 50 to 60 bytes at time and sustained, e.g. large arrays, 10s of KBytes etc.

We haven't bench marked it, but it should be limited by the SDcard, as we do use the SPI hardware to do the writes

>4 Is the data written to the SD files in text format and can these files be read on a PC

It is binary data (which can also be ASCII) and it is written in the root directory readable by any NTFS device (PC, tablet, linux box...)

>5 I noticed some issues with the usage of the 1 microsecond free running TIMER1 being tied to a 24bit counter. This Timer has been a CRITICAL resource for my usage on the ARMmite for timing external events on the I/O. Please give some detail as to its usabilty/reliability on this new board.

The ARMmite uses the internal 1% trimmed RC oscillator so it is only 1% accurate, the Data Logger uses an external 20 MHz crystal so its accuracy
is in parts per million

>6 What is the maximum Baud rate for output to the PC screen when running the BASICtools program

The default baud rate for the DataLogger is 115Kbaud. We found that faster is not compatible with many PC serial drivers. The FTDI parts
do support faster. We have tried 1Mb, but don't know what FTDI limits are. You may run into other limits of the driver inside the USB serial driver, how much is allowed over the USB link, or can be handled by the PC program (BASICtools is capable of bursts of 1 Mb, but can't handle that continuously, BT was not designed for that.)

>7 Do I need to order the EVAL kit or just the board if I have the USB cable

You will need a USB-serial converter which is part of the eval kit, or similar to those used for Arduino or available on eBay. See other
posts here at the forum for details

>8 Can the Battery for the RTC be ordered and installed before shipping

Normally it is not an option, but from time to time we have batteries left over from other OEM products we are building. If that
is the case we can install a battery.

>9 What is a typical Interrupt response time on the EINTx pins

The DATAlogger can interrupt on most IO pins, and the response time is quite fast. ARM documents this more fully, but I would expect it
is around 100 nsec.

>10 How fast will the board ship

The boards are in stock and normally ship within a day of an order.

olzeke51
Posts: 369
Joined: Sat May 17, 2014 4:22 pm
Location: South Carolina

Re: Multi core BASIC being tested

Post by olzeke51 » Tue Jun 23, 2015 1:35 am

What is the latest version of the firmware for the DATAlogger? (during some earlier testing there was an
issue with autostarting a program if the RTC/battery was installed and running.)
'
FWIW-Being an early tester, I needed to install my RTC xtal and caps and battery.
'
Is your SPIFI program (that gets copied to RAM) protected from overwrites in your/user routines?
'
Thanks in advance, Gary

Post Reply