CoreBASIC Wish List

[Paul Curtis]

So, as the author of CoreBASIC, you have what I decided to give you.  Fantastic.  Works well for me.

Now, it's up to you to shake the tree and figure out what you want SolderCore or CoreBASIC to do for you that it doesn't do already.  Within reason, of course.

So, ideas here please...

[soldercoreandy]

You have a very fast CoreBasic and also an Ethernet network interface. What would it take to "serve up" a web page application from CoreBasic?
eg a "mini web server" driven by internal variables and direct I/O from SolderCore. This would be way too cool

[Paul Curtis]

That actually already exists.  But it isn't enabled.  One of the first ideas we had was to enable web output by inserting CoreBASIC variables as server-side includes into web pages.  And Jon has already controlled a LED from a web browser using CoreBASIC.

One of the other projects is to write and edit CoreBASIC programs in a web browser.  This was somewhat complete, but there wasn't time to finish it before release... unfortunately.

So, in short, this may del appear, but you can edit CoreBASIC programs on the SolderCore at the moment--I wrote the editor when it was clear that we  didn't have time to finish the web interface for launch.

[soldercoreandy]

When this CoreBasic web interface appears you got three new customers ready to order SolderCore.

[TheReelDill]

... user interface tools for rapid development of front end MMI's. e.g.Bar graphs, osciloscope trace, buttons, switches etc.  Like you get with Labview for example.

[TheReelDill]

... data structure and enumertors

On Thursday, June 21, 2012 6:27:32 PM UTC+1, Paul Curtis wrote:

[Paul Curtis]

Again, considered this.  Luminary/TI also did this with their IDM, and we have customers that also produce products that are "intelligent LCDs" which do all this stuff.  The problem is integrating it into CoreBASIC in a nice way.  It is easy to do in that under the hood of CoreBASIC is an RTOS, hence a GUI thread is easy enough.

[Paul Curtis]

