LambdaSpeak CPC Sprach-Synthesizer, Sample Player, RTC, MP3, UART Erweiterung

[TFM]

Naja, der Drucker-Port hat auch 8 Bit (D0-D6 und Strobe), aber im Falle das Lambda-Speak wäre es dann sinnvoll beispielsweise Blöcke von Daten hinzuschicken, die angeben was wie lange eingeschalten werden soll. Ja, man könnte sich sogar eine Programmier-Sprache vorstellen.

Schön wäre es in jedem Fall mal generell darzustellen wie man so Relais am besten anschließen kann. Ich habe da selber schon welche am Drucker-Port, das ist aber eher für 5 Volt zum schalten, und auch eher nach CPCAI nachgebaut.

Wie viel "Platz" wäre denn im LS RAM noch frei? Ich denke da an eine simple Sprache...

[LambdaMikel]

Aha! Und was schaltest Du so damit, mit Deinen Relais?

Gute Idee, mit der Sprache... na ein paar 100 Byte waeren schon uebrig. Muss natuerlich als Token dann im "Programm-RAM (Array)" im MCU gespeichert werden, alles andere waere ja 
Das sollte fuer einfach Programme reichen. Dann moechte man allerdings auch ne RTC haben... phhh. Wie krieg ich die denn noch eingebaut.

[LambdaMikel]

Zum Thema Bloecke schicken - waere super, insbesondere denke ich ja auch noch daran, einen non-streaming PCM Sample Player einzubauen. Workflow: PCM Bloecke sende, speicher, bei Event abspielen.

Leider habe ich dafuer nicht genuegend RAM frei. Ich werde mir jedoch mal diese SPI / I2C Serial EEPROMs ansehen. Evtl. sind die schnell genug, um PCM mit 115 kbps zu tun.

Hast Du eigentlich schon mal direkt I2C or SPI mit dem CPC gelesen / geschrieben, ist er dafuer schnell genug?

Ich denke ja auch noch an I2C / SPI header, womit man dann z.B. ein RTC-Modul anschliessen koennte, oder Temperatur-Sensor oder oder oder.... Die Kommunikation koennte mit der MCU abgewickelt werden, allerdings muesste man nach wie vor "Treiber" fuer I2C / SPI je nach Modul im CPC implementieren. Ich frage mich, wie eine deratige Schittschnelle aussehen koennte. Ideen? Es muesste sowas sein wie "I2C Block" send, "I2C BLock Receive", etc.

[TFM]

Der CPC schnell genug? Das ist der immer! Egal für was! 

SPI? Das hat doch auch dem Mini-Booster? Ich mach die Software, wenn Du da etwas brauchst.

An RAM bräuchte man nicht viel... Aufbau je zwei Bytes: Erstes Byte ist Relais-Byte, das wird ausgegeben. Zweites Byte ist Zeit-Byte. Dabei gilt folgendes 0-127 sind Sekunden, 128-255 sind Minuten. Ist die Zeit abgelaufen, dann werden die nächsten beiden Bytes ausgeführt.

Beispiel:

DB &0F,&03

DB &F0,&87

Also werden zuerst für 3 Sekunden die unteren vier Relais eingeschalten,
dann für 7 Minuten die oberen Vier.

Man kann das noch erweitern, aber auf die Art wäre in 256 Bytes ein ganzer Tag unterzubringen.

[LambdaMikel]

Gute Idee TFM... allerdings fällt mir gerade auf, dass für all die Features der LambdaSpeak dann doch etwas überladen werden würde (und PCB zu gross und zu teuer). Der LambdaSpeak 3.0 wird also nur das 12LED-BarGraph für Status-Anzeige, und 8 LEDs für output bekommen, zum Spielen. Und die 8 Output-Header für Relais, damit man dann einfach schalten kann.

Ich spiele aber mit dem Gedanken, eine weitere CPC-Erweiterung zu machen, die dann solche Features zulassen würde - den "LambdaCombinator". Der LambdaCombinator könnte dann also folgendes haben:

