microCore enstand während der letzten 20 Jahre bei der Realisierung
eingebetteter Systeme mit FPGAs als mein persönliches Werkzeug, um
effizienter arbeiten zu können. Nun ist es "fertig" und ich habe es auf
Github veröffentlicht:
https://github.com/microCore-VHDL
Die Dokumentation ist hier:
https://github.com/microCore-VHDL/microCore/tree/master/documents
Am besten erstmal "uCore_overview.pdf" lesen.
microCore ist aus drei Gründen ungewöhnlich:
1. Zuerst war der Assembler, nämlich die Programmiersprache Forth, und
dann erst kam die Hardware.
2. Die Datenwortbreite kann vor der Synthese beliebig eingestellt werden
zwischen 12..32 Bits. "12 Bits", weil man mindestens 4096 Instruktionen
adressieren können will. "32 Bits", weil der Crosscompiler (noch) auf
einem 32-bit System aufsetzt. Ansonsten ist die Wortbreite nur durch die
vorhandenen FPGA-Ressourcen begrenzt.
3. Der "Pause" Mechanismus, ein janusköpfiger Bruder des Interrupts:
Interrupt: Ein Ereignis hat stattgefunden, das die Software NICHT
erwartet hat.
Pause: Ein Ereignis hat NICHT stattgefunden, das die Software erwartet
hat.
Die UART in microCore löst z.B. dann eine Pause aus, wenn versucht wird,
die UART auszulesen - aber (noch) gar kein Zeichen empfangen wurde.
Normalerweise wird dann im Pause-Trap der Multitasker aufgerufen und
eine andere Task aktiviert. Oder im Trap wird sofort ein EXIT
ausgeführt, so dass der Prozessor solange auf der Stelle tritt, bis die
UART ein Zeichen empfangen hat.
schon mal sehr schön, dass der Core auf git ist zum Einsehen und Nutzen.
Die Dokumentation ist auch nicht mager.
Erster Tipp:
in fpga.vhd:156 (und nicht nur dort)
1
sema_proc:PROCESS(clk,reset)
2
BEGIN
3
IFreset='1'ANDasync_resetTHEN
4
flags(f_sema)<='0';
5
...
1. Du verwendest zwei asynchrone Resets. Dann sollten auch beide in der
sensitivity Liste auftauchen.
2. Wenn das zeitkritische Signale betrifft (d.h. eigentlich alles was
nicht auf ein GPIO rausläuft), dann sollte der Reset auf die Taktdomäne
einsynchronisiert werden. Das ist wichtig für das Place&Route.
Zur Nutzbarkeit mit forth kann ich nichts sagen. Sicherlich nicht für
jedermann. Das können andere aber besser beurteilen.
"1. Du verwendest zwei asynchrone Resets. Dann sollten auch beide in der
sensitivity Liste auftauchen."
async_reset ist eine boolsche Konstante. Der gesamte Core kann mit
synchronem oder asynchronem Reset synthetisiert werden, das hängt von
async_reset ab, das am Anfang von functions.fs definiert ist. Das ist
"conditional compilation für Arme" in VHDL ;)
"2. Wenn das zeitkritische Signale betrifft (d.h. eigentlich alles was
nicht auf ein GPIO rausläuft), dann sollte der Reset auf die Taktdomäne
einsynchronisiert werden. Das ist wichtig für das Place&Route."
Das reset in der Sensitivity List wurde in fpga.fs einsynchronisiert vom
externen reset_n. Das ist nicht nur fürs P&R wichtig, sondern auch gegen
Metastabilität gut, weil sonst ein Resetende kurz vor einer aktiven
Clockflanke das ganze System aus dem Gleis werfen kann.
>> Zur Nutzbarkeit mit forth kann ich nichts sagen. Sicherlich nicht für> jedermann. Das können andere aber besser beurteilen.
Es gibt eine recht grosse Forth-Community, insbesondere rund um die
J1-CPU.
In der Industrie gibt es zum entsprechenden Nischenmarkt allerdings
auseinanderdriftende Meinungen...
Ich persoenlich finde Stack-Maschinen wegen ihrer guten
Verifizierbarkeit und recht elegant umsetzbarer Fehler-Intoleranz sehr
interessant, muehsam ist nur, gute C-Compiler dafuer zu bauen. Leider
ist mit dem Untergang der Transputer auch sehr viel Know-How dazu
versackt, so ist das Ganze hierzulande recht unpopulaer und die
'Fachwelt' entsprechend ignorant. In den Staaten sieht's anders aus (da
ist auch die RTX-Serie von Harris noch nicht vergessen...)
Mathearsch schrieb:> Was ist ein Echtzeitprozessor?
Ein Prozessor, der deterministische Ausführungszeiten seiner
Instruktionen hat und deshalb Programme in ausrechenbarer=beweisbarer
Geschwindigkeit erledigt.
Nicht-Echtzeitprozessoren haben z.B. einen Programmcache. In
Abhängigkeit davon, ob der Cache mit dem gerade auszuführenden Code
bereits geladen ist, oder nicht, ergeben sich deshalb sehr
unterschiedliche Ausführungszeiten.
Martin S. schrieb:> .. muehsam ist nur, gute C-Compiler dafuer zu bauen.
Ein C-Compiler Prototyp für eine ältere microCore-Version wurde an der
FH Nordwestschweiz in Windisch (CH) erstellt auf der Basis von LCC. Da
musste nicht nur das uCore-Backend gebaut werden, sondern das Frontend
auch für Stackallokation umgeschrieben werden. Das Ergebnis war
ausgesprochen ermutigend, ca. 90% der lokalen Variablen konnten auf dem
Datenstack gehalten werden mit entsprechenden Stackoperationen.
Beim letzten größeren Einsatz von uCore für den MERLIN Satelliten waren
wir zu dem Schluss gekommen, dass die uCore-Programme in eingebetteten
Systemen im allgemeinen so klein sind, dass sich der ganze C-Kram nicht
lohnt. Zumal in solchen Anwendungen im allgemeinen der Sprachumfang, den
man dafür in Forth braucht, sehr übersichtlich ist. Bei MERLIN waren es
aber immerhin schon 10k Instruktionen Objektcode.
Klaus S. schrieb:> Ein C-Compiler Prototyp für eine ältere microCore-Version wurde an der> FH Nordwestschweiz in Windisch (CH) erstellt auf der Basis von LCC
Tja, der LCC...ansich koennte man mit dem intermediaeren Bytecode schon
was machen (da gibt es auch die X32 CPU). Leider ist der LCC nicht
C99-komplett und hat sich fuers taegliche Engineering nicht wirklich
behaupten koennen.
Ein GCC/LLVM sollte es schon sein.
Die einzig mir bekannte Stack-Hybride die damit vernuenftig nutzbar ist,
ist die ZPU-Architektur. Das Problem ist halt bei fast allen
Optimierern, dass sie auf Basis von Registern arbeiten und man damit den
Hybriden (Register-Fenster im Stack) eben braucht, sonst geht sehr viel
Performance floeten.
Martin S. schrieb:>> Ein GCC/LLVM sollte es schon sein.> Die einzig mir bekannte Stack-Hybride die damit vernuenftig nutzbar ist,> ist die ZPU-Architektur.
Was bitte ist die ZPU-Architektur?
> Das Problem ist halt bei fast allen> Optimierern, dass sie auf Basis von Registern arbeiten und man damit den> Hybriden (Register-Fenster im Stack) eben braucht, sonst geht sehr viel> Performance floeten.
microCore war gut als LC-C Prozessor. Der LCC hatte Forthcode erzeugt,
der dann im Crosscompiler weiter optimiert wurde. Das Frontend war die
3. Iteration in der Kunst der Stackallokation. Die Literatur dazu ist -
verglichen mit Registerallokation - SEHR übersichtlich und leider ist
von den Arbeiten an der FHNW nichts veröffentlicht worden. Den
Returnstack von uCore hatte ich mit Absicht in den Datenspeicher gelegt,
so dass da Stackframes gebaut und sowohl relativ zum Returnstack als
auch mit absoluten Adressen zugegriffen werden kann.
Von sich aus kennt uCore keine Bytes - und hier beißt es sich mit C,
während das Forth egal ist. Macht aber nichts, wenn auf Unions
verzichtet wird. Als der LCC uCore lernte, hatte ich eine
Bytedressierung parallel zur nativen Zelladressierung eingebaut. Das ist
aber aus zwei Gründen Mist:
1. Es beschränkt die Datenwortbreite auf Vielfache von 8.
2. Diese Mischform Celladressen UND Byteadressen - das will man wirklich
gar nicht.
Überhaupt Bytes: Wer die Bytes zum Hardwarestandard für Speicherbreite
erhoben hat, gehört noch nachträglich geteert und gefedert. Ja, mit den
Bytes konnte man ein paar Speicherzellen einsparen, als Speicher noch
teuer war. Funktional bringen die Bytes aber gar nichts, machen aber das
Memoryinterface zum Multiplexergrab. Und eine zusätzliche Stolperstelle
für die Software sind sie auch noch. "Alignment". uCore ist
Zelladressiert und eine Zelle ist data_word_width breit und wenn die
Zelle breiter als 8 Bits ist, dann kann man damit tatsächlich auch 8-bit
Werte verarbeiten.
Klaus S. schrieb:> https://github.com/microCore-VHDL
Das sieht, beim kurzen Blick in den Doc Folder, wirklich sehr gut aus.
Du hast da ein sehr schönes Projekt gebaut. Glückwunsch :)
Aber wenn ich die Lizenz richtig verstehe, dann darf man microCore nicht
in komerzielle Projekte einbinden?
Klaus S. schrieb:> Was bitte ist die ZPU-Architektur?
Vermutlich das: https://opencores.org/projects/zpu
/regards
Klaus S. schrieb:> Als der LCC uCore lernte, hatte ich eine> Bytedressierung parallel zur nativen Zelladressierung eingebaut. Das ist> aber aus zwei Gründen Mist:> 1. Es beschränkt die Datenwortbreite auf Vielfache von 8.> 2. Diese Mischform Celladressen UND Byteadressen - das will man wirklich> gar nicht.
Ich kenne da weitverbreitete Architekturen (Ich glaube ARM und ganz
sicher TI C2000 DSP), die das bis heute nicht eingebaut haben. Byte
access kann man machen, wird aber vom Compiler als Lesen und danach
Schieben Instruktionen umgesetzt.
Muss der Programmierer halt wissen und seine Arrays, Records etc. auf
Celladressen alignen. (Ist natürlich in C einfacher wenn das vielfache
von 8 sind).
Klaus S. schrieb:> Was bitte ist die ZPU-Architektur?
Ein langjähriges Projekt hier aus dem Mikrocontroller.net Universum:
https://www.mikrocontroller.net/articles/ZPU:_Softcore_Implementierung_auf_Spartan-3_FPGA
Klaus S. schrieb:> 3. Der "Pause" Mechanismus, ein janusköpfiger Bruder des Interrupts:> Interrupt: Ein Ereignis hat stattgefunden, das die Software NICHT> erwartet hat.> Pause: Ein Ereignis hat NICHT stattgefunden, das die Software erwartet> hat.
Gefällt mir, das mal in einer Architektur umzusetzen. Mir kommt dabei
gleich Exception Handling in den Sinn, das ja die allermeisten Embedded
Programmierer eben genau nicht nutzen dürfen, weil es so viel
zusätzlichen Bytecode produziert und das deterministische Timing kaputt
macht auf klassischen CPU Architekturen.
Klaus S. schrieb:> Überhaupt Bytes: Wer die Bytes zum Hardwarestandard für Speicherbreite> erhoben hat, gehört noch nachträglich geteert und gefedert. Ja, mit den> Bytes konnte man ein paar Speicherzellen einsparen, als Speicher noch> teuer war. Funktional bringen die Bytes aber gar nichts, machen aber das> Memoryinterface zum Multiplexergrab.
Das 'Multiplexergrab' ist Industriestandard in jedem modernen uC..
Die Frage waere dann, welcher 'groesste gemeinsame Teiler' dann als
minimal addressierbare Speichereinheit in der Praxis geeignet
waere...:-)
Ja, und irgendwie muessen die Bytes vom UART/Interface in den Speicher,
dann hat man halt die MUXer in der DMA-Peripherie, wenn man die CPU
nicht mit Bitschiebereien belasten will.
Andreas H. schrieb:> Aber wenn ich die Lizenz richtig verstehe, dann darf man microCore nicht> in komerzielle Projekte einbinden?
Jein. Entwickeln für ein kommerzielles Projekt kann man schon jetzt,
fürs Produkte verkaufen wird es eine kommerzielle Lizenz geben. In der
wird geregelt sein, dass Lizenzzahlungen fällig werden, wenn mehr als
100 Produkte produziert werden. An der Lizenz wird noch gearbeitet.
Wer sich jetzt davon abgeschreckt fühlt, sollte mir eine Mail schreiben
und dann klären wir das rechtsverbindlich.
Christoph Z. schrieb:> Mir kommt dabei> gleich Exception Handling in den Sinn, das ja die allermeisten Embedded> Programmierer eben genau nicht nutzen dürfen, weil es so viel> zusätzlichen Bytecode produziert und das deterministische Timing kaputt> macht auf klassischen CPU Architekturen.
So ungefähr vor 15 Jahren habe ich den Pausemechanismus eingebaut und
dann wußte ich natürlich erstmal nicht, was ich damit anfangen kann -
außer zu warten, solange ein Device nicht bereit ist.
Heute weiß ich, dass man dank Pause die gesamte Resourcenverwaltung an
die Hardware delegieren kann. Inklusive MUTEX (MUTual EXclusion).
Nehmen wir mal den ADC128S102, ein ADC mit SPI-Interface und
vorgelagertem 8-Kanal MUX. Den kann man in einem Multitaskingsystem in
uForth so ansprechen:
1
<kanalnummer> ADC ! ADC @ Sample !
2
3
das wäre in C:
4
5
ADC = <kanalnummer>; Sample = ADC;
Fertig. Das ! (store) der Kanalnummer kann man erst machen, wenn kein
anderer Prozess den ADC beschäftigt, und das @ (fetch) kann man erst
machen, wenn der ADC fertig ist. Ansonsten ist Pause. Und die Pause Trap
ruft den Scheduler auf, der nicht - wie noch beim Transputer - in einem
ROM liegt, sonder frei programmierbar ist.
Damit kommt eine fehlerträchtige Aufgabe der Software, nämlich die
Resourcenverwaltung, gar nicht erst vor. Aber Deadlocks kann es leider
immer noch geben.
Martin S. schrieb:> Ja, und irgendwie muessen die Bytes vom UART/Interface in den Speicher,> dann hat man halt die MUXer in der DMA-Peripherie, wenn man die CPU> nicht mit Bitschiebereien belasten will.
Gar nicht nötig. Solange die data_word_width > 8 ist (was sie immer sein
wird, weil man sonst nur 128 Programmadressen hätte), kann man in jeder
Zelle natürlich nur jeweils ein Byte speichern. Und wenn es aus
irgendwelchen Gründen sein muss, kann man mit den Bibliotheksfunktionen
pack/unpack komprimieren. Wenn ein Hardwaremultiplier im FPGA ist,
kostet ein Barrelshift 2 Zyklen.
Und DMA braucht man eigentlich auch nicht, weil in einer
Stackarchitektur im Interrupt sofort losgearbeitet werden kann - ist
sowieso schon alles auf Stacks. Und der Multitasker hat keine Sequenzen,
in denen Interrupts ausgeschaltet sind, so dass die Interrupt Trap nach
spätestens 3 Zyklen angesprungen wird.
Als Performancebeispiel: Mein letztes Projekt war die
Frequency-Reference-Unit für den Merlin Satelliten. (Konditionierung von
drei Halbleiter-Infrarotlasern auf 5 MHz genau). Das gesamte System ist
im Prinzip eine SPS mit 5 Regelschleifen, die alle 50 msec abgearbeitet
werden. Nur die Peripherieinterfaces und das Wavemeter sind in VHDL, der
Rest ist Software mit 5 Tasks. Trotzdem hatte das Gesamtsystem nur einen
Jitter < 1 msec.
Klaus S. schrieb:> An der Lizenz wird noch gearbeitet.
Dann lass es uns mal wissen wenn Du soweit bist.
Bei uns wollen die BLs ja immer wissen wenn sie verklagen können wenn
was schiefgeht ;)
/regards
Andreas H. schrieb:>> An der Lizenz wird noch gearbeitet.>> Dann lass es uns mal wissen wenn Du soweit bist.
Es ist nicht einfach. Deshalb werde ich meine Gedanken dazu darlegen und
hoffe, dass eure Antworten mir mehr Klarheit bringen. Vorweg: Ich habe
mich von dem Gedanken verabschiedet, das Produkte lizenzpflichtig sein
sollen. microCore wird freie Firmware sein, so wie Linux oder GCC freie
Software sind.
1. Jeder Ingenieur will alles Mögliche machen, aber eines nicht: Den
Assembler NOCH eines weiteren Prozessors lernen müssen. Deshalb wird
niemand, der nicht bereits durch seine Nutzung süchtig danach geworden
ist (insbesondere beim Hardware Debuggen), microCore IP kaufen. Also
kann ich es ebensogut verschenken.
2. Das kann aber zu einem Problem führen: Wenn jemand microCore
erstmalig einsetzt, dann gibt es meist Beratungsbedarf. Das ist
einerseits schön, weil es für mich Beratungsbusiness bedeutet. Aber wenn
microCore SEHR erfolgreich ist, dann kann ich den Beratungsbedarf
alleine nicht mehr leisten - und das hemmt die weitere Verbreitung.
3. Deshalb ist vor einigen Jahren in dem EU-Projekt ASSISTEC, das sich
um IP-Vermarktung drehte, das Konzept entstanden, zunächst für ca. zwei
Jahre nur eine "Exploratory License" anzubieten mit freier Nutzung für
R&D, Forschungsinstitute und Universitäten. Und erst danach die "Public
License", die die freie kommerzielle Nutzung erlaubt, wenn ein
entsprechender know-how Pool entstanden ist.
4. In jedem Fall jedoch behalte ich mir das Recht vor, eine Prüfinstanz
zu zertifizieren, die berechtigt ist, Implementationen von microCore die
Konformität zum "ursprünglichen Modell" zu bescheinigen. Nur so kann
sich ein Markt für microCore Softwarepakete entwickeln. Das führt dazu,
dass die Weiterentwicklungen von microCore IMMER sourcecodekompatibel
sein werden, was für mindestens die letzten 5 Jahre bereits zutrifft.
5. Aus den Reaktionen in diesem Thread ist deutlich geworden, dass bei
der Exploratory License die Akzeptanz verhalten ist und es zumindest in
der Industrie keine Design-ins geben wird.
Soweit die Faktenlage.
Einerseits hätte ich die Möglichkeit, microCore sofort unter die Public
License zu stellen mit dem Problem der Beratungsüberforderung.
Andererseits könnte ich zunächst die Phase der Exploratory License
beibehalten, aber auf Anfrage Firmen, die damit in die
Produktentwicklung einsteigen wollen, eine individuellen Lizenz zur
freien Nutzung erteilen, wenn die Beratungssituation klar ist. Das hat
jedoch den Nachteil, dass für jede individuelle Lizenz die
Geschäftsleitung eingeschaltet werden muss.
Soweit sind meine Überlegungen gediehen und ich bitte um Feedback.
Klaus S. schrieb:> Einerseits hätte ich die Möglichkeit, microCore sofort unter die Public> License zu stellen mit dem Problem der Beratungsüberforderung.
Wenn ich mir den Traffic auf der ZPU-Mailingliste so anschaue, glaube
ich nicht, das dir sofort nach Veröffentlichung die Bude eingerannt
wird.
Und wenn ich von mir ausgehe: da muß erstmal ein neues Projekt gestartet
werden, in dessen Rahmen man sich den microCore evtl. mal mit anschaut
und evaluiert.
Da Hardwareprojekte eher Langläufer sind, kommt das nicht so häufig vor.
Duke
Mit den Lizenzen wuerde ich mir ja erst die Arbeit machen, wenn jemand
explizites und serioeses Interesse an deiner Nischenloesung als
Werkzeug anmeldet. Oder deine OpenSource mit einer anderen Lizenz
kompatibel sein muss.
Nach meiner Erfahrung kupfern sich die grossen Buden pfiffige Konzepte
einfach ab und scheren sich Null um Lizenzbedingungen. Mit Tools kann
man nur noch mit viel Glueck Geld verdienen.
Und NB: Der Markt ist ziemlich gesaettigt, die Softwerker unter den
Ingenieuren lernen zwar schon noch eine neue ASM-Syntax fuer die 'inner
loops', aber wollen auch gcc-Port, Eclipse und Debugger fuer umme, plus
die kostenlose Support-Community a la Linux.
ZPU ist ne gute Messlatte, und auch da broeckelt es, kaum einer will da
noch die Tools fuer die Community gratis unterhalten. Bei RISC-V geht
das Community-Moment gegen ideal, gegen die Stroemung kann man wirklich
nur noch mit harten Alleinstellungsmerkmalen anschwimmen. Mit
Forth-Prozessoren ist man da schon in einer ganz anderen Nische.
Klaus S. schrieb:> Soweit sind meine Überlegungen gediehen und ich bitte um Feedback.
Hallo Klaus
Schön das es so schnell weiter geht.
> Vorweg: Ich habe> mich von dem Gedanken verabschiedet, das Produkte lizenzpflichtig sein> sollen. microCore wird freie Firmware sein, so wie Linux oder GCC freie> Software sind.
Selbst hier liegt, für gewerbliche Nutzung, der Teufel im Detail.
Programme die unter Linux laufen sind nicht notwendigerweise GPL
lizensiert.
Mit dem GCC compilierte Programme fallen z.B. NICHT automatisch unter
die GPL (oder irgend eine andere vorgegebene Lizenz).
Wäre z.B. das GCC Kompilat auch unter GPL, dann müsste man ja dem Kunden
die kompletten Quellen zur Verfügung stellen. Oft steckt hier aber viel
Firmen-knowhow drin was man nicht so "preiswert" verschenken kann.
Noch schwieriger wäre hier die Verwendung zugekaufter Libraries für die
man die Rechte zur Weitergabe typischerweise nicht hat.
> 1. Jeder Ingenieur will alles Mögliche machen, aber eines nicht: Den> Assembler NOCH eines weiteren Prozessors lernen müssen. Deshalb wird> niemand, der nicht bereits durch seine Nutzung süchtig danach geworden> ist (insbesondere beim Hardware Debuggen), microCore IP kaufen.
Da kann ich nicht zustimmen. Viele Entwickler haben kein Problem damit
sich in Neues einzuarbeiten. Das ist doch eigentlich "Part of the job".
Ich sehe da eher Ein ganz anderes Problem.
Die Vorteile dieser Art der Entwicklung ist heute nicht mehr sehr
verbreitet und braucht darum eine gewisse Neugier um damit anzufangen.
Mein AIM-65 hat noch ein Forth-ROM - wieviele Jahre ist das her^^. Aber
ein eForth kann man heutzutage genau so wenig unter Windows kompilieren
wie Manfred Mahlows e4thcom. Und leider ist Linux in Konzernen immer
noch nicht so verbreitet wie Windows.
WENN man das am laufen hat, dann ist es eine so hocheffektive
Entwicklungsumgebung das Vielen erst mal die Luft wegbleibt.
Aber selbst dann muss man sich an diese Art des Entwicklens reinfinden.
Man liest heute eher Gamma's "Design Patterns" oder Uncle Bobs "Clean
Code". Wer kennt denn noch Moore's "Programming a problem oriented
Language" oder Leo Brody's "Thinking Forth"?
> 5. Aus den Reaktionen in diesem Thread ist deutlich geworden, dass bei> der Exploratory License die Akzeptanz verhalten ist und es zumindest in> der Industrie keine Design-ins geben wird.
Das ist aber verständlich, oder?
Zum einen: siehe oben.
Zum Anderen: Was nützt eine Lizenz die einen dermassen einschränkt?
Seit einiger Zeit kriegt man FPGAs mit ARM8 SOCs, bzw. cortex-M0
Softcore. Oder RISC-V socs (MicroSemi). Die kann ich problemlos auch
gewerblich einsetzen. Und die Leute kennen sich damit, bzw. mit der Art
der Entwicklung, aus.
Nur um das Problem zu verdeutlichen: Ich kann ein Tool mit z.B.
VS-Community schreiben. In der Firma darf ich das nicht benutzen, weil
da die Lizenzbedingungen nicht passen. Ich müsste also erst mal eine
Lizenz durchfechten - Odd job :/
Mache ich das gleich mit dem GCC habe ich da kein Problem.
Bei Deinem aktuellen Ansatz geht nur ein bisschen basteln zu Hause weil
die Kosten, if any, komplett intransparent sind (nicht böse gemaint. Nur
eine Beobachtung).
Es gibt einen Bedarf für solche Lösungen. Siehe z.B. Arduino. Den sehe
ich sehr oft in irgendwelchen Laboraufbauten bei uns. ABER: da ist die
Enstiegshürde selbst für Hobbyisten fast Null.
Finde den Unterschied ;)
Grüße
Andreas
P.S: Trotzem ein tolles Projekt. Mach weiter
A.
Andreas H. schrieb:>> Vorweg: Ich habe>> mich von dem Gedanken verabschiedet, das Produkte lizenzpflichtig sein>> sollen. microCore wird freie Firmware sein, so wie Linux oder GCC freie>> Software sind.>> Selbst hier liegt, für gewerbliche Nutzung, der Teufel im Detail.> Programme die unter Linux laufen sind nicht notwendigerweise GPL> lizensiert.> Mit dem GCC compilierte Programme fallen z.B. NICHT automatisch unter> die GPL (oder irgend eine andere vorgegebene Lizenz).
Oh Missverständnis! Ich hab's aber auch falsch ausgedrückt.
Ich wollte sagen:
microCore wird freie Firmware sein, im Prinzipe so, wie TCP/IP unter BSD
freie Software ist. In GNU-speak wäre das wohl die LGPL. Jedenfalls
dürfen meinetwegen Nutzer von microCore alles geheimhalten inklusive der
Tatsache, dass sie es nutzen. Mir geht es darum, jegliches
Verbreitungshindernis zu vermeiden. Aber ich will - wie ausgeführt -
auch nicht von Beratungsanforderungen überfordert werden.
Wenn es ein microCore-PCB mit den typischen Arduinofeatures gäbe, also
-FPGA bereits fertig programmiert (schlüsselfertig)
-ADC, ca 10 bit, 10kS/s, 4 Kanäle
-ca 32k RAM/ROM
-ca 10 I/O auf 3.3V oder 5V
-ca. 2x PWM, 2x SPI, 2x I2C
-(special) 2x EXCEPTION/PAUSE-Eingänge, 2x Interrupt-Ein.
-Spannungsversorgung und Programmierung über USB (FTDI)
(in dem Fall natürlich on-line auf dem Forthsystem direkt)
für 30-50€ ca
dann würde ich das ohne Bedenken bei kleinen Projekten die schnell gehen
sollen einsetzen
Ich würde also statt Arduino den microCore bevorzugen. Der Schlüssel
ist, es muss genauso einfach und schnell gehen, mit guter
Dokumentation..
Terminalprogramm starten, einstecken und loslegen
Ich denke da gerne an das alte Quickbasic zurück, das hatte all das und
noch mehr, perfekt für kleine schnelle Projekte die auch noch Spaß
machten
Und da könnte ich mir durchaus vorstellen dass sich da ein neuer
Forth-Enthusiasmus entwickeln könnte bei so manchem
Das Beraten müsste man aber outsourcen irgendwie;)
Also Community ist das Zauberwort
eine faq könnte es ja geben, ein Wiki oder so etwas
Also nur meine Idee dazu...
Und bedenke, das ist genau die Schnittstelle zwischen Hobby- und
Produktiveinsatz, welche zu großer Verbreitung des microCore führen
könnte
Für das board käme zB der ICE40 von lattice in Frage um den es sowieso
schon eine gewisse Community gibt
Natürlich bleibt der microCore damit weit hinter seinen Fähigkeiten
zurück aber parallel dazu kann er ja selbstredend auf großen FPGAs auch
zum Einsatz kommen...
Klakx schrieb:> sema_proc : PROCESS (clk, reset)> BEGIN> IF reset = '1' AND async_reset THEN> flags(f_sema) <= '0';
Deine Begründung mag stimmen, es bleibt aber dabei dass es nicht
vernünftig simulierbar ist.
Ich würde das erstmal entschlacken.
>> Deine Begründung mag stimmen, es bleibt aber dabei dass es nicht> vernünftig simulierbar ist.> Ich würde das erstmal entschlacken.
Mit welchem Simulator hast Du es denn versucht? ModelSim hat damit
jedenfalls keine Schwierigkeiten.
Die Wahlmöglichkeit (synchroner/asynchroner Reset) habe ich deshalb
eingebaut, weil sich in der Raumfahrtcommunity ein fast religiöser
Streit entwickelt hat, was zuverlässiger ist. Hier der vollständige Code
fürs bessere Verständnis:
1
sema_proc:PROCESS(clk,reset)
2
BEGIN
3
IFreset='1'ANDasync_resetTHEN
4
flags(f_sema)<='0';
5
ELSIFrising_edge(clk)THEN
6
....Code,wennkeinresetaktivist...
7
IFreset='1'ANDNOTasync_resetTHEN
8
flags(f_sema)<='0';
9
ENDIF;
10
ENDIF;
11
ENDPROCESSsema_proc;
Die Lösung in diesem Streit besteht übrigens darin, dass die Pintreiber
mit asynchronem Reset in safe states gesetzt werden und die interne
Logik ein synchrones Reset bekommt. Das war den Protagonisten aber
bisher noch nicht aufgefallen. Es wird eben auch da mit Wasser gekocht
;)
blub schrieb:> Wenn es ein microCore-PCB mit den typischen Arduinofeatures gäbe, also
Schöne Idee. Das kann gerne jemand machen, ich würde helfen, microCore
entsprechend zu konfigurieren.
Ich habe aber prinzipiell Bauchschmerzen, die verschiedenen
Schnittstelle wie Peripheriechips mit diversesten
Konfigurationsmöglichkeiten anzubieten. Das ist doch der Witz an VHDL,
dass die Interfaces genau so gemacht werden, wie sie tatsächlich im
Projekt gebraucht werden.
Klaus S. schrieb:> Das ist doch der Witz an VHDL, dass die Interfaces genau so gemacht> werden, wie sie tatsächlich im Projekt gebraucht werden.
Da stimme ich Dir zu. Es kann ja, wer erstmal ,,angefixt" ist, tiefer
einsteigen, sich dran machen den FPGA selbst zu programmieren, diese
oder jene Schnittstelle hinzuzufügen.
Das schöne ist daß es durchgängig vom Hobbyisten (kauft fertige Platine,
programmiert im Terminal) über den Intermediären User (Abwandlung der
Peripherie, Erweiterungen an der Hardware) bis hin zum professionellen
Einsatz (großes FPGA Projekt, microCore mit erweitertem Befehlssatz) was
gibt.
Über das forth als Abstraktionsschicht ist der Code portabel auf
verschiedensten Konfigurationen lauffähig was die Kultur des
Programme-Austauschens beflügeln könnte und bei vielen Nutzern Anklang
finden würde.
microCore ist sozusagen das Bindeglied dazwischen und eine ,,Marke"
(vergleiche ,,Arduino")
blub schrieb:> -FPGA bereits fertig programmiert (schlüsselfertig)> -ADC, ca 10 bit, 10kS/s, 4 Kanäle> -ca 32k RAM/ROM> -ca 10 I/O auf 3.3V oder 5V> -ca. 2x PWM, 2x SPI, 2x I2C> -(special) 2x EXCEPTION/PAUSE-Eingänge, 2x Interrupt-Ein.> -Spannungsversorgung und Programmierung über USB (FTDI)
100baseT Interface
Heilandszack. Nun bin ich doch angefixt. Ich brauche nämlich ein Testbed
für UDP, weil ich microCore IoT-fähig machen will.
Aber ICE40 hat mir zu wenig internes RAM und das BGA-Zeugs ist schlecht
fürs Prototyping. Gibt's nicht was ähnlich stromschlankes mit mehr RAM
und PQFP-Gehäuse? Microsemi? - Da ist aber die P&R Suite ätzend langsam,
aber die statische Timinganalyse ist das Beste, was ich je gesehen habe.
Sollten wir vielleicht einen separaten Diskussionsthread für das Board
machen?
Klaus S. schrieb:> PQFP-Gehäuse? Microsemi
Ich hab mich mal ein bisschen dort umgesehen,
es gibt den M2GL010-TQG144I.
IGLOO2, 84 I/O, 933.888 kbit RAM, 12.084 LUTs im 144-LQFP-Gehäuse
Klaus S. schrieb:> 100baseT
ja!
Betr. Board: Auf Spartan6-LX9@TQFP144 hab ich mal fuer div.
IoF-Anforderungen das hier angeschmissen:
https://hackaday.io/project/162259-netpp-node
Ueber den 'goldenen' Bootloader kann man sich eigene Firmware per
Ethernet oder roh per USB-JTAG draufspielen.
blub schrieb:> Ich hab mich mal ein bisschen dort umgesehen,> es gibt den M2GL010-TQG144I.> IGLOO2, 84 I/O, 933.888 kbit RAM, 12.084 LUTs im 144-LQFP-Gehäuse
Ich habe mal Synthese und Place&Route gemacht und die Ergebnisse sind
erfreulich:
16-bit Datenwortbreite:
16k Datenspeicher, 8k Programmspeicher
30% der LUTs, clock 45 MHz.
32-bit Datenwortbreite:
4k Datenspeicher, 16k Programmspeicher
40& der LUTs, clock 30 MHz.
Der IGLOO2-FPGA ist mir aus zwei Gründen lieb:
1. Sehr geringer Stromverbrauch, (Ich habe jahrelang Geräte gebaut, die
bis zu einem Jahr auf dem Meeresgrund lagen und aus Batterien versorgt
wurden.)
2. Die Konfiguration ist direkt durch Flashzellen definiert und damit
ist der Chip sofort nach dem Einschalten betriebsbereit.
Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.
Wichtige Regeln - erst lesen, dann posten!
Groß- und Kleinschreibung verwenden
Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang
Announcement: there is an English version of this forum on 
Thread beobachten
Seitenaufteilung abschalten