Data structures are hard in an interpreter.  :-(

In the guts of CoreBASIC is a property and object system that is exposed to some extent at the user level.  What we could do is something along JavaScript lines, using maps.  However, with added complexity comes additional memory usage.  I tried to keep the tokenized program very compact, hence releasing memory for user data.

One of the things we wanted to do was add external memory (RAM) on the SolderCore, but the LM3S bus is particularly crap.  :-(

[TheReelDill]

... integer variable type (like the bbc b had)

... double variable type  

On Thursday, June 21, 2012 6:27:32 PM UTC+1, Paul Curtis wrote:

[Paul Curtis]

On Friday, July 6, 2012 2:14:49 PM UTC+1, TheReelDill wrote:

... integer variable type (like the bbc b had)

The interpreter uses integers internally, as long as values can be represented in integers.  As soon as contagion happens, the integer gets promoted to either a float or a complex as required.  You don't get to see the difference between floats and integers in use, "it just works" as Jobs would have said.

 

... double variable type  

You can build CoreBASIC with double precision types and then integers become 64 bits and floating types also.  Adding a double type means that things get a lot bigger (code and data, and complexity), and I'm not sure that I want to do that right at the moment.

[TheReelDill]

Thanks for the explanations...

[Iain]

Paul,

The SolderCore hardware team (HardCORE?) have some suggestions:

Support for mass storage on the second SPI bus, the one routed to the headers, would be nice.  I like the following syntax:

INSTALL "MASS-STORAGE-USD" AS X USING CORE.DY

Where X would be the drive letter and Y is the pin number for the CS. We could then put a uSD card into the SExI footprint and support up to 4 cards on the SenseCore. 

A time out feature when reading from sockets would be handy. An optional extra parameter could be used to specify the timeout in seconds.

INPUT #S, HEADER AS STR, TIMEOUT

Regards

Iain

[Paul Curtis]

On 6 Nov 2012, at 19:10, Iain <iain.de...@gmail.com> wrote:

Paul,

The SolderCore hardware team (HardCORE?) have some suggestions:

The quality of these suggestions will be judged and marks awarded.

Support for mass storage on the second SPI bus, the one routed to the headers, would be nice.  I like the following syntax:

INSTALL "MASS-STORAGE-USD" AS X USING CORE.DY

Where X would be the drive letter and Y is the pin number for the CS.

Do hardware engineers read software documents?  No.  ;-)

Did I not say how you would specify the second SPI bus in an earlier post?  Oh yes, I did.

At present a number of shields have undocumented behaviour that allows additional micro SD cards to be added.

My current line of attack is:

INSTALL "MASS-STORAGE-VOLUME DEV=/d" USING CORE.SPI(1), CORE.D22

This mounts a mass storage volume, names it /d, tells the driver to use the internal SPI bus, and uses CORE.D22 as a select.

6/10

We could then put a uSD card into the SExI footprint and support up to 4 cards on the SenseCore. 

INSTALL "SENSECORE" AS SENSE

INSTALL "MASS-STORAGE-SD DEV=/a" USING CORE.SPI(0), SENSE.A

The second install explicitly states we would use the SPI bus routed to the Arduino headers.  CORE.SPI(0), by definition, returns the SPI bus running to the headers, as it does on the Freedom Board.  SENSE.A uses the Site A device select as the SD select.

My long-term aim is to compete the soft UART, soft SPI, and soft I2C drivers.  (Ok, the UART and I2C drivers are written, but you know, time required to wire them into CoreBASIC.)  As such, any set of GPIOs could be turned into an SPI bus:

INSTALL "SOFT-SPI" USING CORE.D0, CORE.D1, CORE.D2  ' SCK, MOSI, MISO

If you only needed to send data on MOSI:

INSTALL "SOFT-SPI" USING CORE.D0, CORE.D1, CORE.NULL

One thing that you need to watch for is that after installation of the mass storage driver, editing your program will cause the /d device (for instance) to disappear all non-fixed drivers are finalised.

Note that if you have four SD file systems mounted, there will be an additional memory requirement for the management data as well...

7/10

A time out feature when reading from sockets would be handy. An optional extra parameter could be used to specify the timeout in seconds.

INPUT #S, HEADER AS STR, TIMEOUT

Yes, the syntax for this would need some modification.  The timeout must come before the thing to input…

INPUT #S; WAIT 10; HEADER AS STR

This inputs from stream (socket) S, specifies a maximum wait of 10 seconds, and then inputs a string to HEADER.

I am not keen on adding more keywords because that trips up CoreBASIC users.  However, there is a plethora of keywords in CoreBASIC (properties are no problem), and it's quite common to say (for instance)

DATA = "Hello"

Of course, this is an error.  Keeping the keyword space to a minimum is a good idea, hence the reuse of WAIT.  Again, I'm not sure whether WAIT or PAUSE would be more appropriate.

Artistic merit: 7/10, Execution: 3/10

Feel free to mark my modest hardware suggestions...

-- Paul.

[Iain]

On Tuesday, November 6, 2012 8:32:19 PM UTC, Paul Curtis wrote:

On 6 Nov 2012, at 19:10, Iain <iain.de...@gmail.com> wrote:

Paul,

The SolderCore hardware team (HardCORE?) have some suggestions:

The quality of these suggestions will be judged and marks awarded.

Interesting... perhaps you should create a table. Winner after 3 months, gets a day with the you and a free device!

 

Support for mass storage on the second SPI bus, the one routed to the headers, would be nice.  I like the following syntax:

INSTALL "MASS-STORAGE-USD" AS X USING CORE.DY

Where X would be the drive letter and Y is the pin number for the CS.

Do hardware engineers read software documents?  No.  ;-)

Wow. Brave comment.

Did I not say how you would specify the second SPI bus in an earlier post?  Oh yes, I did.

The HW team are ridiculously busy. We keep our eye our for HW related issues and leave SW to you.

At present a number of shields have undocumented behaviour that allows additional micro SD cards to be added.

My current line of attack is: 

INSTALL "MASS-STORAGE-VOLUME DEV=/d" USING CORE.SPI(1), CORE.D22

This mounts a mass storage volume, names it /d, tells the driver to use the internal SPI bus, and uses CORE.D22 as a select.

6/10

Harsh!

 

We could then put a uSD card into the SExI footprint and support up to 4 cards on the SenseCore. 