- 8 GPIO mit LEDs für IN and OUT (LambdaSpeak wird nur output haben)
- 8LED-Segment displays für Input / Output
- Click! board socket wie LambdaSpeak für SPI und I2C ClickBoards, 3.5 und 5 V selektierbar per Jumper
- Voltage Regulator für 3.5 V
- Interessante Click boards:

https://www.mikroe.com/click?interface*=i2c,spi&input-voltage=33v,33v-or-5v,5v

Einige! RTC, Temperature / Humidity, MP3, Displays (OLED, LED, LED Matrix, ...) 

Es wäre genial, wenn der LambdaCombinator es ermöglichen würde, dass die SPI / I2C-Steuerung für beliebige Click! Boards durch die CPC-Software gemacht würde. Ich kann ja keine Treiber für > 20 Click! boards in der ATMega-Firmware halten...

Dazu muss ich noch eine Möglichkeit einbauen, mehr (S)RAM für den ATMega bereitzustellen, sodass z.B. MP3 Files vom CPC hochgeladen werden können, die dann autark (dh, nur durch Senden eines Trigger-Signals vom CPC) von der MCU aus dem Speicher-Modul an das MP3-Module gestreamt werden.

Das wäre eine Menge Arbeit für TFM  TFM, würde Dich so ein Projekt interessieren? Wir müssten also eine Art "SPI / I2C" und "Memory Block Upload Protokoll" für beliebige Click! boards implementieren (I2C oder SPI).

[TFM]

Ok, es ist mal wieder spät, ich versuche mich kurz zum fassen. Zuerst mal will ich noch anmerken, daß das nur meine persönliche Meinung ist, und ich niemandem auf die Zehen treten will. Aber Foren sind für Missverständnisse nun mal anfällig. Also - alles nur 'persönliche Meinung' 

0.9 LambdaSpeak 8 Bit I/O: Wenn so eine 8 Bit-Ausgabe-Sprache den LS überfordert (Speichermangel etc.) denn werde ich das hald auf dem CPC programmieren. So einen sinnvollen Unfug hatte ich eh immer schon mal vor. 

1. LambdaSpeak: Es gibt nun mehr so viele Versionen, dass ich total den Überblick verliere, wenn nicht schon verloren habe. Da sollte mal eine Art "Ende" her, so dass sich die Anwender dafür entscheiden können, ohne zu denken "oh ich warte nochmal bis die Version 7.2 rauskommt". Nero kann alles, aber alles ist nicht immer Sinnvoll. Es ist schön wenn LS ganz viel kann, aber es muss ja keine Portale in die 9. Dimension öffnen können (obwohl... ;-)))

2. 8-Bit Output: Sehe ich jetzt nicht so richtig als wichtig an, da man ja das selbe bereits mit dem Druckerport des CPC machen kann, der hat genauso 8 Bit Daten auf einmal und GND, damit kann man kleine Relais ansteuern. Habe ich mir mal selber nach den CPCAI gebaut

3. LEDs: Ich liebe LEDs - vor allem wenn sie Blau sind. Aber nach einem Tag wirds nervig, wenn sie keine Funktion haben. Ob die nötig sind sei dahingestellt.

4. Neue Erweiterung: Super Coole Idee! Vor allem wenn man einen Click-Board-Port hat, oder vielleicht gleich Zwei davon (z.B. RTC und Temperatur messen?).
In jedem Fall wäre es da ganz gut erst mal rumzufragen, was denn bei den Leuten "gut ankommt". Am Ende kannst Du ja immer noch machen was Du willst. 

5. Software: Falls man vom CPC her die Firmware updaten kann ist das alles kein Problem. Einige dieser Module sind sehr interessant. Ich würde mit der Software in jedem Fall helfen.

Alles leibe Euch allen, ich bin jetzt Bett-reif und müde. Lasst uns bitte wissen wie ihr alle darüber denkt. 

[LambdaMikel]

Ok, es ist mal wieder spät, ich versuche mich kurz zum fassen. Zuerst mal will ich noch anmerken, daß das nur meine persönliche Meinung ist, und ich niemandem auf die Zehen treten will. Aber Foren sind für Missverständnisse nun mal anfällig. Also - alles nur 'persönliche Meinung' 