INSTALL "SENSECORE" AS SENSE

INSTALL "MASS-STORAGE-SD DEV=/a" USING CORE.SPI(0), SENSE.A

The second install explicitly states we would use the SPI bus routed to the Arduino headers.  CORE.SPI(0), by definition, returns the SPI bus running to the headers, as it does on the Freedom Board.  SENSE.A uses the Site A device select as the SD select.

My long-term aim is to compete the soft UART, soft SPI, and soft I2C drivers.  (Ok, the UART and I2C drivers are written, but you know, time required to wire them into CoreBASIC.)  As such, any set of GPIOs could be turned into an SPI bus:

INSTALL "SOFT-SPI" USING CORE.D0, CORE.D1, CORE.D2  ' SCK, MOSI, MISO

If you only needed to send data on MOSI:

INSTALL "SOFT-SPI" USING CORE.D0, CORE.D1, CORE.NULL

One thing that you need to watch for is that after installation of the mass storage driver, editing your program will cause the /d device (for instance) to disappear all non-fixed drivers are finalised.

Note that if you have four SD file systems mounted, there will be an additional memory requirement for the management data as well...

7/10

A time out feature when reading from sockets would be handy. An optional extra parameter could be used to specify the timeout in seconds.

INPUT #S, HEADER AS STR, TIMEOUT

Yes, the syntax for this would need some modification.  The timeout must come before the thing to input…

INPUT #S; WAIT 10; HEADER AS STR

This inputs from stream (socket) S, specifies a maximum wait of 10 seconds, and then inputs a string to HEADER.

I am not keen on adding more keywords because that trips up CoreBASIC users.  However, there is a plethora of keywords in CoreBASIC (properties are no problem), and it's quite common to say (for instance)

DATA = "Hello"

zzZZZZ. How much more of this is there!? Surely your time would be better spent actually getting on with it. 

 

Of course, this is an error.  Keeping the keyword space to a minimum is a good idea, hence the reuse of WAIT.  Again, I'm not sure whether WAIT or PAUSE would be more appropriate.

Artistic merit: 7/10, Execution: 3/10

I want a recount!

 

Feel free to mark my modest hardware suggestions...

Hmm. As I've mentioned before choosing the colour of the solder mask is hardly a HW suggestion, certainly not one worthy of a grade...And no, you still can't have pink PCBs!

 

Kind Regards

Iain 

-- Paul.

[Paul Curtis]

On Wednesday, 7 November 2012 12:04:27 UTC, Iain wrote:

On Tuesday, November 6, 2012 8:32:19 PM UTC, Paul Curtis wrote:

The quality of these suggestions will be judged and marks awarded.

Interesting... perhaps you should create a table. Winner after 3 months, gets a day with the you and a free device!

Nobody would want a day with me, and the only thing that I dispense for free is advice.  ;-)

 

 Where X would be the drive letter and Y is the pin number for the CS.

Do hardware engineers read software documents?  No.  ;-)

Wow. Brave comment.

As there is 100 miles separating us, it is hardly brave.  :-)

 

Did I not say how you would specify the second SPI bus in an earlier post?  Oh yes, I did.

The HW team are ridiculously busy. We keep our eye our for HW related issues and leave SW to you.

The HW team have recently been empowered with software capability!

 

This mounts a mass storage volume, names it /d, tells the driver to use the internal SPI bus, and uses CORE.D22 as a select.

6/10

Harsh!

I am the Craig Revel Horwood of the SolderCore world.  :-)

 

 

I am not keen on adding more keywords because that trips up CoreBASIC users.  However, there is a plethora of keywords in CoreBASIC (properties are no problem), and it's quite common to say (for instance)

DATA = "Hello"

zzZZZZ. How much more of this is there!? Surely your time would be better spent actually getting on with it. 

 

My time is currently spent adding additional features for users.  Until there is a proven desire and capability for this, I can demote it to the end of the TODO list, or the HW team can take a stab at it!

 Of course, this is an error.  Keeping the keyword space to a minimum is a good idea, hence the reuse of WAIT.  Again, I'm not sure whether WAIT or PAUSE would be more appropriate.

Artistic merit: 7/10, Execution: 3/10

I want a recount!

Artistic merit: 5/10, Execution 2/10.

 

Feel free to mark my modest hardware suggestions...

Hmm. As I've mentioned before choosing the colour of the solder mask is hardly a HW suggestion, certainly not one worthy of a grade...And no, you still can't have pink PCBs!

The design aesthetic of the SolderCore boards is of paramount importance.  And pink is better than green PCBs any day.  My Freedom board is near pink...  I feel that a high-fashion Barbie Pink PCB would appeal to a certain demographic that is currently not catered for in the SolderCore world!

-- Paul.

[Charles Wilt]

How about a config or autoexec file to auto setup things like net.timeserver, etc? Maybe add time zone correction too.

[Paul Curtis]

Hi Charles,

There is an auto exec capability.  In fact, there are no less than three files you'll find here:

$constant

The CoreBASIC interpreter loads and runs the programs in the order

/c/sys/!network.bas

/c/sys/!boot.bas

/c/!run.bas

The first typically sets up the network for your particular situation (fixed IP/DHCP/node name).  The second does whatever else is necessary after network configuration.  The last is the user-level "autoexec" file.

These files must contain programs, not immediate-mode commands.

You can load each of these using

LOAD $NET

LOAD $BOOT

LOAD $RUN

The predefined constants $NET, $BOOT, and $RUN expand to the filenames above.

I would agree that TZ correction is something that CoreBASIC should offer.  I am thinking that you would use:

CORE.ZONE = -5  ' GMT-5

I think whole hours is good enough.

Regards,

--

Paul Curtis, Rowley Associates Ltd   http://www.rowley.co.uk

SolderCore Development Platform      http://www.soldercore.com

On 11 Nov 2012, at 23:04, Charles Wilt <charles...@gmail.com> wrote:

How about a config or autoexec file to auto setup things like net.timeserver, etc? Maybe add time zone correction too.

--
--
You received this message because you are subscribed to the Google
Groups "SolderCore" group http://groups.google.com/group/soldercore?hl=en

[Charles Wilt]

On Sunday, November 11, 2012 4:17:45 PM UTC-7, CoreBASIC Wizard wrote:

Hi Charles,

There is an auto exec capability.  In fact, there are no less than three files you'll find here:

$constant

The CoreBASIC interpreter loads and runs the programs in the order

/c/sys/!network.bas

/c/sys/!boot.bas

/c/!run.bas

The first typically sets up the network for your particular situation (fixed IP/DHCP/node name).  The second does whatever else is necessary after network configuration.  The last is the user-level "autoexec" file.

These files must contain programs, not immediate-mode commands.

You can load each of these using

LOAD $NET

LOAD $BOOT

LOAD $RUN

The predefined constants $NET, $BOOT, and $RUN expand to the filenames above.

Is that in the manual? I don't remember ever seeing those terms, but I do not have a great track record with the manual. LOL

 

I would agree that TZ correction is something that CoreBASIC should offer.  I am thinking that you would use:

CORE.ZONE = -5  ' GMT-5

I think whole hours is good enough.

 That sounds good to me. There are no fractional time zones that I know of. 

[Paul Curtis]

On 11 Nov 2012, at 23:53, Charles Wilt <charles...@gmail.com> wrote:

On Sunday, November 11, 2012 4:17:45 PM UTC-7, CoreBASIC Wizard wrote:

Hi Charles,

There is an auto exec capability.  In fact, there are no less than three files you'll find here:

$constant

The CoreBASIC interpreter loads and runs the programs in the order

/c/sys/!network.bas

/c/sys/!boot.bas

/c/!run.bas

The first typically sets up the network for your particular situation (fixed IP/DHCP/node name).  The second does whatever else is necessary after network configuration.  The last is the user-level "autoexec" file.

These files must contain programs, not immediate-mode commands.

You can load each of these using

LOAD $NET

LOAD $BOOT

LOAD $RUN

The predefined constants $NET, $BOOT, and $RUN expand to the filenames above.

Is that in the manual? I don't remember ever seeing those terms, but I do not have a great track record with the manual. LOL