I wo denn, des poast schoa!

0.9 LambdaSpeak 8 Bit I/O: Wenn so eine 8 Bit-Ausgabe-Sprache den LS überfordert (Speichermangel etc.) denn werde ich das hald auf dem CPC programmieren. So einen sinnvollen Unfug hatte ich eh immer schon mal vor. 

1. LambdaSpeak: Es gibt nun mehr so viele Versionen, dass ich total den Überblick verliere, wenn nicht schon verloren habe. Da sollte mal eine Art "Ende" her, so dass sich die Anwender dafür entscheiden können, ohne zu denken "oh ich warte nochmal bis die Version 7.2 rauskommt". Nero kann alles, aber alles ist nicht immer Sinnvoll. Es ist schön wenn LS ganz viel kann, aber es muss ja keine Portale in die 9. Dimension öffnen können (obwohl... ;-)))

Na ja, dass Anwender sich nun entscheiden müssten... es gibt ja ohnehin nur eine Version zu kaufen. Und wer es jetzt noch nicht gekauft hat, wird es auch in Zukunft nicht kaufen denke ich. Insofern ist das ganze Projekt ja ohnehin mehr oder weniger geistige Onanie 

2. 8-Bit Output: Sehe ich jetzt nicht so richtig als wichtig an, da man ja das selbe bereits mit dem Druckerport des CPC machen kann, der hat genauso 8 Bit Daten auf einmal und GND, damit kann man kleine Relais ansteuern. Habe ich mir mal selber nach den CPCAI gebaut

Druckerport, stimmt schon. Aber dann muss man ein Kabel basteln und so. Das liegt vielleicht auch nicht jedem. Wenn dagegen die Header schon da sind, ist es relativ einfach, mal ein Relais anzustecken mit Dupont-Kabeln, und zudem hat man nicht so viel Angst, was am CPC kaputt zu machen. Ich weiss noch, wie nervös ich damals war, als ich das Transferkabel zwischen PC und Druckerport gebastelt habe... ich weiss gar nicht mehr, woher das kam. War das mit CPCEmu irgendwie dabei, die Bauanleitung?

3. LEDs: Ich liebe LEDs - vor allem wenn sie Blau sind. Aber nach einem Tag wirds nervig, wenn sie keine Funktion haben. Ob die nötig sind sei dahingestellt.

Die Funktion ist Visualisierung des Datenworts  Die 8Segment-LED-Bar-Module werde ich gesockelt machen. Dann kann man sie per Aufpreis mitbestellen, oder nicht. Und natürlich einfach entfernen wenn's nervt. Das 12Segment-LED-Bar-LED-Modul (verschiedenfarbige LEDs) werde ich aber fest einbauen, der LS hat ja inzwischen eine ganze Menge Modi, die durch die entsprechenden LEDs angezeigt werden.
0 = Power
1 = SSA1 Mode
2 = DKtronics Mode
3 = Native Epson
4 = Native DecTalk
5 = SPO SSA1 Mode
6 = SPO DKtronics Mode
7 = Amdrum Mode
8 = Epson Receive
9 = Epson Send
10 = SPO LRQ
11 = SPO _IRQ

Schon sinnvoll m.E. Und so ein Modul kostet nur 1.50 $...

4. Neue Erweiterung: Super Coole Idee! Vor allem wenn man einen Click-Board-Port hat, oder vielleicht gleich Zwei davon (z.B. RTC und Temperatur messen?).

2 wäre gut! Beide sollten zwischen I2C und SPI schaltbar sein, und zwischen 3.5 und 5 V.

In jedem Fall wäre es da ganz gut erst mal rumzufragen, was denn bei den Leuten "gut ankommt". Am Ende kannst Du ja immer noch machen was Du willst. 

Genau. Und das Rumfragen hatten wir ja auch alles schon 

5. Software: Falls man vom CPC her die Firmware updaten kann ist das alles kein Problem. Einige dieser Module sind sehr interessant. Ich würde mit der Software in jedem Fall helfen.