The golden rule of manual writing:

Say what you're going to say.  Say it.  Then say what you said.

The constants are in the manual -- I may have elided part of the manual when editing stuff for publication.

-- Paul.

[Charles Wilt]

When I test I2C address and it is wrong it hangs. Any chance of setting a timeout that causes an error instead of a lockup?

[Paul Curtis]

Hi Charles,

 

Are you using pull-up resistors on the bus?  The bus should time out, but if SCL is detected low, that is clock stretching.  The underlying I2C code uses the I2C hardware and is interrupt driven.  I will look into adding a timeout for non-response, but see if you have pull-ups…

 

-- Paul

 

--

[Charles Wilt]

Paul,

That was it. I had removed the pull ups from my test device while using another platform.

Thought I would write a simple I2C address scanner.

   10 ' I2C address scanner

   20 ' reports only addresses that do not error

   30 CLS

   40 PRINT "Starting I2C address scan."

   50 FOR I = 1 TO 255

   60   TRY I2C I READ 1 TO X

   70   IF NOT ERROR THEN PRINT "Found address: 0x"; HEX(I)

   80 NEXT I

   90 PRINT "Done."

[Paul Curtis]

Hi Charles,

 

Good news about the pull-ups.  :-)

 

The address scanner could do with a little modification.  As the I2C statement uses an 8-bit address, what you’re really want is to step up in twos:

 

FOR I = 1 TO 255 STEP 2

 

CoreBASIC will adjust even addresses to odd addresses (lsb set) when requesting a READ anyway, so with the original code you will see two responses from the READ of the same device.

 

Secondly, address 0 is the “all stations” address, so you would need to start above that.   And some station addresses are special (to indicate 10-bit or high speed addressing), so you would want to limit the range of addresses further.

 

7-bit addresses 0000xxx and 1111xxx are reserved for these purposes; hence 8-bit addresses 0000xxxx through 1111xxxx are reserved.  So, to be completely pedantic you would need:

 

FOR I = 0x11 TO 0xEF STEP 2

 

However, very well done on the TRY!  I can see you are reading the documentation.  :-)

 

Regards,

 

-- Paul.

[Paul Curtis]

Charles,

 

You might want to output the same type of tabular form that i2ctools does, which Iain blogged about:

 

http://soldercore.com/sexi-beaglebone/

 

At some point I will find an I2C device with a 10-bit address and then will be able to write the code for it…

 

-- Paul.

[Charles Wilt]

Hello Paul,

I know I did not follow protocol and it does report read and write address which I expected but it was quick and dirty. I was testing with multiple I2c devices and just wanted to verify the base address to make sure I had not changed them.

Will change to your for loop.

I have been doing my best to follow the book. ;-) Speaking of... Is there a bit shift command? Would be handy when reading LSB and MSB's from I2c registers.

[CoreBASIC Wizard]

On Wednesday, November 14, 2012 6:01:03 PM UTC, Charles Wilt wrote:

Hello Paul,

I know I did not follow protocol and it does report read and write address which I expected but it was quick and dirty. I was testing with multiple I2c devices and just wanted to verify the base address to make sure I had not changed them.

Will change to your for loop.

I have been doing my best to follow the book. ;-) Speaking of... Is there a bit shift command? Would be handy when reading LSB and MSB's from I2c registers.

Hmm, no, didn't put that in.  Well, that's not entirely true, a previous incarnation of CoreBASIC has a BIT operator to extract bits from a value as a dyadic operator:

x BIT 4  -> extract bit 4 of x and return as 0/1

As a monadic, it would generate a bit mask from a bit number:

BIT 7 -> 128

If you think this is something useful, I can put it back into CoreBASIC.

As a guiding principle, I do not want to add a bunch of ill-thought-out design to CoreBASIC, which is why I like taking my time with ideas.

-- Paul.

[Charles Wilt]

Its not a deal breaker for me. Looking at it from an arduino user point of view, and always needing to shift 8 bits left or right, it came in handy. Simple math works too.

[CoreBASIC Wizard]

On Sunday, 11 November 2012 23:04:52 UTC, Charles Wilt wrote:

How about a config or autoexec file to auto setup things like net.timeserver, etc? Maybe add time zone correction too.

 

I thought I had written about this, and indeed, this information has been available for a some time:

 

http://www.soldercore.com/manual/corebasic_boot_sequence.htm

 

-- Paul.

[Charles Wilt]

How about some sort of file transfer like xmodem?

Being able to update programs OTA can be very useful.

[Paul Curtis]

How would you see that working?

--

Paul Curtis, Rowley Associates Ltd   http://www.rowley.co.uk

SolderCore Development Platform      http://www.soldercore.com

On 15 Nov 2012, at 19:13, Charles Wilt <charles...@gmail.com> wrote:

How about some sort of file transfer like xmodem?

Being able to update programs OTA can be very useful.

[Paul Curtis]

Just to add to that, FTP was one of the protocols that SolderCore has in it, but I didn't enable it.  With an FTP server operating, you have full access to all the files on the SolderCore.  An alternative would be to process HTTP PUT requests.

So, again, I am wondering what you have in mind.

--

Paul Curtis, Rowley Associates Ltd   http://www.rowley.co.uk

SolderCore Development Platform      http://www.soldercore.com

[Charles Wilt]

FTP would work. Would it be possible to ftp between soldercore's though?

[Paul Curtis]

That would require FTP client and FTP server.  FTP server is written, and a FTP client is usually a human-oriented experience...

--

Paul Curtis, Rowley Associates Ltd   http://www.rowley.co.uk

SolderCore Development Platform      http://www.soldercore.com

[Charles Wilt]

1 soldercore acting as FTP server. Another as client. Client could view files on server? Client can be programmed to download a file from the server?

[Paul Curtis]

There are two possibilities:

1. Do FTP server and FTP client.  FTP client is icky because the output from an FTP server is intended to be read by a human, only the data connection is machine-oriented (i.e. the transfer part).  And FTP has big troubles over gateways (because of the additional data connection requiring an IP address that may well not be public...)

2. Concoct our own file transfer protocol between SolderCores and wire it into CoreBASIC.  Thinking aloud:

REMOTE GET "core-000002:/c/log.txt" TO "/c/core2/log.txt"

REMOTE PUT "/c/core2/log.txt" TO "core-000002:/c/log.txt"

REMOTE KILL "/c/log.txt"

Now I say again, this is all thinking aloud…

Of course, you may well not want to enable remote:

REMOTE OFF

REMOTE ON

Just thinking.

--

Paul Curtis, Rowley Associates Ltd   http://www.rowley.co.uk

SolderCore Development Platform      http://www.soldercore.com

[Charles Wilt]

Making our own works too. Add one more command to check if a file exists on another core.

[robbysweden]

Support for larger SD cards. I couldnt find 2 gigs at 3 of 4 stores...  :)

[Paul Curtis]

Hi Rob,

 

This is already done—mostly.  I also want to support long file names on SD cards.

 

It seems rather perverse to store a program of, say, just a few tens of kilobytes, on a SD card that can store 4 or more gigabytes.  J

 

There won’t be support for SDXC cards (i.e. >32GB); these look like they need dedicated hardware.

 

--

Paul Curtis, Rowley Associates Ltd   http://www.rowley.co.uk

SolderCore Development Platform      http://www.soldercore.com

 

 

 

--

[Iain]

I would like support for the one wire protocol please. No particular sensors in mind, just the basics read/write functions would be nice.

Could you add support for simple tone generation using the PWM enabled pins perhaps something like:

INSTALL "TONE-GENERATOR"  using Dx as TONE1

INSTALL "TONE-GENERATOR"  using Dy as TONE2

TONE1.PLAYL(NOTE, LEN)

TONE2.PLAYL(NOTE1, LEN1)

or 

TONE1.PLAY(NOTE)

PAUSE X

TONE1.STOP

Perhaps sequences could be stored in arrays... and played at specific tempo...hmm just thinking.

Might be quite neat and would save me having to buy a MIDI module for my next blog.

As discussed b4, support for asymmetric encryption would be nice, preferably a type that doesn't fall under export regulation...does such a thing exist?

Get to it!  ;o)

Kind Regards 

Iain

[Paul Curtis]

I would like support for the one wire protocol please. No particular sensors in mind, just the basics read/write functions would be nice.

 

This is Dallas 1-wire?  That’s possible, if you have the hardware configured for it.  I think it’s a bit pants myself.

 

Could you add support for simple tone generation using the PWM enabled pins perhaps something like:

 

INSTALL "TONE-GENERATOR"  using Dx as TONE1

INSTALL "TONE-GENERATOR"  using Dy as TONE2

 

TONE1.PLAYL(NOTE, LEN)

TONE2.PLAYL(NOTE1, LEN1)

 

Hmm, simple BLEEPing.

 

or 

 

TONE1.PLAY(NOTE)

PAUSE X

TONE1.STOP

 

Perhaps sequences could be stored in arrays... and played at specific tempo...hmm just thinking.

 

There’s a rich history of BASIC commands in this area.

 

Might be quite neat and would save me having to buy a MIDI module for my next blog.

 

You don’t need to purchase a MIDI module – you can purchase a Fluxamasynth or one of the VSxxx modules which support real time MIDI.  These are amazingly inexpensive.  I would recommend that over loading me up with more software tasks.

 

As discussed b4, support for asymmetric encryption would be nice, preferably a type that doesn't fall under export regulation...does such a thing exist?

 

The basis for RSA encryption is the simple operation a^e (mod m) where m is the modulus, e is the public exponent, and a is what you ‘d like to encrypt.  Decryption uses the *same* operation, except you swap e for the private (decryption) exponent d.  The asymmetry comes from the fact that the encryption key and decryption key are different.  Typically e is a small prime, like 3, 65537.  d is much, much larger.  The security is based on the fact that it is hard to factor the modulus.

 

We have a big problem that general cryptographic mechanisms are subject to export control.  Whilst it would be rather easy to add a modular exponentiation operation to CoreBASIC, that makes it an export-controlled item as the encryption is *general* and programmable.

 

Quite why governments think that export controlling encryption products will stop nasty people having access to encryption, I have no idea.  You can download general purpose encryption/decryption off the web and run it on a GHz PC.  Or put it in an FPGA.  I don’t think a farm of SolderCores running RSA is going to worry the NSA or our government: too slow.

 

However, it is what it is, and RSA$ can be added to CoreBASIC but we would only be able to ship to places in the UK, and it would be a special build of CoreBASIC.  And you’d need to be able to generate the public and private keys, which requires a primality test, so I’m not sure such a crypto toolkit is appropriate for CoreBASIC.

[Paul Curtis]

As discussed b4, support for asymmetric encryption would be nice, preferably a type that doesn't fall under export regulation...does such a thing exist?

 

No; the UK export regulations tell you all about key lengths and the requirements placed upon you for both symmetric and asymmetric encryption.  We could export a DES-style thing, but it’s general purpose and can be converted to 3DES very easily with three applications of DES (using EDE mode) which then makes our device capable of general 3DES which is export controlled.  Hence, offering just a simple DES encrypt/decrypt functionality means that we are export controlled.

[Scott]

On Thursday, 21 June 2012 13:27:32 UTC-4, CoreBASIC Wizard wrote:

So, as the author of CoreBASIC, you have what I decided to give you.  Fantastic.  Works well for me.

Now, it's up to you to shake the tree and figure out what you want SolderCore or CoreBASIC to do for you that it doesn't do already.  Within reason, of course.

So, ideas here please...

Hi Paul & everybody,

I recently bought the SolderCore demo bundle to use for in-house testing.  I am involved in firmware development and frequently run into odd things to be measured, such as motor step pulses, analog voltages, frequencies, etc.  Your controller with CoreBASIC is a really nice fit.  But, there's a couple of features that I really need.  The ability to program pins to generate interrupts on signal transitions (with an internal 8-20 MHz timer capture) and similarly, the ability to generate *simple* output waveforms, such as controlled width pulses.

The other thing that would be great is the ability to test for operator input without stopping the running program (if there is none).

The rest of the bells and whistles are very entertaining, but not essential (yet).

Thanks for listening,
Scott