Eher nicht, da ich den Aufwand scheue. Allerdings m.E. auch nicht notwendig, wenn die I2C / SPI-Kontrolle vom CPC ausgeht! Wir müssen nur das Meta-Protokoll stabil genug implementieren. Dann braucht man keine Firmware updates mehr.

[TFM]

Wo ist der Like-Button wenn man ihn mal braucht? 

[Rennert]

Wo ist der Like-Button wenn man ihn mal braucht? 

Like 

[TFM]

Zum Thema 'Firmware vom CPC aus updaten'. Man muss das Rad ja nicht neu erfinden. Der CPC-Booster hat ja auch eine AT-Mega CPU drin. Der kann die Firmware vom CPC aus updaten und der Source-Code ist vorhanden. Das wäre doch was?
Das würde dann auch ersparen Chips als Update per Post zu verschicken. Aber natürlich weiß ich nicht wie das beim LS jetzt alles ist, ob es da zusätzliche Hindernisse gibt. Jedenfalls ist das hald so ein Gedanke. 

[LambdaMikel]

Klar, stimmt schon. Angucken kann ich mir das ja mal.
Aber jetzt kommt erstmal noch das Experiment mit dem kleinen 1024 KBit SPI-Eeprom 25LC1024, ob ich nicht doch noch PCM-Sample Playback ohne CPC-Zutun hinkriege... mal sehen.

[TFM]

Viel Glück! 

[LambdaMikel]

Gibt einen neuen Speech Chip aus China - 15$:

Kann dem Epson S1V30120 (Emic 2 und Click! Speech Board) aber nicht das Wasser reichen. Und frustrierende Doku... na, für den Spaß-Faktor werde ich dann doch lieber den Speak jet nehmen für eine Low Cost Version von LS (wenn überhaupt)

[TFM]

R2D2 meets dk'tronics! 

[LambdaMikel]

Klar, stimmt schon. Angucken kann ich mir das ja mal.
Aber jetzt kommt erstmal noch das Experiment mit dem kleinen 1024 KBit SPI-Eeprom 25LC1024, ob ich nicht doch noch PCM-Sample Playback ohne CPC-Zutun hinkriege... mal sehen.

OK, das habe ich jetzt mal gemacht... 128 KB sind jetzt fuer PCM Samples verfuegbar. Damit habe ich die Breadboard-Hardware jetzt fertig, und ich kann das Projekt endlich mal abschliessen, und ein letztes PCB fuer LS 3.0 machen.

Die Firmware hat 2 neue Modi - einen "EEPROM PCM Upload Mode", und einen "EEPROM PCM Play Mode". Das EEPROM kann maximal 256 PCM-Samples (variabler Laenge) verwalten. Der Speicher ist in 256 Seiten a 256 Bytes aufgeteilt; minimale Sample-Laenge ist 2 Seiten, maximale Sample-Laenge 256 Seiten.

Zum Hochladen wird einfach PCM Upload Mode aktiviert (Kontroll-Byte senden), dann ein Byte fuer Seitennummer (Adresse), und ein Byte fuer die Anzahl der Seiten fuer das Sample. Dann folgenden die Sample Bytes (evtl. mit 0 Bytes auffuellen fuer volle Seite).

Modus zum Abspielen wird ebenfalls durch Kontroll-Byte aktiviert, gefolgt von einem Byte fuer Abspiel-Geschwindigkeit (Byte),  Seitennummer (Byte), und Anzahl der Seiten (Byte). Abspielen kann auch durch senden einer anderen Seitennummer und Anzahl Seiten vorzeitig beendet werden, sodass "Unterbrechungsfreies" Abspielen moeglich wird.

Das SPI EEPROM ist mit 10 MhZ getaktet und schnell genug... evtl. kann ich sogar (wenn auch Mono) mehrere Samples "parallel" abspielen und mischen, sodass der Sample-Player polyphon wird. Damit koennte man einen einfachen polyphonen Synthesizer programmieren. Amdrum mischt ja ebenfalls 3 Kanaele, einfach durch PCM-Sample-Arithmetik.  Das SPI EEPROM sollte eigentlich schnell genug sein, um 3 oder 4 Kanaele zu bedienen (wenn nicht mehr).